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

@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
Super User

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
UG GA Amplification 768x460.png

Launching new user group features

Learn how to create your own user groups today!

Community Connections 768x460.jpg

Community & How To Videos

Check out the new Power Platform Community Connections gallery!

M365 768x460.jpg

Microsoft 365 Collaboration Conference | December 7–9, 2021

Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.

Users online (2,550)