UPDATE (17MAY2013): There’s now a whitepaper on the topic as well: ALM for Microsoft Dynamics CRM 2011: CRM Solution Lifecycle Management

NOTE: I’ve included related links to both Visual Studio 2010 & 2012 content.  Even thought the Developer Toolkit for Microsoft Dynamics CRM now supports Visual Studio 2012, I recognized not everyone has upgraded.  I do my best to differentiate VS2010 & VS2012 where necessary.  You can always switch to the right version of the documentation if you click the wrong link:

I’ve had a recurring discussion lately about using Visual Studio’s Application Lifecycle Management (ALM) tools:

http://msdn.microsoft.com/en-us/library/fda2bad5(v=vs.100).aspx (Visual Studio 2010)

http://msdn.microsoft.com/en-us/library/fda2bad5(v=vs.110).aspx (Visual Studio 2012)

…including Team Foundation Server (TFS), when developing Dynamics CRM 2011 solutions.  CRM Development is a little different than traditional software development because you write much less code than building something from scratch (in some cases no code).  However, I am a firm believer that CRM projects should be RUN just like a custom dev project.  Especially enterprise projects.  Enter Visual Studio ALM…

Many think of Visual Studio and Team Foundation Server as just for developers, but if you read through the links above, you will learn there’s much more than what you might think.  However, leveraging all of these capabilities in the context of a Dynamics CRM project isn’t really spelled out anywhere.  This post is an attempt to be a contextualized table of contents of public information to help people understand how the two worlds collide.  The 2010 version of the ALM starter page breaks Visual Studio ALM down to:

• Plan and track your project. Enact processes and monitor their quality to help your team turn customer requirements into working software.

• Design functionality, either on top of existing assets or from scratch, by using architectural diagrams to communicate critical information about your team’s software.

• Write, unit test, debug, analyze, and profile your application by using tools that are integrated with the rest of the application lifecycle so that your team can understand how your progress contributes to the project. Use version control to manage your source code and other files.

• Build your application by using an integrated build system so that your team can ensure that quality gates have been met and verify that requirements have been fulfilled in each build.

• Test your application by running manual or automated tests, including performance and stress tests. Manage testing systematically so that your team knows the software quality on any given day.

• Deploy into virtual environments to enable more sophisticated development and testing.

I’m going to use this as the structure of my mapping to CRM.  There’s nothing really specific to Plan and track with CRM.  However, I find it surprising how few people are using the Visual Studio planning and tracking tools (work item / bug tracking, reports, etc.) on CRM projects.  Definitely review the material to learn about how TFS can help you run your projects.  The next area where Visual Studio can really help is Write, unit test, debug, analyze, and profile.  With CRM, you “develop” with two primary tools: The CRM Web UI and Visual Studio (usually with the Developer Toolkit for Microsoft Dynamics CRM):

In may cases, you also use community tools to do things like site map and ribbon customizations.  However, in the end, those tools ultimately modify the CRM system (usually by modifying XML files).  So the writing code part should be pretty self explanatory through the CRM SDK (online / download) and developer toolkit.  The first place where you need to sprinkle in additional CRM context/nuance is unit testing.  My posts here should help you:

How I develop and unit test CRM 2011 plugins (make sure to use Fakes instead of Moles if you are using Visual Studio 2012)

Unit testing CRM 2011 JavaScript web resources

Debugging is another place where people get a little tripped up.  There are multiple approaches to debugging both plugins and web resources.  Debug a Plug-In explains how to attach Visual Studio to the right process to debug plug-in and workflow code.  Of course this requires you to attach to the CRM Server.  In cases where you can’t, you can profile code execution on the server, save it locally and debug by replaying captured state.  See Analyze Plug-in Performance for more details.  The CRM SDK has a section on Debugging JavaScript in Microsoft Dynamics CRM.  If you are developing your CRM code using a Test Driven Development (TDD) approach with unit testing, then you might come to the same conclusion I came to in my Developing CRM 2011 customizations without a local server post.  My personal opinion is that unit testing makes the debugging process much better and improves overall developer productivity.  So what about using version control to manage your source code and other files?  Remember that most of your non-code customizations can be exported as part of CRM solution export as XML files.  I blogged about how to integrate the SolutionPackager tool from the CRM SDK into Visual Studio to source control non-code customizations to help you get started.

The SolutionPackager tool lays the foundation to enable you to build your application on a build server.  However, most people who go to the extent of using a build server also want more advanced build automation such as deploying to a test server or virtual environment.  While there’s a whitepaper called Deploying Microsoft Dynamics CRM 2011 and CRM Online Solutions from Development through Test and Production Environments which covers some of the nuances of such automation, it leaves much of the work to you to implement.  Thankfully, ADXStudio has built the Adxstudio ALM Toolkit which greatly decreases the time it will take a team to reach this level of automation.  Shan McCarthur delivered a fairly comprehensive webcast on team development that brings all the core topics together.  While the webcast is relatively ALM tool agnostic, it’s not a far leap to understand how use Visual Studio ALM tools after watching and having gone through the material in this post.

What about functional testing?  Unit testing is great and all, but not everyone is bought into TDD and unit testing.  I always tell people that unit testing doesn’t replace functional testing.  However, it usually DOES result in less bugs found during functional testing.  The Creating and Managing Tests section of the Visual Studio ALM documentation does a good job of navigating you through the different kind of functional testing it supports.  The little gem that I don’t think enough CRM projects are utilizing is Testing the User Interface with Automated UI Tests (aka Coded UI).  Dynamics CRM 2011 is one of the many Supported Configurations and Platforms for Coded UI Tests and Action Recordings.

And performance testing?  Performance testing is absolutely critical for any large scale software solution.  Not enough people do it.  The end result is usually finding issues in production when you go live.  UGH!  Performance testing can prevent lots of heartache.  The Visual Studio has tools to help you in your Testing Application Performance and Stress.  A compliment to Visual Studio is the Performance Toolkit for Microsoft Dynamics CRM 2011 which is just a set of guidance + additional tools which show you how to Visual Studio Stress Testing Tools with CRM.  Stress testing with CRM is a pretty specialized skill.  While I’ve given you pointers to the tools to do it yourself, you might want to consider the Microsoft Dynamics Benchmark offered by the Dynamics Premier Field Engineering (PFE) team at Microsoft.

@devkeydet