Wednesday 29 January 2014

Enterprise Development Part 1 - Source Controlling CRM Solutions in the Real World

So here is the first in a series of posts regarding Enterprise Development and Dynamics CRM. Our first requirement was to automate the source controlling of our CRM customisations. However, before I get stuck into the detail, a bit of context:

1. Our development is based on the following:

  • Dynamics CRM 2011
  • Visual Studio 2010
  • Team Foundation Server 2012

2. Our development environment is split between a data centre and office network. Although there is a VPN connecting them there is no routing from the data centre network to the office network. This will become a critical factor when determining our approach.

3. We have a single instance of Dynamics CRM that we treat as our Master for CRM customisations and this server is hosted on the office network. The TFS server is hosted on the data centre network.

4. Developers work on standalone instances of CRM and can work on all aspects of CRM including customisations. However, as there is a single server acting as the master for customisations any changes to anything but web resources must be made either directly on this server or exported as unmanaged customisations and imported into this server.
NB. We generally make these changes directly on the server as exporting and importing can prove problematic when multiple developers make changes to the same entity.



ALM Frameworks for Dynamics CRM

Considering Dynamics CRM is itching to increase it's footprint in the Enterprise sector the support for Enterprise Level development within the product is a bit limited. However, there are a some existing frameworks and some open source tools that step into the breach:

Visual Studio xRM CI Framework


A great suite of components including a custom TFS Build template definition that supports exporting and source controlling your customisations. In almost every scenario this would be answer.... 
However, in our case this was not suitable as the TFS Build Agent requires a network port accepting inbound connections (by default this is 9191) from the build server and the network restrictions meant our TFS server could not communicate with our build agent. Furthermore if your build agent is on a different domain this can also cause complications but there is at least a workaround for this issue here.
For those development environments that aren't constrained by the network restrictions we encountered though this would be the recommended approach and you can find it here.

Adx Studio ALM for Dynamics CRM


A collection of powershell cmdlets for supporting Continuous Integration and automated deployments. Powerful but there's a licensing cost and you'll need a reasonable understanding of powershell. There's a bit of a learning curve in getting your head round the framework as well. Unfortunately in our case the cost proved prohibitive and so we went with a different approach....

ALM Framework for Dynamics CRM


A console application for automating the extraction, source control, packaging and deployment of Dynamics CRM solutions. It's a lightweight and open source approach to build automation.  You can find it here: http://crmbuildautomation.codeplex.com.

No comments:

Post a Comment