Unanswered

Multiple developers sharing work on multiple Solutions using ALM Azure pipelines

(1) Share

Report

Posted on by jdfeemster

My organization's tenant has four developers working on five solutions using the Azure pipelines. We have a Production and a Test environment where we import the solutions for the user base to access. Each solution has it's own git repository. We coordinate solution updates when two or more developers are working on the same solution in their respective developer environments in order to avoid collisions. We are experiencing frequent pipeline failures in the pipeline Import steps. Most are due to Dataverse entity schema changes while modifying the solutions. Attempting to move the entity schema(s) between developer environments by embedding them in simple solutions (holding only data table schemas) and then exporting/importing that solution has been very unreliable lately. Currently the only reliable success path seems to be that a solution can only be modified (especially when that solution change involves an entity schema modification) by one developer in their dev environment, pushed up to the repo, pulled down and exported to Test or Production - rather than be shared in any manner. Pulling solution sources from the repo into the dev environment via the pipelines does not address/resolve entity schema changes. I am beginning to think the current approach does not work well for multiple developers and that I need to reconsider a Teams Dataverse approach. That is to say multiple developers using a shared Dataverse database. Any insight on how other community members who work with multiple developers on multiple solutions would be appreciated.

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (7)

Answers (1)

Verified answer

EricRegnier 8,720 Most Valuable Professional on at

Like (2)

Report
Hi @jdfeemster,

Great question and I have a similar situation with 40+ developers. We follow a "Git is the source-of-truth" strategy and pretty much the same ALM process as traditional coding with feature branching. In short the overall process is:

Developers perform their changes in their own developer environment (env) or sometimes in a shared dev env. They create their dev from a clone or sometimes install a solution version from git (#4 below) into a vanilla env.

They create a feature branch off of main/master and once ready to commit/deploy, they unpack the solution from their env. We use the sync command from the pac cmdlets to unpakc which makes life easier. They then review and commit their changes to the feature branch and submit a PR to main.

When main is updated, a pipeline triggers to generate the solution off of the main branch. We use the pack task from the ADO Power Platform build tools.

Solution is now a build artifact and deployed to the target environments, using the ADO Power Platform build tools.

There's lots more happening within these steps, but that's the gist of it. Sometimes we get into situation where the solution is invalid when we try to import to the target env, but that's usually a developer error where they forgot to include something or included something they shouldn't have as part of their commit. The PR process helps to mitigiate this.

Hope this helps a little!

Was this reply helpful? Yes No
jdfeemster 10 on at

Like (0)

Report

We do have the Azure pipelines working for most solutions. The specific problem we are encountering now is that for one solution, the Power Platform Import step is throwing an obscure error and failing to import the packed and checked application. The really odd thing is that only one of the developer environments can successfully export/import this solution - the one that last modified it. The rest of the developer environments cannot when using Azure pipelines. The reported reason given is: "AttributeId is null." I was unable to find any significant differences between that developer environment and the other developer environments. While attempting to find more detail associated with the ALM error, I was able to find the following at one point, but am unable to directly associate it with any specific solution entity:
"Customization.Tab_Solution"
"Customization.Sol_Message" <Cell ss:StyleID="s137"> <Data ss:Type="String">AttributeId is null</Data>
"Entity Relationships" <Cell ss:StyleID="s137" name="ErrorText">
Based on the reference to entity relationships, I did inspect the solutions 28 entities and their Relationships advanced options settings expecting to find an unspecified field. In fact there were several for both the one-to-many and many-to-one links associated with the Delete attribute but I could not discern any pattern that would flag an anomaly.

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report

Hi @jdfeemster,
I would suggest starting a new thread for that specific issue since it doesn't really related to the initial one, but most likely the issue is because of different version/solutions/differences between the environments. Ensure there are all in sync such as: Release Wave Updates are both on/off, service/client versions are the same (see image below), out-of-the-box (1st party) solutions/add-ons are the same version (see 2nd image below). The other thing to check if there are language packs installed and ensure the exists in all envs. If that's no luck, than perhaps opening a Micrsoft Support ticket to get more insights from their telemetry.

Hope this helps!

Was this reply helpful? Yes No
YaroslavSolAlc 2 on at

Like (0)

Report

Hi Eric, as I understand, after PR is merged into master branch build creates only one solution that contains all the artifacts and then this one huge solution is imported to, let's say, test env.
My question what if I have 7 different solutions on dev, test, prod env and I want to export/import these solutions to test env from dev not all. but for example, in the current sprint I want to move only solution 1 and solution 3. These solutions can contain the same js web resource. How would you automate such example? Thank you in advance.

Was this reply helpful? Yes No
EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report

Hi @YaroslavSolAlc, I wouldn't recommend having different solutions having the same objects like JS. You'll need to have a solution layering strategy. See this for more info: https://learn.microsoft.com/power-apps/maker/data-platform/solution-layers?WT.mc_id=DX-MVP-5004271
Also, quick tips: try to have the least number of solutions possible, always use same publisher and have one dev env per produced managed solution.

Hope this helps!

Was this reply helpful? Yes No
Suggested answer

kalluu91 39 on at

Like (0)

Report

In my project (having 4 developers working), I have structure the code and team as following to avoid conflicts:

- All is working on the same DEV environment

- Customizations (forms, fields, views): avoid assigning them on the same component to avoid conflicts

- Plugins: create a DEV plugin dll per developer + 1 main plugin dll for actual plugin, see details here https://kalcancode.wordpress.com/2025/02/14/power-apps-development-lifecycle-for-a-team-part-1/

- JS (web resources): use Fiddler, see details here https://kalcancode.wordpress.com/2025/02/15/power-apps-development-lifecycle-for-a-team-part-2/

Was this reply helpful? Yes No
GarethDoherty 20 on at

Like (0)

Report

@EricRegnier I was wondering if you had a blog post at all which went into more detail about you ALM setup which would answered this post with.

We need to change our whole ALM strategy as the current one is very manual and want it more automated in ADO Pipelines etc. We have a very large complex MDA which is split into 4 base solutions, each with 1000+ components in them.

I want to use the Git is the source-of-truth approach, with 10+ development environments that all need to feed into a single release pipeline. I am struggling with how to create a new solution, with only the change components from the previously merged PR, and then deploy that to the Validation environment.

I can't see to figure out the "give me all the files that have changed since the last time the pipeline ran" part, to then create and add them to a new solution. All dynamically without any user input.

EDIT: we are using unmanaged solutions all the way through to production.

Was this reply helpful? Yes No