Introduction
In the previous blog, we learned that creating magic is not a single step; it requires ongoing effort and dedication. So, if our magic is used, it involves repetition of the lifecycle.
Additionally, by investigating the component lifecycle inside an environment, we understood it is not aligned with the magic lifecycle, so it is inevitable to have different environments. Therefore, we allocated a specific Environment just for development, but it was empty. Now, we need to know how to move our components between environments.
For ease of use, let’s call the movement of our magic from one environment to another deployment.
Provisioning Develop environment
So far, we allocated a specific Environment just for development. Now, we need to know how to move our components between environments.
For ease of use, let’s call the movement of our magic from one environment to another deployment.
Power Platform Solution
As you recall from the first blog, to avoid confusion, I reserved the word solution and chose magic to replace the word “digitalization solution.”
In the Power Platform world, Solution is also a technical term and plays a vital role in ALM. Indeed, it is the only recommended mechanism for deployment.
In short, Solutions are packages containing different components that can be deployed to other environments.
Solutions and component lifecycle
There are two types of solutions, and understanding their differences is crucial to ALM. Let’s keep it simple and investigate the one we need now to solve our problem.
In our example, we needed to deploy our components from production to development and then start editing them, right? The solution type that provides this functionality is called an unmanaged solution. But according to its functionality, I would like to call it an Editing Solution that better reflects its concept and functionality. An editing solution is a package with which we can deploy our components and then start editing them.
Therefore, in terms of the component lifecycle, if the component doesn’t exist, this solution creates it (created mode). If it exists, it edits it (edited mode).
So, it plays a similar role to an editor in the component lifecycle, but without repeating our work. We use editors in the Development environment and make our components. Then, using the editing solution, we deploy them, as if we developed them in the destination environment. That’s what we need, isn’t it?
However, we still need editors to delete a component, but that’s no problem for now.
Deploy to Development
Technically speaking, a solution can be exported as a zip package, which can then be imported into another environment. This is the whole deployment process, Simple and easy.
Now, we deployed our magic from production to development. Bingo! We can edit and test them without affecting the components that are under use in production.
Quality and Speed of our Magic Lifecycle
Previously, we learned that ALM is indeed aligned with business goals. Obviously, businesses need to create value as quickly as possible. We also understood that being fast was not enough. We needed to be fast and provide high-quality value.
So, with ALM, we aim to provide our magic with high quality and as fast as possible. Let’s see how closely our lifecycle aligns with this now.
Speed of Deployment to Production
Assume we have fixed the bug. We have updated our AI Builder model and Cloud Flow to accept Word documents. We tested it, and it worked fine.
Can we also deploy our magic back to production? Yes, we can do it with the Editing Solution. What a fantastic solution type it is! As those components exist in production, after deploying with the editing solution, we change them into edited mode with the latest change in the Development environment, and then by publishing, they are in working mode again. So cool, isn’t it?!
So far, we can deploy to another environment. How fast is it? Our example only needs a few minutes to finish, which is acceptable.
Quality of Deployment to Production
But wait a moment. What if we deploy to production and it doesn’t work correctly? In addition, our end users heard that we have another environment and asked us whether they could test our magic before being surprised by the new version in production. That’s a good idea. This way, we can double-check; if we overlook some bugs, they might find them. Then, with less stress, we can deploy.
It seems we can still improve our quality.
A new environment is needed
We have two environments: Development and Production. Which one do you choose for user testing to accept your magic? We agreed that the production environment is not a good place for testing, so we obviously pick the development environment between the two, right?
However, recalling the component lifecycle inside an environment, we are again blocked until their tests are finished. This does not affect the production environment, but it also influences our development speed. Maybe testers don’t have time right now, and then we must wait some days until they are finished, and until then, we can’t change our components.
There is also another problem. We know our magic works in the Development environment, but are we sure it will work after deployment? Isn’t it better to test our deployment once before deploying it to production? That way, we can also improve the quality.
User Acceptance Test Environment
We solved a similar problem before, right? In that problem, we were developing right in the production environment. In that case, we solved the problem by adding a new environment. So, let’s do it again and add a new environment called a User Acceptance Test, or, in short, a UAT environment. In that environment, like production, we want our components to be in working mode—this time not for production use to improve recruiters’ productivity but for testing.
We also know how to deploy, so we deploy to UAT and start testing. We can also start editing in UAT by using the editing solution; however, we know this is not a good idea, and we will only develop in the development environment. So, let’s use the editing solution to deploy. The editing solution is a tool we already know of, and it works. Why should we bother ourselves with learning a new tool!
Users who test our magic find bugs and let us know. They might also ask for minor improvements that can be done quickly. Then, we will work on our components in the Develop environment again and deploy them to UAT. This might happen many times but without any effect on the production environment. So, at every step, we improve the quality of our magic.
Improving magic lifecycle
In the previous blog, we reached the following lifecycle.
However, as we discussed in this post, we need to review this lifecycle to enhance the quality while maintaining an acceptable speed of value creation.
We know the fastest deployment methods, but we need to test them before the final deployment to improve quality. If we can test in a similar environment as production, the probability of success when deploying to production is higher, isn’t it?
Going directly from Make to Use is fast, but in terms of quality, we need another step in between.
Let’s say we need to test it in a separate environment. When we feel confident, we start using it. We need to do at least two types of tests:
- User Acceptance Test: Testing whether our magic reflects user requirements. This is done by representatives of end users (In our case, recruiters).
- Deployment Test: Testing whether, after deployment, our magic works the same as a Development environment.
Other tests also need to be performed to improve the quality. However, as our goal in this blog series is not to become an ALM expert, we can skip them. The two above are acceptable.
After all, here is our reviewed magic lifecycle:
Using new magic in production
Now, we are ready. We prepared our next magic, and testers approved it. So, let’s bring it to production and use it.
Deploy to production
We know the tools we need, don’t we? So, the solution we deployed last time to UAT was deployed to production. We have tested our deployment before, and our magic was also tested in UAT.
We deployed to production in the afternoon. We sent a test email and saw that it worked fine, so we deleted the Job offer record and also that email.1
What a good day! What a good process we defined!
The problem in Comparing Components
But tomorrow, it won’t work correctly again! What!?
What’s wrong? We published and tested it! Did we need to test everything again in production?
Another critical question is, “Are these components the same as what we deployed to UAT?” How can we be sure? We deployed an Editing solution, which means they are ready to be edited again, right? 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?
Long story short, we deploy again using an editing (unmanaged) solution. That way, we overwrite the changes that might have happened in production.
Great! We were lucky this time. By deploying again, it works fine.
Later, we realized that one of the recruiters had recently learned how to work with Power Automate and wanted to use his knowledge to update the description in the job offer. He thought it was a small change, and yesterday evening, he convinced the admin to do it together. They changed the flow and were happy that they helped us. But they broke the Flow and didn’t notice it.
We can talk to them, inform them that it was not a good idea, and teach them to respect our magic’s lifecycle and how we update it.
However, this stressful experience taught us about another problem.
Conclusion
In this post, we learned more about ALM. We separated the environments, so our lifecycle seems confident. But there seems to be a problem with our deployment.
Let’s not be disappointed. We did a great job. However, we know we still need to learn more and improve.
What if we could prevent editors from editing our components in some environments, such as production or UAT? And what if we could compare component versions between environments?
The good news is that we will still learn some component modes. These advanced modes will help us overcome these problems, and we will explore them in upcoming blog posts.
Footnotes
- The Job Offer and that email are related to an example I explained in previous post. ↩︎