Continuous Integration for Power Apps — the Development Hub
The Development Hub is an open-source Power Apps app which simplifies the continuous integration process for teams working with Power Apps. This blog post should hopefully offer some insight as to why it exists and how it could help you to deliver Power Apps solutions at scale.
Power Apps development strategies
Scaling up development when working with Power Apps can be a tricky prospect and choosing a strategy for development environments will have a significant impact on being able to do it successfully. This is fundamental to how the Development Hub works, so I will cover a few common approaches below. If you would like to know more about this subject, I recommend reading the Solution Lifecycle Management document published by Microsoft. This document explains the various environment topologies and the pros and cons of each.
Shared development environment
A single, shared development environment means that when a developer has finished their changes and extracts the solution(s) into source control, the extract will also contain changes made by other developers. These changes will most likely be work-in-progress that we do not want to be committed. This problem gets exponentially worse the more the development team is scaled up, as it becomes increasingly difficult to extract to source control without introducing breaking changes to your build(s). On the other hand, this is an extremely cost-effective and efficient strategy when working with a very small team (e.g. a single developer).
Individual development environments
Individual development environments ensure that only the intended changes are extracted. Although this seemingly solves the issue, a separate one is introduced i.e. merge conflicts due to developers updating the same components in isolation. Updating the constituent XML files of an unpacked solution is unsupported (except for some components), so conflict resolution must be done within the developer’s environment. As the team scales, the likelihood of encountering conflicts increases.
On top of conflicts and the effort involved in keeping the development environments in sync, there is an additional cost associated with having an environment for each developer. However, this approach is likely to work well with technical, organised teams who are familiar with the process and where the cost of the additional environments is not an issue.
Development and extract environment
A slightly different approach is to maintain a single development environment and use a separate environment for extracting solutions into source control. Developers work in a ‘development solution’ and promote this solution to the extract environment when their work is complete. This is another way of getting around the issue of extracting incomplete changes into source control but without the cost and effort of maintaining individual development environments.
This approach also helps to avoid the other drawback of individual environments i.e. merge conflicts. It does not come without an associated cost, however, as components effectively need to be ‘checked-out’ by any developer modifying them in his development solution. There must also be an awareness of the dependencies between development solutions as it is possible to introduce dependencies on components which do not yet exist in the extract environment.
Despite the drawbacks, this approach can be a good middle-ground for teams that aren’t able to incur the expense or training effort of maintaining individual development environments.
The Development Hub
The Development Hub was created to simplify the process of promoting, merging, and extracting a developer’s changes into source control using the development and extract strategy mentioned above. It also provides a mechanism for automatically versioning solutions as well as carrying out peer review on a developer’s changes to be merged. Carrying out a review of a development solution prior to merging is important as the development solutions are promoted to the extract environment as unmanaged, so the changes wouldn’t be easily reverted if they were rejected after being promoted.
As well as making the overall development process easier, the Development Hub also works to reduce the effort required in onboarding developers and lowering the technical barriers to entry for the continuous integration process - both of which present challenges when scaling up your development team. Once configured, all team members can have their changes committed to source control, built, and deployed with minimal training regardless of whether or not they are familiar with tools such as git. The interface itself should be intuitive to all Power Apps developers as, after all, it’s just another Power App.
The sections below show the end-to-end process of developing a solution with the Development Hub.
Creating an issue
The starting point for any development in the Development Hub is an issue record. This holds details about a bug fix or feature to be developed and provides a header record from which to group solution merge requests. It is important to note that the idea is not for the Development Hub to replace a more conventional issue tracking system (e.g. Azure Boards). The issue records in the Development Hub are solely to facilitate the development process.
You may wish to use something like Power Automate to create these based on work items being created in Azure Boards or simply create them on-the-fly.
Develop an issue
Note the Develop button on the ribbon. This is shown on newly created issues that are still in the status of To Do. Clicking on the Develop button will automatically create a development solution for the issue.
From this point, the developer would work solely within the development solution. Any components they create or update must be included (and nothing more). In this example, I have added a new flow to the solution.
Request a solution merge
A solution merge for the issue can be created now that the development has completed. This is done by creating a new ‘solution merge’ record for the issue. There are three fields that should be set when creating a solution merge.
Target Solution is the solution that you want to merge the development solution into. Creating the solution records is part of the configuration required to use the Development Hub (which I haven’t covered in this blog post but is covered in the README).
Source branch is optional and is to be provided when there is source code that corresponds to any of the solution components. This will mostly apply where a plugin assembly or web resource has been created or updated. The source branch is then passed to the extract build - which will merge the source branch before committing and pushing the extract.
Manual Merge Activities is used to specify whether or not there is a manual intervention required during the merge process. If this is set to Yes, the automatic merge process will complete but will pause prior to extraction. The solution merge record will enter an Awaiting Manual Merge Activities status and, at this point, the developer can make any manual changes required in the extract environment. The most common usage scenario for this will be to delete components (although this may be automated in a later future release). Once the manual merge activities are complete, the Manual Merge Activities Complete field on the solution merge can be set to Yes which will then carry on with the process.
Review the solution merge
The final step in the process (if there are no manual merge activities) is to review the solution merge. This is done using the two buttons present on the top of the ribbon - Approve and Reject. If the solution merge is to be rejected, comments can be added in the form of notes.
The developer who created the solution merge should then fix or respond to the comments in the notes and create a new solution merge when they have been resolved. When the solution merge is finally approved, it will transition to one of two statuses - Merging or Queued. Solution merges are merged in the order that they are approved in. If there is a merge in progress, any solution merges approved will be queued until the solution merge(s) approved in front are either Cancelled or Merged.
Handle a failed solution merge
Solution merges will occasionally fail at various points in the merge process. For example, where components in the development solution are dependent on a component which is missing from the extract environment - as in the screenshot below.
We can see that a solution dependency was added for the cap_issuedon field on the invoice, but it was not present in either the extract environment or the development solution. In this example, the solution would be to add this field to the development solution and click the Retry button.
Versioning and source control
When a solution merge has reached the Merged status, the target solution will be updated to reflect the new version. This is based on the type of issue being merged - a Feature issue will increment the minor version and a Bug issue will increment the patch version. Major version changes must be done manually.
On the Version History tab, we can find zip files containing the unmanaged and managed solution zips for every version of the target solution.
These are also the solution zips that are extracted into source control - this decouples the merge and extract processes and allows them to scale independently.
The extract build, triggered by a solution merge reaching a Merged status, will commit the changes contained within the development solution to the master branch. The commit message will be a combination of the issue type and name and, crucially, it creates the commit as the Power Apps user who created the solution merge rather than the build service account.
The source code of the Development Hub has now been published and an alpha version released on GitHub. If you’re interested in trying it out, download the latest package files from the Releases tab on the GitHub page and follow the installation and configuration steps in the README.
For anybody wanting to contribute, there is a section of the README that will explain how to easily build your own development environment. I recommend signing up for the Power Apps Community Plan, as this will provide you with a development environment at no cost.
Any contribution or feedback is appreciated!
Curious about joining the Microsoft Team? Here are our open roles.
