Collaborative development in Dataverse

[akatakkar]

Is there a recommended approach for multiple users working on a model driven app? More specifically, is there any way to know if someone else is modifying the same dataverse table form that you are working on, within the same solution? Is there a workflow where developers can collaborate through the creation of individual / feature based solutions (similar to a feature or defect fix branch in a code repository) , that can then be merged into a shared solution?

Thank you!

[Devvj]

Hi @akatakkar 

There are tools like the ALM Accelerator which have some advanced features around branching and ALM in general, it is fairly powerful if utilized correctly, but it is pretty advanced.

Anyway, if you want to take a look there is some information on the branching part here:
Branching and environment strategy - Power Platform | Microsoft Learn

Hope that helps!

[EricRegnier]

Hi @akatakkar,

There's not an approach that fits all, but there's definitely some guidelines and best practices. I'm working in large scale implementation in teams of over 40 developers working on the same Dataverse instance and model-driven apps so the platform can definitively support it and has been enterprise scale for a while. Suggest taking the time to go through the official ALM documentation: https://learn.microsoft.com/power-platform/alm and get familiar with some the concepts:

• Environment strategy
• Solutions and solution layers
• Source control and unpacking solution - the best approach is to follow the principle that your source control is the source of truth for your configurations (e.g. tables) and customizations (e.g. JavaScript and code).

 In short, the overall process is:

1. 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.
2. 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 unpack which makes life easier.  They then review and commit their changes to the feature branch and submit a PR to main.
3. 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.
4. 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.

Hope this helps a little!

[cchannon]

Echo everything @EricRegnier says there. The platform absolutely supports enterprise scale development; I've run teams of similar scale myself.

The question is not whether the platform can do it, but whether your practices can. No matter the platform and no matter the ALM strategy, if you have devs failing to coordinate and fighting each other's work, the whole machine will grind to a halt.

[ChrisPiasecki]

I'm going to go against the grain here and push back against @EricRegnier and @cchannon's comments.

ALM is one of the most difficult parts and pain points of the platform when large team or parallel team development is involved.

Unless your team is very disciplined and avoids working on the same components, and syncs developer environments after every PR, be prepared to spend a lot of time dealing with solution merging conflicts. This is especially true when you have separate developer instances and are working with existing components. If you work in a single shared environment, you will spend a lot of time bringing over unfinished features to a build environment to clean them out manually and removing dependencies (unless you decide to try and follow a, feature flag development approach) . If you're touching the same components, expect forms, views, ribbon customizations, entity metadata, model driven apps, and other components to get overwritten by each others changes. 

Another issue is the unpacked components are mostly XML, which isn't very git friendly and sometimes the git algorithm does not always automatically merge the way you expect, so manual intervention is involved.

Then there are some things that are either not solution aware, or require custom scripts to automate deployment, or can't be automated at all.

Personally I find ALM in the Power Platform much more difficult than custom development because of all these complexities and many areas being a black box, and a lack of auditing when it comes to customizations being made, so you can't tell who made what changes in a shared environment. 

Things I can suggest are:

•  creating small topic/feature solutions that only contain compoments you are changing. Then transport them to a master dev environment to merge and remove unnecessary components/dependencies where applicable. 
• Sync all development environments often to reduce the risk of stale components overwriting newer changes and causing regressions. 
• Avoid working on the same components at the same time, especially forms and views. 

---
Please click Accept as Solution if my post answered your question. This will help others find solutions to similar questions. If you like my post and/or find it helpful, please consider giving it a Thumbs Up.

[akatakkar]

Thank you Devvj. I'm reading through the information. Because we have so little code (i.e. a Model driven application), I needed to better understand how to use solutions to created isolated development environments for each developer. Previous to this, I have always worked with code and branching strategies, so this concept of 'low code applications' is all very new to me. Setting up development environments, like in the following link, seems like a step in the right direction: Sandbox environments - Power Platform | Microsoft Learn . I'm also going to check out the ALM accelerator. Thanks for pointing me in the right direction. 

[akatakkar]

Hi Eric,

Thank you for your response. I will definitely read through the ALM documentation. Also, thanks for letting me know that solutions can be maintained in GIT. I'm familiar with git branching and merging so am very comfortable with the concept of creating feature branches and then merging back into a main branch. The gist is all I need for now - many thanks for giving me hope.

[akatakkar]

Hi CChannon,

Thank you for your response. I totally agree that our devs will need to be on board with whatever approach we take and coordinate with each other. I will read up on the docs. 

[akatakkar]

Hi Chris,

I really appreciate your response. Though I am used to dealing with merge conflicts, I am unaware of the subtleties of merging things like solutions. We currently don't even have independent development environments, so if we implement your 3 suggestions, it will be an improvement. This gets me 1 step closer to making some informed recommendations. Thank you.

[EricRegnier]

@ChrisPiasecki, we really have to do a session and discuss the pros/cons and pain points of ALM approaches 😉