Are you using multiple DEV and PROD instances? If yes, what is your use case?

[Suggy]

Are you using multiple DEV and PROD instances? If yes, what is your use case?

PS - This question is for information purpose only. If you have come across such a situation, do share the details so that any other user looking for details on this topic would get some idea/details.

Thanks in advance!

[Suggy]

@Dr Atul G- LNG Good to know that. May I know how were you handling the dependencies. Were you using Team development or how

[Dr Atul G- LNG]

Hi @Suggy 

We were not using Team Development—for us, it was more like moving update sets manually. However, the recommendation is to use either GitHub integration or Team Development for better collaboration and version control.

[GlideFather]

Hi @Suggy,

In the most of the situations, clients have at least 3 environments - DEV, TEST/QA, PROD.

Depending on the requirements you will get access to it, sometimes you can have full admin in DEV, then limited access to TEST and read-only in PROD, or full admin everywhere. 

There is no general answer. What use case are you asking about exactly?

[Suggy]

Hi @GlideFather  I dont have any cases, just that I came across others using it. I wanted to understand their use case because I feel its complicated to manage multiple DEV, PROD etc, to manage the dependencies, overhead maintenance, cost etc and the whole idea of Unification is lost if there are multiple PROD.

so just wanted to hear out the use case if anyone is using multiple DEV or multiple PROD

[GlideFather]

Hi @Suggy,

I have been working for a project who had multiple PROD environments, because one was the standard cloud one and the other one was onsite (it was a national government that did not allow to store data in cloud, but it had its server instead).
Both of the PROD 1 and PROD 2 had their corresponding DEV 1 and TEST 1 eventually DEV 2 and TEST 2, it was always DEV-TEST-PROD at minimum. And it has been already quite chaotic.

I agree with what you say it is complicated to manage all this! If needed you can have DEV A - DEV B - TEST A - TEST B - QA A - QA B - PROD. But I think that would be really difficult to manage the upgrades and all the necessary cloning, because you want to have the environments as similar as possible, optimally 1:1 (or 1:1:1 if you will).

The need for multiple PROD environments can be avoided by domain separation - imagine that each company have their own domain, what makes it look like the whole ServiceNow platform is just for them and they see only their domain and not any other... while all the platform maintenance (bugs, upgrades, enhancements) is done only once and it is applicable for all the domains included...

If you are interested:
https://developer.servicenow.com/dev.do#!/learn/learning-plans/xanadu/servicenow_application_develop...

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0715934