News Ticker

Dynamics CRM 2011 Solution Development Plan

When a development team is pulled together to customize a Dynamics CRM 2011 system, the first thing the team has to figure out is how to plan the development model. If the team members are having significant .NET application development experience then every developer expects a centralised source control like VSTS. With VSTS, you can just dump all your code into the VSTS Server and point your Visual Studio TFS client to link to the VSTS server. Then the whole development team can co-author thousands of lines of code spreading across modules, classes, solutions and the VSTS helps in merging, locking and versioning stuff.

Do we have anything like this around Dynamics CRM development? Unfortunately, we don’t have anything like this. Dynamics CRM 2011 has introduced Unmanaged solutions which can be used to contain the customizations done and then can be exported from the development environment and then imported to any other environment. But this mechanism does support locking, versioning et cetera and the merging of components are also restricted with few limitations. Hence the usual dilemma is what should be the development plan. I am trying to put thorough my experience here.

The best practise is not to use Default solution for customizations, always wrap the customizations within an unmanaged solution.

There can three possible strategies which can be applied for any team development scenario:

    • (No Isolation) Create one single CRM Organization and One master unmanaged solution. Every developer logs in to this organisation and work on this master unmanaged solution. With this approach, every developer has to make sure he/she does not leave any incomplete customization because this could break someone else’s customization modules and the system could become unstable. This is like someone checked-in a code which does not build and because of that other developers could not run the executable and test and continue with their bits.

The customizations added to this master unmanaged solution has to be well controlled. This makes it little difficult for any kind of POC work in the system. This approach is usually be effective in a very small development team. If the team size is high, say above 5 or so, then solution development becomes increasingly difficult to manage.

Single Org Single Solution

 Avoid clicking the “Publish All Customizations” button, as this would not only publish your customization  but also publish any unfinished customization of your fellow developers and thus causing instability in the system.

    • (Partial Isolation) Create one single CRM Organization and multiple Unmanaged Solutions plus one Master unmanaged Solution. This approach is far widely used. In this approach multiple unmanaged solutions are create, usually one per developer and a master unmanaged solution is created to finally contain all approved and unit tested customizations.  This is better than the earlier approach because now each developer has their own unmanaged solution and they can add their components to their solution only. It is more controlled development model as only the approved and tested customizations goes to the master copy, which would then be exported. 

But developers can still face few issues. As they are using the same CRM Organization and unmanaged solution, any component which is “Published” will be visible in the whole CRM Organization. This can impact other developers. This is not true isolated environment.  Any customization, until published would not be visible in the system. Hence care is required to be taken before publishing any customizations. 

Single Org Multiple Solutions

Avoid clicking the “Publish All Customizations” button, as this would not only publish your customization  but also publish any unfinished customization of your fellow developers and thus causing instability in the system.

    •  (True Isolation) Create One Organization per Developer:

      In this approach, each of the developers are going to have their own CRM organizations and one or more unmanaged solution. This provides true isolation between multiple developers. One developer’s customization remain within the organization and thus does not cause any issues to other developers. However, each developer has to export their unmanaged customization periodically and then import back to another master organization. Every developer’s work would then get merged into one copy in the master organization. This is sometimes an overhead and requires unit testing to be redone in the master CRM organization to make sure the customization which were working in silos still works in the master copy, having all customization.

Multiple Orgs Multiple Solutions

About Dipankar Bhattacharya (59 Articles)
A multi-skilled Dynamics 365 Professional with strong experience in delivering IT projects especially across multiple industries. A Microsoft technology evangelist, a regular speaker at tech events, blogger and avid reader. Certified IT Architect and well versed in Solution Architecture of Business Applications using Microsoft platforms like Dynamics 365, Azure and Office 365.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: