Microsoft Dynamics CRM: Setting up your MSD CRM Development & Source Control Environment
Every time when people trying to get CRM projects going, most of them have plenty of queries about how to setup environments and source control properly. Unfortunately, there is no easy answer. However am sharing a model that was used on many occasions and that works well with a combination of a defined methodology, appropriate tools, training, commitment and discipline from the project team members. It is mostly relevant for large projects with multiple developers.
The proposed setup is based on the flowchart below,
The proposed setup is based on the flowchart below,
Development machines (CRM DEV)
The development machines can be a developer’s laptop or work station with CRM development tools + a dedicated CRM organization for the developer (CRM Online or on premise). It can also be a full server (or VM) with CRM installed and dedicated to a single developer. These organizations are setup with a master configuration solution (more on this later) and smaller transport solutions to bring required components for development.
Developers use the various development tools to write code and to debug (attach to CRM services, attach to IIS, using Profiler, browsers debugging tools or using tracing).
When development items are completed, developers build temporary “transport solutions” containing the components they worked on and they push them to the Master Configuration organization. Developers must be careful and not make schema changes on their own development organizations. As the code is deployed to the master configuration, it should also be archived in the source control.
Master Configuration CRM Organization
There is only one Master Configuration environment. It contains the schema configuration and all schema changes should be made there. There is usually one or multiple “Master” solutions sitting in this organization based on how you decide to structure your deployments. You may want to have multiple solutions for various types of customization (e.g. one for schema, one for plugins, one for web resources etc.), or based on functionality grouping.
When developers set up their organizations, they can pull the entire master solutions from the master configuration organization as uncontrolled and install them in their development. They can also create temporary “transport solutions” to pull only the customization they need.
A process (manual or automated) should be put in place to archive the master solutions on a regular basis (daily is recommended). Archiving could be saving the CRM solution files in source control, or even creating snapshots of the server and keep them around for a reasonable period of time.
Integration / Test CRM Organization
This organization receives the master solutions and is used to perform tests. It can be combined with the master configuration environment. The choice to go with a controlled or uncontrolled solution when going from master configuration to integration/UAT/Prod environment is a business and technical decision. It is a separate discussion and we could write an entire blog post about that J.
UAT / PRE PROD / PROD
These environments receive the master solution(s) after they have been tested and validated on the Integration/Test CRM organization.
Wrap Up
Putting this type of environment in place is not easy to do. It takes a lot of process implementation, tools and automation build and more important, training and discipline from the project team members. When working on small project (small number of developer, low amount of customization and code), going with this approach is overkill. It applies best for big projects when you have multiple developers and heavy customization requirements.
Hope this is of any help!!!
