Different Environments for Different Apps

[jase]

Hi all,

At what point would you decide to create different environments for different solutions/apps?

Currently we've been using one set of Production type environments: 1 x Dev, 1 x Test and 1 x Live.

Using those we've created several different apps/solutions. We are getting to the point where we are getting some cross-contamination between solutions and it is becoming a pain when exporting and importing between env's as we're get dependency issues, resulting in us having to includes tables that have nothing to do really with the solution we are importing. We use the Microsoft Entra ID table in some, which I think is causing some of the issues.

So, we are now thinking that for this new app that we are making, which in the 'real world' has nothing to do with the others, we'll create a new dev, test, live for that new app/solution. Just wondering what people's general approach is?

[Amik · Accepted solution]

@jase -

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 an 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, and as you have pointed out, 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.

One option to address this, and one which I personally use, is to adopt the segmented solutions approach for ALM. 

https://learn.microsoft.com/en-us/power-platform/alm/segmented-solutions-alm 

The fundamental purpose of this setup is to avoid cross dependency risks when managing multiple Managed Solutions in the same environment, because as you have experienced, cross dependency errors are a nightmare to resolve.

Another problem segmented Solutions can potentially avoid is a scenario where 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 for this solution to properly work in the "real world" as you put it, you will need to:

1. Import your Unmanaged Solutions to your Developer Plan Environment as a holding area and take zip backups

2. Completely reset your Dev, Test and Prod environments.

3. Take the Unmanaged Solutions and start splitting out the components into separate Solutions

4. Import the Segmented Solutions back into your Dev, Test and Prod environments to end up with something like this:

I should also caveat that managing individual components in this way via a segmented Solution creates more work – especially if you’re doing automated deployments via Pipelines. At the beginning of this response I mentioned there is no single right answer, and this is because sometimes it is sensible to just include all components into a single Solution and manage updates with bi-weekly releases without worrying about dreaded dependency issues and solution layering.

[jason_prod]

.

[jase]

Thanks very much @Amik. That is a really helpful and detailed response. Lots for me to consider there and you have definitely helped clarify some things for me.