ALM and Dynamics 365 Solutions explanation

12

min read

A- A+

read

Dynamics 365 Solutions explanation:

Introduction

ALM

Application Lifecycle Management - or ALM - refers to the entire life of an application, from the initial development to the maintenance, through release managed and governance. The goal of ALM is to give a standardized system and guidelines for the collaboration between all individuals involved in a project. Such a standardized system often comes with the automation of its processes from software development and delivery, with the ultimate goal to achieve efficiency through predictable and repeatable software delivery processes.

When ALM is considered an integral part of building applications, it can drastically improve the speed, reliability, and user experience of the app. It also ensures that developers, from people coding C# plugins to people creating Canvas App or people orchestrating Flows, can jointly contribute to the application being built.

ALM and CDS

The Common Data Service has been built as the backbone of all applications from the Microsoft Power Platform world. Thanks to CDS, all applications are based on a common database. This is a fundamental principle of the Power Platform and turns out to be crucial to use ALM tools for Dynamics 365 projects.

Along with the CDS, solutions are the other primordial concept to enable ALM. Solutions are used to distribute components across environments. The following scenario explains briefly how a solution can be used in an ALM process:

In the source environment, create a new solution.
Add components to the solution. A component represents something that you can potentially customize, for example, a field in a form for the Contact entity.
Export the solution from the source environment. Solutions are exported as a simple ZIP file.
In the target environment, import the solution ZIP file. The cus

When coupling solutions with a source control system (e.g: GIT) and some automation tools, a very good and basic Application Lifecycle Management policy can be put in place for CDS based projects. Microsoft offers such a solution with the Azure DevOps services.

Solutions are used to transport apps and components from one environment to another, or to apply a set of customizations to existing apps.

Tools such as the SolutionPackager tools can also be very helpful to have an ALM strategy. This tool can compressed solution file into multiple XML files and other files so that these files can be easily managed by a source control system.

Solutions

Solutions are the way how the Common Data Service must be extended. Customizers and developers can author, package, and maintain units of software to extend their applications via solutions. Once a solution is packaged, customizers and developers can distribute it to any other organization using the CDS. If an organization installed the packaged solution, the functionalities of the solution will be added to the system without requiring any other investment.

Inside the Common Data Service, every customization that is made is part of a solution. It's always the case, even if no solution has never been installed. By default, any CDS environment has two solutions:

The Common Data Service Default Solution, used by default for all customizations in an environment.
The Default Solution contains all components in the system, from the OOB (out-of-the-box) components to all new ones.

Users can and should create theirs owns solutions to manage their work. Solutions are composed of components and anything that can be included in a solution is a component, such as site maps, apps, entities, fields, charts, or plug-ins for example.

When a solution is exported from the source environments, the Power Platform will generate a ZIP file. The file contains mainly XML files that describe all components of the solution. When importing a solution to the target environment, the Power Platform will analyze all XML files and create or update the components described in it.

Type of solutions

When exporting a solution from the source environment, the Power Platform offers two types of solutions:

Unmanaged solution
Managed solution

Following Microsoft's recommendation, it's considered a best practice to work in development environments using unmanaged solutions and then import them to other downstream environments - such as test - as managed solutions.

Unmanaged solutions

Those kinds of solutions are meant to be used in development environments, while changes are being built upon the application.

An unmanaged solution behaves as a travel container for the components inside it. When an unmanaged solution is imported, all components are added to the environment. When an unmanaged solution is deleted, only the solution container is deleted. All the components that have been installed remain in effect and are not removed.

The components that are installed via an unmanaged solution are being installed at the default solution level individually. They become part of the system, like an OOB feature. As such, they can be edited and deleted - always individually.

Managed Solutions

Those kinds of solutions are meant to be imported in any environment that isn't the development environment for the solution.

As for the unmanaged solutions, a managed solution behaves like a travel container for the components inside it. But components imported via a managed solution are also bond together: when a managed solution is deleted, all the customizations and extensions included in it are removed.

Components imported via such solutions are not installed at the default solution level. They cannot be edited nor deleted. They are meant to be together as-is.

A managed solution is created from an unmanaged one, in the development environment. Once imported, a managed solution cannot be exported. Only the development environment can export it. Note that you can't import a managed solution into the same environment that contains the originating unmanaged solution. To test a managed solution, you need a separate environment to import it into.

Solution components

As described above, Solutions are composed of components and anything that can be included in a solution is a component. A component represents something that can be customized, for example, a field, a form, or a chart.

Components can be seen as the unit of a solution. They define what type of customizations must be added to the target environment. As such, there is a very strong link between components and some components are part of bigger components. For example, a field is contained in a view that can also be contained in a form. Each of those components requires the other one to existed and they are dependencies linking them together.

Dependencies

Components may depend on other components to exists. But what if a component from solution A depends on another component that is part of solution B? This is also possible!

Because of the way that managed solutions are layered, some managed solutions can be dependent on solution components in other managed solutions. Some solution publishers will take advantage of this to build solutions that are modular. You may need to install a “base” managed solution first and then you can install a second managed solution that will further customize the components in the base managed solution. The second managed solution depends on solution components that are part of the first solution. The system tracks these dependencies between solutions. If you try to install a solution that requires a base solution that isn’t installed, you won’t be able to install the solution.

Similarly, because of the dependencies, you can’t uninstall the base solution while a solution that depends on it is still installed. You have to uninstall the dependent solution before you can uninstall the base solution.

Publisher

A solution represents the extension and improvement made on the CDS by a developer or customizer. The solution publisher represents the owner of all components of a solution. A component's owner can control what changes can be performed upon the component. A publisher can therefore control what other solution publishers can do with its components.

Visually, the name of the publisher will appear as a prefix for all component's technical names. This avoids having collisions on field names for example.

ALM with solutions

The solutions as defined in the Microsoft Power Platform world must be used through the entire lifecycle of an application. Here we detailed how an ALM policy can be built around such solutions.

Solutions Operations

Create

The first operation when dealing with solutions is to create it. By default, a solution is empty - except for the solution technical name - and users need to add at least one entity to it. When an entity is added to a solution, it's possible to include the entity metadata. If checked, information like the auditing or quick create booleans.

When adding an entity to a solution, it's also possible to check the "Include all components" option. This option includes all components and metadata associated with the entity. It can include other entities or entity components such as business process flows, reports, connections, and queues. Be careful because once selected, the option cannot be unselected! The only way is to remove the entity completely from the solution and adding it again. It's considered best practice to use this option when importing a new unmanaged entity.

Patch

Patches are a very powerful tool from the Microsoft Power Platform world. With patches, we can easily deploy a fix or a small enhancement to an already released solution. A patch can add or update components and assets in the parent solution when installed on the target system. It's recommended to use patches for hot fixes. No components will be deleted when patching a solution.

Publishing a full solution is a time-consuming operation. Patches enabled to avoid this by only deploying what has changed. We could create a new small solution with only the customization we need to deploy without creating a patch and the patch is tracked back to the original solution, so we can ultimately roll these changes back into the base solution.

Another nice feature is that patches can be easily rolled back just by deleting them.

Some tricks:
- After you have created the first patch for a parent solution, the solution becomes locked, and you can’t make any changes in this solution or export it. However, if you delete all its child patches, the parent solution becomes unlocked.
- Patches are created from the parent solution: right-click -> Clone -> Clone a patch. A parent solution can have multiple patches but a patch cannot have a patch. Each patch can only have one parent.
- Be careful with patches version numbers! A patch version must always have the same major/minor version number as the parent solution. But the build/revision number must be higher.

Update

Once a solution has been created, components have been added to id, and the solution has been exported into a ZIP file, it is ready to be imported. If the solution has already been installed in the system, it's possible to install an updated version. If the solution is unmanaged, importing a solution will just install all components and nothing more. Regarding managed solutions, there are three different options when importing a solution already installed:

Update: Similar to importing an unmanaged solution, the components in the solution are installed to the target environment - if not already installed.
- It's not recommended to use it.
Patch: As stated above
Upgrade: The upgrade import will remove unused components and only import components used in the new solution version. Meaning that solution upgrades will delete components that existed but are no longer included in the upgraded version. Upgrade will also merge all previous patches of the solution into a new version.
- The "Stage for Upgrade" option divides the upgrade into two phases. If selected, the solution is imported but the old version is not removed. This enables administrators to assert that all changes have been correctly applied. Then, users can go on the solution and - with the right click- select the "Apply upgrade" option. This will remove the original solution and roll up any patches.

When updating a solution, Microsoft advises two approaches:

Release a new version of your managed solution
- From the dev environment, use the unmanaged solution to make the customizations. Increase the version number and export as a managed solution.
- Import it again in the target environment.
- Simple and preferred method.
- If you want to go back to the behavior in a previous version, simply re-install the previous version:
  - It overwrites any solution components with the definitions from the previous version but does not remove solution components added in the newer version.
  - Those newer solution components remain in the system but have no effect because the older solution component definitions will not use them.
Release an update for your managed solution
- When only a small subset of solution components urgently requires a change, you can release an update to address the issue.
- To release an update, create a new unmanaged solution and add any components from the original unmanaged source solution that you want to update. You must associate the new unmanaged solution with the same publisher record as was used for the original solution. After you finish with your changes, package the new solution as a managed solution.
- When the update solution is installed in an environment where the original solution was installed, the changes included in the update will be applied to the environment. If you need to ‘roll back’ to the original version, you can simply uninstall the update.

Solution Layers

Layers are the base components upon which solutions rely on. A layer is where the customizations of a solution are stored. Solution layering is quite well explained by the below picture from Microsoft's documentation:

The unmanaged solutions are always on the top of managed solutions. All unmanaged solutions share the same unmanaged layer. All imported unmanaged solutions are installed at the managed layers - the same layers that the system solution. But contrary to the unmanaged solution, when multiple managed solutions are installed, the last one installed is above the managed solution installed previously. This means that the second solution installed can customize the one installed before it. This is why the system solutions are at the bottom, to prevent from any changes in the entities and components requires to make the platform work.

Sub-layers

A managed solution can also be divided into four sub-layers:

Base: This layer includes the solution publisher and the managed properties associated with it.
Top: This layer is the layer defining the runtime behavior. It can be the same as the base solution, or an upgrade or patch solution.
Patches: The component has one or more solution patches imported, they're stacked on top of the base layer, in a FIFO order.
Pending update: Is a staged upgraded is imported, it resides on top of the patches layer.

Merge

When importing a solution to an environment, it will be merged with the solutions already present in the environment. For most of the components, the merge is straightforward: “top level” wins. But for some components like the model-driven forms or sitemaps, the merge is more specific.

Forms
- If the form is already present in the environment, Power Apps will merge the two forms. For example, let’s assume you’re updating the OOB Information form for the Contact entity and add your changes to a managed solution. When exporting the solution for the dev environment, the form definitions stored in FormXML are compared to the original FormXML and only the differences are included in the managed solution, so only the differences will be imported into the test environment. It also enables the Power Platform to easily locate those new elements when a managed solution is uninstalled.
SiteMap
- The behavior when importing a solution with a SiteMap with very similar to the behavior when importing a form: only the differences are included in the managed solution.

Solution Lifecycle

In the past versions of Microsoft Dynamics CRM (prior to Dynamics 365), most of the code deployments were done via unmanaged solutions as this was regarded as the fastest way. Working with managed solutions was considered a tricky challenge, and issues often required a holding solution (and lots of time!) to get fixed.

Unmanaged solutions have however their drawbacks. Of course, it's not possible to perform roll-backs or removing all components as one. As components are installed in the unmanaged layer directly, they can be edited directly in the target environments. Therefore there is a risk that the source and target environment aren't aligned!

Manage solutions don't have those kinds of drawbacks, but they have some other disadvantages. For example, the deletion of a managed solution will delete all of its components and the data stored in those fields - even if it's regarding a system entity.

Take-away points

Solutions have these features:

They include metadata and certain entities with configuration data. Solutions don't contain any business data.
They can contain many different Microsoft Power Platform components, such as model-driven apps, canvas apps, site maps, flows, entities, forms, custom connectors, web resources, option sets, charts, and fields. Notice that not all entities can be included in a solution. For example, the account and contact entities aren't solution components.
They're packaged as a unit to be exported and imported to other environments, or deconstructed and checked into source control as source code for assets. Solutions are also used to apply changes to existing solutions.
Managed solutions are used to deploy to any environment that isn't a development environment for that solution. This includes test, user acceptance testing (UAT), system integration testing (SIT), and production environments. Managed solutions can be serviced (upgrade, patch, and delete) independently from other managed solutions in an environment. As an ALM best practice, managed solutions should be generated by a build server and considered a build artifact.
Updates to a managed solution are deployed to the previous version of the managed solution. This doesn't create an additional solution layer. You can't delete components by using an update.
A patch contains only the changes for a parent-managed solution. You should only use patches when making small updates (similar to a hotfix) and you require it to possibly be uninstalled. When patches are imported, they're layered on top of the parent solution. You can't delete components by using a patch.
Upgrading a solution installs a new solution layer immediately above the base layer and any existing patches.
- Applying solution upgrades involves deleting all existing patches and the base layer.
- Solution upgrades will delete components that existed but are no longer included in the upgraded version.
When you import a managed solution, all component changes will be brought into the environment in a published state. However, when you import an unmanaged solution, the changes are imported in a draft state so you must publish them to make them active.
Every change you apply is tracked and any dependencies with previous customizations can be calculated. When you export a solution, it contains all the changes that have been applied for that solution into a file that you can then import into a different Common Data Service environment.
Note that the base solution can be used to create new apps and make customizations to it. But it should never be used to do so: the default solution can't be exported; therefore, you can't distribute the default solution to another environment.
The unmanaged solution layer is above the managed layer, if changes from a managed solution have to be taken over, it is possible to overwrite all customizations from unmanaged customizations during import.
If a component in the standard solution is customized, this component behaves like an unmanaged solution and stands above the managed one.