CRM 4.0 Master Schema Management and Customization Change Control

ExtremeCRM provides developers coding examples, insights, concepts and options for developing customizations for Microsoft CRM 4.0. The primary contributor, Brenden Smith is a Microsoft MCP and Microsoft CRM 4.0 Lead developer for a federal agency in Washing D.C. If you would like to be a contributor for extremeCRM.net

Recently I found a CRM 4.0 Schema comparison tool that I find makes life much easier when I’m playing the role of Schema Master. Managing schema changes is in my opinion a arduous and very manual process. It is not advisable to use TFS for schema file comparisons and definitely not for merging, this is because TFS does line by line comparison not XML tag comparisons. The Customization Comparison Utility lets you compare the customization files between two Microsoft Dynamics CRM systems and the Configuration Data Utility lets you transfer custom configuration data from one Microsoft Dynamics CRM system to another. You can download the solution file here

The process I recommend for the proper management and change control practices essential for the ongoing life cycle of a Microsoft CRM Dynamics Organization Database Schema. The diagram below represents the three typical scenarios that the Schema Master may encounter on a frequent basis. The three scenarios are Jr. Developer or Third Party Developer interactions, Senior Developer Interactions and Multi-Developer Entity Edits. Using the Customization Comparison Utility along with this process will ensure the integrity of your CRM schema and save you from a lot of pain.

Scenario 1

Under scenario 1 a junior developer or a third-party or outside vendor may need to promote changes to the CRM Master Schema. In this circumstance the Schema Master would likely be responsible for heavy validation of the schema changes.

1. The schema items impacted are exported from the developers environment .

2. The schema items impacted are documented in a standard SharePoint change-log.

3. The schema export file is checked in to the weekly schema build folder.

4. The Schema Master reviews the change-log and the may make manual or automated adjustments to the Master Schema.

Scenario 2

Under scenario 2 a senior developer may need to promote changes to the CRM Master Schema in this circumstance would likely be responsible for validation of the schema changes.

1. The schema items impacted are exported from the developers environment .

2. The schema items impacted are documented in a standard SharePoint change-log.

3. The schema export file is checked in to the weekly schema build folder.

4. The Schema Master reviews the change-log and the may make manual or automated adjustments to the Master Schema.

Scenario 3

Under scenario 3 multiple developers may need to promote changes to the CRM Master Schema impacting the same entity. In this circumstance the developers would likely be responsible for creating and validating a single schema export file.

1. The schema items impacted are exported from the developers environment .

2. The schema items impacted are documented in a standard SharePoint change-log.

3. The schema export file is checked in to the weekly schema build folder.

4. The Schema Master notifies the developers of potential conflicts or collisions.

5. The developers create a single schema export file and check it in to TFS.

6. The Schema Master reviews the change-log and the may make manual or automated adjustments to the Master Schema.

The TFS Role

TFS is used as a repository for the incremental schema edits that are proposed as candidates to the Schema-Master. It’s critical that developers only submit specific entity schema segments rather than the full CRM schema, this is because TFS analyzes code line by line rather than in the XML tag format the CRM schema model uses. Also because the environment that the CRM schema is exported from can alter the format and order of the XML. For these reasons it will be incumbent upon the Schema-Master to understand where the schema segments are coming from and to identify the risks associated with the submitting party.

The SharePoint Role

A standard SharePoint form should be used to capture the schema changes being submitted by each developer. The SharePoint form should capture at minimum:

o ID Number

o Entity, Workflow or Role Name

o Attribute

o Deployment Comments

o Impact Analysis Comments

The ID Number shoul

d always be references within the TFS check-in comments and included in the release and deploy notes sent to the Deployment team for each build.

Posted in: CRM 2011 Customization