Best practice for dev,uat and prod deployment

Please share link or any document on best practice for dev, uat and prod deployment on orchestrator.
How to use pkg of dev in uat and prod ?
What are the limitation to use same pkg on all environment?

The associated question I have, is for the best practice for managing “Parameters” used by processes in each environment?

Assets are not set per environment.

It is possible to name assets with an environment name and get the process to examine environment variable (e.g. Domain, Machine Name) to calculate the asset name. Is this the best way?

A simple example of a “File Path”, which is going to be different in Dev, Test and Prod.

I appreciate “Configuration Files” could be stored on different machines, but that cannot then be controlled by Orchestrator.

Hello @DavidMartin
I’m not sure what other people do, or what best practice is, but i can tell you what i do:
In orchestrator I have an asset pr robot that defines what environment that robot is placed in.
Then i use that asset in the workflows, so the workflows know what environment they are running in, and use that to do stuff that is different pr environment.

Example:
Robot 1+2+3 is in production and have “CurrentEnv”-Asset set to PROD
Robot 4 is in test and have “CurrentEnv”-Asset set to TEST
Robot 5+6 is development machines and have “CurrentEnv”-Asset set to DEV (one which is my machine)

When i then run process “download file” that needs to download to my desktop if running on my machine, or to another folder if running in test or production, i then write:
CurrentEnv = Get asset(“CurrentEnv”)
If (CurrentEnv = “DEV”)
Then DownloadFile(“c:\user\xxx\Desktop”)
Else DownloadFile(“networkfolder\robotOutput”)

If you want to use asset, you can do the same:
Get asset(“CoolProcess_FilePath_”+CurrentEnv)

Now with example
currentEnv.xaml (4.9 KB)

Hi Konrad,
Thanks for your response.
Yes, so you are adding specific environment elements to the Asset names.
I have done that, but I am not sure it is best practice.
Regards, Dave

Well no. When using assets, I’m just using value pr robot:

The example was for your connivance. Sorry if that was unclear :slight_smile:

I think i understand your question now.
You want an asset pr environment, instead of an asset pr robot, so you don’t have to type the same asset value for multiple robots in the same environment.
My answer was for a different question. My bad :slight_smile:

Hi Konrad,
The ideal solution would be a set of assets and queue names, etc, per environment.
There could be many robots in each environment depending on the scale of the solution. So there should be nothing specific to a robot in my opinion.

The Studio publication is a release of code to a process in an environment.

I do appreciate you could create “Multiple” services within a “Tenant”, which would give a way of using the same assets, queues, etc, but with different values in Dev, Test, Prod.

If you take that approach of multiple services, what is the use of “Environments”?

UiPath has invested to deliver “Test” capability, so I am hoping somebody can advise on the Best Practice to implement the use of parameters across Dev, Test and Prod. For tests to be valid, there needs to be clear control and separation of parameters.

Once a process has been tested successfully, the ideal, is a utility to “Release” the code plus a check on Dependency of associated Assets names, Queue names, etc, from the Test environment to Production.

Regards, Dave

1 Like