Team working on Dev organization, each of them created solutions named UserStory1(UserStory1.zip) and UserStory2 (UserStory2.zip), respectively. Our scenario has two developers (Dev 1 & Dev 2) building two user stories: UserStory1 and UserStory2. Let’s play out a user story-based deployment scenario.
By default, the CRM imports process merges the components in to the target solution file to Default CRM components. Main take away here is that the solution file has references to the components, like a pointer back in C++ world. You can’t delete the components by uninstalling the solution. When you import an unmanaged solution, you add all the components of that solution into your default solution.
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. Most solution components are nested within other solution components. Anything that can be included in a solution is a solution component. A CRM solution file is a component represents something that you can potentially customize. Let us take a step back to understand what a CRM solution file is.
If you have not read my earlier post, CICD for Dynamic CRM, please review the link For all purposes, I am assuming to be working with an unmanaged solution file. 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. App Dev Manager Kamal Yuvaraj explores an approach for merging Dynamics CRM solutions with your DevOps implementation.
0 kommentar(er)
