Simplifying Solution Updates

Solution updates are always a delicate subject throughout Dynamics 365 history and is an action that should be performed with the utmost attention to avoid overwriting or omitting components. In older version of Dynamics 365, when we added an entity to a solution, all the components related to that entity were automatically included in the solution. With the recent upgrade to solution functionality, we can now explicitly determine which individual sub-components of an entity should be included within our solutions.

Solution patches allow for greater control, where only the necessary components are exported.  Within the overall process of importing a solution patch to a target environment, changes can be merged and deployed in the target organisation.

Solution patches can be managed using Organisation Service, Web APIs or Web Application. Managed or unmanaged solutions can have patches.

One simple process to explain the process is detailed in the following steps,

1. Create a Solution in the source organisation
2. Create or Update Components in the Solution
3. Export from source organisation and import in the target organisation
4. Clone Solution Patch in the source organisation
5. Export and Import the Solution in the target organisation
6. Clone Solution in the source organisation to roll up all the changes into the solution

Create and Update Solutions and Patches

The version number <major>.<minor>.<build>.<release> of the original (or parent) solution is very important, as based on this number, the target organization can control the import process.

It is only possible to create a Patch from a Solution. It is not possible to create a Patch form another Patch.

During the creation of a Patch the <major>.<minor> version number for a Patch are predefined as the parent solutions major and minor version numbers. The parent solution is also locked, meaning that it can’t be modified.

Patches can perform the same actions as ordinary solutions to add or update components, but to remove components from a target environment, it is necessary to perform an upgrade and then remove directly from the parent solution.

Export and Import Solutions and Patches

To import patches there are three required points,

• The solution parent must present in the target solution
• the same unique name/display name.
• Version number of the patch must be higher than the solution parent and the last patch imported – What does it mean? If you have a solution v1.0.0.0 two patches v1.0.0.1 and v1.0.0.2 all the solutions must be imported subsequently.

Clone Solution

Once the solution is locked, after creating a patch, to unlock and come back to work on the solution it is necessary to perform a Clone Solution operation. This will roll up the patches into the solution and update the solution with a higher <major>.<minor> version number and all patches are deleted.

Once the new solution is imported into the target organisation, the same sequences of actions will happen – all patches will be merged into the parent solution and only the parent solution with the higher version number will remain.

Another important point – while importing the cloned solution the solution import wizard will auto detect that the solution is a Holding Solution, in the target organization, and the stage for upgrade is pre-checked. After applying the import, the last step is click on Apply Solution Upgrade to commit the solution import.

Delete Solutions and Patches

There are different steps to delete patches from unmanaged and managed solutions.

• Unmanaged – Necessary to uninstall all the patches and then delete the solution.
• Managed – Deleting the solution the organisation take care about delete the patches

This article covers the context of patches, to see more details about how uninstall or delete solution access the link below.

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/uninstall-delete-solution

Approaches to Apply

Different approaches can be used to include this feature in Projects and see below two suggestions to use this concept.

• Bug Fixes – During the test phase when QA rise bug the development team can create a patch in the Dev environment only to fix the bugs and in the end of each cycle test deploy the bug fixes.

The best point to use this approach is because the development team can perform changes only on the components with bug and the deployment tend to be easier, faster and secure since only the necessaries components are in the patch.

• Agile Methodology – For each release one solution can be created and one patch per sprint and the solution can be upgraded in the end of the release before the deployment in production.

The benefits are pretty much the same plus the stories can be also tracked by patches.

Solution Patching in Action

Demonstration of how to create a Solution, Patch and Upgrade the Solution.

Create the Solution Parent and add Account Components.
Solution Version 10.0.0.0

Existing Account with all assets Components

Create Patch and add a create new Entity.
Select the Solution Parent and click on Clone a Patch

Popup Clone to Patch
Version 10.0.1.0

Solution 10.0.0.0
Patch 10.0.1.0

After created a Patch the Solution 10.0.0.0 is locked.

Note: You cannot directly edit the components within a parent solution. If customization is enabled, you may do so through the patches.

Patch with new component Entity A

 Entity A  now is visible within the source organisation

Target organisation without Solution from source organisation

Solution imported from source to target organisation
Solution Customisation v10.0.0.0 Managed

Custom entity Entity A is not in the target organisation

Patch imported from source to target organisation
Patch Customisation v10.0.1.0 Managed

Entity A is now visible in the target organisation

Popup Clone to Solution
Version 10.1.0.0

All patches are rolled up into the parent solution and the new solution is created v10.1.0.0

Solution with Account, Entity A and the new entity, Entity B

Every time this solution is cloned, and the solution is then imported into a target environment with an earlier version of the solution installed, the flag stage for upgrade is preset as required.

Before applying the solution upgrade, all solutions remain in the organisation.

After applying the solution upgrade, only the updated solution remains in the target solution.

 Entity B is now visible in target organisation

The pictures above illustrate the application of solution patches in a very simple flow and without any complications or more complex components. With these concepts it is now possible to start using the clone and patch functionality available within solutions, to increase speed, quality and security of overall solution management.