How do you / your company handle publishing robots to dev and prod environment?

[codemonkee (Tim)]

@GeraltDieSocke

First of all, UiPath has an integrated “Publish” button that does all the heavy lifting with a one click solution (creating release notes, a good version and publishing it to the orchestrator) - so why not use it?

There are many ways to go about building/publishing your packages. Directly from Studio is one of them, but depending on your organizational needs, requirements, and governance a developer is not always going to have access to such functionality. This will of course differ from org to org.

As you’ve mentioned you could Publish from Studio and Studio by default pushed to an Orchestrator Nuget Feed, but there is nothing saying it has to be Orchestrator and can just as easily Publish to nuget.org or some other feed.

There are also other methods of building your package, given that it is just a Nuget Package, you could use common Nuget tools to get the job done, or UiPath also provides a UiPath.CLI package with some sample usage using GitHub Actions from @Andrian_Szewczyk here and source available on Github - GitHub - andrianoid/helloUiPath-sample

@GeraltDieSocke

Now it would be cool to have a distinction in Orchestrator itself to “promote” it to master and only have one orchestrator in the first place. But thats not possible, so there needs to be a way to bring the finished “product” to the productive Orchestrator.

This really depends on your infrastructure as well as your workflow. We for example have 2 Orchestrator Environments and within those clusters we have multiple Folders that provide us a logical separation for “Development”, “QA”, “Preprod/Staging”, “Production” mainly due to Network restrictions isolating certain ‘environments’. But you could just as easily have Multiple Tenants on a single Orchestrator. It can also further be complicated depending on how you have your Feeds setup, are you leveraging the Host Feed, or Tenant Feeds, are you using Modern Folders with dedicated Folder Feeds… etc.

@GeraltDieSocke

A business partner of us handles this with a powershell script and the odata api. He basically copies the whole folder structure from dev to master when triggered (it only copies folders that are new, it sort of checks first).

I use PowerShell a lot when doing stuff by hand or when I was managing UiPath infrastructure in AWS and there are packages out there to help make that easier for you such as the Orchestrator PowerShell, though it is a little dated as the individual within UiPath has been busy to maintain it, the aforementioned UiPath CLI Package, or the Jenkins Build package you currently use and I am sure there are others out there. UiPath also provide things like Orchestrator Manager, not ideal for what we are talking about but it is available. The only real downside to using the API is when it comes to Credentials the API will not provide these so you’d need to fetch them from another source anyways.

@GeraltDieSocke

This has also the advantage of bringing over assets / queues etc. Cause right now thats another tedious task we have to do when we go live with a bot. Creating assets / queues / processes with all the arguments anew.

This to be is where the CI/CD comes into play and in my mind where I would define a build.config of sorts that instructed something like Jenkins to handle all that for you.

@GeraltDieSocke

Also don’t get me wrong, git makes totally sense and I would like to keep it in the future, but only one branch. The advantage of 2 branches and merging code from dev into master in the coding world makes totally sense, since you can then check the Changes that had been made - and then go through it and only then approve the merge. Makes totally sense for example Javascript Web Applications.
But in my oppinion not in UiPath PRojects. Cause all you can see is a lot of XML gibberish that you can’t compare.

I wouldn’t agree with this entirely, sure the makeup of the XAML file (Logical Flow and Presentation in the same file) doesn’t make comparing it easy, but if you focus on the logical nodes in the XAML and not the presentation layer, it is pretty straight forward and no more complicated than any other XML based configuration. Do I want to stare at it? Not really, but that is what Inspections and Code Sniffers are for. With that I think the main talking point at this stage is about Code Review and less about the build pipeline, which is going to come down to how guarded the organization you work for is.

@GeraltDieSocke

Because it adds so much overhead. So much work has to be done before I can even start coding. Very error prone. Publish Button from UiPath - it’s there, why not use it?

I would counter that with if you have a build pipeline already setup pushing the Publish button is no more or less complex than committing your changes in your VCS and having that action trigger the build/publish.

If the overhead of starting a new project is a strain than perhaps how a new project is started should be review to streamline it.

Mainly playing the devil’s advocate here, what you described doesn’t paint a bad or really a good picture for me, every house has their own needs and you need to find a flow that works for you and your team(s) that follows any guidelines that exist, if that means Publishing from Studio directly to Orchestrator and only using Git as your version control, nothing inherently wrong with that so long as it works for you and company.