@M-M
I, and many others I've spoken to in the community, have been able to shrink their managed solution deployment times down from hours to minutes if they use the following options in the solution import operation:
- Stage & Upgrade: TRUE (or FALSE if you wish to use the Update pattern)
- Import as Holding: FALSE
- Overwrite unmanaged Customisations: FALSE
- Convert to Managed: FALSE
I would recommend you review your selected deployment options in line with the above suggested configurations if your solutions are taking longer than expected to deploy. Of course, it also depends on the delta in the solution being deployed versus any pre-existing versions already installed.
In addition if you ensure that you don't have any managed objects in your solutions that have not been customised (ie. do not have unmanaged layers) in the development environment, you will find that the solution deploys faster
Historically, people have chosen to segment their solutions for one or both of two reason:
1. To improve deployment times
2. Because they have a genuine need for more granular control over deployments - ie. they have intentional target environments to which they do not wish to deploy all of their solutions, just a subset
With the deployment optimisations now available with the new 'Stage & Upgrade' pattern (previously similar optimisations were only available using the Update pattern), the first of these reasons is eliminated.
As far as maker/developer isolation of changes is concerned, having spoken to various people at Microsoft, I've been advised that solution segmentation was never intended to be used for this purpose. Due to the very nature of multiple team members working in the same development environment, solution segmentation will not achieve true developer/maker isolation due to the inherent risk of cross solution dependencies. You only need someone to create a relationship between two tables in different solutions, for the platform to then automatically bring in a table into one of the solutions where you were not expecting to include it. To truly take dependencies, you need to implement proper Solution Layering and take those dependencies on managed objects. This implies that you need to have a separate development environment for each unmanaged solution being built. This introduces additional complexity when you consider what happens when you wish to delete a managed object that you have a dependency on in a second-layer development environment. You will need to go back to the source of that managed solution and delete the object from the source, generate a new version and then upgrade to the new version in the second layer development environment.
In their current state, Power Platform Pipelines do not provide a enterprise-ready ALM approach, where you want source control to be the single source of truth, you want to deploy artifacts built from source control, you want to deploy multiple solutions, you want to deploy artifacts other than Dataverse solutions etc. If you have multiple solutions, you need to account for and carefully consider:
1. Which order they will be deployed in
2. What happens in the case of cross-solution dependencies and the impact if you need to delete a managed object as part of a managed solution upgrade. For example, if Version 1 of Solution A has introduced component A, and Version 1 of Solution B has introduced component B and solution B has a hard dependency on component A, so you have installed Solution A first in your target environment. Then in Version 2 of Solution A component A has been deleted. But because solution B has a dependency on solution A, in order to resolve that dependency to allow Solution A to be gracefully upgraded to delete component A, you need to upgrade solution B first. So now the order/upgrade pattern of your solutions has to change
It's not trivial managing the above using manual deployment, or Power Platform Pipelines which currently only support the deployment of a single solution at a time. Having a single solution totally removes these issues.
Finally, regarding solution layering - it's not just because of too many layers, and it's unfortunately, not always a case of "top one wins". There are some additional nuances to be aware of whereby the customisations to certain component types do not always merge as gracefully as you expect them to across multiple solution layers. So to avoid this complexity, it better to minimise the total number of solution layers you have, or at least, do not include the same component into multiple solutions if you do end up having multiple solutions.
