Understanding D365 CE solution Deployment – Part 1

Today we are going to talk about one important topic – solution deployment in D365 CE.

Before we move on to the topic directly, let us understand the need of discussing the solution deployment in Dynamics CRM. Yes at the moment we are only talking about the solution deployment which includes the customization like configuration changes in entities, fields, business rules, workflows, sitemaps etc and our plugins, custom workflows, actions, java scripts etc.

Data migration / movement is a different vast topic altogether and we can discuss about it in later posts.

Generally in any CRM implementations we would have three basic environments as mentioned below

• Development
• SIT
• Production

Based on the implementation complexity and flexibility of budget, we might add few more environments like Staging, UAT etc

It has been also observed that apart from development environment,  individual developers might use the free trial versions for their own development and then move the changes or even recreate the changes in actual allotted development environment.

As the best practice, we should never do any changes in the CRM default solution which is created when an organisation is created. Hence we generally create new solution in development environment and ask all team members to do the changes in the same solution. They can add the required components and start their changes.

Once the changes are completed and are needed to be moved to SIT or staging environment, solution deployment comes in picture. There are different ways to deploy the solution from one environment to another.  I think we should discuss all the options as its important to understand this to know the implementation in depth.

Different options for solution deployment

• Manual deployment : Here we export the solution from source environment manually and import it in the destination environment
• Using Package Deployer:  Here we export the solution manually from the source and create a package for the deployment. This package can be deployed by using Package Deployer utility provided by Microsoft
• Automated deployment using DevOps: Here everything is automated including the export of the solution, creating package and even up to the deployment to destination

We can opt for any approach for the solution deployment, but we need to first understand the types of solutions and its layers.

Let us go back to early days of application development and deployment in .Net era. When we wanted to deploy our code and did not want to allow anybody to do the changes, we used to create the dll file and deploy the dll file. Similarly we work in Dynamics CRM and would like to distribute the sealed solutions, we have the option of using Managed solutions.

Managed vs Unmanaged solution

• Whenever we create new solution in Dynamics CRM, it is by default unmanaged solution. When we export such solution from source instance for importing into the target instance, it can be exported as Managed or unmanaged.
• If we import Managed solution in target instance, it can not be again exported
• If we delete the Managed solution, all customization from that solution will be deleted along with the data in the deleted entities and field
• Generally we should avoid uninstalling or deleting managed solutions from production instances, any changes should be handled by patches instead
• If we delete unmanaged solution, individual customization will not be deleted. In fact deleting the unmanaged solution. will always remain in the default solution
• Once changes done in unmanaged solution can not be rolled back
• While we import the managed solution, we can decide the fields which can be allowed to customize

We would go through detailed steps on how to actually export and import the solutions and Patch deployment in my subsequent blogs

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/introduction-solutions