Managed Solutions vs Patches
The Problem
Microsoft’s article, Create patches to simplify solution updates, suggests patches can simplify solution management, but does it always? When should you use patches vs. deploy a new solution altogether?
The Helpful Bit
In most cases, I recommend using new solutions for both hot fixes and feature deployment, rather than patches. Here is a summary of some advantages and disadvantages of each approach, why I generally favor new solutions over patches, and when to consider using a patch.
Patches
Patches automate the process of merging down incremental layers when the next full solution is deployed. This automatic rollup and removal of the patch layers is the primary convenience offered by Patches. However, they also require patches to be deployed in the order of their version number. This can impede solution deployment if a hot fix is deployed on top of other work in progress.
For example, if Base Solution 1 has a feature solutions A and B in development, and a hot fix C is created and deployed promptly, A and B can no longer be deployed to the target environment due C having a higher version number. A & B’s version numbers cannot be incremented to a value higher than C. However, a new patch can be created containing A and/or B, once they are ready to deploy. The XRM Toolbox’s Solution Components Mover makes this relatively easy. At a future point, once all outstanding patches have been deployed, they can be rolled up into Base Solution 2. When done, the patches are all automatically removed.
The drawback is the restriction to your order of deployment, requiring the movement of solution components to a patch with a version higher than the highest deployed in the target environment. If you always have a consistent deployment schedule, this would be fine. Real world scenarios, however, may complicate this.
Another disadvantage is that patches require rolling up all of the outstanding patches to the next version simultaneously. If you are working on multiple features or fixes in separate patches tied to the same solution, you cannot roll up only a subset of them to the base solution.
A final consideration is that once a patch is created, the base solution is locked. While these locks have their place, even opening components to look at them can become tedious, as they must be accessed via other means, such as adding them to a patch or through the default solution.
Solutions
Solutions will not automatically rollup, nor will they be automatically deleted after you merge their components back down to your base solution. This means you will have to do more work to keep the solutions list clean and concise, or else you will eventually end up with an unwieldy list of solutions and layers.
Solutions can be deployed in any order, noting that the last deployed solution in the target system will override the values on any shared components. This makes it easier to facilitate and manage solution release. Your hotfix will override the needed customizations and sit above the base solution layer it is intended to modify in the target environment.
The drawback is that cleanup is not automatic. Before your next full solution deploy, you will want to merge these hot fixes and/or features back down to the base solution to ensure that any new components, not present in the base solution, are not inadvertently removed when you later uninstall the feature solution in the target environment. Doing this manually can be time-consuming and prone to missing items. However, the XRM Toolbox Solution Components Mover makes this very easy.
A second advantage is that you do not have to roll up all outstanding feature solutions at once. For example, if solution A from above is tested and production ready, but solution B is flagged for revision in UAT, provided they do not share any dependencies not ready to deploy to production, such as updates to two controls on the same form, then solution A can safely be merged down and its solution removed from all environments, while leaving B untouched.
Note: Neither solutions nor patches will not alleviate the need to verify dependencies and coordinate deployment to prevent feature leaks.
Conclusion
Use patches when the following conditions are all met:
- The order of deployment to all environments will be the same as the order the patches are created.
- All the patches will be rolled up together for the next full solution version.
- You want to save the time required to manually merge the patches back to your base solution.
Otherwise, I advise sticking with new solutions. While they are a little more work to manually roll up and keep tidy, doing so will help prevent versioning dependency hell. For doing this, the XRM Toolbox Solution Components Mover is indespensible.
Reference Material
Solutions overview
Create patches to simplify solution updates
Solution Components Mover
