And why would I even start writing about this.. Well, not because I’m hoping to offer a decisive argument, and certainly not because I am hoping to bring Jonas Rapp to the “unmanaged” camp or Gus Gozalez to the “managed”. Those would be all futile attempts.
I just think that managed solutions are overly complicated. And I also think that unmanaged solutions are overly complicated. And (I think) those two statements can live in perfect harmony.
For the managed solutions, solution layering, even though it’s, in a way, an awesome concept, can easily make you lose sleep once you start thinking of how it works.
For the unmanaged, there is a lot of housekeeping that you may have to do in different environments (manually or using your own and/or third-party tools).. although, I am not sure it would have been all taken care of automatically if you just started to use managed.
But, in general, the whole concept of solutions in Dynamics/PowerApps has an inherent flaw which is not going to be solved just by making a solution managed or unmanaged. So, in my mind, arguing over managed vs unmanaged can surely produce some very interesting discussions but, eventually, is not going to produce any final conclusions.
Unless, of course, PowerApps product team decides to lock it all down somehow and just enforce managed solutions in production, but, that’s only going to lock down the last leg of the deployment process. We will still have to live with the mix of managed / unmanaged between “dev” and “integration” environments, so the whole argument is not going to be over.
I can’t figure out a single word for that flaw I mentioned above, so let me just try illustrating the problem by comparing PowerApps solution development to a regular .NET solution development.
What do we do when we are developing a .NET(or Java.. whatever, it does not matter) application?
- We have source code repository where our code is stored in its “native” form (well, “delta” or not, but we can look at the latest version of the code in its normal form)
- We have merge tools
- We can commit code changes and resolve merge conflicts
- Finally, we can set up nightly builds to build and test the code we have in the source code repository
Then, we have PowerApps/Dynamics, and it all goes wrong from the beginning.
- There is nothing “native” about the files (solution files or extracted component files). Those are XML (and, lately, json in some cases) interpretations of the actions we had taken in various UI designers – some of us can understand those files better, some may have troubles.. but there are only a few(if any at all) people who can responsibly say that they know everything about those files
- There are no merge tools. Combine this with the statement above, and you will see how this whole picture is starting to get dark
- Without the merge tools, committing the changes and resolving merge conflicts is becoming an impossible task
- The last step is, actually, somewhat achievable. Yes, we can automatically deploy solutions. As far as testing goes, that’s a big questions.. although, it’s mostly a question of whether we have decided to dedicate enough time to automating the QA with the tools like EasyRepro
Whether we are using managed or unmanaged solutions does not help with any of the steps above, so no matter which solution type we choose, we are not going to solve the actual problem, it seems.
Question is, then, whether one approach is, somehow, better than the other, since neither one is perfect.
Quite frankly, the way I’m looking at it is: if there is an irreversible action, I would not take it. Almost as in “no matter what”. I don’t like burning the bridges – you never know when you’ll need one. Managed solutions, in my mind, is an example of such an action. Once it is deployed in the environment, that environment is locked down. And if it were really locked down in terms of development, I might still understand.. but it’s not – a System Admin can still go to the default solution and customize a lot of things in the environment. But our solution is, now, locked – there is no way to export it once it’s managed. So we can’t get a copy of that environment to restore it in dev.. Which means we have to maintain a dev environment somewhere all the time.
So, yes, it seems I’m totally on the unmanaged side, but, like I said above, this is one of those arguments where there probably can be no winners.
Because, of course, managed have some benefits. They are easy to uninstall. They do support attribute removal. Some customizations can be locked down. Although, that said, just don’t give system customizer/admin permissions to the people who are not supposed to have those permissions, and you would not need to worry about unwanted customizations in production.
Do unmanaged have benefits? Sure – we can take a copy of production and turn it into dev in a matter of minutes. Which is, often, what we need to do anyway since we won’t have some of the licensed production solutions in dev(due to licensing), but we will need related solution entities to be able to reference them in dev. Are there disadvantages? Of course.. You need to delete an attribute? You’ll have to do it manually, or you’ll need to create some kind of script to automate the process.
Maybe what could get us closer to settling this argument is if the whole concept of solution development were changed. For instance, what if solutions files were written in some kind of scripting language? I think I’d be able to work with those (Something like: add_an_attribute(“test_attribute”); )
Although, this does not seem to be where it’s all going, not at all.. but we should all have hope anyway, and, possibly, stop arguing
You have a few extra environments to use managed solutions? That’s fine. You don’t have those? Well, stick to unmanaged to be able to export from production (or from a copy of production). But, no matter which way you choose to go, you’ll certainly find at least a few problems along the way.
So, take it easy and have fun with the PowerPlatform!