Introduction
In this post, I want to discuss an essential concept in the software industry: package immutability. It is relatively easy to understand and implement in most software projects. However, because of its mechanism, it needs more work in Power Platform projects, and sometimes, it is missed.
Let’s investigate the idea first.
Note for new readers: This is number four in this blog post series. If you are new to this series, I recommend reading the previous ones if you haven’t because the concepts I explain are in order. Also, I gave an example in the second post and continued discussing it.
Here are the links to previous posts:
- Part 1 – Introduction – Here, I defined some words that I often use them in the whole series including the current one.
- Part 2 – Basic Component Lifecycle – The basic component lifecycle is explained here, and why we need more than one environment.
- Part 3 – Test Stage – Why do we need a Test or UAT environment and primary way of deploying components
Immutability of packages
Let’s examine two open-source projects. Usually, each open-source software has a release page on which it publishes the newest release package and explains what is inside.
Example 1
For example, here you see the release page of a photo editor application called PhotoDemon.[1]
This PDF import was a big hit in this application, and they announced it with that picture. However, in the red marked place, you can see more features they implemented and put in this version (2024.7). They mentioned that export is coming soon, and we can expect it will be added in a version such as 2024.8 or 2024.7.1, depending on how they number their versions. It doesn’t matter; what is important is that we are sure it won’t be the same version we see in this picture. Additionally, you can download this version and expect to see the features defined in this release notes.
Example 2
Another example is Visual Studio Code, a Microsoft open-source application that is an ALM university in itself. Look at the left part of the picture. You can easily find out that they have a monthly lifecycle. This picture shows its latest version, according to the time of this post: version 1.92. You can see in the image that they published and updated 1.92.1 and 1.92.2, which address some issues, and a link to them.
You will see the following picture if you click on the issues for Update 1.92.1. They can trace these eight issues they could resolve before their next release. I highlighted one of them, and as mentioned, they could find an issue in version 1.92.0, and they were able to reproduce that bug and resolve it. Then, they released a new version, 1.92.1, that addresses this with seven more.
You might know many more examples. Although each announces its new releases differently, there are some similarities, too.
These are the ones I want to focus on:
- Consistent behavior in versions. You can’t expect to download one of them and see behavior other than what the release notes explain. It is as apparent as it looks like oxygen in the air, right?
- Unique version and Traceability of changes. The release notes do not include a repeated version number. As you can see in the Visual Studio Code example, they found some bugs in 1.92.0 after its release, fixed them, and released them as a new version, 1.92.1. Next month, they will probably release a new version 1.93.
We investigated the features of immutability here. In short, their software packages are immutable. When packages are immutable, both end-users and developers expect consistent behavior.
Keeping this consistency is crucial for the lifecycle of an application or, in our terminology, magic. We will investigate this further, but we have learned the concept for now.
Immutability in our deployment
Assume that in any of the above open-source examples, it was possible for you or any other end user to download and install the application and change what is inside their package. So, we couldn’t expect consistent behavior in the installed application, right?
Or assume you could update the package version after installation. Then, you could break the traceability of changes.
In short, the following break immutability:
- Updating the version after installing
- Adding, Editing, or Deleting one or more components in the package
Recalling the section “The problem in comparing components” in my previous post, there was a critical question: Are these components that we deployed to production the same as what we deployed to UAT? What if someone edited them again afterward? Last time, our admin started fixing the problem right in production. What if he doesn’t know we should not work directly in production?”
These questions addressed immutability. As you might remember, here is our situation:
- We used an editing solution (unmanaged solution) and were able to update the version after importing it.
- Besides that, our admin was able to change the components after the import
Yes, our deployment was not immutable. That was our problem.
Problems of Mutable Packages in Power Platform
1) Troubleshooting and support
It is hard to reproduce a bug when you don’t have consistent behavior in different environments. Reproducing a bug is a software concept that means you know the exact steps to take to produce that bug in another environment. This is essential in finding and fixing a bug in your magic. It is necessary to have consistent behaviors of your magic in different environments.
2) Traceability of changes
When solutions are immutable, any changes must be made by creating a new version. This practice allows for better traceability of changes, making it easier to identify which version is deployed in each environment and ensuring that all updates are intentional and well-documented. You can see it in the Visual Studio Code example.
Now that we understand immutability and its importance let’s see why Power Platform environments tend to be more mutable than immutable.
Mutable Essence of Power Platform Environments
First, we must acknowledge that Power Platform Environments are, per se, mutable. That’s because of the capability of editing inside the environment. Immutability is not a switch to turn on or off. Instead, managing immutability in Power Platform projects requires more concern and practice than classic software projects. Therefore, we need to understand more and then act more.
Are you still with me regarding the names I defined in the first part? Let’s see them again because I need them in the following section:
- Component: the building block of a Power Platform project.
- Editor: Recognized as studio, designer, or whatever else you use in Power Platform to create or edit a component.
- Environment: A place where you can both create/edit components and use them in working mode.
Let’s delve into the environment and how components are stored.
Layers of storing components
Do you remember the following picture of how components are stored in an environment?
Well, that was part of the truth. Logically, there are two essential layers that components can reside in inside an environment, and I didn’t show them in this picture to keep it simple.
Now, it is time to turn on the lights in the environment to see the whole truth:
Indeed, our components were stored in the topmost layer, the Unmanaged layer. As the name implies, it is the layer on which you can’t manage immutability.[2] It is unmanaged; there is no control over changes. You change components, and tracking what has been changed is not easy.
In the previous post, I introduced the solution type called editing solution. I intended to convey the concept of solution in a simple way until I could explain the unmanaged layer. Now, you should know the Microsoft term is the unmanaged solution. Also, we should know when we deploy an unmanaged solution, we move it together with the components inside to an unmanaged layer.
Component lifecycle and Unmanaged layer
Knowing the unmanaged layer, we must investigate component modes again and understand their relationship with the environment layers.
Let’s see this picture again from previous posts.
As you notice, these are component modes that editors can provide. The following picture shows their relation to layers. Indeed, the component modes we have learned so far make our package mutable.
To elaborate, you can open editors inside an environment and start creating, editing, or deleting your components. Whatever you do with editors is stored inside the unmanaged layer, where you can’t manage immutability.
In addition, an unmanaged layer is a place where you can create unmanaged solutions. Unmanaged solutions can never reside in managed layers, which I will delve into in upcoming posts. Even when we deploy unmanaged solutions, they will reside in the unmanaged layer of the following environment.
Do you remember how we provisioned our development environment and moved our components from production to development? (Explained in Provisioning Develop Environment in the previous post).
Indeed, in terms of layers, this was the reality:
That was indeed good practice. Because we wanted to provide a development environment, we needed to move the components into an unmanaged layer in the Development environment to continue working with editors. Using an unmanaged solution was the best way to move the components into an unmanaged layer in the development environment and continue working on them.
But what about the other environments? Let’s look at all our environments.
Indeed, every time we deployed our unmanaged solution, we deployed it to an unmanaged layer.
I guess you can recognize the problem. We did right in the development environment I explained above. But what about UAT and production?
Given what is said in this post, do you think we should manage immutability in them or not? Don’t we want consistency in the behavior of our magic when users start testing it? And after they accept it, don’t we want consistent behavior after deploying to production?
Instead, we deployed the Bizchitect Recruiters Solution to UAT. It resides in an unmanaged layer, which means we can edit it. Everyone with the same privileges as us can edit the Job Offer Table, change its forms, edit the security role, or add some steps to the cloud flow. The same can happen in Production. Worse, we can even update the version of our unmanaged solution.
Long story short, by moving our magic to an unmanaged layer of UAT and production, we broke immutability. It is bad practice. But don’t worry, it is just the start of our project. We can quickly fix it. I’ll show you the best practices later in the series.
Conclusion
So far, we have learned many things.
We talked about unmanaged solutions. Later, we will discuss the managed layer and managed solutions, and I will introduce you to some new component modes.
We learned why we need different environments. Then, we discovered a primary way of deploying to other environments: using unmanaged solutions. However, we can see its advantage in providing our development environment.
In addition, we know the importance of immutability, but we haven’t learned how to manage it. We just learned that using an unmanaged solution is against immutability. Later, we will learn immutable component modes and how to practice immutability.
Footnotes
[1] It was developed by a developer called Tanner Helland and 12 other legends. I value people who dedicate their time to providing invaluable products for the world.
[2] I must acknowledge that this relationship between immutability and unmanaged layers is not mentioned in Microsoft documentation. However, I found it easier to understand the Environmental layers by relating them to immutability.