I have a user who wants 2 production tenancies. They want to do Design Validation in Environment A and then at some point make that Production and switch the Production Environment (environment B) to a Staging environment. And then regularly switch back and forth every couple months.
This sounds like a REALLY bad idea to me, not the least of which is the inability of DNS to automatically and immediately references. What other reasons can people here come up with?
Hi Dave,
My first question was why do they want to do this? What is the expected benefit?
For this to work, there would have to be some way of synchronising changes between the two environments. If I deploy some new feature on A then put it into production, I need to also deploy it on B so it is still available when B becomes the production environment. If you can do that, why not use a more typical staging → prod promotion process where changes move forward when they are ready?
A more Cumulocity-specific gotcha that seems like a showstopper to me is that all your operational data is tied to the tenant. So you switch A from staging to production and suddenly all your production data is replaced by whatever was in staging? I don’t see any way around that.
Cheers,
Scott
The first question is the same question I had. I think that the benefit seen would (allegedly) be that they do Design Validation against an identical environment to Production.
That’s a good point about the data… it’s now in two places and devices register in 2 separate environments