You now have everything setup, so it’s finally time to get this thing running, have your releases automated, then relax on the beach. This article will talk about steps to carry out, but within the context of why, both technically and ways of working.

Terminology: ADO = Azure DevOps. Pipelines Service = Group on left that contains pipelines and releases. Pipeline = Build that exports solutions. Release = Release that imports solutions.

Preparation

There is 1 step you need to perform before we start running your pipelines, as it ensures the account DevOps imports solutions as can access the connections defined in your connection settings file.

• Visit make.powerapps or make.powerautomate and select each target environment.
• Select Connections
• For each connection, click the 3 dots, then Share.
• Enter the name of your app registration that ADO uses in the release.
• Ensure Permission is Can use then save

Repeat the above for all connections and all target environmens.

Running Pipelines

As you will be aware, Power Platform does not use code and therefore does not use a git repo, pull requests, CD, CI, etc, so instigating the process is manual. However, manual is still a different context to fully manual via PP itself.

Firstly, navigate to pipeline service > pipelines > all > the folder you created. Within here you created your multiple pipelines for each solution and each will be run individually. This may seem confusing, as you have multiple pipelines but only 1 release, but the reason is the release can be triggered from any of the artifacts generated from these pipelines.

• Click the 3 dots on the right of the pipeline representing the solution you need to export.
• Ensure Branch/tag is your mainline branch, such as develop, master, etc.
• Click Run

The pipeline will now run completely unattended, version and export your solutions and publish the files ready for the release. You should ensure it did not fail and this should be repeated for each solution you need to export for the work item you have been working on.

Running Releases

This stage, in terms of actioning the running itself is fully automated. Although only 1 release exists, an instance of that release will be created for every successful pipeline. So let’s say 2 pipelines were run in the previous section to export 2 solutions – you will have 2 release instances automatically created, 1 for each and they will release your 2 solutions in completely isolated paths.

The renaming stage will run automatically, then the release will pause before your first environment. This is because you have set a pre-approval condition, to ensure appropriate staff approve it rather than it automatically flying into each environment instantly. To approve:

• Each person (be they individuals in the list or part of a team) will recieve an email from ADO. You can click this to take you to the release.
• If you don’t do the above, you can go to the renamed release instance.
• With both options, click the Approve button underneath the first stage.
• A panel will fly out from the right hand side, you need to click Approve or Reject on here.

You should do the above when you are happy the change has been reviewed and is an appropriate time to import. Once everyone (as individuals or representative of a team) has approved, the stage will start and import the solution automatically.

At this point your ways of working take over and you carry out work your teams are required to, such as QA testing. When you are happy the change is acceptable in that environment, you can repeat the process above for the next environment (you will already have receive the email), all the way to live.

Summary/Next…

This may seem short, but this is really all there is to releasing your solutions to other environments after development. This is by design, to provide the following benefits:

• Faster release process and less manual steps.
• Decreased risk of human error.
• Increased visibility and governance of entire process.
• Increased accountability of process stages and actions to be perfomed within them.
• Increased security with personal accounts not required to be logged in to untake this.

This is a massive step towards improving the overall governance of Power Platform in your organisation. You will start to discover more and more items you can improve from here, such as security, environment structure and we will discuss some of these wider ways of working in future articles, in collaboration with specialists from other fields such as QA, infrastructure, coders.

I hope you have enjoyed this series and it serves as a helpful basis to start your ALM journey. I am openly available to discuss these topics on Reddit, Discord and Linkedin (links on this and all pages of this site), to help others as well as discuss options where we can all learn.

As an important thing to remember – no one is automatically wrong or right, but we should understand ways of working can and should always be improved and we can adapt with that to make things easier and safer for ourselves.

I’ll see you next time.