Simplify your deployment with the new Solution Patching feature in Dynamics CRM 2016.

In my earlier blog post, I have explained in detail the solution segmentation feature in Microsoft Dynamics. In you are new to the solution segmentation feature, please refer to the blog post – https://debajmecrm.com/understanding-solution-segmentation-in-detail-in-dynamics-crm-2016-create-a-solution-with-just-what-you-need/

In this post, I will cover in as much depth as I could explore , the new feature of Solution Patching in Dynamics CRM 2016. A really innovative solution to all your versioning problems and solution management for your CRM deployment. So without wasting much time, I will jump straight into the topic.

Before understanding the what part of it, let us first understand the why part of it. So when do we need a solution patch? Well say you made a pretty significant deployment and enjoying glass of beer with you team. And before you come out of the hangover, customer points that some stuff is not working and an urgent fix is needed. Wondering how this part of testing got missed even after so much comprehensive testing. Well don’t worry, these happens in all projects.

So what immediately comes to your mind. A patch or a hotfix right? Yes that’s what would come to my mind at-least. To take an example, say you gave the length of a field as 300 characters but some application is feeding data into CRM with more than 300 characters in the field. So if you need a hot fix, you would ideally want a solution with just the field with the modified length. Segmentation in CRM allows you to do that which I have explained in the blog post link above.

Since this hotfix is related to the major development. So when you export the hotfix as managed solution and import it into the target environment, you would need it to apply just on top of the main solution. In other words your hotfix is tied to a basic solution. This is what Solution Patching allows you to do. And remember this point. It is very important and I will come back again to this. So marking this in red.

I have a solution in my environment, called “segmentation demo”. This is the same solution I would use for this post.

Inside the solution, I have two entities “Account” & “Contact” and account entity have two field “name” and “numberofemployees”.

 

I go the solutions grid, select this solution and click on ‘Clone a Patch’ button on the menu.

 

The first thing that comes to notice is the Version Number. All of us know, but to just bring the context a version number is usually of the format <major>.<minor>.<build>.<revision>

As you can see, since this is a patch, you are only allowed to edit the build and revision numbers. Wonderful isn’t it? All this time I have been harping that version numbers doesn’t make much sense in CRM and this time Microsoft has just shut me up and made me crawl in the corner . I keep the format provided and click on Save. CRM creates a new solution with the same display name but a different unique name.

So as I explained before, the patch solution is now connected to the base solution which is Segmentation Demo.

Say I just want to patch a fix in the “description” field of the Contact entity. So I just add the field in the entity.

Lets go a little bit deep here. Let us export the solution and peep into the xml and see how the solution looks like. Remember we are more interested in how the solution.xml file looks this time rather than customizations.xml

Looking at the XML, it is very easy to understand how CRM maintains a link between the base solution and the managed patch.

Remember in the beginning, I told I would be back with the concept of how managed patch is applied. You can see I am a man of my words and here I am back .

Prior to CRM 2016, managed solutions are imported on the top of managed stack. Say for example you have a imported three managed solutions i) Solution A ii) Solution B and iii) Solution C. See for the screenshot below. The order of import is from bottom to top as indicated by the arrow.

The final outcome would be that the description field would be of 2000 characters.

Managed patches work differently. That is managed patches are not applied at the top of the managed stack. Rather they are applied at the top of the corresponding base solution. Suppose in the previous screenshot, you need to create a patch for solution B and deploy it. Prior to CRM 2016, it would apply on top of solution C. However a managed patch for Solution B, would apply on top of solution B, it would sit between B and C.

The arrow above indicates the way the managed stack is applied irrespective of the order of import.

I know by this time, you must be wondering about all the advantages and disadvantages of this and personally I can jo
lt down points both in favour of and against. This post is more related to make you understand the concepts so that you are best judge to decide when to apply patches and when to go ahead with new solutions.

In my next topic, I have covered in detail the solution cloning.

https://debajmecrm.com/understanding-solution-cloning-feature-in-detail-in-dynamics-crm-2016/

Happy holidays to you all and keep exploring the wonderful CRM 2016.