Microsoft SaaS – Vrushali's Techno Blog

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

Patchtarget1w

As this field was customized twice, we can see one default solution by Microsoft and rest two are from publisher Vrushali 🙂 Patchtarget12

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

clone17

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.

clone18

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.

Patchtarget13

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. Patchtarget14

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.

Patchtarget15

It will import the new solution in the target instance Patchtarget16

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.

Patchtarget17

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.

Patchtarget18

Let us do apply the upgrade now by selecting the original solution and clicking on the Apply Solution Upgrade option from the the top

Patchtarget19

Now it will apply the upgrade Patchtarget20

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.

Patchtarget21

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 🙂

Continue reading “Understanding D365 CE solution Deployment – Patches – Part 2” →

In previous post we saw how to deploy the solution using manual export and import method.

Let us discuss a scenario where we have frozen the solution, have the sign offs on the SIT and there is one critical CR or a bug which is to be resolved. Assume that the change really small and is required to be done in an entity. However if we do the changes in our solution and export the solution, all entities and related assets will get exported and there are chances that any unnecessary changes might getting imported in the target solution. To avoid such situation, we can use patches in Solution deployment

Let us understand patches in details

Unlike the solutions, patches include only changes related to the entity and related entity assets. It does not contain any non customized system components or any relationships on which it is dependent on as this would be already included in the original solution, deployed in the target system.

Few important facts about Patches:

Patches can only be created from a parent solution and hence we can not create a patch based on any patch
Patches can only have one parent solution.
A patch creates a dependency (at the solution level) on its parent solution.
You can only install a patch if the parent solution is present in the target instance and its major and minor number are matching with the major and minor number of patch. Additionally the patch should have higher release and build number than the original solution in target instance
The rule is that patch protection (managed or unmanaged) must match its parent.
If a solution has patches, subsequent patches must have a numerically higher version number than any existing patch for that solution.
Patches support the same operations as solutions, such as additive update, but not removal. You cannot remove components from a solution using a patch. To remove components from a solution perform an upgrade
For managed solutions, when we uninstall the original solution, all related patches would get uninstalled automatically, however for unmanaged solutions, we have to first we need to uninstall all the patches in reverse order based on the version and then we will be allowed to uninstall the based solution

Let us now see how to create patches. As we saw in the last post we have two CRM instances and we have a solution named deployment already deployed from source to target. Let us consider one requirement where I have to add few fields in the account entity

To learn the patch deployment, let us follow 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)

All above steps would help us to make the concepts of patch deployment clear. Let us start following the steps one by one

Create solution in source instance and export

In this step let us create new solution,

Add existing Accounts entity to the solution and do the changes in the Description field’s max length
Create new entity named project and do the changes in the description field’s max length
Publish the customization
Export the newly created solution

Kindly refer to previous post for creating new solution and export. I am using the same solutions from last post

Click Add existing and select Entity

Patch4

Select the Account Entity

Patch5

Let us add new Component, select Entity and add Entity Details Patch8

Let us add new field to it as Description Patch9

Kindly note that the field length is 100 Patch10

Finally we have two entities in the newly created solution

Patch11

Once the solution is published, let us export the solution as managed.

Patch12

Now we have the zip file downloaded of the managed solution.

2. Import the solution in the target instance

In this step, let us import the solution in the target instance.

Go the setting- solutions – click on Import as we seen in the previous post

Patchtarget1

Now we have first solution deployed in the target instance.

3. Create first patch in source instance and export the patch

As discussed above, let us consider a requirement comes where we just need to change the length of Description fields of both the entities Project and Account. I am giving a simple example, but the original solution might be quite complex and large solution and changes required can be unique. Hence we would create a patch and only add those particular fields in the patch and do the changes as depicted in below stage.

Again go to the settings-solutions, select the original solution and click clone the patch

clone1

Make a note here that we are allowed to change the build and release number of the version

Clone2

Once saved, we can see the patch solution is available under solutions

Clone4

Now we can do add our changes in the patch solution.We we try to do any changes in the original solution, its not allowed as depicted in below snippet

Clone3