Collaborating on Power Apps Using Personal Environments, Power Platform CLI, Git, and Azure DevOps

Niels Swimberghe

Niels Swimberghe - - Dynamics

Follow me on Twitter, buy me a coffee

Graphic with text that reads 'Collaborating on Power Apps Using Personal Environments'

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. 

Visual process of building customizations between environments

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:

  1. Pull the latest changes from the remote git repository to your local repository using git. These changes are stored in unpacked solution files.
  2. Pack the solution files into solutions using the SolutionPackager tool and use the Power Platform CLI to import the solutions.
  3. 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.
  4. 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.
  5. 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: 

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. 

Related Posts

Related Posts

Power Apps logo

How to Create Dataverse Activities using Power Automate

- Dynamics
In this Power Platform tutorial, you will set up an HTTP webhook using the "When an HTTP request is received" action. With the HTTP request JSON, you will calculate the duration between two timestamps and fetch a contact and user by finding matching phone numbers. Then, you will create a phone call and update the status of the phone call.
Azure Pipelines and Power Apps logo

How to deploy Power Apps Solutions using Azure Pipelines

- Dynamics
Learn how to automatically deploy Power Apps solutions using the Power Platform Build Tools and Azure DevOps.
Azure Pipelines and Power Apps logo

How to deploy Power Apps Portals using Azure Pipelines

- Dynamics
Learn how to automatically deploy Power Apps portals using the Microsoft Power Platform CLI and Azure DevOps.
Power Apps Logo

Delaying JavaScript Execution Until HTML Elements are Present in Power Apps and Dynamics CRM

- Dynamics
Learn how to customize forms using JavaScript in Model-Driven Power Apps forms and Dynamics CRM forms.
CRM and PowerShell logo

PowerShell snippet: Get optionset value/labels from Dynamics CRM Entity/Attribute

- Dynamics
Instead of having to use the CRM interface to copy all the labels and values manually, you can save yourself a lot of time using this PowerShell script. Using the following script file named "GetOptionSet.ps1", you can list all the value/label pairs for a given Entity + OptionSet-Attribute:
CRM and PowerShell logo

Use PowerShell to communicate with Dynamics CRM using the .NET XRM SDK

- Dynamics
If you've developed client applications or plugins for Dynamics CRM before, you are familiar with the CRM/XRM DLL's. You may have gotten those DLL's from the CRM installation, the SDK zip, or the NuGet package. Another way to interact with the CRM DLL's is through PowerShell. PowerShell is built upon .NET meaning you can call exactly the same CRM libraries from PowerShell as from .NET applications.