Best Practice/Setup Dev,Test,Prod Orchestrator Small Scale

Hello,

I am looking for some tips/best practice when it comes to separating dev test prod. What i can find in other forums thread is that there is 3 ways to go.

  1. Different Orchestrator instances.
  2. Different Tenants.
  3. Different Folders in a tenant.

Where i work we are very small scale so far and is not expanding any time soon. My first thought was to separate this via folders in the same tenants. In that case, is it best to have different package feeds for every folder or should you use the tenant feed for all folders?

Any help would be nice.

Hi @Ninjabullen

@@@UPDATE
I wrote that in hurry yesterday before finishing my workday, and just reformulated the whole statement. It should make more sense now and be easier to read.
@@@

I would say that it depends on the number of robot licenses you think you will have in the future.
New licensing strategy (User License Management) allows users to share licenses across the tenants of same Orchestrator. Which means that one named account can use the same licence across all tenants(One user can use it on up to 3 tenants/machines at the same time).
However robot licenses are assigned per tenant which means that if you have 1 robot license, you can use UR(Unattended Robot) on 1 tenant only.
You possibly could reassign the license between tenants(you can do this in Orchestrator settings or with API), however this will disable your production robot and would need some monitoring system to tell you where the license is(It would be a bumer to leave UR on DEV/TEST over a night).

If you know that you will expand in the future and your licensing allow your org to get at least two tenants, 1 testing robot and some prod robots I’d go with option number 2.
This way your PROD env would get safer/more fool-proof and you won’t have to pass the UR licenses over.
You could make 1 tenant for DEV/TEST and 1 tenant for PROD this way.

In any other case I’d go with different folders in 1 tenant. You can make up to 6 subfolders for each root folder as well as you can assign different groups to different folders/subfolders.This will allow for more granular management of each folder (Please have in mind that permissions propagate down the folder tree, so groups in the root folder, will have same access rights to its subfolders.)
If you want to go with 3rd option I would advise to have separate package feeds for each folder.

If you must believe that you need a shared tenant feed (you feel like moving packages between folders is a hussle) I’d suggest creating DEV/TEST with tenant feed and PROD with folder feed.
This would minimize the problem with package versioning.

In case that your company do not know if they will scale up in the future, you can always start with option 3 and in case of scaling switch to option 2. In this scenario, you will have to recreate the whole infra on new tenants (I am not aware of option for cloning the tenants, but it may come up in the future) and then move the packages over there.

Just one important thing to remember is that you always want your only tested and production ready packages in PROD.

2 Likes

Thank you for the input. :+1:

@Ninjabullen

No problem, if you still have some questions or want to ask about specifis please do.

Hi @Ninjabullen

My 2 cents on this topic is this.

You have to assess what is the level of security that your company requires. Is there PCI or PII data? My guess is that this is not an issue for you. So, folders are a viable option for you. But I’d rather set up one Orchestrator instance with multiple Tenants. That gives you a logic segregation of your environments.

You don’t need multiple Orchestrator Instances since you are running a small solution. One Orchestrator instance can handle up to 50k bots. So, unless you have a massive need for bots, or a more reliable environment, don’t go for it.

1 Like

Important input. Thank you. :slight_smile:

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.