we are currently on prem and in the past we always published a process to one orchestrator. Then we went into the orchestrator - downloaded the package - went into other (prod) orchestrator (2 different orchestrators) and uploaded it there.
We now move into the cloud which means we only have one orchestrator anymore (thank god). We created now 2 tenants company_dev and company_prod ==> What is now the best practice to also comfortable publish to dev orchestrator, test and then publish it to prod orchestrator?
We are not allowed to use Github and therefore we can’t use the brand new “Source Countrol (Preview)” from Automation Ops.
What is a good and comfortable way to keep source control (we have a onPrem Gitlabs environment) and also publish the package comfortable to both tenants?
thx for the input. That shows how to clone or connect a studio project with Gitlabs. We already have that in place for source control.
But my question leans more towards how to publish the package then to orchestrator for both tenants. Maybe even with assets and queues and everything that belongs to it. Right now i have to do everything twice and also copy paste the published package on dev to prod (which feels not good).
I understand that you have 2 tenants dev and prod and you want to be able to push packages to both these tenants directly from studio. What you dont want to do is to publish the package first to dev, then download it from there and go to prod orchestrator and manually upload the package the package there. Right?
So if I have understood your requirement correctly, here is what I think needs to happen:
When developers publish on lower environments(dev or UAT), it is to test whether the bots they have developed works rightly the way it should be when productionized. Also when you test the code in UAT, then a general process would be to get a sign off from process owners on the code that you developed is working as expected and is good to go to prod environment. Usually this process would also include the package details(like name and version that is being signed off on UAT/dev) so that the exact same version can reach to pro environment and there are no discrepancies in what was signed off and what was productionized.
Now what you are trying to achieve(by being able to publish directly to prod without having to download first from lower environment) can be achieved by:
having the studio installed on production machine which is connected to prod orchestrator. Usually dev/uat machine on which you are developing the code will not be mapped to prod orchestrator and it generally wont have UiPath studio there.
Even if you get the access and are able to do it somehow, there are higher chances that you may end with having discrepancies in the code or I would say this would act as a broken link in the process of how processes from lower environments should make it to production.
Hence, in my view this would not be right approach.
What you are doing right now by downloading from dev/uat environment and then uploading to prod is the right approach.