Merging D365 Power Platform Solution Patches into a Major Version Update

If you would like to understand what are solutions and how to use them please visit my previous two posts where I talk about How to create a solution and how to create a solution patch. In this post we will see how we can merge the patches we created and create a Major version update of the solution for release.

 

To start off we will create another patch on top of the existing 9.1.0.0 base solution and the patch 9.1.1.0

To create another patch, select the base solution and click on Clone a Patch

This will create the second patch and versioning will stay in order

To create a major release we will follow what is called the cloning process. The good thing about following the patch approach and sticking to the recommended versioning is that our cloning will merge all patches together along with the base solution when we create a major version. In order to do so we will select the base solution, in this case 9.1.0.0 and click on Clone Solution

As we can this time the process recommends the next major version which is 9.2.0.0 instead of 9.1.3.0. When we click save the base solution and all patches will be merged automatically and we will end up with a single solution versioned as 9.2.0.0 this will be the solution we export in order to do a version upgrade at the managed box end (more on that in later posts)

 

To read more on patches please visit, https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/use-segmented-solutions-patches-simplify-updates

 

Creating a solution patch in D365 Power Platform, why would you do so?

Note: I’m a firm believer in releasing only managed solutions to testing and production environments and maintaining an unmanaged solution on the development box only, therefore this post is based on the MS best practice architecture of exporting managed solutions for distribution.

To understand solution patches think of them in the direct definition of what a patch is, something to mend or fix up a weak or broken point. For example a complete wall with a hole or a small missing piece in it would require a patch not a new wall. Solution patches are meant to fix up or complete a deployed solution, not to deploy new functionality; I repeat, they are not meant to deploy new additional functionality. This generic definition should be your rule of thumb when deciding whether to create a patch and release that or a new major version release.

On the other hand whether you are in a situation of actually needing to release a patch level fixes or working on a new sprint in your project to release for UAT after the first version of the solution has already been release, creating a patch is always a good idea to keep your new sprint functionality separate from the main solution until you decided to release the functionality, as that helps a great deal in identifying/reviewing the changes done before they are merged into a new version of the solution( more on major releases to come in future posts)

In order to create a patch for an existing solution in your development box. Select the base solution and click on Create patch

Clone a solution patch

 

You get the option to change version, ideally you should let the system recommended one stay as it is managed in order of creation if you create more than one patch

 

Once the patch is created you will see the base solution as well as the patch:

 

This patch is now ready to be exported as a managed solution independently and applied to target environment.