ALM Accelerator
Practical aid or an unruly black box?
The ALM Accelerator is an independent part of the Center of Excellence (CoE) Starter Kit provided by the Microsoft Power CAT Team. It is in public preview since January 2022. As the name ALM accelerator implies, it’s a tool which intends to make the Application Lifecycle Process for Power Platform Solutions easier and faster. Admittedly, when I first read about it, I was quite skeptical. I thought that this is just another “black box” which would only suit for very little scenarios, leading to the situation, that in almost every “real-life” scenario, lots of modifications would be required to handle all the exceptions that usually occur. And those exceptions would have to be handled again by professional developers with deep knowledge of Azure DevOps, whereby the advantage of this tool would get lost.
In the meanwhile, we also surrendered our ambitions to configure our own DevOps pipelines. After investing quite a lot of efforts, we managed to create a more or less robust solution for individual projects. But the configuration and maintenance efforts were so high, that the required effort would never pay off for smaller projects. And as we are dealing mostly with smaller Power Platform projects, this was not a viable practice for us.
That’s why I recommend (in the first line to citizen developers) to handle ALM requirements for most solutions following a baseline process similar to this:
From the development environment: Export Solution (managed and unmanaged)
Upload both solutions to a repository
On target environment:
Create connections
Import managed solution
Set environment variables
Start Cloud Flows
Verify and fix connections in Canvas Apps
If the solution consists of additional components like “Dataflows”, “Custom Connectors” or anything else, we extend the deployment checklist with additional instructions.
Of course, most of those steps could also be automated by writing some scripts with PowerShell and the Power Platform CLI. But this would lead to unwanted dependencies from IT-Professionals again.
After all, a tool like the ALM Accelerator could definitely make sense, if it would be able to handle most of those exceptions. In the last months, the Power CAT team has released several new versions containing lots of improvements. That’s why I thought it’s time to give it a try now.
Understanding the concepts
Even though users (usually Citzen Developers / Makers) of the ALM Accelerator do not necessarily need to understand the detailed concepts of ALM with Azure DevOps, at least the person who is installing and introducing it, should have a solid understanding of both, the technical architecture of the Power Platform and the concepts of Azure DevOps.
There can be found quite a lot of documentations on Microsoft Learn (formerly Docs). Unfortunately those are quite confusing, incoherent and incomplete. I assume this is due to the fact that the ALM Accelerator is still in public preview. I sorely missed an overview of the process, which is covered by default.
That’s why I drew the following diagram after doing some research of the solution:
Default ALM Process from the ALM Accelerator
The ALM accelerator basically consists of the following components:
The “ALM Accelerator for Power Platform” (Canvas App)
This is the core app which is being used by the makers/developers in order to trigger the desired steps in the ALM process:
Import Solution - This imports an unmanaged solution from an existing repository to a development environment. This can either be used to create a new development environment or to update or restore an existing one.
Commit Solution - This copies and extracts the solution files to a Git repository on Azure DevOps. In other words, this creates a copy of the current development version in a repository to keep track of changes and having a copy for further deployments.
Deploy solution - Simply said, this deploys the current version to the selected target environment.
Note: The ALM Accelerator has the option to act in different modes (“Deployment User Settings”) which can be configured in the Administration app. Depending on that you can either simply select the target environment, e.g. “Test” or “Prod” or you select the source branch and the target branch of the current solution. In the default settings, this step initiates the deployment to a validation environment and created a “Pull Request”. A “Pull Request” in this context is a confirmation that the validation was successful. After this confirmation, the solution gets deployed to the target environment.Delete Solution - This is a nondescript feature which is quite smart. If you have ever tried to delete an unmanaged solution, you probably noticed that this isn’t as easy as expected, since the deletion of an unmanaged solution won’t delete its components. Therefore, this feature installs a managed solution and deletes it right afterwards. Like this, also the belonging components get deleted.
Configure Deployment Settings - This very useful part is addressing many of the challenging details when it comes to an automated solution deployment. For instance, these settings allow the preparation of connections, definition of environment variable values, flow ownerships, flow activation order and much more. These settings are stored in the repository and applied during the deployment steps.
ALM Accelerator for Power Apps (Canvas App)
ALM Accelerator - Configure Deployment Settings
The “ALM Accelerator Administration”
Deployment User Settings - This is the place where different user profiles can be defined. There are quite granular permission setting that can be made. Additionally, some labels from the main app can be renamed in order to make it easier to understand for non Pro-Developers.
Deployment Profiles - Every solution which gets managed by the ALM Accelerator has to be assigned to a “Deployment Profile”. A “Deployment Profile” defines the Azure DevOps Organization, Project and repository, as well as the deployment stages, the stage order, the source and target branches and a lot more I didn’t figure out yet, which gets hopefully a bit better documented in the future.
Deployment Requests - This is the log which stores all the requests that have been made in the “ALM Accelerator for Power Platform” App.
Projects - This is a very powerful area of the tool, which allows you to easily create new Azure DevOps Projects that include everything needed in order to be managed by the ALM Accelerator. For instance, it automatically creates a new repository where the deployment pipelines are stored. Or it sets permissions, variable groups and service connections for the environments involved in the ALM process.
Azure DevOps Projects Overview
Pipeline Templates
The pipeline templates are the heart of the ALM Accelerator. Everybody who looks at the details will notice that there’s a lot of know-how in them, and they’re very sophisticated. The pipelines get automatically created by the ALM Accelerator based on a template repository as soon as they’re needed.
The most important pipelines are:
export-solution-to-git
deploy-ENV-SOLUTIONNAME
Note: Those pipelines consist of lots of individual steps trying to anticipate the most common use cases, I’ve mentioned at the beginning. A summary of all pipelines and their parameter can be found here.
Conclusion
The ALM Accelerator is in public preview since quite a while. The pipelines are highly sophisticated. In the meantime, the tool as a whole makes a fairly mature impression.
Once the solution, the Azure Project and all the environments are set up, it’s quite easy to use, also for non it-professionals and definitely reduces the deployment efforts. This finally reduces inhibitions from adopting professional ALM, which finally considerably helps to ensure quality by always keeping track of any changes made to a solution and separating development, testing and production activities. Preconditioned that the pipeline run without errors.
Ensuring mid and long term benefits will be highly dependent on maintenance and involvement. Meaning a seamless adoption of new Power Platform components and features. Maintaining those complex pipelines will always be a costly task for IT-Professionals specialized in Azure DevOps and the Power Platform. Probably this is not just costly but also a bit risky, because such resources are rare to find. Thankfully, the Power CAT team currently puts much effort in it, and we can benefit from it. Of course, this leads to dependency on them. This is why I recommend not to do too many customizations in order to stay upgradable.
In the future, the ALM Accelerator has to prove if the benefit outweighs the efforts for maintenance and the ease of troubleshooting pipelines which do not run as desired or got stuck. I’ll definitely be following this topic this with interest.