Difference between revisions of "How to work with Solution Patches"

From Power Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
Sometimes when working with Solutions you might not need a full deployment of the whole solution, here patches come in.  
+
Sometimes you might not need a full deployment of the whole solution, that's where patches come in.  
  
−
Imagine that you have your solution live in a production environment and you are about to start a new big project. During this project it might be the case that you need to do a smaller update/fix in the production environment, but you will not be able to do that from the DEV environment where you are working with your big new project. Because there will be changes you do not want to add to production yet. In the future you could potentially use Settings for this, but for now and an alternative approach is to make a copy of DEV to another environment before you start with your new project. In that temporarily DEV environment you could do the small fix and create a patch to import to the production environment.  
+
== 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).
  
−
More to add here... We'll continue soon!
+
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.
  
−
== Microsoft Resources ==
+
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 ===
 
* [https://docs.microsoft.com/en-us/power-platform/alm/create-patches-simplify-solution-updates Create patches to simplify solution updates]
 
* [https://docs.microsoft.com/en-us/power-platform/alm/create-patches-simplify-solution-updates Create patches to simplify solution updates]
  
−
== Community Resources ==
+
=== Community Resources ===
−
* [https://benediktbergmann.eu/2021/02/28/how-to-handle-hotfixes-in-dataverse/ How to handle hotfixes in Dataverse]
+
* [https://benediktbergmann.eu/2021/02/28/how-to-handle-hotfixes-in-dataverse/ How to handle hotfixes in Dataverse] by Benedikt Bergmann

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

Retrieved from "http://powerwiki.net/index.php?title=How_to_work_with_Solution_Patches&oldid=5714"