Continuous Integration, Deployment and Test Automation for Dynamics CRM

Developer Support

In this post, App Dev Manager Kamal Yuvaraj explorers CI/CD and Test Automation for Dynamics CRM

A successful agile software development process enables shorter development cycles which means a faster time to market. DevOps adoption is key to achieve a successful agile software process. Dynamics CRM has it’s challenges, especially when it comes to continuous integration and deployment (CI/CD) process. Through this series I will be able to share my journey on implementing CICD process for Dynamics CRM with process workflow, POC, and tools. I am sure this will assist developers and architects in having confidence in implementing a successful CICD process for CRM. Multiple organizations have adopted this process with great success. The end goal in adoption of this process is to enable a repeatable and reliable release pipeline for a Dynamics CRM application.


My journey started when I was assigned as DevOps lead for a Dynamics CRM implementation project. Having come from a custom development background, I was used to automated, continuous build and deployment every time code is committed into source control. I had few key challenges with Dynamics CRM.

  • Solution files were manually extracted and imported to target as a deployment process
  • No Unit testing or validation for deployed solution
  • Multiple deployment process is followed between release environments. For example, in Dev and Sit environment the solution was migrated manually, and in UAT, Pre-Prod and Prod environment DB compare was applied to promote changes
  • Reference data was mutually entered in each environment
  • Multiple developers working in the same organizations overwriting the changes
  • CRM is a project, team must work within the exposed API for automation

Rules and Term definitions

Before we started solving the problem, let us take a moment to define some rules of engagement and common terminologies. The rules also illustrate the end goal of the process.


  • Everything must be in source control. For example Plugin Code, Solution file, Reference Data and user roles etc..
  • Check in regularly and every change should trigger the feedback process
  • Feedback process should be short and validates the committed component
  • Track changes and rollback as needed

Dynamics CRM CICD process

The below diagram illustrates a basic flow of an applications’ CICD process.

A basic continuous integration system


Dynamics CRM Workflow


Pre-Commit: This is the development stage where the changes are made to the application. At a start of scrum, a user story is assigned to developer. He uses this environment to make the change and validates them. Unit test is developed in parallel as part of test driven development. XRM interface was used to validate the entity and attribute changes. I have written a framework which simplifies the access to XRM which I will be sharing part of this series.

Commit: This is a completely automated phase which begins as soon as the developer commits the changes into the version control. The result will be reported with pass or fail status. This stage also generates a solution validation script, integrates the checked in solution and validates the solution after deployment.

Acceptance: This is the phase in deployment where the validation is in more detailed and takes hours to complete. This phase is executed against the latest version of solution passes commit phase. In my project this phase was a daily job which usually runs regression test using selenium scripts and validates the integration to multiple systems. Again, the result is pass of fail with published result. If passed the deployable artifacts are versioned and stored in a Binary repository. This version will be used for production release.

Having defined the basic CICD workflow. In my future posts, lets investigate flow of the developer activities and build process in each of the above environments. I will dive into each of the above phases (Pre-Commit, Commit and Acceptance) with detailed explanation of the process with sample code on how to automate the steps.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality. Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.


Discussion is closed. Login to edit/delete existing comments.

  • Michael J. Blackburn 0

    Can you provide links to the other parts of this series? At this point, it’s describing what should happen, not what had been done that works.

  • Mustaque Ali 0

    Hi Kamal / Team,
    In the Commit Phase, I would like to know how to compare the user story specific changes with the base solution and prepare this as a patch for UAT update.
    I was able to automate the Dev to Test migration, but I do not know how to prepare the patch by selecting only user story specific changes.  Can you please help me with that step?


  • John Doe 0

    It’s a pity that there are no further blog posts on this topic. Would be great to have to some more information after this awesome introduction.

  • Marcel Dutt 0

    This blog post sounded very promising. I’m missing a follow-up post though. When will this become available? We want to build our CI/CD chain for Dynamics365.

  • Muhammad Naderi 0

    Looks like a promising blog post,
    Is there a second part we are missing?

  • Shyam Singh 0

    This was the pretty promising blog to get started with Dynamic crm deployment automation. Thank you for this.
    Still, this blog talks about the introduction part only. I needed to automate the parameter setting after the solution is being deployed to the target environment. Could you please suggest how can I do it to automate reference or parameter setting after the solution being deployed using AzureDevops.

Feedback usabilla icon