Solutions & Release Management – CRM 2011
Microsoft Dynamics CRM 2011 comes with a brand new concept of solutions. Solutions are how customizers and developers author, package, and maintain units of software that extend Microsoft Dynamics CRM 2011. In this post I will be focusing on development of enterprise CRM implementations and utilization of solutions.
In enterprise CRM implementations, many processes/iterations are running in parallel which result in many product releases in parallel. So development, testing and rollout of all releases in parallel with no interference with work in progress are massive challenges.
For example, your CRM implementation is comprised of N release as shown below and you want to utilize Microsoft Dynamics CRM 2011 solution concept to fulfil following goals:
- Development of releases in parallel
- Multiple teams working on multiple releases
- Testing of releases in parallel to development
- Release based rollout to production
- Install or uninstall releases from test or production
- Post production support (Patch/hotfix)
I am expecting that you are familiar with managed/unmanaged solution concepts. So in order to implement above scenario, you need to design your organization and solution structure for CRM 2011 accordingly as given below:
- Create a base organization and a base unmanaged solution in it
- This solution will carry generic customization i.e. account and contact entity customization
- Any generic plugins i.e. creation of counter/auto numbers on custom entities
- Configuration entities and plugins
- Add common security roles
- Add core JavaScript libraries
- Create another organization for each release with one unmanaged solution per release
- Install base solution as managed in this org i.e. very similar to solution library concept.
- Add all release 1 specific components to release 1 unmanaged solution
Similarly, for all other release, use rest of all released as managed solution (reference).
Now, if something is changed in release 1 or base solution, you can use managed solution update feature. Just export new version of base/release 1 solution as managed and install it to release 2 organization by using overwrite or merge option.
Leave a Reply
MSCRM Team Blog
- RELEASE: ALM for Microsoft Dynamics CRM 2011: CRM Solution Lifecycle Management
- Dynamics CRM 2011 IG Update V5.9 May 2013
- Using Power View in Excel 2013 to Analyze CRM Data
- Creating and Publishing a Web Portal to an Azure Cloud Service
- How to build and run the Dynamics CRM SDK samples on Windows Server 2012 and Windows 8
Keep in mind after release 12 in a monthly release cycle you would have 12 orgs to maintain the various levels. To me that creates too much compexity to manage effectivley.
Often times I like to look for more modular breakdown where you can still acheive some level of release agility without complexity that too many layers create.
Just my 2 cents..it’s a great discussion to have as I think we are all learning what works best.
Dave
I have to chime in with Dave here and say that having a division either by technical or functional needs is the better way to go in the long run. Short term it might actually work better if you create solutions for releases. I found that at some point it wasn’t necessary anymore to have all those organizations up at all times. It’s easy (on-premise
) to create new organizations and remove them as you desire. One of the things I ran in to though, when working with a VPC for example, is that a single *empty* organization database is 420 MB
Hi David/Alex,
Release is basically a functional boundary or a module that can be packaged together and not a periodic release.
Administration of organizations and increasing number of solutions are overheads but flexibility of release management is massive.
We can also get rid of all those orgs by incrementally adding solutions to base solution when a release/module is completed. For example, if we have Base Solution, Release 1 and Release 2. After development/test of Release 1, just export release 1 solution as unmanaged and import to to Base solution. In this way Base solution will grow after each iteration and we can also get rid of Release 1 Org and solution. Then for release two use managed base solution as reference solution.
Hi Ayaz,
We have a scenario where we are using base Managed Solution & on top of it Unmanaged Solution.
We have Managed Solution & on top of it when we use unmanaged solution the customizations from Managed solution gets overridden.
I believe this is going to be a common issue when we do development on multiple solutions. Is there any way where I can Compare & Merge the customizations.
Regards,
Ranjeet
Hi Ranjeet,
Managed solutions provide layers on one another depending on their installation order. But priority will be given to any unmanaged customization/solution.
So if you have a managed solution installed and you install an unmanaged solution on top of it your common components will get overwritten. In order to fix this issues, add that entity/component to base managed solution and then try to update managed solution using merge option.
Moreover, Managed solution provides version control, merging and overwrite features which can be utilized to provide hotfix, patched and post production support.
Hope this helps,
Hi Ayaz,
Thanks for your quick response….
I will check your solution & update you if any issues I face.
Regards,
Ranjeet
Hi Ayaz,
I would like to find the solution for Spelling and Grammer check in MS-CRM 2011 could you please help me out.
Thanks
Prakash.G
Hi Ayaz,
Just wondering your thoughts on having separate solutions to manage your CRM deployment. i.e. 1 main solution to contain the core of CRM (Forms, Entities, web resources, etc) along with two supporting solutions that would be Reports and Security Roles. The contents of each solutions would be maintained in your Development Org. with versions of each solution maintained with TFS.
Assuming that the majority of changes would stem from Reports and Permissions having them separate from the main solution would provide flexibility in deploying just those vs. the whole solution for CRM.
Cheers.
.
But how are we doing this in production. Changing a managed solution to an unmanaged solution without loosing all the data?
People often complain that they are managing their sales from one crm program and their time management from a different application. Now Clarizen and Salesforce have a data integration system http://www.clarizen.com/ProjectSoftware/Integrations/Salesforce.aspx that allows your online crm program to “talk” to your online project management software. And it integrates with Microsoft too.
According to Microsoft when you import an unmanaged solution over the top of a managed solution from the same publisher it will create an invalid layering of solutions. We have in fact seen this and are now unable to update our managed solution because of this invalid solution layering. We are on Rollup 5 with the latest updates as well.
Hi Jason,
How can you install same solution as managed and unmanaged from same publisher! It is not permissible.
Ayaz,
Have you gotten this to work in a real-life project? I would be very interested in getting in touch with you. Email me at peter.bjorkmarker at intuni.se.
I have been testing out the same approach. All works well once you get to the step that you describe on your comments. When you have done release 1 and add that one to your base solution. How do you then update the other organizations and specifically the one that you used to make the release? What happens in our testbed is that you are unable to import the base solution. The error message is that “the managed components that you are trying to import already exist in an unmanaged state”. Overwrite/merge does not seem to be an option when the guids are identical.
Or do you simply scratch that org completely and setup a new one? Is that practically possible? When running a parallell project that has say, 3 releases, once they have done their first release, we have to setup a new org for them?
I guess that could work if you are using one joint development environment, but for quality reasons I like devs having their own virtual environment and then one where we merge their changes. You can of course script this, but it is starting to get fairly complicated at this point…
Again, would be great to discuss further.
Hi Peter,
It is very complex structure and you have to follow instructions religiously when creating and customizing solutions. We have also faced many issues but we are now using this approach successfully for our releases. For detailed discussion catch me on skype with your specific questions. My skype ID is ayazi82
Hi Ayaz,
Thanks very much for your sharing. I am wondering if your model can apply for the scenario that has many solutions per release?
Do you find any difficulty with these model?
Thanks,
Hi Ayaz,
If one wasn’t able to work on functional releases as you have outlined and so the problem becomes one of multiple developers amending the same entities with any developer potentially “winning” the race to release, could this be solved similarly to your model but:
OOB
Base (managed)
Developer 2 (managed)
Developer 1 (unmanaged)
plus
OOB
Base (managed)
Developer 1 (managed)
Developer 2 (unmanaged)
and so forth?
I have starting writing it up and would like to bounce the ideas off you.
Thanks
I’m amazed, I have to admit. It’s not every day you see a blog that’s this good on web 2.
0 site, and you’ve got it down completely. Not too many people these days take the time to put some thought into this issue. It’s awesome
that I was able to find this while searching for related topics.
hello!,I really like your writing very much! proportion
we be in contact extra approximately your post on AOL?
I require an expert in this space to unravel my problem.
Maybe that is you! Taking a look forward to look
you.