Please note that this document is part of The automation Success Framework and is referenced by the following parent document. This specific article discusses different approaches to configuring the platform for DevOps to ensure a secure and practical development methodology.
DevOps refers to the tools and practices that guide a software development team and ensure solutions are developed securely and effectively. Automation Anywhere can be configured in various ways to suit different approaches to DevOps. In this article I discuss best practice approaches, which you can adapt to the specific needs of your organisation.
The structure of your CoE will have a significant impact on your DevOps approach, as will the number of control rooms you have licenced.
Two Control Rooms
With two control rooms it is still possible to implement a methodology which implements a clear separation between Development, Testing and Production automations. The diagram below outlines the suggested approach. In this scenario the Development and Testing activities are combined into a single control room. Various aspects of this DevOps approach are discussed below.
- A Bot Creator licence allows a user to build bots in their Private folders. As the bot creator builds the logic, they test it by running it on their own computer.
- The bot creator will need rights to clone any re-usable components they wish to use when developing the new automation. Re-use of logic should be encouraged.
- When the bot creator checks the automation into the Public folder they are passing it to the Testing phase.
- Testing phase should involve running the automation on bot runner machines that are a copy of what will be used in production. Testing should then identify hardware, software or configuration requirements to meet for a production deployment. Testers should be familiar with the process, systems and use case involved. The developer or another CoE role may need to assist testers by setting up schedules, groups or any other configuration required to facilitate testing.
- The bot creator will need rights to check out the automation logic if any rework is required. Once changes are made they simply check the bot into Public again.
- Non-production versions of business applications should be used for development and testing. Depending on your organisation you may grant the bot creator rights to create and enter credentials for these systems. For tighter controls you may restrict this access to a senior member of the CoE.
- As of version .29 you can copy an automation across control rooms using the Promote Bots wizard in the Public folder. This process can automatically copy all dependent files as well. This is the recommended approach for migrating to Production. (You must configure a URL for the control room (CR) in settings to facilitate this).
- Note that promoting bots will not copy any required credentials or folder security roles to the production CR. These should be setup manually and any required separation of duties to protect credentials for production systems can be applied via configuration of access to credential lockers.
- It is recommended that a separate role (eg. CoE Leader) be assigned the rights to promote bots and schedule them on the production control room. This ensures that a clear ‘stage gate’ exists before any automation is promoted to production. At this point any additional reviews of logic and documentation can occur to ensure the automation meets the required standards. Other steps, such as updating a Register of Bots and placing documentation into a repository should be performed at this stage.
- If a Git repository is configured it is usually linked to the production CR. This is because Git is more of a backup approach, (the CR keeps full version control), and usually only production automations need to be backed up. A second Git repo could be used for the development server if you wished to backup work in progress also.
- A Sandbox CR is typically used to test mission critical automations before upgrades are rolled out to cloud control rooms. (Sandbox CRs will be upgraded several weeks before any ‘standard’ control rooms). Once a new automation is rolled out to production, the CoE team can choose whether to copy that automation to the Sandbox CR. The bot promotion wizard can be used for this use case as well. The same role (eg. CoE Leader) can be perform this task.
Three Control Rooms
With three control rooms a more detailed methodology can be implemented with clearer separation between the Development, Testing and Production phases. The diagram below outlines the suggested approach. The aspects of this DevOps approach that differ to the first approach are discussed below.
- Bot creators work on the development server and test automations on their own PC as they develop them. It may also be valuable to have developers also do “unit testing” against bot runner computers before they pass an automation to the Testing phase. For this scenario the bot creators could be given rights to check in bots to Public and to promote to the Testing control room (CR).
- Because testing is now performed on a different CR, any new credentials will need to be setup before testing. If the same set of non-production business systems are used then the same users can be involved in setting up credentials on both Development and Testing. However if the test business systems are different and have more secure data, then different users and roles may be needed.
- The developer or another CoE role may need access to the Testing CR to assist by setting up schedules, groups or any other configuration required to facilitate testing.
- If rework is required the testers can notify the developer. The developer can then check out the bots on the Development server, check them back into Public after editing, and the promote the relevant bots to the Testing CR again.
- The steps and user roles involved in promoting bots from the testing phase to production CR, and from production to sandbox CR are much the same as outlined above.
Single Control Room
If a single control room is available, the the only clear DevOps ‘stage gate’ involved is when an automation is checked into the Public folder. This makes governance and control difficult from a DevOps perspective.
- To enable switching between Non-Production and Production business systems in the same control room (CR) an addition “work around” will be needed. One approach is to use two different sets of connection logic in the bot and reference a global variable via IF THEN logic. The global variable can then be used to switch the bot between Dev/Test and Production mode.
- As soon as a bot is checked into public it is immediately visible to any user who has access to that folder for running automations. This means the bot creator is effectively putting the automation into production even before proper testing has begun. (Note however that only users with an Attended Bot Runner licence will be able to see the bots).
- Ensure that only a suitable role (eg. CoE Leader) has access to schedule any unattended automations. This effectively separates the duties of the bot creator from those of the CoE Leader who should put the automation into production. Testing can then manually be performed using specific bot runner computers that testers have access to. Only when it is scheduled is the automation then effectively put into production.