The Development Hub brings continuous integration to Power Apps development by allowing developers to easily submit their Power Apps configuration/customisation for review and automated merging to source control.
- Peer review
- Solution merging
- Automatic semantic versioning
- Automatic source control
Two instances are required to use the Development Hub - a development instance and a 'master' instance.
For more information on the purpose of the master instance, refer to the Solution Lifecycle Management document published by Microsoft. The relevant information can be found in the Instance topologies for development approaches table.
The package can be deployed to your development environment using the Package Deployer. Download the package files from the Releases tab and follow Microsoft's guide to using the Package Deployer here.
Access to the Common Data Service Web API is required in order to merge development solutions with the solution(s) in the master instance. Follow Microsoft's guide on registering an app with access to the Common Data Service Web API here.
Once registered:
- Grant admin consent for the tenant for the Dynamics CRM API permissions
- Navigate to Authentication and set Treat application as a public client to Yes.
- Make a note of the client ID and tenant ID
Use the plug-in registration tool to set the secure configuration parameters necessary for authentication for the Web API. The steps to set the secure configuration for are under the InjectSecureConfig plug-in within the DevelopmentHub.Develop assembly.
The secure configuration is a JSON object with the client ID, tenant ID, and user credentials:
{
"ClientId": "<from app registration>",
"TenantId": "<from app registration>",
"Username": "<service account email>",
"Password": "<service account password>"
}Note: the user must have admin permissions in the master instance.
The Development Hub currently relies on integration with Azure DevOps to provide automated source-control functionality.
Navigate to Project Settings -> Repositories in the Azure DevOps project that contains repository. Select the relevant repository and assign the following privilges to the project Build Service user:
- Bypass policies when pushing
- Contribute
- Create branch
A build definition capable of extracting solutions is required. Refer to the samples folder for a possible build configuration. If you use the sample files as is, the Cake build script assumes that your folder structure is similar to that of this repository i.e. you have a solutions folder at the root, folders within this that match your solutions' unique names, a solution.json within each of these that provides the development environment URL, and an Extract folder alongside it to contain the unpacked solution zip file fragments.
If you have an existing folder structure which is different, the build.cake file will probably require tweaking to how the outputPath variable is assigned as well as the path used to retrieve the solution.json file within GetConnectionString. The azure-pipelines-extract.yml file shouldn't need to be changed.
You will need Cake installed in your repository to use the sample build files. You can do this easily within VS Code by installing the Cake extension and running the Cake: Install to workspace task. If no build.ps1 bootstrapper file has been created in the root of the repository, you can create this using the Cake: Install a bootstrapper task. The sample build.cake file can then be used.
The sample build requires that a variable group named 'Cake' exists and that it contains two variables - dynamicsUsername and dynamicsPassword. These will be used by the build to connect to the development instance when extracting the post-merge solution zip.
Note: the Common Data Service package Yeoman generator will scaffold a build and repository compatible with the Development Hub.
There are four environment variables to set:
- Solution Publisher Prefix
- Azure DevOps Organization
- Azure DevOps Project
- Azure DevOps Extract Build Definition ID
The build definition ID is the numeric ID given to the build definition by Azure DevOps. This is the extract build created either by modifying the sample in this repository or by the Yeoman generator.
There are two flows located in the devhub_DevelopmentHub_AzureDevOps solution that must be set in order to trigger extract builds. The flows to set the connections on are:
- Environment Variable Key -> Environment Variable Value
- When a solution is merged - Commit changes to source control
Ensure you have created or imported your unmanaged solution(s) for extraction in the master instance. Once this is done, they can be registered within the Development Hub app.
The first step is to create an environment record for the master instance:
Then create a solution record for each solution in the master instance:
Do not change the version numbers if the solution is new. If it is an existing solution, update the version numbers to match the solution in the master instance. The version will from then on be managed by the Development Hub when merging changes.
Issues must be created within the Development Hub in order for a developer to begin working on a new feature or bug fix.
The issue records in the Development Hub are used to group solution merge records and aid in applying semantic versioning to solutions. The Development Hub is not intended to replace a more conventional issue tracking system (e.g Azure Boards).
It is suggested to either create issue records on-the-fly, at the beginning of a sprint, or by integrating Azure DevOps through a tool such as Power Automate.
An issue with a 'To Do' status will have a Develop button in the ribbon. Clicking this will create a development solution and transition the issue to 'In Progress'. The Development tab will show details about the development solutions and solution merge history.
The developer must add any new components or components to be modified into their development solution. It is important that only one developer makes changes to a component at a time. If a component appears in more than one development solution, it will result in either incomplete work being merged or solution merges failing due to missing dependencies.
Development solutions should contain just the components created or updated for that issue and no more. Adding all assets to a development solution will add all assets to the target solution when merged.
Once the issue has been developed, a solution merge record can be created. This will transition the issue to 'Developed'. The solution merge is created in an 'Awaiting Review' status. Review comments can be added to the solution merge in the form of notes and the solution merge either approved or rejected.
Once approved, the development solution will be merged into the target solution. If multiple solution merges have been approved, they will enter a queue. This means that an 'Approved' solution merge will transition to either a 'Merging' or 'Queued' status.
A successful solution merge will transition to an inactive 'Merged' status. The 'Version History' tab on the target solution record will also contain two new attachments with the post-merge unmanaged and managed solution zips. The new solution version is based on the type of issue 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.
If the solution to be merged has associated source code (e.g. you have made changes to plugin assemblies or web resources) then you must specify the source branch. Ensure that you perform any manual merging required in Git on your source branch before creating the solution merge. This branch will be merged automatically.
Specifying that there are manual merge activities on the solution merge record will cause the merging process to pause before extracting to source control. This is useful where you are merging changes by hand e.g. components that need to be updated frequently by multiple developers or where you need to delete components from the solution.
When the merging process is in a state where manual merge activities can begin, the solution merge will transition to an 'Awaiting Manual Merge Activities' status. If you are deleting components from the solution in the master instance, it is recommended to update the major version of the solution record in the Development Hub during this period.
If the merging process failed (e.g. due to missing dependencies) then the solution merge will transition to a 'Failed' status. A Retry button is available after the necessary steps have been taken. Failure reason will be attached as a note to the solution merge record.
A VS Code/Cake task has been defined which will allow you to recreate a development instance for a given solution. If you wanted to contribute to the devhub_DevelopmentHub_Develop solution, you would open the command palette within VS Code (ctrl + shift + p) and select Tasks: Run Task followed by Build Development Environment and devhub_DevelopmentHub_Develop. This task requires that you have first configured the development environment url solution.json file in the corresponding solution folder and set up your environment variables (see below).
If you do not have an existing instance, you can create one for free with the Power Apps Community Plan or by signing up for a trial.
Two environment variables are required to enable you to authenticate with the development and staging environments:
- CAKE_DYNAMICS_USERNAME_DEVELOPMENT_HUB
- CAKE_DYNAMICS_PASSWORD_DEVELOPMENT_HUB
The username in the environment variable is used unless overridden by the username set in the corresponding solution.json file. This is useful where the username for each solution is different (e.g. where you have multiple trials).
A number of Cake build tasks have been defined to make development easier. It is recommended to call these via the command palette (ctrl + shift + p) and selecting Tasks: Run Task.
The following tasks are available:
- Build Development Environment
- Extract Solution
- Pack Solution
- Build Package
- Deploy Plugins
- Deploy Workflow Activities
- Generate Model
Before creating a pull request containing your changes, you must extract the solutions into source control. This can be done using the Extract Solution task and specifying which solution(s) to extract.