The Never-Ending Managed vs UnManaged Solution Debate

I came across a great win the other day when doing some work using pipelines in PowerApps.

When it came to deploying to another environment, the only option was to deploy as Managed.

Yes, Managed.

That was the only option and the first time that I have ever seen a definite push for people to use Managed Solutions in subsequent environments in deploying code as in PowerApps as they move out of DEV to TST and anywhere in between to eventually land in PRD.

All, I can say, is it’s ABOUT TIME.

I have done presentations, seminars, training workshops, whiteboard sessions, etc, etc, on the importance of deploying solutions as managed once you’re out of Development. This might come from my early years as a software developer where we “shipped” code to customers and they consumed what we shipped. You had to make it all work together, there was no extra fussing around what you could do with it once it shipped and when shipping it, you made it as small as possible.

It doesn’t matter whether you deploy internally to your customers or ship to others, managed solutions are the representation of your code that your customers should always see.

You don’t ship your source code, you ship the end product – same with managed solutions.

If you’re on the fence as to why to use some Managed Solutions, here are some Pros;

  1. You know what you are deploying where.
  2. No one can mess with your code once you deploy it.
  3. You don’t have to worry about people “changing” stuff for one-offs in other environments.
  4. Current ALM practices are pushing Managed solutions.
  5. Your code is your product.
  6. You can offload deployments to other groups because it’s as simple as them following wizards.

All the errors I have ever run into over the years and reasons for not using Managed Solutions have been more ingrained in poor decisions that an unmanaged solution let you “get away with”.

Namely;

  1. Poor solution architecture design decisions.
  2. Not knowing what is where and who has changed what.
  3. Fear that things “might not work” and we “might need to change things” the night of a deployment.
  4. Worry over not being able to touch things once deployed.
  5. Errors occur when you upgrade on top of them.

I can come up with reasons that all of the above would eventually become bigger issues with unmanaged solutions as you move forward and then get to a point where it blows up big time.

I hope Microsoft doesn’t undo this change and allow for unmanaged solutions to be deployed via pipelines – it would be a huge step backward as we are finally moving past the debate.

To put it in simpler terms –

  • Would you ship all your sources to your customers?
  • Do you want team members messing around with code that you have just finished testing and validating simply because they aren’t sure how it works and it’s easier to do it in that environment?
  • Would you run any of your service code that you write through VSCode or Visual Studio in the debugger on your server by pressing F5?

The answers to these questions are all NO, which are the same reasons for not deploying unmanaged solutions into any environment other than Development.