Agile style development with Dynamics CRM 2011

Question

My team is in charge of a medium sized CRM system (~1000 users). Currently our CRM is built in-house on Java Servlets, and we are switching over to Microsoft Dynamics CRM 2011. We will have to do a lot of customizations to suit our business logic and regulatory requirements.

We currently do bi-weekly release of features and bug fixes (swap out old jar/jsp files, and swap in new ones). My questions are:

1. With Dynamics CRM, how would something similar be done? Managed Solutions?
   What if a user made customizations based on v1 of a deployed managed solution, can I uninstall that solution, and install a v2?
2. How is change control done?
3. What do you find are best practices, and pit falls?

Answer 1

This is very important discussion and i don't think that is a best answer, it will depend what you want and how you work. I agree with most of Rickard said, i will give you some links that help me a lot establish a process of development:

1 and 3:

• http://gonzaloruizcrm.blogspot.pt/2012/01/managed-or-unmanaged-solutions-in-crm.html
• http://xrmconsultant.blogspot.pt/2011/11/crm-2011-solutions-problems-best.html
• http://channel9.msdn.com/posts/Merging-CRM-2011-Solutions
• http://www.dynamicscrmtrickbag.com/2011/05/28/dynamics-crm-2011-solutions-part-1/

2:

• http://intovsts.net/2012/12/28/integration-of-dynamics-crm-2011-solutions-with-tfs/
• http://community.dynamics.com/product/crm/crmtechnical/b/crmmusings/archive/2012/05/31/solution-packager-enable-source-control-for-solutions-in-crm-2011.aspx

I think you can encountered here useful information for you define your process of development.

Answer 2

If you should use managed or unmanages solutions are up for debate so you won't get a "do this" answer, or to be more correct perhaps you will get a LOT of "do this" that will differ.

My experience is that it's better to use unmanaged solutions for systems you own or maintain and to use managed solutions for products you sell. The reason I think this is that it's quite easy to make dependencies between solutions which make them hard, if not impossible, to remove and in some cases even to update.

You won't be able to uninstall solutions that have resources depending on them, you can update them with a new version though.

Change control isn't implemented in the system so anything you need has to be managed somewhere else.

These are my thoughts on the subject, you will probably hear a lot more and I will be very surprised if they don't differ. I found one article on MSDN that covers some of your questions.

Hope this helps.

Answer 3

1. Just my humble opinion: go unmanaged unless you're developing a stand alone product that you might want to protect its integrity, when installed by customers/random users etc. But if you are developing/customizing a customer specific solution I don't see any benefits of going managed. My experience is that you will likely run into dependency problems etc that will make you regret the choice of going managed. So, only go managed if you are planning on selling an isolated product that you need to protect in some way.