Getting started with Application Lifecycle Management (ALM) in CRM – Part I

Series overview

For now, I have these episodes planned.

Part I – Web Resources in source control

Part II – Solutions in source control

Part III – Data in source control

Part IV – automating deployment

Introduction

To begin with, I would like to point you in the direction of two real experts: Shan McArthour (http://community.adxstudio.com/blogs/shan/) and Wael Hamze (http://waelhamze.com). Both are amazing people, and much of my inspiration comes from them. In this blog series, I will try to get you started with some very basic ALM, and once you are ready for building a fully automated ALM environment for your projects, you should check out how Wael and Shan do things. 

I am no expert in ALM, but the last year or so it has been a central interest to me. I see many CRM projects fail on quality, repeated errors, inability for the team to act agile and so forth. One of the major problems with many projects is that the first few iterations work fine, but after a while the pace slows down. All of a sudden, it takes a day to add some little piece of javascript code, a new field, or whatever. Not because the code gets harder to write, or the task itself is more complicated, but because we now have many environments that we need to distribute the change to, we have multiple people working on the same CRM system, we fear breaking existing features and so forth.  The solution is better governance, and in software development, we automate the governance and call it ALM.

ALM is very much about automation, scripting, practices, distribution to multiple environments, build servers and so forth. However, before we get started with that we need to have some basic stuff in place that solves some even more basic needs of a CRM project: Complete version control of an entire CRM project. If you can answer yes to all of the following questions you can stop reading, and come back for Part IV in a few weeks.

Does your CRM project have version control of the following bits?

• CRM Solutions (unmanaged)

• C# code (plugins, workflow assemblies)

• JavaScript (as individual files)

• SSRS Reports

• External web services

• Custom pages

• Configuration data

• Lookup data (countries, zip codes, etc.)

• Test data

• Scribe dts files

• SSIS files

• Etc.

This is the source of the CRM system and should be treated as source.

Can you honestly tell me that if all of your dev servers disappeared in a puff of smoke, all it would set you back was the price of buying some new hardware? No work would have to be remade? Until half a year ago I couldn’t!

Source control

First things first: your source control system. Most of the CRM projects I have seen have used Microsoft Team Foundation Server (TFS). If you have one in place already, this is where you want to place your source. If you don’t have a TFS server you might want to check out Visual Studio Online (formerly TFS online): http://www.visualstudio.com/products/visual-studio-online-overview-vs or you could check out something like Git Hub. TFS online is going to be the next big thing for us – as we can work at customer sites and still use our own version control system. In the future we could use tools like Release Manager. Git is a proven technology, supported by visual studio and the basis for a huge number of projects. And it’s more or less free. If TFS doesn’t suit you this could be an alternative.

In this blog series I will assume that you use TFS and my screenshots / examples will be from TFS. I don’t think it will be hard for you to modify the examples to use your favourite version control system.

Putting CRM bits in source control

Of the many things listed that we need to put in source control, I start with web resources. It’s a good place to start as many projects I have seen don’t have version control of JavaScript code, and that’s just a plain disaster. Also using tooling from Microsoft, it’s actually quite easy to fix.

Use CRM Developer toolkit to put your web resources under source control

An easy way to get web resources under source control is to use CRM developer toolkit. This tool adds CRM support to Visual Studio. Download the latest SDK, go to SDK\tools\developertoolkit and run the installer (for VS 2010 or VS 2012).

Once installed, run Visual studio and create a new project. Choose Dynamics CRM as below

 

Create your solution and wait a few seconds.

Now enter your CRM systems credentials and wait a little longer.

 

 The developer toolkit will create a number of solutions for you. Their names pretty much explain their purpose. If you are not using Silverlight you can remove the Silverlight project and its host.

For this example we will also remove the plugins and workflows projects, as we are not about to compose any of those. The developer toolkit is great for that too, but that’s another story.

Now its time to add our web resources to source control and start working with them. First a word of warning: Once you have your web resources in source control, ownership shifts from CRM to TFS. If someone were to update something directly in CRM, his or her changes risk being overwritten next time we deploy from visual studio. This is desired behaviour; your source control system is supposed to be the owner of your source code.

In visual studio choose CRM explorer, go to web Resources -> Scripts right click and choose “Add to packaging project”. Now your files are in visual studio and if you add your solution to source control (you probably already did when you created your solution), you have versioning of your script files. Repeat the process for the other web resource types.

 

Next time you want to change something in your code, you go to your visual studio solution, edit the code and once you are done you deploy the CrmPackage project. That will deploy the files to CRM. Once done you check in your solution to TFS.

Round up

We started using the CRM Developer Toolkit around the time the tool was released and I have had my share of fights with it. It might not always be 100 % stabile and I’m sure you can find people who dislike it. But for web resources I find it to be a great tool. Version control of Web Resources, and especially JavaScript is an essential brick in the ALM puzzle.