Should developers be developing where Orchestrator installed?

Help Studio
1

Hi,
We are using an on-prem Enterprise version of UiPath.
We have Orchestrator installed on DEV, UAT and PROD windows servers + some unattended bots.
We then have a few developers with Studio installed on their personal laptops.

We are just starting on the RPA journey but noticing that our developers are tending to develop on the same host where Orchestrator is installed.
The reason according to them is they say that the might have a working version of their Job on their Laptops but when they publish to Orchestrator, some selectors might not be the same so they need to then login to the windows server to Debug.

Our Windows server only allows 2 concurrent login’s and the developers are looking for this to be extended to allow more of them in at any one time.

Just wondering how normal this is?

Any help appreciated…

Thanks,
John. (newbie!)

2

Hello @John_O_Mullane, welcome to the UiPath community!

Let me try to give my 2 cents regarding your question.

Q: Should developers be developing where Orchestrator installed?
A: My answer would be: No.

  • Devs have the freedom to develop wherever they choose. Providing of course they have a licensed studio installed in the machine of their choosing.

Now, regarding their reasoning about selector issues:

  • This is a valid concern, since selectors can vary from machine to machine.
    • For example, some of your developers may have a specific language pack installed in their machine, which isn’t installed in the machine where the job is supposed to execute.
    • And, depending on the job & automation environment, resolution can also can also be a factor when it comes to selectors.
  • There are many factors & various scenarios which may validate your devs’ concern, but they don’t necessarily relate to the Orchestrator.

I guess, a better question would be:
Q: Should developers be developing where the automation job is supposed to run?

Now personally, I don’t think this can be answered with a simple Yes or No. Since as I mentioned earlier, devs have the freedom to develop wherever they choose.

Although, admittedly, I would say that it would be better to develop your automation jobs in one of the machines (i.e workstation) where the job is supposed to run, as this would allow the developers to have a sort of standard to follow which will be applicable all the job-designated machines.

Hope I was able to give you a better insight regarding your issue.
If you need further clarifications, then feel free to ask and we’ll try to help you out.

Have a great day, stay safe & healthy!

3 Likes
3

thanks @BenMar
All makes sense.

Anyone else out there have this concern?

4

Hi @John_O_Mullane I’m also facing issues with my selectors when I change the computer where I execute my process. I’ve developped the process in a computer with Windows 7, Excel 2013 and English language, when I tried to execute it in my laptop where I have Windows 10, Excel 2010 and Spanish language I have a lot of steps not working. For the moment, the only solution that I’ve found is to repair selectors or even add “if” steps that checks the environment where the automation is working (for example, “Get environment variable” to get if it’s Windows 7 or 10 and then execute the steps according to that OS, that I’ve developped for Windows 7 since my main computer and for windows 10 since my laptop).

But I’m not sure if this is the best way to face it. Do you know any other way?

5

Hi,
I would suggest you to develop on same Machine as robot has to run. Selectors must be identical from when creating ro running the robot :slight_smile:

I never use local to develop - only samm hotfixes.
I always develop on rdp.

6

But, what if we want an automation to be available for a whole team (for example a team of 5 Human Resources employees) each one with different computers? We can’t create an automation compatible with all their computers? What if the user changes the computer or upgrades something (windows, office version…)? :confounded: :flushed: :woozy_face: :cold_sweat: