In previous post we saw how to create a patch and deploy it to the target instance. We have completed four steps from below steps
- Create solution in source instance and export
- Import the solution in the target instance
- Create first patch in source instance and export the patch
- Import the first patch in target instance
- Create second patch in source instance and export
- Import the second patch in the target instance
- Delete the second patch from target instance
- Merge the patches to original solution in source instance
- Export the merged solution from source instance
- Import the merged solution in target instance (target solution has first patch already)
Let us continue the further steps and learn more.
5. Create second patch in source instance and export
To know more about patches, let us create a more patch on the same solution. Now let us change the Max length of description field and see how this would reflect in the target instance. I am not getting into all the details again as its same as previous steps of creating Patch. Only difference is we are creating second patch on the same solution. Hence create the patch and then export the same
6. Import the second patch in the target instance
As we have above patch solution exported, let us import the same in the target instance. and check if the changes are reflected.
Here we can see the different solution layers as depicted in below snippet. As we have done changes in the description field in both the patches, we can check solution layers for the same field. Similarly we can check for other fields or components to understand when it was changed
As this field was customized twice, we can see one default solution by Microsoft and rest two are from publisher Vrushali 🙂
7. Delete the second patch from target instance
Now let us delete the second patch from the target instance , we can see the original solution and the first patch remains unaltered. The changes from second patch will only be removed. I added this step as I wanted to show the upgrade functionality in the patch deployment, otherwise I had to create one more patch and explain. Hence a shortcut 🙂
8. Merge the patches to original solution in source instance
We have two patches in the source instance, now if we think its better to merge those to solution from ease of maintenance. In this case we can use the functionality of Clone to Solution. This functionality will merge all available patches to the solution and update the original solution with incremented major version as depicted in below snippets.
Select the Solution and click on Clone to Solution
We are allowed to change the major version of the Solution and save. Once saved only single original solution with updated version number would be shown in the solution list.
9. Export the cloned solution from source instance
Exporting the cloned solution from the source instance is the same process as we export any normal solution. Hence not going in details again.
10. Import the merged solution in target instance (target solution has first patch already)
Let us import the exported solution into the destination instance. Here is the catch. We already have the original solution available in the target instance along with the first patch. We are trying to import the merged solution, the import will recognize that original solution is already there and will give you option to upgrade the existing solution with new solution updates or if you are not sure, you can keep new solution isolated from this .
Let us see step by step the specialty of importing the updated solution
As we can see in below snippet, original solution and first patch already exist in the target instance, and we are importing the upgraded solution now which has first and second patch cloned in the original solution.
As soon as select the solution and click on next, the instance automatically detects that the solution package contains an update for a solution that is already installed and the same message is displayed on the top.
Once we click on the next button, we see below options for the action to be taken
- Upgrade : This is recommended action which upgrades the existing solution to the latest version and rolls up all previous patches in one step. Any components which are removed in the to be imported solution will be deleted from the instance
- Stage for Upgrade : This option also upgrades the existing solution to higher version, but unlike the above option, it defers the deletion of removed components , until we apply a solution upgrade later. Its like a a staging state and then you can apply actual changes later when you are comfortable
- Update: This option would not delete any removed component from the instance
We are selecting the stage for upgrade action here for learning purpose
Also we have the option to select the action on the previous customization on components included in the to be imported solution such as maintain the customization or overwrite the customization and click on Import button.
It will import the new solution in the target instance
Here again it will ask if we want to apply for upgrade by providing the button, but we are not clicking it now and going ahead.
As we see in below snippet, there are three solutions present at the moment, one is the original, then second is its patch and third one the staging solution as discussed above. Also notice the versions for these solutions.
Let us do apply the upgrade now by selecting the original solution and clicking on the Apply Solution Upgrade option from the the top
Now it will apply the upgrade
Once the solution upgrade is completed, we can see the single solution available in the target instance with the upgraded version as shown in below snippet.
This is how we have seen the complete patch deployment process in these posts.
I would recommend to do the hands on , follow the steps while going through the blog which will give more clarity.
Hope these posts help you in solution deployment and watch this space for further details on solution deployment using package deployer and Devops -Powershell scripts.
Happy deploying and patching 🙂
Why would you use “Stage for Upgrade” with managed solutions?
Solution Patching in Microsoft Dynamics CRM 2016
2 thoughts on “Understanding D365 CE solution Deployment – Patches – Part 2”
When I tried to apply solution upgrade, it didn’t merge the _upgrade solution into the main solution so _upgrade solution is still sitting on my managed box. When I am trying to apply upgrade- it says this -”
The base solution cannot be deleted due to dependencies from other components in the system. Remove all the dependencies to allow for the solution deletion”. The dependent components in the list is empty. Can you please guide me as to how can I solve this?
Aw, this was a very good post. Finding the time and actual effort to generate a really good article… but what can I say… I procrastinate a lot and don’t manage to get nearly anything done.