DEV, TEST ja PROD are vastly different

[ilied84]

Hello!

I have a situation where I was tasked to oversee a Power Platform application of a customer. The application was not done by me and I do not have a way to reach the individuals who made the application. The problem is, only one environment works as it should. The other two only half work and all the solution packages are wildly different in all of the environments. This makes it extremely difficult to develop any new features or troubleshoot bugs.

The environments are as follows:

DEV

Unmanaged solutions. This somewhat works. It has the latest versions of solution packages, but it hasn't been tested properly. It also contains some solutions that are not found on the other environments. No idea, if they are even needed. Propably not.

TEST

Unmanaged solutions. This works the worst. Lots of weird bugs in the application itself and the version numbers do not match those that are in the production environment. Not all of them anyways. The solutions are named horribly, so I have no idea what any of the packages contain, unless I go and browse through them. It's a nightmare.

PROD

Managed solutions. This works the best. Customers are using this and there are no major issues. Solution naming is also horrible here, but at least I know that everything is working as it should for the most part.

Since developing new features / troubleshooting is difficult, I was tasked to make the environments the same, to have a fresh start. This seems like a good idea. The problem is, how do I do this?

Here are the options I could come up with:

1. The obvious choice would be to export the solutions from the PROD environment, make them unmanaged and replace all the solutions in DEV and TEST with those. But since the solutions in PROD are managed, I can't export them. So thats a no go, unless someone finds a way to export them.

2. Create new unmanaged solutions in PROD and use Solution Components Mover to copy the solution components from the managed Solutions to unmanaged Solutions. Then backup the old solutions from DEV and TEST and replace them with the new ones. After testing, replace the Managed solutions in Prod with the new ones as well. This is very time consuming and a recipe for disaster in my mind, but still doable. I think.

What do you think? Is there a better option available?

[joe_hannes_col]

Hello @ilied84,

It sounds like your DEV and PROD environments are okay, but the TEST environment was not used for testing only but also for development.

As you probably know, the kinds of solutions in the environments should be:

- Dev --> Unmanaged

- Test --> Managed

- Prod --> Managed

The question probably is where the solution versions in the PROD environment come from:

- From the DEV environment,

- From the TEST environment, which contains customizations of unmanaged solutions from the DEV environment

- Unmanaged solutions imported from the DEV or TEST environment, but customized in unmanaged layers in the PROD environment

Based on your description, it's probably a mix of all three situations.

I would suggest the following approach:

- Create a copy of all environments in case something goes wrong 🙂

- For each solution, try to identify the origin (DEV or TEST, ideally)

- Create new DEV and TEST environments, and import the "original" unmanaged solution of each solution into the DEV environment

- Set up properly automated ALM, e.g. using the ALM Accelerator, and import each solution from DEV into TEST

Probably an imperfect approach, but the best IMO.

I think using the Solution Components Mover approach will pose some practical challenges, e.g. updating the currently installed versions of the managed solutions with newly created solutions.

Do you know if any systematic ALM approach was used before? Maybe there is some sort of repo where the unmanaged solutions are stored. Doesn't sound likely, but that would be ideal 🙂

[DeviKrishna]

Hi @ilied84 ,

Please find my suggestions below.

Prod - Leave the environment as is , since it is working fine.

Test - Do a full copy of P system. Please make sure to group the users with Security group and apply the right security group in test so that P users are accessing on the Prod environment.

Dev - Please look at the open requirements. If there are in progress work items and the changes in dev are matching the requirement evaluate the changes. Else , always create a unmanaged solution from Test environment restored in the above step, work fresh on the requirements and push it to test/ Prod on need basis.

This way you will not waste the time as well. Once all these are sorted out as suggested by @joe_hannes_col  please set up ALM pipelines and govern the solution movements.

-------------------------------------------------------------------------
If I have answered your question, please mark your post as Solved.
If you like my response, please give it a Thumbs Up.

My Blog: Dynamics 365 Key Topics – https://d365topicsbydk.com/

My YouTube Channel : https://www.youtube.com/channel/UCxSIryP2ah2VpEFr-Z72t1A

Regards
Devi

[ilied84]

Thank you for the suggestions! I forgot to mention one thing that complicates this a bit more. Every environmet also has a Power Apps portal in use. I'm not too familiar with portals, but I think this creates a problem with copying the production environment. Unless I can somehow backup the portal separately beforehand and restore it to the test environment, after replacing it with a copy on the production environment.

[joe_hannes_col]

It probably depends on how old your portal is. Recently, Microsoft has improved how portals can be managed and deployed through solutions.

Do you have an unmanaged version of your portal in either Dev or Test?

[ilied84]

All three portals are production versions. They were created on june, 2020. I can't see them inside any solutions. They are in the applications section in make.powerapps.com and I can see them in the Power Platform Admin center.

[ilied84]

The portals created problems, so I went with a different route. I used Solution Comparer (XRMtoolbox) and I checked the solution version differences in Production and Test. There were 8 differences. I created temporary unmanaged packages in production and used Solution Components Mover to copy the contents of the mismatched solutions to the new unmanaged solutions. After that, I created new solutions to Test with the same names and version numbers as was in Prod and moved the new unmanaged solutions to Test and used Solution Components Mover again to put the contents in the right places. In theory, Prod and Test are now identical. I will repeat the same steps on Dev, as soon as the customer has tested that everything works as it should.

I made a manual backup of each environment before I did anything, of course. Hopefully this is fixed now. Thanks for the help!

[joe_hannes_col]

Sounds like a good approach, and thanks a lot for sharing! I'm sure this will be helpful for others in a similar situation.

How did you handle portals, specifically?

It's probably already in your backlog, but I would move away from unmanaged solutions in Test once you have synchronized your Prod and Dev environments.

Have you tested updating a managed solution in Prod with your newly created unmanaged solution from Test?

[ilied84]

I did not touch the portals. I'll just leave them be, as they are working. I have not tested updating a managed solution yet, but since the contents of the solution are the same, I don't think it will be an issue. Either A) the updating works as it should, or B) it gives an error (solution has the same name, but different id, etc), at which point I can just remove the solution from PROD and replace it with the solution from Test. That will be a one time problem, so i'm not too worried.

[parvezghumra]

@ilied84 Is the behaviour of the portals application consistent across the 3 environments? You could potentially use the paportal group of commands from the PAC CLI to interrogate the portal configuration data in the 3 environments to verify if they're consistent.