ALM within the Power Platform – A Compliance Love Story

A Bit of a Backstory

If you had asked me about ALM when I first began working in the Power Platform, I wouldn’t have known what you were talking about, and if you’d described it to me, I definitely wouldn’t have seen it as a benefit. Now, only a few years later, I can’t envision my job without it.

Stepping into the Power Platform was originally a personal, self-guided journey; I was looking into the tools available to me and wondered what potential Power Automate held. I was not a developer, and it was not officially within the scope of my job to develop solutions for my team. As I learned more about the Power Platform and showed my coworkers and managers the utility it had, we wrote my new job description to include a role known as a “Citizen Developer” – this was not how we worded it, but, by definition, this is what it was.  

At the time, I had not found a community to learn from; I didn’t know anyone else at my organization who was using these tools. As other teams learned of the apps I was creating for my own team, they recruited me to develop some solutions for them, as well. This was equally exciting and overwhelming – I was learning as I went and didn’t have a structure or basics to fall back on. It was as if I were learning to play piano without knowing how to read music; I was playing by ear and didn’t even know what a chord was.  

After I’d developed five or six solutions on my own at my previous job, I was introduced to the folks here, at Bulb Digital. It was liberating to have others that shared the same tools and language I’d grown to love over the last few years. After joining the team here, I was tossed into my first project in an official development role, and that’s where I first met ALM. This was not a Hallmark love story – there was no love at first sight and the only sparks flying were the ones created by the friction I felt being forced to reign in the unwieldy development I’d taught myself. It was a slow burn, but I’ve now come to love the structure and safety that ALM provides.

Let’s Conceptualize: What Is It and What Are The Benefits?

Application Lifecycle Management (ALM) principles provide a methodology of best practices for application development and maintenance, which is beneficial for both developers and end users. Microsoft has tools made for ALM that help communication among key groups and even automate deployments. At its core, the goal is to have your work move through clean and separated life stages. A copy of the solution you’ve built will exist for each step in the journey of development (and the maintenance that follows). In action, you’ll do development and updates in one place, then create a copy of the solution to be tested. Once bugs or gaps have been ruled out, a “final product” copy is made for our end-users.

What do we gain?  

• Users see new features when you want them to, after they’ve been tested.  
• You’re able to do maintenance on existing applications in a thorough manner without impact to the folks currently using the app.  

What are we leaving behind?

• Hurried, behind-the-scenes updates to the automation people are using.
• After-hours work to reduce downtime of an application.
• Taking a solution offline to make a change.  

Just a note - I don’t follow this for my personal automations or apps, this is to be used for larger-scale applications where multiple users will be interacting with it.

Let’s Make a Comparison to Video Game Development

What if game developers were not following ALM principles and worked on the same exact copy of a game that you were actively playing? Say they’re patching a section of the map and suddenly you fall through or they’re updating a texture and it displays incorrectly on your screen. Or they have to shut down the game while they’re making changes, and now you can’t even play. Sounds pretty messy, right? That’s why they have different “copies” of the game they work on. Folks can get “early access” to new features of the game or even be involved in a beta release – they’re playing a copy made for testing. If you’ve purchased a fully released game, you’re playing a production version.

How Can We Do This Within the Power Platform?

Let’s focus on the main, actionable item for Citizen Devs: separate life stages. The number of stages can vary based on the breadth of your project or other variables such as company policies. At a basic level, we need copy of the apps and automations and a data source for each step of the process.  

Create copies of your apps:

Microsoft has tools that help facilitate this process, such as environments and solutions. If you’re unfamiliar with environments, head over to Mike’s blog or watch his video to get a better understanding – if you still have questions, write out a comment on either and we’ll get back to you with more info. To give us some context, here is what Mike says:

Think of environments in the Power Platform as a way to create containers for your applications and data. These containers create boundaries that you can use to delineate purpose and secure data.

If you haven’t used solutions before, they’re more like subfolders within environments; my previous blog can provide an introduction. One environment can contain multiple solutions and they can be copied to other environments. If you need a demo, check out the video we put together to show you how to use solutions. These can be used to help you create the “copies” of your apps and automations for ALM purposes.

Create separate data sources:

Since there are a variety of ways to structure your data and apps, I won’t go into details about each method, but these principles can be applied across the board. If you’re using Dataverse as your data source, importing your solution into a new environment creates a copy of your data source. Another note – while this is my personal favorite, there are some licensing requirements that may prevent you from using it.

If you’re using another connector, such as a SharePoint list, you can leverage environment variables to point each copy of your solution to the appropriate list; Mike’s blog on environment variables can help guide you. Create a list with an identical structure for each stage of the development lifecycle.  

What Are The Lifecycle Stages?

For the basics, we’ll focus on three vital stages – here at Bulb Digital, we refer to them as DEV, TEST, and PROD; your company may have a slightly different set of abbreviations for them and may also have additional stages involved. As a reminder, the goal is to use a different data source (SharePoint list, Dataverse table, etc.) for each so that our data is separated, and to use a different copy of the app and automations for each stage so that updates can be made in a controlled manner.

DEV – Development

• What Happens: This is the only space where you do your work. It’s your space, as a developer, to build new features and make changes – your “real” users won’t have access here. You “overwrite” the other copies of the solution with this one after you’ve made updates; you do not make direct updates to the other copies of the app.
• Who is Involved: The development team, possibly service principles and service accounts.

TEST – Test

• What Happens: I bet you can guess what this is for – testing! After you’ve created a solution or a new feature, this is the first stop it makes after the development stage. I like to invite a small group of what I like to call “superstar users” to help me “try to break” the apps and automations I’ve put together. They help quality check the things you’ve built and use scenarios that they, as real users, will encounter as they use your application. The data in this environment is separate from the “real” data; we’re able to test new features that could negatively impact our actual data, without risk.
• Who is Involved: Service principles, service accounts, and a small group of real users and product owners; these are folks who understand what the ideal function of the application will be.  

PROD – Production

• What Happens: This is the “real” application; it’s the solution’s final stop in its journey, it’s the end goal. Only features that have been vetted in the test environment will make it here. The production data source should not include any testing data since this is done separately, so there is no clean-up process. You’ll be able to know what your users will experience in production because it has been tested in the test environment first.
• Who is Involved: All actual users, service principles, and service accounts.

To summarize, the only place you make changes is in the development environment (aka “copy”); once you’ve made these changes, you’ll overwrite the current version of the TEST app with the latest version of the DEV application. After it’s been thoroughly tested, this same version is used to overwrite the PROD app. If it requires more changes before it’s suitable for production, go back to DEV, create your changes and push them to TEST; the process is not linear, it’s iterative. When you follow the basics of ALM, by the time your solution makes it to production, there should not be discrepancies between the copies in each stage.

My “Happily Ever After”

After a few frustrating experiences with ALM, I had called it off for a short time and we went our separate ways. I had been working on a project outside of the structure it provided when I realized I’d made a mistake and that we were meant to be. Maybe it was a classic Hallmark movie, I didn’t know how good I had it with ALM until we were no longer together. I had to wait until late in the evening to make an update to a support request app in production (since it was the only version of the app), quickly test it, then cross my fingers and hope I’d ruled out any bugs.  

The process was rushed, and I found out I had a bug after my team had missed a few incoming support requests; I regretted ever calling it off with ALM. If I’d had a separate development stage, I’d have been able to slowly make my changes during my normal work hours. If I’d had a separate testing stage, I could have worked with real users to catch the bug I’d overlooked. It wasn’t that ALM was flawed, I just didn’t understand the system. The separation of the stages of development creates space that allows for a more thorough and thoughtful solution to be developed – and that’s my ultimate goal.

Additional Resources

If you want additional information on this topic and related tools, Microsoft has plenty of documentation available – here are some starting points:

• Overview of ALM  
• Power Platform Environments
• DevOps Build Tools
• Setting up Pipelines
• ALM for Developers
• DevOps for Automated ALM