Managing Solutions : Why Solution Patching is a better approach?
Updated: Dec 20, 2019
With the aggressive timelines of iterations and continuous deployment, it is very difficult to manage Solutions. I have seen these scenario multiple times where after each iteration deployment, some components get missed from the developers' end. And to cover those miss, we have to do the Post Deployment Steps.
To avoid these kinds of circumstances, we should go with the Solution Patching and Cloning Approach.
What is a Patch?
Patches are the sub-components of Solution. These are the empty containers with a dependency on Parent Solution. Patches do not contain any component as they are derived from the Parent Solution.
Here are some facts about Patches:
Patches are stored in the Customer Engagement database as Solution entity records. A non-null ParentSolutionId or ParentUniqueName(in solution xml) attribute indicates that the solution is a patch
Patches can only have one Parent solution.
Parent Solution has a dependency on its patches which means, you cannot modify Parent solution until patches are present.
When a patch is installed, it is installed just above the base solution it is patching and below any solutions on top. This means any solutions on top will override the settings in the patch for the same component type.
Suppose a base solution named "SolutionXYZ_1_0_0_0" is already installed in an organization. Now you have imported two patches, "SolutionXYZ_1_0_1_0" and
Patch "SolutionXYZ_1_0_2_0" can override the component of patch "SolutionXYZ_1_0_1_0", if it contains the same component.
Patches support the same operations as solutions, such as additive update, but not removal. You cannot remove components from a solution using a patch. To remove components from a solution, perform an upgrade.
Patches exported as managed must be imported on top of a managed parent solution. The rule is that patch protection (managed or unmanaged) must match its parent.
A patch version must have the same major and minor number, but a higher build and release number, than the parent solution version number. The display name can be different.
Steps to create Patch:
Select the Parent Solution and click on Clone a Patch.
Set the Build and Revision component of the version(Major.Minor.Build.Revison) and save the Patch.
This will create an empty solution where you can add only those components which are required to be deployed as part of either Build or bug/hot fix.
Now you can export this Patch as a Managed or Unmanaged solution and import in the Target environment.
How to upgrade the Solution?
After creating the patch, now we need to deploy that in the Target solution. Let us assume that, a managed solution is deployed in the Target Environment.
Follow the below steps to export and deploy patches for quick fix and Solution Upgrade:
After creating the patch, export it as Managed.
Import Managed Patch in the Target Environment.
By doing this, you'll easily provide the quick fix for the bugs.
Now at the time of build deployment, you just need to follow below steps:
In the Source Environment, select the base solution and click on "Clone Solution". It will rollup all the patches and increase the Minor version by 1.
Export the upgraded Solution as Managed.
Import the managed solution in the Target Environment.
It will ask for Solution Action to select. It is recommended to go with either Upgrade or Stage for Upgrade. Select any option and click on Import.
If you select Stage for upgrade, the solution will get import as a separate solution and it will not rollup the previous version patches, until you Apply Solution Upgrade to the Base solution.
If you select the Upgrade option, all the previous patches will get rolls up with the Solution import.
This way you can manage the Solution deployments even if you have aggressive timelines for the project.
Some Key Benefits of using Solution Patching and Cloning
When we remove any attribute of an Entity, it is very painful to deploy those changes to other environments as we have to remove those manually from the target environment. But if we use, Managed Solution and Patching approach, we don’t need to worry about all those manual work. The solution itself remove all those component which are not present in the Solution which we are deploying.
You don’t need to worry about all those unnecessary solutions which deployed as a Hot Fix/Bug fix. You just have to create a patch for those and at the time of Solution upgrade, all those patches will get rolls up and your solution table gets cleaned up.
You can easily manage the solution versioning with the iteration deployments.
For more information, please refer to this Microsoft Docs link:
I hope it will help.