Microsoft Dynamics Solutions - Management & Best Practices

This post is to help clarify what the best approach is to manage and use Microsoft Dynamics CRM Solutions to distribute your customizations and software components through your various CRM Environments, from Development, QA, Staging and Production.

That said, there isn't really an ultimate approach which is 100% right or 100% wrong, rather each with its own pro's and con's.

Managed vs. Unmanaged

I don't want to go too deep into the differences between managed and unmanaged solutions, but it is important for you to understand why you would use one and not the other, based on your requirements.

Unmanaged
Commonly this is referred to as the source, where you can distribute the solution to a different CRM organization, but with the added flexibility of having the ability to further making changes to what has been installed. For example if there was a new entity, which a screen you didn't like the look of, then you have the ability to make changes to that screen.

You cannot uninstall a unmanaged solution, you have to individually delete each company manually.

Installing different versions of the same solution will just overwrite what was installed by the previous version, there is no unmanaged solution layering based on versions.

Managed
Commonly referred to as the compiled or build version. The main reason to use this, is to protect your solution. For example if you are a software vender which has built a great add-on solution, you want to sell this solution but do not want others being able to further customize or copy your hard work. There is an exception to the rule, where you do have the flexibility to mark specific components as customizable,  a good workaround if there was a scenario where you did want to give the option to change a specific part of your solution.

All managed solutions can be uninstalled, which automatically removes all components that were installed as part of that solution.

Managed Solutions can also be layered, this is where different versions of the same solution can be installed on top of each other. For example, version 2.0 of a solution can be installed on top of version 1.0. Now if there was an issue with version 2.0 and you needed to rollback, then you can uninstall 2.0 which would revert the system back to version 1.0.

What are the Options?

1. Single Solution - this is where all customization's and components are distributed within a single solution file

2. Multiple Solutions - where components are split into various solutions, for example:

Pro's & Con's

Single Solution

• Pro's
• Less dependency issues
• Everything in one place, single install
• All components have one version
• Con's
• Solution can become large
• Releasing a change to a single component will require releasing all components in the solution. Developers who have incomplete items can become a bottleneck
• Incomplete customization's can accidentally be exported and included in the solution
• Cannot use different versions for different components. 

Multiple Solutions

• Pro's
• Smaller solutions
• Categorize components into relevant solutions
• Developers can work on components in different solutions in parallel with less concern of exporting incomplete customization's, or becoming a block point for a solution export
• Don't have to release everything, only the solution that has a change 
• Better Granularity with solution versioning, as each solution can have its own version number
• Con's
• Installation will fail if dependent components do not exist, dependent solutions must be installed prior. Thus the order by which the solutions are installed becomes very important.
• More than one solution is required to fully install your entire solution, as the various components are split between several solutions
• Rollback requires you to uninstall each solution

Conclusion

Many times I've had to make the decision, whether to go with a single or multi solution approach. I have devised an easy method of selection, depending how and who you are targeting the solution for.

Single Solution

Software House - if you plan on targeting your solution for sale as a product based solution, then I would recommend using a single solution as the release cycle for this product will be managed by you the software vendor and your customers would expect an easy upgrade process between versions. Also simplifies the uninstalling process for the customer.

Multi Solution

In House - for an internal CRM project. Having the ability to make changes and perform smaller releases and hot fixes outside major releases are much more likely. Think about all those business users that say one thing but want another. Reacting to bugs can also become easier to manage due to the ability of smaller deployments, as you have the ability to release only the solution that has changed. As the development project is managed by you and not a third party software vendor, using a multi solution approach makes much more sense. 

Mixed Mode
Hopefully this won't confuse you further, but a mixed mode of the two could also be utilized  Whereby you use a multi solution approach during development and then merge and produce a single solution for production release.