Who's your Source on That? Creating Source Control for CRM Customizations

Part 1 of 2: Suggestions for CRM Customization Versioning in Team Development

By Michael Dodd of BroadPoint Technologies and originally posted on BroadPoint Tech Topics Blog.

One of my newest CRM books is called "CRM as a Rapid Development Platform" by David Yack. The book is probably the first CRM 4.0 book that only covers CRM Development. The book's focus is on using MS CRM 4.0 as a platform for Line of Business applications. In doing so, Mr. Yack touches upon some of the pain points experienced with CRM 4.0 Team Development. The top 2 pain points will be the focus of this 2-part blog post:

1. No Versioning/Source Control in the CRM Entity Customization UI (10 out of a possible 10)


2. No Intellisense for Client Side (JScript) Coding (9.5 out of a possible 10).
   

No Versioning/Source Control

This is most evident in developing client side (JScript) code for a given entity, whereby developers can over-write someone's code with their own revisions and publish these changes without ever knowing they were stepping on the other developer's toes. As you may or may not know, this will all change with CRM 5.0, where they have finally departed with the quick-to-deploy, yet “versionless”, customization UI and added a new "Solution Deployment" UI, which will not only include files for Source Control, but native versioning and roll-back features.

I have created my "Top 5 Ways We Can Improve CRM Team Development" below.

1. Do all CRM Customizations & Development on a Shared Environment - This is possible the most obvious yet most ignored step to improving team development. If the client does not have a development environment, we should create a shared virtual environment that everyone can access (and have local access to via diff disks). This would contain all the necessary development tools (CRM, VS, SQL, SRS, Scribe) as well as an instance of Visual SourceSafe.

2. Treat CRM Customization Files as Source Code - First, all CRM Customization should be done against a Blank Solution in Visual Studio. Next, create separate folders for each Entity being customized. Finally, you must keep each Customization.xml file and all supporting JScript (as .js files) for each CRM Entity being customized (and checked into SourceSafe) in the appropriate entity folder. This will allow for some semblance versioning for each CRM Entities, Workflows, Sitemap and ISV configurations. It will also provide (albeit somewhat flawed) roll-back capability.

3. Standardize Naming Conventions for Customization files

4. Have a Scheduled Deployment of CRM Customizations - Whether it is nightly of weekly, developers must be in sync with the team's changes. one of the biggest reasons we step on each other code is because of a lack of organized deployment of code to the "Master" (or Testing/QA) environment. This will also keep "quick changes" from messing up your code

5. Use Descriptive Comments in your JScript Code

For more information contact BroadPoint Technologies