Model driven apps and version control

(1) Share

Report

Posted on by fatenyahiaoui_m

Hello everyone,

As a team we have the following setup for our model driven app implementation :

- Each one of us owns a dev environnment in which they perform their day to day tasks.

- At the completion of each feature , a developer will run a devops pipeline to commit their work to Git, He(she) will also make sure to pull the latest code from Git to merge any conflicts before submitting a PR.

Our solution is an unmanaged solution for the time being as we're in the early stages of development.

The issue we have been facing lately is that some components would be removed or cleaned up in the main branch but then would be restored in of the commits of the dev branches since our Azure Devops comit pipeline packs and exports the solution that is unmanaged and therefore any zombie component is also checked out to Git. These are viewed as additions in the PR review process and sometimes go unnoticed and merged into main.

We have thought about including two steps at the beginning of our import Azure Devops pipeline:

- Dev Environnement Reset

- Import of test data

After that, we would proceed with the import of the unmanaged solution like we normally do.

Before we dig into this solution, I was wondering if there are any other solutions to this and to having to manage the solution?

Best

Faten

Categories:

Building Power Apps

I have the same question (0)

All responses (3)

Answers (1)

Giraldoj 762 Super User 2025 Season 2 on at

Like (2)

Report
Hi @fatenyahiaoui_m ,

Those "zombie" components are a common issue and are one reason I don't recommend handling Power Platform components in different branches/environments. Currently, Power Platform does not support component versioning.

The simplest way to work with multiple developers in the same model-driven app solution is by segmenting your unmanaged solution into smaller pieces. You can refer to the Microsoft documentation for more details on creating segmented solutions.

Each developer can work in their own segment (or "branch") and then move the components to the main branch once they are completed.

Suppose Developer 1 is changing a component and is in the middle of development, but Developer 2 has something ready to deploy to production.

In these cases, you should use patches instead of branches. Even if you reset the environment, the last developer to commit will overwrite others' changes.

A more versioning-friendly approach is to use a managed environment. Deploy all developers' changes to this managed environment, creating a new layer for each change. The last developer to commit will create the highest layer. Learn more about solution layers.
some additional Tips
Segment Your Solution: This is the most practical control method. In your dev environment, segment your solution to manage different components independently.
Version Control for JS Libraries: If you work a lot with JavaScript in your forms, it’s worth having a version control system specifically for your JS libraries. This way, each developer can commit their code changes to a single library.
Built-in Version Control: Power Apps and Power Automate now support built-in version control, allowing multiple developers to work directly in the same environment on the same flow or app simultaneously.
If my response resolved your issue, please feel free to mark it as the solution by clicking "Accept as solution." This helps others find the answer more easily. If you found the content helpful in any other way, a "Thumbs Up" would be greatly appreciated. Thank you!

Was this reply helpful? Yes No
fatenyahiaoui_m on at

Like (1)

Report

Thanks @Giraldoj for the detailed answer.
I have some questions on this:
1. Regarding segmenting the solution into smaller pieces, this assumes that a developer will own one or more components at a time and if they needed to do minor changes to a component that is not in their pool then they will need to align with whomever is the owner of it. I see some potentials drawbacks to this approach:
** This relies on components rather than on functionality. Some people might become blocked because they will not be able to adjust other components since it is not under their control.
** You need to know upfront all of the components you need to be able to split out the tasks which might not be the case in a real life scenario
** Workload between the different team members might not fair since some people will have more or less tasks to do depending on what component they get. In a scenario based on a user story , everyone is pretty much touching everything to make sure we deliver on the functionality needed.
2. Agree for JS Librairies: process seems pretty straight forward to me
3. Can you share some documentation for this , how to modifiy the same component simultaneously ? How do we resolve conflicts?

Was this reply helpful? Yes No
Verified answer

Giraldoj 762 Super User 2025 Season 2 on at

Like (2)

Report
Hi @fatenyahiaoui_m

A few clarifications about point one regarding segmenting the solution into smaller pieces:

Potential Drawbacks
Component Ownership and Minor Changes: Segmenting your solution doesn't mean developers are strictly limited to their components. While a developer may own one or more components at a time, it doesn't prevent them from making minor changes to components outside their pool. They will need to coordinate with the owner, but it isn't a rigid barrier.

Functionality vs. Component Focus: Segmenting by components can potentially block some people because they can't adjust components not under their control. However, you can segment by modules or features instead, allowing developers to work on related sets of functionality.

Upfront Knowledge of Components: It's true that knowing all components upfront might not always be feasible. In real-life scenarios, you can adjust the segmentation dynamically as the project evolves, ensuring flexibility.

Workload Distribution: Workload distribution might seem unfair if it's based solely on components. Instead, you can assign tasks based on user stories or features, ensuring everyone gets a balanced workload. This way, developers might touch various parts of the solution, contributing to the needed functionality.

To give you a better idea, Look at these segmentation samples:

Module-based Segmentation: Divide your app by modules. Developers can access and work on different modules, and you can have multiple developers working on the same module if needed.

Developer-based Segmentation: Each developer has their own solution and uses the "add existing components" button to get the components they need. They can create new components and keep them in their segment until development is complete, then add them to the main solution.

Also regarding to point one in my previous response i forgot to mention something really important. to avoid ownership issues is recommended to use service accounts it also simplifies connection references. This allows developers to create components using a service account, preventing constraints tied to personal accounts.

Regarding to point 3 you can find more information about co-authoring and collaboration in power platform bellow, please check these articles:

Power Automate: Announcing co-presence in Power Automate
Model-Driven Apps: Announcing public preview of coauthoring in Modern App Designer
Canvas Apps: Allow multiple Power Apps developers to simultaneously edit canvas apps - Azure DevOps version

If this helps, please mark it as the solution by clicking "Accept as solution." A "Thumbs Up" would be greatly appreciated if you found the content helpful. Thanks!

Was this reply helpful? Yes No