I want to confirm the best practice when setting up multiple environments (Dev/Test/Prod) in Orchestrator in an enterprise setting.
In this post, a user links to the official docs recommending the following multi-tenant approach:
By using more than one tenant, users can split a single instance of Orchestrator into multiple deployment environments, each with its own Robots, processes, logs, and so on.
I’m tempted to consider this the final answer and just run with it. However, in that same post the same user then says:
It’s even possible but not best practice to have all three on one Orch by using three different tenants.
I don’t mean to call him out but he seems to be contradicting his own link. Or maybe I’m misunderstanding something.
Similarly, this tutorial appears to corroborate the multi-tenant approach. However, that user mentions the terms “working” environment (aka Personal Workspace?) vs. “deployment” environment, and I’m not sure if they refer to the same thing. In addition, the comparison between classic vs. modern folders may be muddying up the waters for me.
Finally, in other posts some users recommend having a separate Orchestrator server for each environment. But that appears to be unnecessarily expensive / overkill.
So to confirm, is it the enterprise-level best practice to have one single Orchestrator server / instance containing multiple tenants, one for each environment?
The enterprise level best practice is to have a separate orchestrator instance for Dev/Test/Prod.
But with the modern folders , you will be able to achieve similar separation with the help of folder structure but having a separate instance for Dev/Test and Prod allows us to be more flexible .
we have an on premise orchestrator installation . with this , we are able to test the orchestrator upgrades and additional implementations like splunk in test before expanding this to the prod server.
Once the upgrade is complete in test , we can test out the Business crucial processes in the test and see how the impact of the upgrades will be , before proceeding with the upgrades in prod . This means no surprises
Ok so what I’m understanding then is that ideally the company would pay for multiple orchestrator instances. However, if that is not possible / desired, then the next best thing would be to have multiple tenants in one orchestrator instance.
I should have mentioned that I’m talking about Orchestrator Cloud (and not on-prem) because that appears to make a big difference.
With the Cloud version, it seems like the multi-tenant approach is good enough, as explained by @Anil_G. On the other hand, with the on-prem version, multiple Orchestrator instances is probably best, as explained by @vishnuvarthanp.
Since my case is the former, I suppose Anil’s solution is the most relevant, although I appreciate Vishnu’s as well.