ALM with Microsoft Dynamics CRM

This is the first of a multi-part series suggesting an ALM process in  projects where Microsoft Dynamics CRM is used as a data store.

 

In the last few years, I have been worked on some solutions that use Microsoft Dynamics CRM as the primary back-office system. Dynamic CRM’s rich feature set and it’s ability to be an XRM (eXtended Relationship Management) system makes it an ideal candidate to be an alternative of bespoke database systems. However, in each of the solution, there were some externally exposed services/systems which needed to access the data in Dynamics CRM. So, there was a services layer that will expose required data to other services/systems. In other words, Dynamics CRM acts as data store for other systems.

With Microsoft Dynamics CRM in the frame establishing ALM process has an additional challenge. This challenge comes from the fact that Dynamics CRM is essentially a platform onto which customisations (such as entities, plug-ins, workflows, data, etc.) are deployed. Moreover, the customisations are additive. Because of this setting up a repeatable process is tricky. It is also vital that the “baseline” of Dynamics CRM system is properly captured in any build and deployment process.

Development Build

One of the foremost activity at the start of the development is to get a development build going. The purpose of development build is to make sure that all constituent parts of the system are compiled, the unit tests are run and some level of integration testing done on development workstations. Developers are, of-course, required to run the development build before they check-in.

The same can be achieved with Gated builds in TFS, but from experience running integration and Coded UI tests on team build is somewhat “high maintenance” and developers don’t get the isolation that they get with a development build on local machines.

 

Using CRM in Development Build

So, with Microsoft Dynamics CRM in the picture, what should the process be? The very first thing for you to decide is how to achieve “isolation of environment” for developers. This is needed because each developer will be running his / her own set of integration tests. There are two options:

 1. Local CRM Instance

• Each developer has a Microsoft Dynamics CRM server deployed locally.
• A developer is a deployment admin on her/ his own CRM Instance.
• The CRM team check-ins CRM code and deployable packages in the repository.
• Each run of development build sets up a CRM Organization by compiling checked-in code and use deployment and data files from the repository.

2. Single Development CRM Instance

• A single CRM server for all developers or a group of developers.
• Each developer has his / her own CRM Organization
• All developers are deployment administrator on the Development CRM instance.
• The CRM team check-ins CRM code and deployable packages in the repository AND also “publishes” an CRM organisation  by taking a back-up of a stable version.
• Each run of development build  sets up the CRM organisation by restoring the “published” CRM database backup and running post organisation restoration packages such as map users.

Each of the two options has advantages and disadvantages.

A local CRM instance on each development machine provides more isolation but requires more local resources and CRM knowledge for the local developers. It also means that the development build is slower as setting up an organization is slow. Also means that the CRM SDK needs to be installed each developer’s machine.

The single development CRM instance means that all the developers are dependant upon availability of one server, however, most of CRM details are hidden from them. As long as they are able to restore an organisation database and import an organisation, they are fine.

PLEASE NOTE: The CRM team should always work on a separate instance either way because publishing customisations in CRM is a resource intensive project and them trying to do it on a CRM server used by all other developers will impact the velocity of the team.

Team Build

Like any other project, two types of Team Builds should be set up.

Continuous Integration Build – To be triggered with each check-in, the purpose of the CI build is to ensure that all checked-in code (including CRM customisation code) is compiled and built well and pass all quality gates.

Product Build – The product build is triggered periodically (overnight in our case) and produces deployable packages from the source repository. The deployable package in terms of CRM were the managed and un-managed solution zip files along with scripts for organization settings, import data, data maps,  etc.

PLEASE NOTE: It is important that you generate your CRM Package from the source repository and not from the CRM development instance (for example taking a backup of the organization database) otherwise your source repository will be side track and people will make code changes and fixes in the development environment without ever checking in source code, population scripts, etc.

The structure of CRM deployment packages warrants a separate post, which I will write in the next post.

Deployment

The last piece of setting up the ALM process is setting up a process for the deployment of CRM to take place. The end goal is to have a deployment process that can deploy the deployable package in a consistent and reliable way. The process needs to be repetitive so that you can do it every time when you move between development to test to staging and then to production. This ensures that you don’t get any surprises when you are deploying to production.

As mentioned earlier, any deployment to Microsoft Dynamics CRM is additive. This means that that you need to make sure that the target system deployment is properly baselined. For example, if your production environment has already got some customizations from say another managed CRM solution, make sure they are present in your functional test, pre-production and any other environments as well.

I prefer to use MSBuild based scripts for deployments. The MSBuild Engine is deployed with .Net Framework and libraries such as the “MSBuild Extension Pack” provides a rich set of functionality. You can well use PowerShell. In fact, Dynamics CRM is well  supported in PowerShell. For CRM, there is good PowerShell support as well. However, the latest release of MSBE has now got support for CRM such as Create Organization, Import Solution etc.

Updated 12/03/2014: In my next blog post, I have elaborated the development build process with sample code.

Technorati Tags: Dynamics CRM,ALM