Collaborating on Power Apps Using Personal Environments, Power Platform CLI, Git, and Azure DevOps
This blog post was written for MetroStar Systems and originally published at MetroStar's blog here.
One of the challenges of working on Power Apps with multiple developers is that you can accidentally overwrite each other's work. This is a common challenge whenever you develop in a "shared" development environment. You can communicate and coordinate at all times to avoid losing progress but that's not an ideal solution. Luckily for professional developers, there are some tools you can use to collaborate in a more effective way.
Using Personal Environments #
Each developer can create their own personal environment instead of using a shared environment where everyone develops in parallel.
You can use the built-in copy environment feature if your personal environment is within the same tenant. If your personal environment is on a separate tenant, then you can export the desired solutions manually or use the Power Platform CLI and then import those solutions into your personal environments. These customizations are applied to the target environment when you're exporting and importing solutions, but no data is imported, unlike when you use the copy feature.
Using Git, Power Apps CLI, and SolutionPackager to Move Customizations Between Environments #
Once every developer has their own environment, you can establish a process for moving changes from the shared environment back into the personal environment and changes from the personal environment back to the shared environment.
Shown below is a visualized example of this process. This diagram was developed during our internship program by Brendan Moore.
The following components are in the above process:
- A remote git repository. In this project, it was an Azure Repository but it could be any git remote. This remote repository holds all of the customizations merged together by different developers.
- A local git repository. The developers use this to track their local changes and merge them with changes made in the remote repository.
- A personal Power Apps environment. This allows developers to implement their features before pushing them to the shared environment.
- A shared Power Apps environment (staging). This holds all of the merged customizations from the remote git repository.
As a developer wanting to start work on a new feature, you will need to follow the following steps on the diagram:
- Pull the latest changes from the remote git repository to your local repository using git. These changes are stored in unpacked solution files.
- Pack the solution files into solutions using the SolutionPackager tool and use the Power Platform CLI to import the solutions.
- Once you have implemented your feature in your personal environment, you should export the solutions using Power Platform CLI and unpack the solutions using the SolutionPackager tool.
- Review the local changes and commit them to the local git repository when ready. Pull the latest version from the remote git repository and merge any conflicts if necessary. Push the merged changes back to the remote git repository.
- You can deploy them to the shared development environment once the changes have been merged and pushed to the remote git repository. In this project, the deployment was automated using Azure Pipelines.
Depending on your needs, you may want to introduce multiple branches and pull requests into your process.
During our internship project, Brendan made this process more approachable for developers with different levels of experience by wrapping each of these steps in PowerShell scripts which guides developers through. Read these additional resources if you're interested in learning more:
- How to Deploy Solutions Using Azure Pipelines and Power Platform Build Tools
- How to Deploy Portals Using Azure Pipelines and Power Platform CLI.
Summary #
It can be hard to collaborate on Power Apps with other developers. Sometimes you can overwrite each other's work or break things; however, each developer can safely make their changes by using personal environments instead of a shared development environment. They can then merge their work together into the shared environment. A developer can track changes to solutions using git and move solutions between environments using the Power Platform CLI and SolutionPackager tool.
The Power Platform team has been developing more tools, features, and documentation for professional developers to get the most out of the Power Platform. Read this documentation on Application Lifecycle Management (ALM) to dive deeper and author your own processes for developing Power Apps.
