Developing Power Apps in a developers team

Prerequisites

First of all, make sure that you’re familiar with the following two master pieces:

1. the foundations of GIT Flow: Introduction to Git Flow
2. a CI/CD scenario that makes use of build and release pipelines (Azure Devops or Git GitHub Actions)

Development team setup

It doesn’t matter if you are developing one or more Power Platform solution with one or more devs – the «right choice» is to make on the decision on how you want to work together.

There are two scenarios that are relevant to you and the dev team:

Scenario	Code Repository Setup	Power Platform Environment Setup
Scenario A: «Standard»	All developers share two branches: develop contains one shared codebase that is synchronized with the development environment main contains the production-ready code that can be deployed in the production environment	Two (shared) environments: development environment production environment
Scenario B: «Grow together»	All developers share two branches: develop contains one shared and actual code base that is synchronized with the development environment main contains the production-ready code that can be deployed in the production environment Upon starting to implement an new feature, every developer creates his / her own feature branch: feature/{id of epic or task} the git flow feature branch, holding the code base of the content that is currently in development by the dev	Two (shared) environments: development environment production environment n individual environments (one per dev): developers' environment

As mentioned earlier, it does not matter how many devs are working together – it depends on how you want to share and organize your development setup.

👉 One crucial thing: always choose the setup that supports you the most and makes you best productive!

Scenario A: «Standard»

Scenario A is the «standard» way of working together in a dev team. All devs share the same solution in the development environment on the Power Platform. It is always in sync with the same code base on the develop branch.

Every change in the development environment must be committed and pushed to the develop branch – in a Power Platform development setup we would call this a solution export. This way, the code on the develop branch always reflects the current implementation stage of the solution in the development environment.

When a feature or epic is finished and ready to be deployed to production, it is merged from the develop branch into the main branch. This can be done via a pull request to ensure that the changes are reviewed before being merged.

The main branch holds the production-ready code that corresponds to the solution that was deployed to the production environment.

Scenario B: «Grow together»

When choosing scenario B, every dev must checkout the latest develop branch and initialize his / her own new feature branch – always before he / she starts to work on the epic or task that has to be implemented. Don’t forget to push the branch to the central repository (backup and collaboration purpose).

Given that, the develop branch always hold the actual code base that stays in sync with the solution in the development environment on the Power Platform, while the evolution of the current feature and its code base is completely independent from the develop branch. No matter if the progress of the development of your Power App goes with the speed of light and the code base changes daily: your code on the feature branch is always safe! As soon you’re in the stage of developing the new feature, create and remain onto the feature branch – and merge back into the develop branch when you’re finished.

Each new feature should be on its own branch (that can be pushed to the central repository for backup / collaboration purposes). When a feature is finished, it is merged back into the develop branch.

Let’s put that into a drawing:

Why every dev needs his own development environment in the Power Platform

Guess why… You’re right: as long as you develop in your own environment – no one else’s changes will affect your work. This means that your work is always safe from «accidental move of destruction» (as long as you’re backing up the changes on your feature branch in the central repository) or a change that affects the same module.

Even if a «massive change» was published on the develop branch while your feature development is still in progress: check out the develop branch to your local repo, and update your feature branch (at this time or at the end – as you wish): your work will always be safely backed up by the commits on your feature branch. That’s it! 😃