In one of my last blog posts, I have shown you my ALM process optimized for my Citizen Developers. I have used a solution based on a Power App and some Power Automate Flows to run a fully automated solution export and import in Dataverse. You remember also my simplified process focused on the needs of a Citizen Developer:

This slim process is great for Citizen Developers to get started with ALM. But I’m a Pro Developer – I need more!

I want a Professional ALM process! This is because I use Azure DevOps, track my development changes in a source code management system (Git). Furthermore, I add automation pipelines in Azure DevOps to my ALM process to build and roll out my solutions. All the fancy technical stuff which I love!

I do this, because I want to avoid manual work for repeatable tasks. I use a standardized process for ALM for every single solution.

In conclusion, my Pro Developer ALM process is also an infinite loop, but with additional steps for SCM, build, test, …:

And yes, I include my Citizen Developers. This is because, my Citizen Developers are the main part of the whole process. A Citizen Developer drives the digitization process of a company. In conclusion I must empower my Citizen Developers to be part of ALM without the technical background of a Pro Developer.

Home-made or open source?

2 Years ago, I hadn’t a real option. But today – good news, we have the choice.

Early this year, Microsoft have introduced the ALM Accelerator for Power Platform (AA4PP) as open source solution at GitHub. The solution is part of Microsoft’s Center of Excellence Starter Kit and helps Makers as well as Pro Developers to establish an enterprise grade Application Lifecycle Management process for Dataverse.

Let’s start with the ALM Accelerator for Power Platform (AA4PP)

On the first look, the ALM Accelerator is a Dataverse solution containing a nice looking canvas app. This is because the canvas app hide the technical Pro Developer stuff from Citizen Developers. Behind the scenes, is Azure DevOps with it’s repositories and automation pipelines.

Initially the ALM Accelerator for Power Platform solution must to be installed in a Dataverse environment. Additionally, you need to setup your Dataverse environments and application users. Afterwards, the Azure DevOps project must be prepared and configured. Finally, both parts must be configured to work together and are able to run the magic of ALM…

Setup ALM Accelerator for Power Platform

In other words, I need to setup something in my Azure Active Directory, Azure DevOps project and my Dataverse environments:

Technically, it’s a lot of stuff and a nightmare task to do this manually. Kudos to microsoft, there is a better way. I can use the CoE CLI from Center Of Excellence Starter Kit to setup all my needed components:

All I have to do is to use these commands, answer the questions and run the installation:

# collect setup information
coe alm generate install -o setup.json …

# install AA4PP
coe alm install -f setup.json …

As result, my AA4PP Canvas App is presenting information from my environments and available for my Citizen Developers:

… and my Azure DevOps project is prepared for Pro Developers with configured pipelines and repositories:

Environments

First of all, I need an dataverse environment where my ALM Accelerator solution is installed. In my case it’s the CoE (Center of Excellence) environment.

As you already know from my blog posts, a classic ALM environment should have DEV, TEST, PROD environments like this:

Furthermore, the ALM Accelerator for Power Platform uses also a VAL (validation) environment. It’s used during deployment. I’ll explain this later.

In conclusion we have these environments:

• CoE … where my ALM Accelerator solution is installed
• DEV … my development environment to develop Power Apps and Cloud Flows in my solution
• TEST … the test environment for my stakeholders to test my releases
• PROD … the production environment for my released solutions
• VAL … as validation environment for the ALM Accelerator

AA4PP for Citizen Developers

As a Citizen Developers, I’m focused on developing Power Apps and Cloud Flows in a solution.

Getting started means: Either I start from scratch and create a new solution or I have to restore an existing solution.

Create New Solution

I start from scratch. In conclusion, I create a new solution in my DEV environment, add my components. And now? Yes, I need to add this solution to my ALM process.

First of all, I add my solution to the Azure DevOps Git repository as a new branch. For that, I use as a Pro Developer the CoE CLI:

# Add a solution branch
coe alm branch --source main --destination MyUniqueSolutionName ...

Additionally, I must assign a solution profile in my ALM Accelerator app for my solution:

The solution profile specify where in Azure DevOps my solution will be stored and which dataverse environments are used for deployment in VAL, TEST, and PROD. I can use an existing profile or create a new one:

Finally, I start the development on my canvas apps and cloud flows…

Restore Existing Solution

Let’s assume: I start with a new Development environment. My solution already exists as source code in an Azure DevOps Git repository and I want to continue developing the solution …

For that the ALM Acceleratore support me to prepare my development environment. I can import my solution from source code:

In detail, AA4PP trigger a pipeline to restore the unmanaged solution from my Azure DevOps Git repository into my Dataverse environment. I select a prepared profile with information about my project, repository and solution folder.

Finally, I start the import. After some minutes my unmanaged solution is imported in DEV and I start with development…

Save my Solution Changes

When I finished my work, I want to save all my changes. In other words, I commit my solution:

The selected profile define my target repository in my Azure DevOps project. Furthermore I can separate my work into an own development branch. This sounds very technical, but make definitely sense for me as a Pro Developer.

Branches

Let me explain this. It’s all about SCM (source code management) and deployment environments.

The ALM Accelerator stores the solution source code in an Azure DevOps Git repository. By default, source code from the main branch will be imported as a managed solution into my PROD environment.

When I start developing a new solution, I create a branch for my solution with the Coe CLI. I fork this solution branch direct from my main branch. Remember the command parameters “source” and “destination“:

coe alm branch --source main --destination MyUniqueSolutionName ...

I create a new branch because I want to test my solution source code as managed solution from solution branch in my TEST environment. In other words, I use the solution branch to stabilize a solution before I ship my release into PROD.

And finally, I export my finished work as a Citizen Developer frequently from my DEV environment into my personal developer branch. If my developer branch does not exist, AA4PP fork my corresponding solution branch during the export and create my developer-solution branch:

As result, each of my solutions exist as source code in 3 branches:

• main branch
• solution branch
• developer-solution branch

… and each solution exist as datavers solution in my environments:

• in PROD as managed solution (current release)
• in TEST as managed solution (next release)
• in DEV as unmanaged solution (my development version)

Connections, Environment Variables, Owners, …

What is still missing? Right – I must configure my deployment settings for all target environments!

In other words, my solutions contains canvas apps and cloud flows. For this, I must specify who is the owner of my canvas apps and flows in my target environments. Furthermore, I want to share my canvas apps or cloud flows automatically, active the flows, …

Oh yeah, I also use connections, environment variables, and much more in my solution. The ALM Acceleratore canvas app helps also to setup this information for me.

Finally, my prepared settings are used during the automated import by Azure DevOps pipelines into my target environments:

With the ALM Accelerator I have now the chance to prepare all components for my automated rollout to each deployment environment. Perfect!

Deployment

The million dollar question: How do I trigger the deployment?

As Citizen Developer – it’s just a click to the right button:

Afterwards I enter my release notes – I describe my change like “Title” and “Release Notes”:

Hmm, I also must select branches… Remember, each branch stands for an environment. In other words, I specify here which changes – my source Branch – are transferred into which target environment – my target branch.

This means I can transfer:

• Changes from my developer-solution branch into my solution branch – deployment into TEST

or

• Changes from my solution branch into my main branch – deployment into PROD

Finally, the action Deploy Solution in my ALM Accelerator results into an Azure DevOps Pull Request.

Pull Requests and Branches

Ok, another “bad word” for a Citizen Developers and again it’s related to source code management. This means: I want to pull over (transfer and apply) my changes from a source branch into a target branch.

It is called Pull Request, because there is a valuation and an approval in this process. In detail, a policy invoke a test installation in VAL and might add some an reviewer for approval:

Nothing special – just a little bit “Pro Developer Magic”…

My Pull Request can be completed only when all checks are valid. Afterwards, my source code changes are merged (applied) my target branch and a deployment pipeline in Azure Devops starts.

The new managed solution file is now generated based on the merged source code. As result this solution is imported in the corresponding dataverse environment. Finally, the prepared settings (Owner, Connections, Environment Variables, …) are applied to the solution components in the target system.

And now we are finally leaving the world of Citizen Developers…

Summary

The ALM Accelerator for Power Platform is in my opinion an amazing tool. The AA4PP helps Citizen Developers to accomplish the necessary tasks in the ALM process without a deep technical understanding of Azure DevOps, pipelines or Git repositories. In conclusion a Citizen Developer is still the main part of the development process in dataverse.

On the other side, I as a Pro Developer get an enterprise ready ALM process. First of all, I have source code management for my solutions. Secondly there is an enforced validation with possible reviews during pull requests. Finally, the best part: only pipelines install my dataverse solutions…

Both worlds – Citizen Developers AND Pro Developers – are combined in professional application lifecycle process. Kudos to Microsoft!