Power Platform ALM – Basics by CRMK

What is Power Platform ALM? In this post we’ll go through the basics of ALM, as we at CRMK see it.

The application lifecycle describes the complete circle an application normally does over and over again. The following image describes which elements are included in the Application Lifecycle. 

The Management of this lifecycle is called ALM, Application Lifecycle Management. In the ALM process, each of those 5 aspects should be included. However, we normally focus on only 3 of those steps when we talk about ALM. Those are: Test, Deploy and Maintain. 

When it comes to the Power Platform the word ALM is often only used for the deployment part only and is mostly associated with automated deployments. 

In a lot of our projects, we have seen that this particular part, automated deployments, is the part our customers struggle with the most. Therefore, it is also what we will mostly focus on in this article.

Before one is going into detail of automated deployments we also have to think about other parts of the whole. Those are the Environment structure, solution structure, repository, and users.

Let’s dive a bit more into each one of those.

To be successful with a “healthy” ALM process we need at least 3 environments. We need one development environment where all our changes are made. The solution would then be deployed to a test environment. When all changes are tested and accepted the solution will be lift to Production.

In addition to those 3 environments, there could be more environments. Either in the pipeline or on the side as “supporting” environments.

In the pipeline we could for example have another second Development environment where the customer itself is making changes (or another team).

Other more supporting environments could be for performance tests, evaluation (of new product releases from Microsoft) or hotfix environments.

Another important part of ALM is the target structure of your solutions.

One thing which is recommended both by Microsoft and CRMK is having all the environments besides Development deployed as Managed.

But also, which solution(s) you have is a key factor. Microsoft’s recommendation is to have one environment per unmanaged solution. Despite this fact, we tend to have several unmanaged solutions in one development environment if there is a need for them. Those could be a solution for DataSources or Automatic Record Creation (ARC) rules.

Microsoft’s recommendation for a healthy ALM process is to store an unpacked version of your unmanaged solution. This is best done in a repository. We usually use the same repository where our code (plugins, TypeScript, and so on) is stored as well. For projects which do not have any code (plain low-code or even no-code projects) we still create a repository to store our solution as well as the automated export and deploy pipeline yaml definitions.

Before you go and create your automated pipelines it is a good recommendation to invest some time in setting your user strategy. In this case we mean the credentials needed to deploy your solution as well as use in your solution.

Usually, we use an Application Registration (or Service Principal) as the user who deploys the solution. This has the advantage that all components are owned by this user as well which ensures that they stay active when developers leave the company.

In addition to the Application Registration, you also could have the need for service accounts depending on which flows/connectors you are using.

As you see there are a lot of different areas to cover when it comes to ALM.

Here you can find more information from Microsoft related to Power Platform and ALM. 

If you now got interested in the whole ALM topic don’t hesitate to contact us. We can help you get started as well as improve an existing ALM process.

// Benedikt Bergmann, Microsoft Business Applications MVP