Challenges
- Power Platform uses solutions to package and move changes from one environment to another (for example moving changes from Development environment to QA environment)
- Multiple developers can work on same tables in an environment. This brings in a challenge of making sure the changes are not overwritten
- The table metadata should be correct when changes are deployed
- Power Platform solutions create layers of changes. The layers go on top of each other and can stop from changes being shown after the deployment
The points above cause a big challenge in the release process and can delay the development process because multiple developers may not be able to work on the same area in an environment.
Click here to see the suggested approach documented below, in action.
Suggested Approach
Figure 1, below suggests the steps and and environments that can be used in the release process.
Important Points
- Each developer will have their own copy of DEV environment for the specific user story being worked on. The DEV environment will be aligned to Main DEV environment before beginning any work on a user story
- Steps 2.1 and 2.2 are important to follow. The process will break without carrying out these steps. As in normal software development lifecycle, the responsibility falls on developers to merge changes before deployment. Step 2.1 makes sure that a DEV environment is up to date if another developer has deployed to DEV Test already. Step 2.2 makes sure that changes have been merged correctly before deploying to DEV Test environment. Steps 2.1 and 2.2 will be carried out after the changes to DEV environment and before deploying to DEV Test environment
- DEV Test environment shall be set up. This environment will be used to test merging of development work from different DEV environments
- No development / configuration work will be done on Main DEV environment. This environment is present to provide baseline environment for developers to start development work
- Main DEV environment will only be updated by importing unmanaged solutions from pipeline, once UAT has been successful. Release to Production environment can be delayed for various reasons. This step will make sure that Main DEV environment is up to date once UAT is successful on stories being worked on and further development can carry on
- Each deployment step will store Unmanaged and Managed solutions
Steps in Detail
The steps are best explained using a scenario. Let’s look at one of the most challenging scenarios.
Scenario:
- Two user stories are in the back log that need changes to Account entity
- Both user stories will require new attributes added to the Account entity and displayed on the same form under same section
- Two different developers will work on each of the stories
- Both developers will work on same solution called ‘Configuration’
Steps for Continuous Development and Continuous Integration
The swim lane diagram (figure 2) shows the release process. The steps are explained in detail below:
- Developer A takes a copy of Main Dev and call the environment DEV 1
- Developer B takes a copy of Main Dev and call the environment DEV 2
- Developer A and B check the version of Configuration solution against the version in DEV Test environment
- If the version in DEV Test is greater than in Developer 1 and 2 corresponding environments, then import back the unmanaged Configuration solution in their environment to sync with DEV Test environment. This can happen if there is already another developer working on another story.
- Now DEV 1 and DEV 2 will be inline with DEV Test environment. Developer A and Developer B can work in isolation within their DEV environments
- Both developers can add attributes and update form according to user stories they are working on. In this scenario, both developers will add attributes to the Account entity and update the same form as well
- Developer A completes the changes and is ready to deploy to DEV Test environment. Developer A compares Configuration solution version in DEV 1 and DEV Test environment. The version number should be the same. Developer A can deploy managed solution to DEV Test environment while incrementing the Configure solution version. Both managed and unmanaged solution with corresponding version numbers are saved in the repository
- Developer A checks and tests their changes in DEV Test environment
- Developer B completes the changes and is ready to deploy to DEV Test environment. Developer B compares the Configuration solution version in DEV 2 and DEV Test environment. The version in DEV Test environment will be higher compared to DEV 2 environment, indicating DEV Test environment has moved on. Developer B will have to merge the changes before deploying to DEV Test environment
- Developer B now downloads the latest version of unmanaged Configuration solution from the repository and import it back into DEV 2 environment. There are other ways of merging the changes and we will discuss these later on. However, I feel this is the best approach
- Step 10 may overwrite the changes on the form and views (I have used the word ‘may’ because it depends on how the changes have been made on the form – more on this later). Importing the solution will not affect the new attributes added to the Account entity in DEV 2 environment by Developer B
- Developer B checks and if necessary, again updated the forms and views accordingly
- Now Developer B is ready to deploy to DEV Test. Developer B does a final comparison of Configuration solution version numbers before deployment
- Developer B deploys the managed solution to DEV Test environment and increments the version number
- Both managed and unmanaged solutions are saved in the repository
- Developer B tests the DEV Test environment after deployment
- After testing DEV Test environment, the managed solution saved in repository is ready to be deployed to QA environment with changes from both user stories
- Managed solution saved in the repository is deployed to higher environments (QA, UAT etc)
- After passing UAT, the unmanaged solution saved in the repository is imported to DEV Main environment to update DEV Main environment
Merge Options
We mentioned the requirement to merge in our steps above. Here we discuss the options available and why I feel, the method suggested above is a better option.
Merging of branches in Software Development Lifecycle (SDLC) is nothing new. Developers will always remain responsible of merging the changes into a main branch. This happens in normal software development. For example, if GitHub is used as a repository.
Normally, a developer will get their branch updated by pulling from repository and then merge when pushing back to main branch. We use the same methodology here for Power Platform deployments. Developers and Build Managers should be prepared for merge steps in the favour of CD / CI (Continuous Development and Continuous Integration).
Deployment tools can be used to set up pipelines and automate steps. We will look at some of the options later on.
- Unzip the solution files and merge XML files
As the developers know, the solution file from Power Platform can be unzipped. It contains three xml files that can be opened and viewed in an editor. Three files include:
[Content_Types].xml
solution.xml
customizations.xml
It’s customizations.xml can be compared between the exported solutions to identify the differences.
Power Platform developers are normally familiar with these files and can merge different sections of the file.
This method is going back to basics of software development and files can be merged by manual read using an editor.
Advantages:
- Developer can merge in a traditional manner of merging code files before importing / overwriting changes in their environment
- Developer can control what should be merged. This can be very useful if a same attribute is added from a different branch
Disadvantages:
- Developer needs to fully understand the XML format. For example, if a new attribute is being, how this needs to be defined to in XML. It is not just one line of code. It’s multiple XML statements
- The solution version has to be set manually in solution.xml file before importing it back to the developer environment to keep solution version consistent. Steps like these can be missed out and cause inconsistencies
- An error in manual merge can cause errors and error hunting required
- Developers need good knowledge of different sections of customizations.xml
- Import higher version on Unmanaged solution from DEV Test environment
This is a defined method of moving changes from one environment to another. However, the way the solution layers work, this will remove any UI changes from the environment. It will bring all the new changes that have been deployed to DEV Test environment since the developer started working on their instance.
Developer will have to repeat the UI customisations on their instance again to complete the merge.
Advantages:
- All the customisations from DEV Test environment are brought into Developer environment
- Use of Power Platform specified mechanism for moving the changes between the environments
- Solution version number is maintained automatically
- Developer merge the changes using the graphical user interface
- Reduction of merging errors as XML is updated automatically in the background
- New components such as JavaScripts, Workflows, Plugins and Business Process Flows are not affected by the import
- Extended knowledge of XML format of customisations.xml is not required
Disadvantages:
- UI changes on forms, ribbons and views will have to be redone
- Changes to existing components in the solution (JavaScripts, Workflows, Plugins and Business Process Flows) need to be backed up (can be exported out using a different solution) in developer environment
For the above reasons, I feel, importing of unmanaged solution is a better option and I selected that for the process.
The drawback of UI changes sounds daunting. However, any JavaScripts for ribbon buttons already exist these all can be very easily instated. This will also encourage developers to make small changes and deploy to DEV Test more often for testing. Also, careful planning and enforce better communication between the developers when working on same area of the application.
Conclusion
Continuous Development and Continuous Integration (CD/CI) is and integral part of any Software Development Lifecycle (SDLC). It is nothing new. It has become a challenging topic with Power Platform because of too many moving components and not using traditional source code files.
However, it does not mean that it is not possible. CD/CI always involve some sort of merging when push and pull of code occurs. This methodology can be extended to Power Platform and responsibility taken by developers to merge like in any other software development environment.
DEV Test environment provide developers an environment that is using managed solution like other higher environments (QA, UAT, PROD). This is a platform for developers to test how the managed changes will behave. Developers can make sure before a deployment to QA environment happens.
Integration with other Platforms
This is also important point to consider. In most deployments there will be integrations with other downstream systems.
DEV Main and DEV Test environments in figure 1 are shown as permanent environments. Integration to downstream dev environments shall be connected to these environments. DEV 1 and DEV 2 environments are shown as temporary environments and integrations don’t need to be connected to these. With the exception of when a new integration is being developed / set up.
Tools for Deployment
It is strongly recommended that a known tool is used set up deployment pipeline to automate some of the steps in deployment and securing the artifacts. There are various tools available, such as Azure DevOps, ALM tool, Power Platform pipelines and from other providers as well.
Short video below shows all this in action with a use of Power Platform pipeline. For most advanced options, it is recommended to use Azure DevOps along with ALM tool.
