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!

Common CRM Solution Package Components

As a CRM Solution Architect, one thing that I often try to do is keep the complete solution package with a minimal amount of components in order to simplify the deployment process. In an ideal world, we want to limit a deployment to a solution deployment. In reality, this never happens on complex implementations. The purpose of this article is to point out some of common elements that are typically deployed as part of a CRM solution deployment.

  • CRM Solution: This is the .ZIP file extracted from your development CRM server that contains the system configuration and customizations. As part of a deployment, you typically always have one or multiple CRM solutions to apply to the target environment
    • Steps: Import CRM solution(s) in your target environment
    • Can be automated: Yes, use CRM SDK
  • CSV Files for data import: There is often a need to load master data on the system. For example, if you have entities for “Country” and “State”, you may want to populate them with data before people start using the system. This is easily done with a CRM data import wizard.
    • Steps: Import CSV or XML files in your target environment
    • Can be automated: Yes, use CRM SDK
  • Run Workflow(s) against a specific set of record: This is a technique that is often used to fix data issues. Examples of use: change record ownership, populate new fields created as part of the current release, delete records (data clean-up).
    • Steps: Define the query that will return the records you need to run your workflow against, find them (Advanced find or FetchXml) and execute the workflow against all records
    • Can be automated: Yes, use CRM SDK
  • Perform data load from external source: Loading data is usually done by external system (SSIS, Scribe, custom integration etc.) that have connectors to CRM. As part of a CRM deployment, you’ll often have to run data load/update tasks after configuring your integration service to point to your production server. This is used to do data migration or to enable on-going integration between multiple information systems.
    • Steps:
      • Deploy integration components and/or configure them to execute on your target environment (e.g. install SSIS packages, configure Scribe etc.);
      • Turn on integration jobs
    • Can be automated: Depends on the integration tools used
  • Deploy custom web services and/or web sites: To provide extended integration with CRM, we often need to create our own web services that expose custom operations involving CRM data. We also frequently see the need to build custom web applications outside of CRM to display complex and/or integrated data within CRM screens or to create external portals. These web services and web apps become part of the release cycle of your CRM solution.
    • Steps: Package web services and web sites; deploy them on target IIS server(s) and configure CRM endpoint(s) in Configuration files as needed
    • Can be automated: Yes, depending on how web apps is built and packaged

When delivering enterprise solution deployment packages, one best practice is to always plan to automate the deployment of all components that be can be automated. It shortens the solution package deployment process, limits the possibilities of human errors and helps make deployment administrators happier which results in them having a better relationship with the solution and product (I speak from experience J).

CRM 2013 Deployment Certification Tips

I just passed Microsoft Dynamics CRM 2013 Deployment certification exam today with fairly little preparation (i.e. no course, no question studies, and no book). In my defense, I had a second shot voucher so I was thinking I could go back in a week if I didn’t pass it :).

I thought I would share the “study material” that I used to prepare for it.

YouTube Videos

Other Resource

That’s all I used, plus obviously a few years of experience with the product.


Spend some time on

  • CRM Outlook Client material (upgrade path from 2011, Online/Offline mode, having multiple organizations on the same outlook client etc.)
  • Email functionalities (router installation, configuration, server side synchronization, smart matching/tracking token).

Good luck!