An overview of environments to support Dynamics CRM development

In my current Dynamics CRM project, I am the solution architect for a new initiative that was set up as a "mini-project" separate from the existing CRM solution's production support and feature enhancement teams. We had our own PM, testing team, business analysts and developers. As we approach go-live of our solution, we are at a point where we are now integrating our work with the other work streams, and this has led me to wax philosophical on the optimal arrangement of environments (dev, QA, production, etc.) to support a successful Dynamics CRM project both pre and post-launch. In this post, I will present an overview of the environments needed along with diagrams showing how configuration and releases should flow through them.

Generally speaking, we think of a generic software application as moving from dev->QA->staging->production, and conceptually a Dynamics CRM solution is the same. (In this post I am using the term "solution" to mean the totality of an application as opposed to an actual CRM solution package.) For a small project team (< 10 people) or a small project (minimal customization, limited custom code), having only these four environments would probably work just fine for the entire solution life cycle. Once you exceed either of those thresholds, though, this model will no longer work.

For the purpose of this discussion, you can think of a Dynamics CRM solution as existing in one of two states, pre-launch or post-launch. Pre-launch you will have many developers doing many different things (forms, workflows, plug-ins, migration scripts, etc.). It's frenetic and messy, and you have to deliver a single integrated solution at the end of the process. Post-launch, on the other hand, your primary objective will be stability, and you'll need to make sure you can move bug fixes into production rapidly without also having to deploy incomplete or not-fully tested feature enhancements.

Here is the pre-launch environmental diagram:

pre-launch

Here is the post-launch environmental diagram:

post-launch

Each of these examples follows the basic dev->QA->staging->production paradigm except they start with a data model environment. Pre-launch has multiple dev environments with a single QA environment, while post-launch has a separate dev and QA environment for each work stream (production support, feature enhancements, other initiatives, etc.).

Master data model

The data model environment is the environment where new entities and attributes are added. It is the only environment where changes to the CRM data model are allowed to be made, but no actual customization of the UI takes place here. Having a single environment where fields are added serves two purposes:

  1. It prevents you from ending up lots of fields like "neweffectivedate" and "neweffdate" that are basically duplicates added by different teams.
  2. It's a sanity check to keep developers from adding new fields all willy-nilly.

The master data model environment is the same in both pre and post-launch.

Dev

In pre-launch, you will likely have multiple teams, each specializing in a different aspect of your solution. If you have a group working just on the CRM front-end, that team should have a separate development environment than the data interfaces team. This keeps developers with different agendas from stepping on each others' toes, and it makes release management easier because each team will generate its own solution (unmanaged, of course). In post-launch, you will likely have fewer teams and/or smaller teams, so the need for multiple dev environments is diminished. I will note that some people feel each developer should have his or her own development environment, and the structure I have outlined can support that, if you treat each of the depicted dev environments as the single "master" dev to which the individual team members promote their changes and where all official unit testing takes place. Also, your specific pre-launch dev environments may be different from what I illustrated in the pre-launch diagram. The point is that you should have a separate dev environment for each separate development team.

QA

As I mentioned earlier, the goal of pre-launch is a single, integrated solution, so that's why all the dev environments here feed into a single QA. At this point your testing team can make sure the different teams' code and configurations play nicely together, and it's better to catch any issues early. In post-launch, it's important not to commingle code too early lest you need to move an isolated piece into production quickly, so that's why each work stream has its own QA environment where testing can take place without impacting the other work streams. QA is also the lowest environment in which any customers or external stakeholders (interfacing applications) should see the solution for demos or reviews. There is of course some risk in showing code before it's been passed by the testing team in QA, but since it should already be unit tested in dev before being promoted to QA, the risk should be minimal.

Staging

Staging is where code goes when the testing team has passed it and it is ready for the customer and/or production support team to formally accept. In pre-launch the production support team may not yet exist as a separate entity, so you can look at the staging environment primarily as an environment for user acceptance testing (UAT). In post-launch you may or may not have UAT for everything that passes through staging, but the production support team will conduct regression testing and take ownership of the solution. Anything that cannot be passed through staging in either pre or post-launch will return to its respective dev environment and must pass QA again before going back into staging.

Three additional points on staging:

  1. Staging should contain something approaching a production volume of data, and it should reside on hardware (physical or virtual) that is similar to your production system.
  2. Pre-launch staging is effectively a synthesis of all the dev environments, so it's not possible for a dev environment to be out of sync with staging. In post-launch, however, because different QA environments feed into staging and the subordinate dev environments are not as stratified as in pre-launch, it is important to pass updates from staging back to all the individual dev environments periodically.
  3. Staging is where integration testing with other systems should be conducted.

Training

You may or may not need a training environment, I think it's a good idea to have a place where users can learn in a relatively consequence free environment and you don't have to worry about them accidentally deleting or creating data that would impact UAT, integration testing or production support validation activities. Updates should flow into training when they are ready to move to production.

Production

Production is where the solution goes when it's ready for users to use it. There will always be only one production environment for a given solution.

comments powered by Disqus