Application Lifecycle Management 🛞

If you just Google Bing it, it will show you a lot of circles.

It’s going round and round and never stops…

My focus is probably only a part of it, so I focus on these five slices:

🧑‍💻Develop – 👷‍♀️Build – 🧪Test – 🚚Deploy – 📢Release

It’s actually in one of the images above:

This is “my ALM“, and it goes round and round and gets back around again – forever…

I’ve never been in a project where we just go from A to Z, and then we’re done. Are you? I guess not. So…

We iterate.

Power Platform Solutions 😍

It is wonderful that it is sooo easy to do all things with Solutions!

But it’s sooo easy to do it in the wrong way…

You really need to know about Solutions – if we are in the Power Platform area. There is nothing “I’ll read it during my vacation, one day” – just do it now.

I’ve been talking and writing (e.g. Case closed: Managed or Unmanaged solutions) about why you should use Managed solutions for a long time. Scott Durow wrote (Pets vs. Cattle – How to manage your Power App Environments) similarly; but stayed away from the discussion.

You should probably start by reading Microsoft Learn – Solutions overview. Please do. 🙏 Then you continue here. Ok?

Untangling Solutions

Too many times, I have got in projects trying to untangle dependencies to finally find what their system is really what they actually need.

Why is that? How can it be too easy to tangle up the solutions?

I’d like to say:

Without a proper ALM, you are asking for problems.

Without a proper ALM, you get two risks: Unmanaged Solutions and trying Inconsistent Products compared to your environments.

Unmanaged Solutions

Used too much to create a new solution might be a “Sprint 5 Solution” or a “Jonas Quick Fixes Solution” and when it is fixed/done, imported to Test and Prod as an unmanaged solution. Sure, we can remove that solution to “clean it up”, but the components in that solution can never be removed by removing their solution. Unmanaged solutions only contain points to the components, but they are owned by the Default solution. And the Default solution can not be removed. Period.

Inconsistent Installs

A classic problem is installing a new product in Dev or Test, just to test it, and then you can’t import your solution in the Prod. Now you have created – probably without even knowing it – dependencies between the tested product and your own solution.

🧑‍💻 The Develop slice

The development covers: setting up the data model, views, forms, canvas apps, flows, and more techy stuffs; javascript, typescript, and C#. So we shall not be narrow to only look at low/no-code technology. Though also not only “the code” either. We just talk about everything…

Commit e v e r y t h i n g ✅

You should survive even if all environments blow up badly and you have nothing left. You should be able to recreate both DEV, TEST, and PROD from the source control.

The committed files are the Source Of Reality.

Notice the difference between “pets” and “cattle“. These environments are not pets. They are cattle. Period.

There are interesting discussions on the difference between pets and cattle – here on StackExchange, and here from cloudscaling.

Even if nothing has been blown up for you, creating a new branch development environment should be easy!

So the development environment is where it is designed and built – but it’s not the Single Source Of Truth.

👷‍♀️ The Build slice

Pipelines

After the Develop slice, we start using the Azure DevOps Pipelines 🥳 (Note that you may use GitHub Actions as well.)

I’ve been working with pipelines for a long time, and I love it. I started with WISE in the ’90s, and then I used the Pipelines in Azure DevOps. Back in the day, only tools from the community existed, and even I created a few tools that we just needed. Now there are Build Tools for the pipelines related to Power Platform. The best community available is created by Wael Hamze – read it, use it when needed!

Something bad happened a few years ago… MS says that we are going roughly 30 years back in the technology. Stop with a decent UI, and go back to simple texts. Actually worse than before – now everything is broken with a small <space>. This is the idea of YAML.

I will only say this once, but…

I hate YAML.
Yes, I truly do.

/Jonas A. Rapp

Now move on, we like pipelines anyway. But read the docs of YAML, and you’ll love it too. Not.

Purpose of the Build slice

Two main things to do here: pre-testing and getting an artifact.

Pre-testing (=unit testing) should be written in the Test slice, but since we are using a phenomenal pipeline, unit tests will be executed during the Build.

Artifact means the result of the build, what we bring to the next stage – Deploy slice. An Artifact can contain a compiled exe-file, a dll-file, a full installation, or a managed Power Platform solution.

🧪 The Test slice

The Test isn’t really a separate slice. Instead, it is included in both Develop and Build.

There are two types of tests:

The first ones we can automate are done during the Build pipeline. Both unit tests in C# and TypeScripts are run there as the Solution Checker from Microsoft.

The second one needs to be used manually, so technically, it is done after the Deploy pipeline to be able to have an updated environment with our solutions.

Note: you can test it in the DEV environment before even starting the pipeline – but you shouldn’t!!

Test Environment

Where do we test? Everywhere, of course…. but we focus on one or a few different environments.

There may be a simple TEST, there should be a UAT (User Acceptance Testing), there should probably be an SIT (System Integration Test), and there may be even more environments for different purposes.

Regarding how many testing environments we have, we can quite simply add more targets for the Deploy pipeline.

🚚 The Deploy slice

Deploying seems hard… but that part it’s really simple. Basically, it means “Start to use this new artifact.“

The general way of deployment pipeline is just:

1. Install the exe-file. (or similar)

It is actually quite close to our Power Platform deploy pipelines, but a few more steps in it:

1. Get solutions from the Artifact
2. Import managed solutions
3. If needed, apply solutions updated
4. Apply setting file
5. Update data

Deploy Environments

The Deploy environments are quite obvious – the environments for tests (TEST, SIT, UAT, etc.) and, finally, the goal we have to deploy to the Production environment, and the end users can now use our awesome features.

📢 The Release slice

This slice is mostly an administration task.

My personal thoughts are: this means we have created this build, tested it and accepted it, deployed it to the test environment (actually in the wrong order… but anyway), and now it’s ready for an official release with this version. But it’s more a statement than a technical issue.

The technical part can be to retain the created artifact.

Conclusion

This post is not an official statement; this is just what I think, what I like, and what I truly believe in. I have seen too many projects and maintaining systems that are all working too hard – too unsure, too much ´we’ll wing it‘ and too much crossing-fingers-lets-hope-it-works-today kinda attitude.

That really hurts me. Why are so many pros working too hard? I don’t know.

There may be better ideas than mine, of course, but this is what I like to share with you.

Do you really want?

• Do you want to have a great system or to deliver a great system? If you have read this far, I’m sure you do. Thanks for that 🙏
• Do you want to be able to upgrade to even newer features, when they are available?
• Do you want to be able to – in the worst case – need to roll back to a previous release?
• Do you want to find out when who did what?
• Do you want to see how the system really works, instead of being lost in repositories?

I can go on forever with reasons… but now it’s time to finish it up.

Or maybe put like this:

🧑‍💻Develop – 👷‍♀️Build – 🧪Test – 🚚Deploy – 📢Release