Managing Solutions in Dynamics 365 - Part-2

As discussed in Part I of this blog, the solutions management is important for the ability to effectively maintain customization's between environments. Microsoft has provided OOTB capability to do solution versioning, patching and updating which is discussed in this blog.  

Solution segmentation / versioning.

The solution versioning can be in the following format – Major.Minor.Build.Revision

For example - AA.BB.CC.DD where,

AA = Major version #

BB = Minor version #

CC = Build #

DD = Revision #

1. Create a base solution – version 1.0.0.1

You can create a base solution in a source environment. We will include the entities and related assets, customization's…, that needs to be in the base solution. Let’s version this base solution as Release-1 version 1.0.0.1

And add the following assets –

Entity – Account – field – Account number

Entity – Contact – all assets

We can export the base solution as a managed solution and import the same into a Target environment.

2. Update base solution – Clone a Patch - version 1.0.0.2

Next lets us add a new custom entity called Hobby and add the same to the base solution. Now if we want to update the base solution we can create a patch of the base solution in Source environment.

Select the base solution and click on Clone a Patch button as shown below.

This will open another window where you can update the patch build and revision # as shown below.

Click Save.

Now there are 2 solutions, the base solution version 1.0.0.0 and a patch to the base solution version 1.0.0.1

In the source environment they will be as unmanaged solutions.

You can export the patch as a managed or unmanaged solution and import the same in the target environment where the base solution was imported. This blog will focus on deploying as managed solution.

Once a patch is created the base solution becomes a parent solution, it is locked in the source environment and no changes are allowed in the base solution. Also you cannot export the base (parent) solution from source environment.  If you delete all child patches of a parent solution, the parent solution becomes unlocked and it can be changed in the source environment.

You can create multiple patches for the base parent solution. More details on patches is given below (reference-1) -

·        A patch represents an incremental minor update to the parent solution.

·        A patch can add or update components and assets in the parent solution when installed on the target system, but it can’t delete any components or assets from the parent solution.

·        A patch can have only one parent solution, but a parent solution can have one or more patches.

·        A patch is created for unmanaged solution. You can’t create a patch for a managed solution.

·        When you export a patch to a target system, export it as a managed patch. Don’t use unmanaged patches in production environments.

·        The parent solution must be present in the target system to install a patch.

·        You can delete or update a patch.

·        If you delete a parent solution, all child patches are also deleted. The system gives you a warning message that you can’t undo the delete operation. The deletion is performed in a single transaction.

·        If one of the patches or the parent solution fails to delete, the entire transaction is rolled back.

3. Updating the solution – Cloning

Once all necessary patches are applied to a base solution you can update the solution using the Clone Solution button. Please note the following about updating solutions. (Reference-1)

·        When you clone a base solution, all child patches are rolled up into the base solution and it becomes a new version in the source environment. You can add, edit, or delete components and assets in the cloned solution.

·        A cloned solution represents a replacement of the base solution when it’s installed on the target system as a managed solution.

·        Typically, you use a cloned solution to ship a major update to the preceding solution.

Cloning a solution will combine the base solution and all the patches into an updated solution and also allow the solution version to be updated. As seen below we now have a Release 1 solution with version 1.1.0.0 in the source environment which is an upgrade of Release-1.

Now you can export the upgraded version as a managed solution and import in the Target environment.

The import process will detect this as an update and will offer the following import options.

1. Stage for upgrade – This option allows you to import the upgrade but not merge the solution with the base parent solution

2. Maintain customizations – This will allow you to maintain any unmanaged customizations in the target environment for the components in the managed solution

3. Overwrite customization's – This option will overwrite any unmanaged customization's in the target environment for the components in the managed solution

Once the update is imported the results window will show the button for applying the solution update.

You may want to not apply the solution update immediately. As this will combine the base solution and all the patches into the updated solution version 1.1.0.0.

The following figure shows the base solution with 2 patches and the upgrade solution in the target environment.

I would recommend to first do a test and make sure the customization's in the solution are all working as designed and then do the update of the solution. If there are any errors you can delete the version of the patch and the upgrade solution 1.1.0.0 and it will roll back the changes.

Once you are ok with the upgrade you can select apply solution upgrade button as shown below.

This will apply the upgrade and will update the solution to version 1.1.0.0

I hope the above helps in understanding the solution versioning, patching and updating process for managed solutions. It is important to take caution when deploying managed solution as even a small error can lead to lot of trouble. And if it is done correct, deploying managed solutions can eliminate many deployment issues and save considerable effort for the team.

.

Please do let me know your experience with managed solution and thanks for reading.

Reference-1 - MSDN - Create patches to simplify solution updates. - https://msdn.microsoft.com/en-us/library/mt593040.aspx

Managing Solutions in Dynamics 365 - Part-1

Solution deployment is always a major concern for Dynamics 365 projects. This blog is to discuss the OOTB options available for Solution management and focuses on Managed solution deployments in an online environment.

In a typical Dynamics 365 project you can have multiple deployments as the software customization code is moved using solutions from one environment to another.

Consider a solution as a bucket of components. Components is customization's done based on user story / requirements. So each solution is basically a group of user requirements delivered to environments for QA and UAT testing and finally deployed to Production.

Effective Solution management requires -

1. Ability to identify, track and control the solution versions deployed in each environment

2. Ability to differentiate between the software codes deployments between multiple environments

3. Ability to uninstall (rollback) to an earlier version if an error is detected in the current version of the solution (using managed solutions)

4. Ability to map and connect user story (requirements) to software customization's (components) 

Solution Types

There are 2 types of Solutions –

1. Managed Solutions

2. Unmanaged Solution

Most of the code deployments in the past versions of Dynamics 365 (CRM) was done using unmanaged solution. It was a challenge to work with Managed solution in a production environment. Also managed solution were mainly used by ISV’s for add-on package software distribution by Microsoft partners.

Some of the risks involved with using unmanaged solution in Production are –

1. It is difficult to control the code getting modified in a non-development environment.

2. It is not possible to roll back or undo the changes made with an unmanaged solution

3. Deleting an unmanaged solution does not delete the customization's in the solution

There are advantages to using Managed solutions -

1. A managed solution only includes solution components that have been customized.

1.1         This prevents unintentionally changing existing solution components on the system where the                                      solution is installed,

1.2         It also keeps the size of the managed solution smaller.

2. Managed solution helps in keeping control over any changes made in the non-development environments. 

You can defined what custom component can or cannot be customized in the managed environment. The managed properties have to be set in the unmanaged solution before exporting as managed solution.

3. Versioning and patching / updating is useful and easy to manage with OOTB functionality.

Risks involved with Managed solution – 

If a managed solution is deleted it deletes the following –

               1. All data stored in custom entities that are part of the managed solution

               2. All data stored in custom fields of system entities that are part of the managed solution

Hence it is never a good idea to uninstall or delete a managed solution as it will delete the data. You can update the managed solution thus maintaining the data.

Details about versioning, patching and updating managed solutions will be discussed in my next blog – Managing Solutions in Dynamics 365 Part-2.

Multiple Solutions –

Agile projects have a continuous development cycle. The solution will grow in size and complexity. It also requires multiple releases to production. It is a good practice to divide the solution into different multiple solutions so it is easy to manage and move from one environment to another. 

For example – You can divide your customizations and configuration components into 2 different solutions. It is also a good practice to have a separate solution for Security Roles to avoid user issues implications during deployments. So there can be multiple solutions like - Configurations / Customization's / Security Roles etc.

Resolving conflicts -

There can be a plethora of solutions OOTB from Microsoft (the last time I counted it has @14 managed solutions if you include all options), ISV solutions and custom development solutions which can be managed and / or unmanaged. 

It is important to understand how Dynamics 365 will resolve conflicts. The figure below shows how the different solutions interact with the System solutions resulting in the final application behavior. The system solution is the default OOTB solution. Managed solutions and Unmanaged customization's determine what the user will finally visualize and experience.

When there are multiple solutions Dynamics 365 will resolve conflicts using the two strategies – Merge and Top Wins. 

1. Merge – All UI components are re-calculated and merged from bottom to top. The unmanaged customization are last to be displayed.

2. Top Wins – All other non UI customization's the conflicts is resolved based on the solution components that is applied last.

Update to a Managed solution does not follow the above rule. 

If unmanaged customization's already exists for updates made to a managed solution, the user may not see the updated changes in the organization. The user will be given an option when updating the Managed solution whether to overwrite or preserve any existing customization's on top of the Managed solution. 

In addition the following is to be noted for updates to managed solutions

               1. Forms merging – Any form customization's may need to be further customized after the updates are published. 

                  

               2. Site Map – Site map customization's need to be verified and further changes may be needed as they are also                            getting merged.

In my experience it is better to have a pre-production staging environment to do a complete test before the solutions are deployed to production.

I hope the above helps in understanding and managing solutions. In my next part II of this blog I will write about the solution versioning and patching options.  

Let me know your past experience with solutions and if you are using Managed solutions for deployments.

Thanks for reading.

Mihir Shah