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

Hi guys,

so all i want to know is how your company our you decided to create like a “build pipeline” for your robots. The more detailed the better.

I work at a company that does it like this (and i hate it):

  • create git repo with 2 branches, set dev branch as main, protect master branch
  • push the repo to git via UIPath on dev branch
  • Set up Jenkins Build Pipeline ==> Project now gets built with the Jenkins UIPath plugin
  • Now you can select it in orchestrator

To get this robot into production:

  • Merge the repo from dev into master in Git
  • Jenkins Build Pipeline
  • Now i can select the package on Prod

This involves so many steps for each project. Also we can’t use the built in “publish” function from UIpath Studio. Our Team is pretty new and I joined when this has already been configured the way it is right now. So I want to find out better solution how to handle this dev / prod workflow. I have a very strong feeling that this might not be the best solution of the world :slight_smile:

I’m very eager to hear your experiences on this topic. Thx

1 Like

Hey @GeraltDieSocke

It’s surprising, that why you think this is not the best solution ?

:slightly_smiling_face:

Thanks
#nK

I would agree with this question and interested in hearing your aversion to your current flow?

… we currently manage our projects within Git Repos with multiple branches, however Publishing and configuring Orchestrator is currently done manually which is simple but tedious in itself.

Our eventual plan is to move into a CI/CD Pipeline and extend the process so that builds are triggered on commit followed by some Unit Testing, and if good would upload the package to a Nuget Feed such as Artifactory so that Non-Final builds are accessible for non-prod Orchestrators and Final builds are available for Production, promoting through the environments would be gated by Merges and Approvals to fit in our Change Management requirements.

To streamline additional configuration such as Assets, Buckets, Queues, etc. we’ll probably define a build configuration that defines these attributes so that we can easily upgrade and rollback a given process.

1 Like

@Nithinkrishna @codemonkee

Thanks very much for your input.
So why do I think it’s not a good idea:

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? - that is for development. 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.

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).

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.

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.

In summary or a TL;DR:

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?

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

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.

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.

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.

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.

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.

3 Likes

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