Approach for Merging Dynamics CRM Solutions with DevOps implementations.

This post has been republished via RSS; it originally appeared at: Microsoft Developer Blogs.

App Dev Manager Kamal Yuvaraj explores an approach for merging Dynamics CRM solutions with your DevOps implementation. How do I merge solutions in CRM? How do I perform feature-based deployment in Dynamics CRM? These are a few frequently asked questions when I am presenting DevOps for CRM talks or asked about my post on “Continuous Integration, Deployment and Test Automation for Dynamics CRM." In this post, I will focus on an approach to address the above questions and help the community in Dynamics CRM’s DevOps implementations. For all purposes, I am assuming to be working with an unmanaged solution file. Please note this is a follow-up post. If you have not read my earlier post, CICD for Dynamic CRM, please review the link https://devblogs.microsoft.com/premier-developer/continuous-integration-deployment-and-test-automation-for-dynamics-crm/ Let us take a step back to understand what a CRM solution file is. A CRM solution file is a component represents something that you can potentially customize. Anything that can be included in a solution is a solution component. Most solution components are nested within other solution components. The purpose of having solution components is to keep track of any limitations on what can be customized using properties and all the solution dependencies so that it can be exported, imported, and (in managed solutions) deleted without leaving anything behind. When you import an unmanaged solution, you add all the components of that solution into your default solution. You can’t delete the components by uninstalling the solution. Main take away here is that the solution file has references to the components, like a pointer back in C++ world. By default, the CRM imports process merges the components in to the target solution file to Default CRM components. Let’s play out a user story-based deployment scenario. Our scenario has two developers (Dev 1 & Dev 2) building two user stories: UserStory1 and UserStory2. Team working on Dev organization, each of them created solutions named UserStory1(UserStory1.zip) and UserStory2 (UserStory2.zip), respectively. At the end of sprint, both these two solutions need to be merged to Master solution (Master.zip) in Commit environment (integration or Test environment). Manual way to merge these solutions to master solution in commit : Export & Save the both UserStory1 & UserStory2 solutions Extract the saved solution .zip folders Open “Solution.xml” files in both solutions in a notepad. In the <UniqueName> node, provide unique name in both as “Master” files Import these two solutions to commit environment (integration or Test environment) After the import, we get a new merged Master solution file with UserStory1 and UserStory2 changes. This is an easier way of merging if the solutions have a lot of components. The similar process can be automated using Azure DevOps as a build step. The C# code below does the same solution edits process. After this step, you can use import solution task to import the UserStory solution to Test environments. We can extend this concept to implement feature switching be dynamically selecting the User stories before promoting to production environment. Please feel free to reach out through you Microsoft Premier Support relationship to help your team with an end to end solution for Dynamics CRM CICD implementation. Other References: https://community.dynamics.com/crm/b/crminthefield/posts/introduction-to-devops-for-dynamics-365-customer-engagement-using-yaml-based-azure-pipelines

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.