Dataverse Solution Strategy

[JasonSealy]

Hello,

I have seen some videos and blogs about solution strategy in dataverse but I still don't fully get it. I believe I understand the application life cycle management (ALM) part of solutions where there is unmanaged solutions that can be exported to other environments to be tested then go to production. But I think there is a gap in my knowledge about "creating solutions per the component type". Below is a a screenshot of a video I watched that talked about this and I don't really understand it.

My main questions are:

1. What is the fundamental purpose in separating the solutions in the screenshot above.

2. Is there any considerations I should be taking into account when developing a solution strategy. (For a bit of context the I am working with a startup company and don't expect to have a large amount of apps or users but want to build a framework that can support a large amount in the future)

Thanks,

All the best!

Jason

[dpoggemann]

Hi @JasonSealy ,

I am interested in learning more about the solution by component approach because this is not how I have ever done this.  Can you share a link to the video so I can review?  

Are you building solutions that might go into ISV solutions or for your own organization as internal systems?  If for your own organization / company as internal applications then I would probably build a single solution and manage this deployment through your environments (unmanaged in development and managed in test / production).  This is the approach I have utilized in many customer deployments but the best practices here continue to progress.

[Amik · Accepted solution]

Hi @JasonSealy ,

1. The fundamental purpose of this set up is to avoid cross dependency risks when managing multiple Managed Solutions in the same environment, these can be a nightmare to resolve.

2. I do not think there is a single right answer. If you have a simple app with a couple of tables and a few components, and you can be virtually certain those components will not be depended on by other Solutions, then using a single Solution is the recommended option. In addition, if you have app which uses Flows and those Flows are only associated to that app, then packaging those components into a single Solution is fine as well.

Where trouble can begin is when you have multiple Solutions which share the same components. For example, suppose Solution A includes a specific component, such a Table, a Flow and a Canvas App. Developer A is making updates to the Entity views and Flows, while Developer B is currently making updates to the Canvas App. If we included all components into a single Solution, we cannot import to Production yet because although the Canvas App is ready to deploy, the Entity View and/or Flow is not. By segmenting the Solution, you only include components that are ready for distribution as an update into the Production Environment.

Another problem a segmented Solution can potentially avoid is a scenario whereas several Solutions contain the same component. For example, Solution A includes a specific component, such as a Security Role. Later, you also have Solution B which also includes the same Security role as a required component. Later, you remove the Security Role from Solution B but receive an “import failed due to missing dependencies” error because Solution A depends on it.

Note however that managing individual components in segmented Solutions creates more work – especially if you’re doing automated deployments via pipelines. Often it is sensible to include all components into a single Solution and manage updates with bi-weekly releases without worrying about dreaded dependency issues and solution layering.

------------------------------------------------------------------------------------------------------------------------------

If I have answered your question, please mark your post as Solved. Remember, you can accept more than one post as a solution.

If you like my response, please give it a Thumbs Up.

[JasonSealy]

Here is the link, the screenshot is taken at 10:30 and before the screenshot the video explains the reasoning. I think for my purposes I will build my application in a single solution as it seems like the most reasonable for my situation.

Thanks,

Jason

(2) Creating a Dataverse Environment and Solution Strategy - YouTube

[JasonSealy]

Thanks Amik, helped a lot!

Jason