Difference between revisions of "How to work with Solution Patches"
| Line 14: | Line 14: | ||
You can't do a full deployment since you would deploy changes that aren't tested or approved yet. In this case, you could create a patch, only containing your hotfix, and deploy that. | You can't do a full deployment since you would deploy changes that aren't tested or approved yet. In this case, you could create a patch, only containing your hotfix, and deploy that. | ||
| − | Another problem could arise though. Usually, the version of your solution has been changed already when you come to that point, which makes the created patch unusable (because of the mentioned version constraints). A solution to that would be a hotfix environment that contains the same version of your solution as production. Either you have this environment always running or create it when needed from an unmanaged solution which should be stored in your repo (see | + | Another problem could arise though. Usually, the version of your solution has been changed already when you come to that point, which makes the created patch unusable (because of the mentioned version constraints). A solution to that would be a hotfix environment that contains the same version of your solution as production. Either you have this environment always running or create it when needed from an unmanaged solution which should be stored in your repo (see [[ALM]]). |
== ALM == | == ALM == | ||
Latest revision as of 22:03, 22 December 2021
Sometimes you might not need a full deployment of the whole solution, that's where patches come in.
What is a patch
When you create a patch from a solution the system will create an empty solution tied to the base solution. You can then include only the parts you would need rather than having the whole solution. This will increase deployment speed but brings other downsides (which will be explained later).
As mentioned a patch is tied to a base solution, to be more specific even to a certain version of it. This means the source environment and the target environment need to have the same version of the base solution installed to be able to install a patch.
Whenever you create or install a new version of the base solution all patches will be rolled up into the base solution.
Use case
Imagine you have your solution live in production, started development of new features already and a bug is detected. You can't do a full deployment since you would deploy changes that aren't tested or approved yet. In this case, you could create a patch, only containing your hotfix, and deploy that.
Another problem could arise though. Usually, the version of your solution has been changed already when you come to that point, which makes the created patch unusable (because of the mentioned version constraints). A solution to that would be a hotfix environment that contains the same version of your solution as production. Either you have this environment always running or create it when needed from an unmanaged solution which should be stored in your repo (see ALM).
ALM
As mentioned there are restrictions when it comes to the solution version. Another problem with ALM and patches is that every patch has a unique name which makes it hard to automate the export of it. Those reasons make it nearly impossible to handle patches in an automated ALM process. Patches are therefore mostly usable when handled manually in certain limited use cases.
Related Content
Microsoft Resources
Community Resources
- How to handle hotfixes in Dataverse by Benedikt Bergmann