I have an orchestrator enterprise license for our Production environment. Now I can separate my Dev, Test environment within the same Orchestrator instance. I have three approaches to achieve this. Please suggest me a right and recommended approach @Lahiru.Fernando@Palaniyappan.
Approach 1: I will create different tenants for the Development and Test environment. So I can separate my robots, queue, and assets value with the different tenants.
Approach 2: I can simply do this within the same orchestrator instance by creating separate environments. So what I can do, first create separate environments for development, test, and prod. I can connect my development machines with the development environment robots so that I can only work on the development environment.
Approach 3 : Can I deploy separate Orchestrator instance for Development, Test, and Production environment.
Hi
Either first or last approach would be fine buddy
Why not with second one is though you have created different environment for different instance it would tough to manage each instance at a time
It is always easy to manage the data of different instances been isolated.
Sorry for my late reply on this. I was stuck with a bunch of meetings today.
So for this, I would agree with my friend @Palaniyappan on the first or the third option.
Approach 1: This is good. Having different tenants can manage the development, test and production instances separately so that things don’t get confused etc.
However, the ideal approach I would suggest is to have a separate orchestrator instance for the three environments prod, test and Dev.
Why I say that is, having tenants created in the same instance will actually refer to the same SQL Database of the Orchestrator. Usually, development environment is where we try out all kind of stuff, and it is quite messy with unwanted and wanted things. So having such stuff in the same database, that I would not recommend even though they are in different tenants.
1st option is good, considering the budget and other external factors… However, ideal approach to have would be the third one. In this, every orchestrator instance is installed separately and does not depend on one another. Here, we can try out all crazy things in dev and leave the production and test untouched unless when are doing a actual deployment…
My company has done Approach 3, and there’s good reason behind it.
Approach 1, would allow you to do what you’re stating, but, if you are going to update your Orchestrator version, you have to do that in production without first checking to see whether that adversely affects any of your processes, which may or may not be okay depending on your situation.
Approach 2, This is probably the worst of the three, especially considering you want separate assets to all have the same name since the ReFramework has the developer state specifically what they will be in all cases.
Approach 3, This allows for the testing of different environments in a self contained way. Any updates to the Orchestrator environment can happen in a safe way in development, QA, and then finally pushed into production without adversely affecting production jobs. This is especially important if you have batch jobs that end users are depending on happening and even a day or two delay would be untenable.
Then you have one more approach, that is simpler and can suit your needs well, would be using folders to separate resources for different environments:
Of course yes buddy
Like when we create a tenant it is unlicensed until you add a license file. The same applies with the default tenant. If you don’t add a license file on it, it will remain unlicensed. Each license file that you add to your tenants has a number of Robots that you bought, So for that we need to pay for the numbers we buy
But is of less cost when compared to the third approach though is the one everyone prefers because of its data integrity.
If we are ready to afford the third approach of buying different orchestrator license for each instance then it’s the best
approach 4: single Tenant (Default). separate domain by using Modern Folder such as Testing. then we assigned a non-production Robot to this folder. for Developers, they can use their personal workspace folder and we use Orchestrator manager to migrate resources to other folders or u can use links manage links.
Anil_G
Yoichi
prateek.mehandiratta9
argin.lerit
ppr
arjunshenoy
Learner007
Bhushan_Nagaonkar
lakshmi.mp
michael.zura