Setting up your Dynamics CRM Development & Source Control Environment

Every time I meet people trying to get CRM projects going, I get plenty of questions about how to setup environments and source control properly. Unfortunately, there is no easy answer. However I thought I would share a model that I’ve 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, and it is inspired by fellow MVP Gonzalo Ruiz’s article on the same topic.


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 customizations (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 unmanaged and install them in their development. They can also create temporary “transport solutions” to pull only the customizations 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 managed or unmanaged solution when going from master configuration to integration/UAT/Prod environment is a business and technical decision. It is a separate discussion that we could write an entire blog post about J.


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 customizations and code), going with this approach is overkill. It applies best for big projects when you have multiple developers and heavy customization requirements.


This was fun. Hope it helps!

8 thoughts on “Setting up your Dynamics CRM Development & Source Control Environment

    • Hey Andre! No, I haven’t tried the CI build tools. Looks like its got a very good set of features to automate a lot of operations. I’ll play with it. Thanks for pointing it out!

  1. Hi Salim,

    Thanks for your sharing. It seems this model is suitable for CRM on-premise but it’s not a best fit for CRM online. Any advice?


    • Hi Phu,

      I would argue this can also work for CRM Online environments, where Master CRM Configuration & Test are CRM Online non-production (sandbox) environments. Performing development on local CRM environments is the way to go if you are very keen on having the ability to debug your plugins and custom workflow activities. If you go that route, keep in mind that CRM Online and CRM on premise builds are a little bit different depending on the versions you are using so make sure you only move features/entities that are available in both spaces.

      Otherwise, you can have another non-production organization for development in the cloud (it gets expensive if you have a lot of non-production environments in the cloud though). There is no one size fits all kind of solution, depending on how complex your solution is and how much development is required, you can greatly simplify that I proposed above, or follow it strickly.


  2. Hi Salim,

    This article is insightful, great sharing. I m curious about the source code usage. Should it be a separate branch for every developer ? If so at what stage developers will be using a single code repository ?

    • Hi Yawer, there is not one size fits all. We’ve used both approaches in the past. Single branch for the entire team when we were all working on the same project and towards the same release, different branches when we were working on the same base solution with different areas of development/deliverables. Not sure home much this helps but I hope it does!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s