Solution Overview

In the Power Platform, when we discuss ALM (Application Lifecycle Management) at a high level, we’re really hitting on three major components:

• Environments
  • Dev, Testing, Prod, etc… These are where the application runs and data lives
• Solutions
  • Vehicles that carry the application logic and components, i.e. flows, tables, power pages, power apps, etc…
  • Solutions are what get deployed between environments
• Pipelines
  • Optional - automates solution deployment between environments

In some other posts I might cover pipeline best practices and lessons learned (there are a lot), but for now we’ll assume a simple example throughout this post of a manual deployment.
You have some solution, you export it from a dev environment, and import it into a prod environment.

What could go wrong?

What Could Go Wrong?

Missing Solution Components

We’ve all been here, not a huge deal. You just forgot to add some new flow or table to your solution. Once you do, everything works great. Basically a non-issue.

Missing Dependencies

An extension of the previous issue. Let’s say you added your flow, but that wasn’t enough.
You forgot your flow relies on two other flows and a connection reference - whoops!
Then you find out that one of those new flows actually relies on a table, and the table relies on a global choice value.
It takes a few minutes, but you use the solution checker tool to find the all the missing dependencies and you’re eventually able to resolve the issue. Certainly not ideal, but hopefully you didn’t have to take an aspirin.

Mega-Solutions

You saw this coming, I know. This is what happens when a solution snowball rolls down the Power Platform hill. You keep adding dependencies and adding dependencies until one of three things happen:

• You run out of aspirin, quit, and become a farmer
• You eventually manage to find every single component that is a part of the dependency tree
• You add every single component that exists in the environment into your solution so that you can, for the love of God, move on with your life

If you find yourself in this situation, the end result is always the same (unless you chose farming - good for you): you have a mega-solution.

Here are the reasons this is a bad idea:

• Deployment times. Smaller solutions deploy faster
• Deployment specificity. You can’t deploy part of your solution - it has to be the whole thing. That means if something is broken in your solution it gets deployed as well.
  Can you imagine working on a team where everyone deploys the same solution? You would have to coordinate a deployment schedule and every dev would have to ensure all their content is ready for deployment on that day. Not happening.
• Documentation. I mentioned pipelines earlier. You might setup some sort of pipeline proces to use automated tools to document solutions (Powerdocu is a great one). Smaller solutions result in better documentation.

What Can We Do?

Treat solutions as self-contained, individual components and maintain a flat hierarchy.

The key here is that each component needs to be able to scale and deploy on its own. Break your system down into smaller systems that can communicate with each other. As small as they can be while remaining discrete units. These are your basic solutions.

No solution can be dependent on a component from another solution. Just don’t do it. This usually happens when:

• We have some flow that provides share logic
  • Great, put this flow and its dependencies in its own solution. Treat it like an export function in your utils folder. Any solution that wants it can add it and its dependencies, but it doesn’t belong to those solutions.
• We have some table that needs to be shared
  • Similar idea as the flow. Let the table span multiple solutions by existing in its own solution.
• One solution needs to communicate with another
  • You may have tried a child flow here, which lead to a mega-solution. Child flows create dependencies. Use HTTP request actions and triggers to communicate between solutions without creating dependencies

Conclusion

I hope this helps! Keep going, and remember the Power Platform motto -
there’s always a workaround.