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
Impactful Individual
Impactful Individual

@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

secondImage

Demo Extravaganza Winner Announcement

Please join us on Wednesday, July 21st at 8a PDT. We will be announcing the Winners of the Demo Extravaganza!

V3_PVA CAmpaign Carousel.png

Community Challenge - Giveaways!

Participate in the Power Virtual Agents Community Challenge

Carousel 2021 Release Wave 2 Plan 768x460.jpg

2021 Release Wave 2 Plan

Power Platform release plan for the 2021 release wave 2 describes all new features releasing from October 2021 through March 2022.

Users online (1,850)