Power Platform | Pipelines

Today I´d like to talk about my recent experience using Power Platform Pipelines. This time I will set the focus to the Maker or End-user experience. But first, what is Power Platform Pipelines?

The Power Platform engineering team recently announced it´s GA as an early suprise and the aim of this feature is to democratize application lifecycle management (ALM) for Power Platform and Dynamics 365 customers and make this service more approachable for all makers, admins, and developers.

Those not having a classical software developer background may now ask what this is about and why does it need to be democratized? Let´s have a look at the following visual which talks about the continuous integration and continuous delivery (CI/CD) which beside automation the deployment process is one of the major ingredients found inside ALM.

The visual outlines, that from a Maker’s perspective the goal is to continue developing first. This being in an individual developer’s sandbox or being in a shared sandbox environment in case of acting as a Fusion Teams development for example. The major differences are:

• You don´t develop directly in a production environment
• You share resources with other developers (such as Dataverse, Environment variables, Connection References, etc.)
• You typically develop inside a solution container that aggregates all your developed assets
• You´re using a developer prefix which is either your individual or a developer team shared prefix which is defined via a Publisher assigned to a solution (learn about it here)
• The solution you´re developing in is an unmanaged solution (learn about it here)
• The solution you´re developing typically would be deployed to a QA/Merge, after success to a UAT- and finally to Production environment

The last item outlines why this ALM concept should be democratized and simplified as you may not want to learn all the things about ALM in full detail.

From the visual above you can also see two major „ingredients“ the admins of ALM would have an interest on. Those are:

• having a repository where all source code is stored
• having the ability to audit of what code changes have been made, who made them, etc.
• automating the build process (which for Power Platform solutions typically are – having a solution check, converting the unmanaged solution into a managed solution, merge solutions if multiple developers have been creating assets that would aggregate into a release solution, deploy the unmanaged solution to the next stage
• perform unit tests or automatic tests in the backend
• ensure quality of application releases deployed to production

As today, I am setting the focus on end-user experience, I will stop here and return to the part of why ALM needs to be democratized and where does Power Platform Pipelines fulfill on this.

To better outline the complex part of the creation process, I shared above visual that outlines the overall goal (creating a Release), shows the various creation processes which are devided into a Master, a Develop, and n-times a Feature track. The Maker would normally only care about the Develop track and if them developing a special feature only, them taking care of n Feature tracks. Those would be aggregated in a final step to a release, that then becomes deployed to production. It could be multiple releases over the time of creating and improving the solution. In a Master track your company also wants to ensure to keep an eye on the source code in a format that could be re-used, re-compiled or re-written in case needed.

As a Maker you may now understand that learning all this, not coming from a classic software development background would take time and all you wanted is to create a solution for an issue that occured during your day-to-day job. You decided to use low-code tools to help you solving your issue, improve yours or others productivity or fulfill on a different goal.

This is why Power Platform Pipelines came alife. To make your life a lot easier while dealing with the steps involved in application lifecycle or release management. And let´s face it: Have you ever asked yourself why your asset should have a version number, and when making any changes you should increase this number? And of course, why does it have this funny format of „__.__.__.__“ – who came up with this?

All these responsibilities are now becoming a hack lot easier by using Pipelines. The admin of Pipelines created yours everything that is needed and all you´re doing from a Maker perspective is using the Pipelines front-end to deploy your solution to the various stages.

It´s a build-in UI experience into solutions and once activated you can use it with a single click of a button and following the deployment wizard which walks you through the deployment steps.

Even though the experience isn´t yet finished and more features to be added soon, here´re a couple of things, I wished to become even easier from running my tests with it:

• Making Error Messages meaningful to any developer
• After deploying a solution to Test/QA/UAT ensure an easy process of sharing the app with Testers (currently you would need to use „Go to this environment“ and do these steps manually
• Pre-testing ensure that all security roles assigned to Makers inside at least the three main environments are the same (in my case I used System Customizer but figured out that the latest environment(s) containing this role are not matching previously created environments containing the same role)
• Ensure Makers can provide some more description during deployment process that at least could be used as triggers for further automation steps (like sending an email invite to Testers where to Test the assets)
• Allow Makers to better understand the version numbering and principles it follows

From the list above you may want to take your own look into this new feature, discover the capabilities and decide on which solution to go. For those being in evaluation of ALM for Power Platform –

I am sharing with you this visual that in addition to providing a list of all the current options available, it also provides a decision tree that you can use. This has been shared by Suparna on her blog page. Check out her content.

Finally, as I already received a couple of questions in regards to licensing. There´s a great example of a common setup experience provided in the FAQ section:

A common setup example:

Matching this example with a typical Enterprise customer´s licensing – you should have:

• Storage capacity entitled by given standalone licenses that allows for setting up a separate production environment that remains the Host for Power Platform Pipelines
• Standalone licenses for all end-users using solutions hosted in final Production environment

And if you ask how to evaluate on low-budget? Go with a Power Apps Developer Plan. It allows all environments to be turned on as Managed Environments. You can have at least three of them. Pipelines are a feature of Managed Environments. As such, the development and target environments used in a pipeline must be enabled as a managed environment.

Have a great evaluation time with Power Platform Pipelines and watch out the upcoming improvements. Until then, …