Let’s face it, RPA was not a consideration when DevOps was being formulated. There’s nothing inherently limiting RPA from participating in an DevOps strategy, but I’ve been talking about DevOps since 2010 and participated in many conferences on DevOps as well as conversed with many of the other thought leaders in the DevOps world. And never has the term RPA come up.
Interestingly, in the past year, more and more influencers from IT who have been following the trends of CI/CD and DevOps with regard to other major projects are starting to ask for Enterprise RPA products to support the same CI/CD actions that accompany development and release for other Enterprise application software development lifecycles.
We’re now seeing requests for support for Git repositories with auto-versioning and rollback, automated build and test, unit testing, etc. This is a major change in attitude toward RPA in the business. It signals they are starting to see RPA as not a shadow IT activity, but a corporate asset that needs to be managed and maintained with the same rigor and process as any other digital asset.
This change also comes with its own headaches too. CI/CD works well in environments with trained software engineers who understand software development lifecycles, it’s a much steeper learning curve for citizen developers who’s primary experiences with automation has been building macros in Excel.
I can’t tell you the amount of times I’ve been asked if there’s anyway to retrieve an earlier version of an Excel document after the author inadvertently overwrote a prior version with something that doesn’t work. In my earlier days working on Wall St. we developed a specialized system for traders to store their workbooks at the end of the day so that they were automatically versioned to save them from the inevitability where they would no doubt screw up their models and need to revert.
The other aspect of a strong automated release cycle is adherence to unit and integration testing. This is an area that I find notoriously weak in many professional software development organizations. So, how can we expect the same rigor to be incorporated into a much more decentralized program with includes individual with little to no professional software training? This clearly highlights the need for a Center of Excellence (CoE) supporting automation, but more so, it highlights the need to help those creating the bots to think about how to manage exceptions and to test for expected results, not relying on the expected case to always be true.
Bringing RPA into the CI/CD fold is definitely an interesting challenge. I am really enjoying my conversations with my product team about the requirements to support these goals. But, I’m also aware that the requests for these features are being driven by the CoEs and the IT organizations that often support the automation efforts within the business more often than they are being requested by the business users that often are driving the use of RPA in the business.
One thought on “CI/CD and RPA”
At this time RPA and CI/CD do not play well together. If CI/CD is constantly changing the underlying metadata of a window screens/webpages; typically the automation will break. The RPA bot is trained in a very specific way to understand window screens/webpages layout. When CI/CD is introduced, the RPA Bot Creator is having to be reactionary to implement break/fix. Any thoughts on what would be a theoretical best practice implementation to know proactively if screen/webpage layout are planned to be changed and the RPA CoE team can be alerted proactively that a automation update may be needed.