Source Control¶

This guidance is for professional developers familiar with Application Lifecycle Management (ALM) (including branching), but who may not have experience applying ALM to the Power Platform. The branching practices below illustrate how to use branching strategies while developing with Power Platform.

Branching Best Practices¶

• Each Power Platform production environment should have its own project in Azure DevOps or GitHub.
• Create a dedicated folder in the project for each solution in the environment. Put the production version of the solution in a related folder in the main branch of the project.
• Create a branch with the same name as the solution (referred to below as SolutionName) and store the v-next version deployed to the test environment. Promotion from the v-next branch to main should occur via PR creation, which triggers another build and validation steps. Once complete, the PR should trigger a build and deployment of a managed solution to the production environment.
• Use Feature branches for work in progress and inherit name from the SolutionName branch to enable Product Owners to specify work and developers to commit code for validation before being accepted into the test environment. Commits to a feature branch should trigger a build and deployment to a temporary validation environment. Promotion from a feature branch to the SolutionName branch should occur via PR creation, which triggers another build and validation steps. Once complete, the PR should trigger a build and deployment of a managed solution to the test environment.
• Work branches can inherit from the feature branches to allow multiple developers to work on the same task and consolidate their commits into a single PR for the feature. When working on work branches, developers are working on unmanaged solutions.

Note: Do not make changes to solutions deployed to test or production environments via the Power Apps portal. These environments should only have Managed solutions deployed. Changes (updates, patches, bug fixes, etc.) should be developed in development branches and promoted to test and production via automated pipelines triggered by a PR.

The following illustrations provide practical examples of how this branching strategy works.

gitGraph
       commit
       branch SolutionName
       commit
       branch feat-1
       commit
       commit
       checkout SolutionName
       branch feat-2
       commit
       commit
       checkout SolutionName
       merge feat-2
       checkout feat-1
       merge SolutionName
       commit
       checkout SolutionName
       merge feat-1
       checkout main
       merge SolutionName
       checkout SolutionName

Figure 1. Branching strategy. In this case, main corresponds to the Production environment and SolutionName corresponds to the Test environment. feat-1 and feat-2 branches are the working branches for new features or bug fixes.

Figure 2. A concrete example of a branching strategy for two separate environments (HR Production and Finance Production).