Hello! Welcome back to our course.
In our last lesson, we examined the critical developer-relevant constraints of the Power Platform, such as API request limits and Dataverse capacity. Understanding these "rules of the road" is essential for designing solutions that are robust and scalable. Now, we shift our focus from the constraints of what we build to the process of how we build and deploy it.
This lesson marks the beginning of our deep dive into Application Lifecycle Management (ALM). We'll address the learning outcome: Compare and contrast the use of unmanaged and managed solutions for application lifecycle management. Mastering this concept is fundamental for any professional developer on the Power Platform, as it provides the framework for moving your applications from development to production in a controlled, repeatable, and safe manner.
1. The Foundation of ALM: Environments and Solutions
Application Lifecycle Management (ALM) is the process of managing an application's development, testing, deployment, and maintenance. For a developer with your background, this cycle of dev -> test -> prod is second nature. In the Power Platform, this process is built on two core concepts:
- Environment Strategy: Separating your work into different environments (e.g., Development, Test, Production) is the cornerstone of ALM. You build in one place, test in another, and release to users in a third.
- Solutions: These are the containers you use to package and transport your application components (apps, flows, tables, etc.) between these environments.
To get a high-level overview of how these pieces fit together, the following video provides an excellent introduction to the Power Platform ALM philosophy.
How to do ALM with Power Platform
Watch this short segment from the 'How to do ALM with Power Platform' video by Microsoft Developer. It frames the discussion by defining what ALM means in this context.
Watch from 01:54 to 04:14. Focus on the three key pillars mentioned: environment strategy, packaging components into a solution, and repeatable deployment.
As you saw, everything you build for deployment should be inside a solution. The critical decision you must make when moving that solution is what type of solution it will be.
2. Unmanaged vs. Managed Solutions: The Core Distinction
Every solution in Power Platform is either unmanaged or managed. The type you use depends entirely on the stage of your ALM process.
Think of it this way, which should be familiar from your software development experience:
- An unmanaged solution is like your raw source code. It's open, editable, and lives in your development environment where you are actively making changes.
- A managed solution is like a compiled binary or an installer package (e.g., a .dll or .msi). It's a sealed, versioned artifact that you deploy to test or production environments. You don't edit the binary directly in production; you go back to the source code, make changes, re-compile, and redeploy a new version.
This visual provides a clear summary of the key differences and their intended uses.
For a definitive explanation, please review the official Microsoft documentation.
Solution concepts with Power Platform
The Microsoft Learn article 'Solution concepts with Power Platform' is the source of truth for this topic. It provides the official definitions and rules.
Read the section titled 'Managed and unmanaged solutions'. Pay close attention to the definitions and the 'Important' notes, which highlight key rules like not being able to import a managed solution into its originating dev environment.
Detailed Comparison
Let's break down the comparison into a more detailed table, which synthesizes the information from the resources.
| Characteristic | Unmanaged Solution | Managed Solution |
|---|---|---|
| Primary Purpose | Development and authoring. | Deployment and distribution. |
| Typical Environment | Development environments. | Test, UAT, Production environments. |
| Editability | Components can be directly added, removed, and modified. | Components cannot be edited directly. The solution is "locked" or immutable. |
| Source Control Analogy | The "source code" of your application. | The "compiled binary" or "build artifact." |
| Exporting | Can be exported as either Unmanaged (to move between dev environments) or Managed (for deployment). | Cannot be exported. |
| Deletion Behavior | Deleting an unmanaged solution only removes the container. The components remain in the environment as part of the "Default Solution." | Deleting (uninstalling) a managed solution removes the container AND all its components. |
This distinction is the most critical principle of Power Platform ALM. You always develop in an unmanaged state and deploy to downstream environments using a managed state.
3. The ALM Process in Action
Now let's see how this theory translates into practice. The following video demonstrates the end-to-end process of building an application in an unmanaged solution, exporting it as managed, and deploying it to a test environment.
Solutions in Power Platform | ALM, Power Apps, flows & Environments
This comprehensive video by Reza Dorrani walks through the entire basic ALM cycle. It's a practical demonstration of the concepts we've just discussed.
Watch the segment from 03:10 to 20:17. This covers three key phases: Building (Unmanaged): (03:10 - 15:35) Observe how a new unmanaged solution is created and how an app and flow are added to it. Note the use of environment variables, a best practice for ALM. Exporting (Managed): (15:35 - 17:42) This is the crucial step. Pay close attention to the choice between exporting as 'Managed' or 'Unmanaged' and the reasoning provided. Importing (Managed): (17:42 - 20:17) See how the exported managed solution is imported into a separate 'test' environment and how the environment variables are configured upon import. Notice that the components are locked from editing.
4. Solutions and Professional DevOps
Your interest in professional ALM and DevOps practices is where these concepts become even more powerful. Storing application configurations in a source control system like Azure DevOps or GitHub is a standard practice. But how do you store a Power Platform solution in Git?
You use a tool—historically the Solution Packager and now more commonly the Power Platform CLI—to "unpack" the unmanaged solution file (.zip) into a structured set of human-readable XML and other files. This unpacked folder is what you commit to your source control repository. Your DevOps build pipeline then automates the process of packing this folder back into a managed .zip file, which is then deployed by the release pipeline.
This leads to a key strategic decision for your ALM process.
How to do ALM with Power Platform
This segment from the Microsoft Developer video discusses how solutions fit into a professional DevOps workflow and source control.
Watch from 04:14 to 07:15. This part explains: The unmanaged/managed paradigm again, referring to the managed solution as an 'immutable unit'. The two common patterns for source control: storing only the unpacked unmanaged solution, or storing both the unpacked unmanaged and the packed managed solution.
Committing the unpacked unmanaged solution to source control is the most common and recommended practice. It treats your repository as the definitive source of truth for your application's code.
Test your understanding!
Your team has a Development, a UAT, and a Production environment. A new developer on your team has just finished a set of changes in the Development environment. To deploy to UAT for testing, they export the solution as unmanaged and import it into the UAT environment.
What are two major problems with this approach? What is the correct procedure?
Show answer
Problems with importing an unmanaged solution to UAT:
- Lack of Control and Drift: The components in the UAT environment are now fully editable. Anyone with the right permissions could make changes directly in UAT. This breaks the ALM principle that changes only flow from Development. The UAT environment will "drift" from what is in source control, making future deployments unpredictable.
- Inability to Uninstall Cleanly: If you later decide to remove the solution, deleting the unmanaged solution from UAT will only remove the container, leaving all the components behind. This litters the environment with orphaned components and makes cleanup very difficult.
Correct Procedure:
- In the Development environment, export the solution as managed.
- Import this managed solution file into the UAT environment. This ensures the components are locked from editing and that the entire solution can be cleanly uninstalled if needed.
Conclusion
Today, we've established the foundational pattern for professional development in the Power Platform. By understanding and correctly utilizing managed and unmanaged solutions, you ensure a reliable, repeatable, and governable ALM process.
Key Takeaways:
- Unmanaged for Dev, Managed for Deploy: This is the golden rule. Unmanaged solutions are your source code in development; Managed solutions are your compiled artifacts for all other environments.
- Managed Solutions are Immutable: They protect your Test and Production environments from direct, uncontrolled changes, preventing configuration drift.
- Clean Uninstallation: Managed solutions can be cleanly uninstalled, removing all their components and preventing orphaned customizations.
- ALM Automation: The unmanaged/managed paradigm is the basis for professional DevOps, where unmanaged solutions are unpacked into source control, and build pipelines generate the managed artifacts for deployment.
In our next lesson, we will build directly on this knowledge. Now that you understand how to deploy managed solutions, the next logical question is: what happens when you install multiple solutions that modify the same component in an environment? We will answer this by exploring the learning outcome: Explain the concept of solution layers and the merge behavior of solution components.