cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Dlabar
MVP

Unmanaged to Managed Solutioning Strategies

I'm starting my first project where I'll be using managed solutions.  In my unmanaged solutioning, each release I create a new solution, and put only the changes that have been made into that solution, and then deploy through the environments.  Can I just do the same thing in a managed sense?  Or should I be having a single managed solution that contains everything that I deploy each release?  This seems wrong to me.  I know I could use patches, but then at what point should I do an Upgrade vs another patch? I've also seen different projects where solutions are divided up, Tables/code/other/etc.  Is that helpful as well?  And if so, how do I not create issues with inter managed dependencies?

11 REPLIES 11
cchannon
Continued Contributor
Continued Contributor

@BenediktB If a given feature is in development and you need to release a separate enhancement, you just make another patch and have them in parallel. If you need to release something big (that crosses patches and makes them impractical to release independently), you clone as upgrade and you are right back where you would have been if you'd never made a patch in the first place. Sub into that paradigm your 'spin up a new org' solution and you need minimum 3, possibly 4 orgs to get the same thing done and you can't easily see possible points of overlap/conflict between the feature releases until you try to bring them back together (at which point, you're assumedly doing it unmanaged and Dataverse won't even warn you if there is a conflict, just last one in wins).

 

I get that it adds overhead, I really do, but it also adds value. Not right for every situation, of course, but not something that should be dismissed out of hand.

 

I now dub myself "that crazy guy who has spent more effort defending patches than any person would ever consider reasonable."

EricRegnier
Super User II
Super User II

Hi @Dlabar,

For a green project/system I would also recommend managed solutions all the way for some of the benefits described in the previous posts. Without going into the theory, practically in my opinion the main benefit with managed is that it automatically cleans up unused components like fields, views, etc. Whereas unmanaged every developer needs to be disciplined and manage/script those for upstream environments. This saves a lot of time and headaches in the long run. Some other benefits mentioned like the ability to uninstall/rollback a solution, in my experience is not realistic. When do we ever do that in prod? We usually roll forward with a new version or solution.

To answer “seems wrong to push full solution”: traditionally the dev environment would be the source of truth for the configuration (eg tables/entities). With the latest CI/CD practices, regardless managed or unmanaged solution, the source control should be the source of truth and place to manage conflicts, and production ready code/config. That said, whether you choose to deploy only the changed components in a small unmanaged solution or same managed solution with a new version is mostly irrelevant... As Scott alluded to, it’s probably more management to create a new unmanaged solution and determine what change for the upcoming deployment, then to simply reused your managed solution and increase version. For deployment time, technically having larger solutions will increase deployment time but in my experience that’s negligible. Having a solid CI/CD pipeline does because there are more repeatable and automatic steps/actions to ensure the target environment is in the expected state. As we know even if it takes more time the advantages outweighs immensely the time. Traditionally again, with unmanaged although not the reason but it facilitated us to directly update in prod or test and then redo the change in dev.

 

The most important and critical thing when choosing to go the managed route is the design of your environments which will dictate how you segment solutions. A general rule of thumb is one managed solution per dev env. In a constantly changing agile ALM, it is very hard to determine this. You might not think a component/module is “core” but then tomorrow a new business initiative arrives and becomes it!

 

BTW it might seem that I’m against unmanaged but I’m not, I do appreciate its simplistic approach sometimes. What matters the most is having a healthy ALM and you can have with unmanaged. It just that with managed solutions, I find it will help more with that process.

 

Hope this helps!

Helpful resources

Announcements
PA User Group

Welcome to the User Group Public Preview

Check out new user group experience and if you are a leader please create your group

MBAS Attendee Badge

Claim Your Badge & Digital Swag!

Check out how to claim yours today!

secondImage

Are Your Ready?

Test your skills now with the Cloud Skill Challenge.

secondImage

Demo Extravaganza is Back!

We are excited to announce that Demo Extravaganza for 2021 has started!

MBAS on Demand

Microsoft Business Applications Summit sessions

On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks

Top Solution Authors
Users online (60,698)