If you have problems shifting gears in your car, you don’t call Volvo to say “Hey, I don’t like how this gear shifting thing works, so I’m just going to use reverse and drive backwards from now on.”
What you probably do is call them to say “I’m having trouble shifting, you need to fix the problems or show me how to use it properly.“
Ever since Microsoft introduced the Solution platform with Dynamics CRM 2011, there has been an ongoing and never ending discussion about whether to deploy managed or unmanaged solutions.
I can’t say I can end the discussions or solve all problems. But I will try to convince you – there is no discussion.
The messaging from Microsoft has been clear from the beginning:
Use unmanaged in development.
Deploy managed to test and production.
To me, and I guess in theory to most, this has always made sense. Just like we compile our code before shipping, we “compose” our managed solutions, with the delta we want to apply to the target environment.
Not only does this give us the possibility to surgically introduce our solutions in Dynamics environments without overwriting existing solutions and customizations, it also gives us the possibility to remove them by uninstalling our solutions.
Okay, I know, I know… “This all sounds good in theory, but the reality is so much more complex, and we’ve faced too many problems with dependency conflicts, we won’t do managed anymore.”
I have been lucky in this case. I have mostly worked on accelerators, utility sets and modules for business verticals. In our case, everything we did in these areas were enablers – just like the Dynamics platform itself – to create tailored customer solutions on top of.
So I have worked with managed solutions for almost eight years.
We don’t drive backwards
The car is designed to be driven forward, and over the years the use of the gears improve. We use reverse when we park, but we don’t drive backwards.
The real problem with Dynamics 365 solution management is not in the managed solutions.
The real problem is that we even have the possibility to deploy unmanaged solutions.
Driving backwards on the Dynamics platform has become too tempting, and a short term easy way out, just because you don’t like how the gear stick works.
There is no discussion
As I said above, the message from Microsoft has been clear all the way, and the platform is designed to follow their original statement. We can like it or dislike it all we want. But that does not change the design or the long term commitment from the Mothership up in Redmond.
The only reason we even have the possibility to export unmanaged solutions is to get backups of our customizations in development, and to support necessary ALM stories.
The only reason we can put the gear in reverse, is to back up on our driveway.
The real discussion
This is the platform we are working with. So can we please stop talking about if we should use it the way it was designed?
If we can focus on the real discussion, we will all save a lot of time, effort and money.
The real discussion should of course be about:
- manifesting best practices for solution management
- overcoming the obstacles we are still facing
- helping Microsoft sort out remaining issues
Simply put: Let’s work together on this, towards the same goal.
The progress
We have come a long way since when I starting working with Dynamics CRM 4.0, shipping customizations.zip
files that we manually manipulated during our long dark Nordic nights up here…
It’s been a bumpy ride at times, using the Solution concept. It’s been “Missing solution component with id {B1AB1A-1123581321-1337-B1AB1A}
” and we’ve seen “Cannot delete due to dependencies I'm not gonna tell ya about
” not to mention “LocalizedLabel has gone AWOL
“.
But with the introduction of Clones, Patches and Upgrades, we got more options for updating our solutions in a more granular way, reducing the risk of seemingly irrelevant dependency issues.
The release of the Package Deployer tool, with both UI and scriptable execution, the road was paved even more for a Dynamics landscape where we ship managed solutions that are deployed as additions to the target environments, instead of the complete overwrites of unmanaged solution imports.
Microsoft practicing what they preach
With v9 Microsoft has finally taken the last step to practice themselves what they preach to us.
1st party solutions for Sales, Service, Marketing etc are now delivered as managed solutions. When we get updates in Dynamics 365 Online, we can see the updates in the solution import history in our organizations. Developers at Microsoft follow the same rules (almost) that we have to comply to.
Okay, there are still some mysterious internal stages for plugins and Subject
is still a bit of a freak entity, but by large the 1st party solutions are deployed to the core CDS instance the same way any AppSource solution, ISV product or customer specific system is deployed.
Focus!
We have come so far, so please, let us focus on fixing any issues that may be left instead of debating if that eight year old design decision was the right one or not.
Use your gears! Drive forward!
Cover Image Credit: https://static.carthrottle.com/workspace/uploads/memes/stick-shift-54b1be11df7b9.jpg
Hi good article I agree it is never ending however I blogged about it too here had a polar opposite view on it to yourself which is good for learning new stuff from my perspective.
https://antonyellisdynamicscrm.wordpress.com/2017/03/16/understanding-dynamics-365-solutions/
Microsoft documentation also says which you didn’t mention in this post “Only export a solution as a managed solution when you intend to distribute it”.
This infers clearly that managed solutions are aimed at ISV’s predominantly or indeed when Microsoft release new versions of *their* apps. Whilst there can be benefits even if you are not a ISV; on the practical side of things managed solutions are incredibly difficult to work with and for very little business and technical gain even with the new features.
Clients that perhaps are not so agile for example makes it hard for developers to explain to them why there are conflicts/delays every time you plan a deployment, this is made worse when you have larger development teams all contributing to a managed solution and all at different places in their skills and learning curves.
What are the real-world benefits of a managed solution?
Perhaps you would say change control .. and the new features?
Really??? How does that help with a smooth development lifecycle?
If by change control we mean solution versioning (we have that with unmanaged) if you mean you can uninstall and rollback… great but practically how is that useful when entire entities/relationships/fields and more importantly business data is removed from Live? Protecting against accidental data loss ironically, is simpler and less risky with unmanaged than it is with managed.
Not to mention that you can never truly fully uninstall a managed solution fragments of meta-data exist in the platform bloating it over time.
Many organisations CRM deployments evolve over time, a data model that is perfect today does not mean there won’t be some major surgery required tomorrow, scrap major, heck dropping a field. They are constantly being developed… the compiled (managed) version is only any good for a *finished* vanilla product. Plus I know we love to say “compiled” but really there is no comparison between what that means traditionally with application development vs. how Dynamics CRM actually works and all of its painful nuances.
The relatively new options of cloning, patching etc add more complexity and management resource to actually “manage” a “managed solution approach”.
You say its not for discussion
Ironically my blog said otherwise and it really is up for discussion 🙂 I think MVP and Microsoft staff in general which I have met on several occasions have gone through the Microsoft brainwashing school we don’t Google it we Bing it…. but practically speaking whilst it is great that Microsoft have been improvements with a managed solution approach the costs outweigh the benefits.
I’d love for someone to prove me wrong and show me what I am missing here. As honestly the whole CRM deployment is a pain in the arse even if you have good communication in the team and talented people.
Thanks Anthony for your inputs!
My reply became a new post: https://jonasrapp.net/2018/11/case-open/