Separate test and production instances of orchestrator....moving between?

Help
1

So we are beginning to look into creating a production instance of Orchestrator which would live on a separate server from our test instance. My question is what is the best practice as far as promoting packages from test to production? The only way I can really see it working is if you disconnect the robot you are using to publish to test and reconnecting it to the production instance of Orchestrator but that seems painstaking and less than ideal. How have folks dealt with this type of scenario?

2

Here is how I’m currently doing it (or in theory) to ensure stable production process for my RPA dev team, which isn’t the most ideal either.

  1. Develop components and a working project on a disconnected laptop; break on purpose to ensure Error handling and logging is correct.
  2. Migrate project to the test server from a dedicated user connected test orchestrator. Fine tune issues caused by new Enivronment.
  3. Once project is working from Studio on test server from the dedicated robot, test using the console where it kicks you off and runs in backscreen (or Orchestrator if you don’t mind a plethora of errors showing up). Fine tune issues found through that run (might consider Launch Workflow Interactive if problems are found). After console test, test run in Orchestrator just to make sure. --Publish from the server that is connected–
  4. Once multiple tests and scenarios are successful through the backscreen, log in to each user id being used as a robot on test server one at a time, and test run process through Studio to get rid of any Environment differences (first time popups et cetera).
  5. Test process one at a time on each Robot in test Orchestrator.
  6. Note which user ids or servers where there is a fatal Environment issue like memory-related problems where process just won’t work.
  7. Repeat all steps on production server after long testing is successful and that all things that were not considered previously have been fixed. --Publish project from the server–

To be honest, there is no way of getting around needing to test from Studio on the production server at this time, unless you want many “scratch your head” moments when your process doesn’t work correctly :stuck_out_tongue: So, may as well just publish it from Studio when you need to ensure it works on the server before migrating fully.

Those are my thoughts, but also interested if there are better ideas out there. I just don’t think Windows Server and browser/app automation is very stable without complete testing.

5 Likes
3

@cvent978

For me the ideal setup is to purchase at least one non-production Robot in addition to your production Robot. This makes sure that your production Robot is not interrupted. When you’re ready to deploy your code, just flick update on the production Robot and that’s it!

Otherwise, if you only have one robot, I agree on what @ClaytonM has explained. :slight_smile:

4

Yeah, I agree with that, but our production servers and Orchestrator are separated from anything related to testing, and we are relying on our test servers to fall back on in an event where our production infrastructure dies. I don’t necessarily agree with our setup though, because it requires twice the effort on server/user migration and troubleshooting. It seems that a setup where your test Robots intersect with the Production Robots would be ideal so you can migrate to the production environment much quicker. However, the drawbacks to this is if a test robot fails in a way that crashes the UiRobotSvc or does something funny like shutdowns the machine, then everything goes down, not to mention the memory for performance that would be needed.