Excellent topic that not nearly enough people take the time to dive into, IMO!
There are a lot of considerations to make when you jump over to managed solutions. It definitely introduces new risks to your process, but it also delivers some really excellent benefits at the same time.
My best advice is to start by thinking about the classic stratified visualization of solution layers (see my terrible MS paint skills below): As any component in Dataverse gets returned, it is evaluated against each of your solution layers in order, going from the oldest to the newest managed layers then finally the unmanged layer.
Layering managed layers therefore gives you the ability to have an almost polymorphic control of your solution components where you have mgd solution 1 define an entity "animal", then managed layer 2 says that animal is specifically of type "mammal" and managed layer 3 says that animal-->mammal is specifically of type "ape". This is a really powerful tool when you are mixing together customizations from multiple sources or teams, but if you only have one source definition (this project's dev environment) then it might just be overkill.
"but what about ease of deployment and only moving the newest customizations?" With an unmanaged solution you are always dumping to the same default solution so you can easily just add in the things you've changed and toss it from org to org, but with a managed solution this is less straightforward. You don't want to remove content from your solution just to minimize it (what a management headache!) but you also don't want a ton of managed solutions floating around your higher environments. Skipping right past the fact that it is ugly, when you have multiple managed solutions that contain references to the same components, it becomes very difficult to ever remove those components; say you have field X in mgd solution A and mgd solution B, now you want to remove it from the system. You remove it from A and go to import as an upgrade. but--oh no!--the import fails because you can't delete a component required by another managed solution. You remove it from B and try again, but still no luck because it is required by A! This kind of headache happens more often than you might think because a big advantage of managed solutions is that you can do these subtractive "upgrade" pushes which unmanaged solutions don't let you do. So, we're left with promoting this same managed solution again and again or, as you suggested, Patches.
Patches are an excellent tool, although I think they are no longer the 'preferred' approach of MSFT and may eventually be replaced with something more functional (that is still a long way off, don't worry). A Patch gives you the best of both worlds: it lets you stack managed layers on top of one another in a way that makes them very easy to remove if you want to back out a release, but also sets them up to be cleaned up eventually so you don't wind up piling up conflicts over time and making future subtractive releases unnecessarily difficult. When you generate a patch, what you're doing in your source system is creating a new unmanaged solution that is linked to your main unmanaged one, and when you export it and import it into the new org, it does not merge them, but stacks them so you get your changes, but can also easily back them out. The "Upgrade" you refer to is when you decide that all your patches are rock-solid, the solution is clean and there is no chance you will need to roll any of them out, so you are ready to again call it just one managed solution. You clone as Upgrade and it will consolidate your base solution and all patches into one Managed layer and upon importing into the new org it will do the same; flattening all patches and the base into one nice, clean managed layer again. (if it isn't already obvious, patches are the path I recommend)
So when do you consolidate your patches? That's really a question to be left to your project specifics and how you want to define a patch, but for the ISV products I manage, we do our releases in batches. We lump each of our 'preview' features as individual patches I can give out to customers to review and offer feedback and when we've incorporated feedback and are ready to finalize the release, we consolidate and issue a new major release.
Issues you'll have when using a patch:
- The source is still all one unmanaged layer, so as tempting as it is to pretend that you can cleanly issue patches as individual features that can be installed in any order, this is often not really the case. I especially find a lot of headaches with ribbon customizations where it is an all-or-nothing add to the unmanaged solution. So, for example, if Patch A has a new ribbon button on some entity and Patch B is updating a different ribbon button on the same entity, there is no way to prevent these customizations (and their dependencies) from bleeding over into one another, so when it comes to things like this you will need to plan carefully and often subsegment your patches based on the schema they impact.
- Patches cannot be subtractive
- Patches lock down the core solution so that from the moment you make your first patch until you clone the solution again as an upgrade, you are dead stuck; you cannot even touch your core solution until you go all the way.
On balance, there are of course downsides to every approach, but I find that patches let me and my teams experiment freely with new features, knowing that we can always safely rip them out of an environment if there is an issue. This is an enormous value-add that I just adore, and good enough reason for me to recommend it to anyone.
