ALM is a term being used more and more around the Power Platform and covers a wide area of topics. In this series, I want to take a deeper look at it and use a project of mine to illustrate the process with lots of examples.

Let’s start with the most obvious questions: What does “ALM” even mean? 🤔

ALM is short for “Application Lifecycle Management” and is most commonly used to describe the combination of processes, tools, and most importantly people to manage a product or app during its complete lifecycle from development, testing, deployment, production usage, feedback and so on. You can imagine that this in our SaaS world usually ends up being a circular process diagram, software is never “finished” so we need processes for that. I won’t go into more theoretical details here, but instead, want to show you a practical implementation of an ALM process I like to use specifically with the Power Platform 👍

✨ Overview & general process

The process can be structured along the lines of how you would develop a typical project. Just remember, it’s circular, so you will always start over again.

Since ALM is such a wide term used for so many different things, we will first focus on the technical parts of it:

  • Development
    • Develop low-code parts in Power Platform instance
    • Develop pro-code (Plugins/JavaScript) in Visual Studio
  • Source Control / Versioning
    • Store all changes in a repository
  • Build
    • Automated builds for every change
  • Release
    • Automated or semi-automatic releases to all relevant pipelines

Also, I am going to link to other blog posts from the community because there already is a lot of great content out there on this topic. I’m excited to see that so many people working on this and that it is becoming more “mainstream” 🙂

🧱 Power Platform Fundamentals

The first process picture could properly be used for all kinds of different software projects/programming languages, so let’s make it Power Platform specific to be useful ✌

In Power Platform the main construct to move customizations from one environment to another is a “solution”. Think of it as a folder. A solution/folder can hold any number of different customizations, from tables, columns, views, forms to processes, flows, and virtual agents. Microsoft is working hard on making everything “solution aware” meaning you can transport it with a solution. Especially in the last 12 months, they made huge steps towards this goal 👍

One other very important distinction is the difference between “unmanaged” and “managed” solutions. Coming back to the folder analogy, “unmanaged” is just like a folder, where you can edit everything inside. But “managed” is like a zipped folder, you can not just go inside and start modifying its components.

Microsoft defines it like this:

  • Unmanaged solutions are used in development environments while you make changes to your application.
  • Managed solutions are used to deploy to any environment that isn’t a development environment for that solution.

Pretty clear, right? 🙂 There has been some discussion in the community regarding this, but in my opinion, nowadays nothing is prohibiting you from following exactly this approach. Don’t take my word for it, but here is Microsoft MVP Jonas Rapp recapping the discussion: https://jonasr.app/2018/09/case-closed/

For a more hands-on instruction on solutions, I’m recommending to take a look at a fresh blog post from Michael Megel “Application Lifecycle Management for PowerApps: Solutions” which gives a great introduction to solutions and how to create and deploy them manually.

The whole ALM concept I’m going to present in this series will be based on solutions.

  • In the Development phase, we will create solution components in low-code and pro-code ways
  • In the Source Control phase, we will store that solution in a compatible way for releases and backups
  • And in the Build and the Release phases, we will use that solution to deploy to multiple stages.

As you can see, solutions are whats holding the whole ALM process for Power Platform together so if you haven’t tried it yet it’s a great time to get started 🚀

📖 Next steps

I started writing this blog post but quickly realized that it will be too much content for one post. Hence the series was born. In the next part we will take a closer look at our business case:

Creating a small application which consists of multiple solutions, an anchor solution with the table definitions and a dependent core solution which has processes and logic. To keep manual steps, we want to store implement this ALM process and automate the deployments of our anchor solution to keep our dependencies in order.

The next step will be using Visual Studio to extract solutions from Dataverse environments and store them in Source Control.