Automation Transformation
Vishal Patel
Engineering leader | DevOps | DevSecOps | Platform Engineering | Product Management | Product Delivery | Automation
With the advent of DevOps, DevSecOps, automation has gained a significant focus in the software life cycle and these days, companies are giving it a special attention. Seperate budget is allocated for automation development/testing. Almost every part of development life cycle is automated, viz., Code builds, code scans, Unit tests, binary source management, smoke testing, integration testing, functional testing, acceptance testing, performance testing, user acceptance testing, business acceptance testing, boundary value tests, build verification tests, infrastructure verification tests, environment verification tests, UI testing, browser testing, SAST (Static app security testing), IAST (interactive app security testing), DAST (dynamic app security testing), threat modelling & analysis, vulnerability scans etc. A lot of infrastructure activities, viz., access management, log management, monitoring, alerting, disk space management, environment creation etc.
Since the focus is high towards automation and it has now become one of the most significant project success parameters, it requires a holistic approach in which automation is developed & maintained. Following are the different design parameters around which automation solution should be developed.
- Automation planning: Automation is not just a bunch of scripts together. Automation solution goes thru a full circle of life cycle effort. Automation solution required thorough planning for Budget, effort, schedule, infrastructure etc.
- Adopt Agility: Go agile for automation development.
- Version Control: Automation is a set of code scripts and unlike any other pieces of app-code, automation code should be under version control and should under the project's (or organization's) change control process.
- Object based automation coding: Follow object based coding for automation solution. An object here is a task for which automation is developed. Each object has a property and it has a permissible set of configurations. Commenting each line of automation is a must, since this helps not just to understand the automation code better so as to modify it as and when required, but also to monitor it & log it. This serves as a building block towards smart automation.
- No Hard-coding: Automation developed should be as generic as possible. By parameterize every object. Instead of hard-coding values, let users provide the value for these parameters during the runtime or let the output of one automation be an input to another automation. This increases re-usability of your scripts and also helps you get closer to achieve self-service.
- Access Restricted: This point focuses on Segregation of Duties for automation solution. As mentioned earlier, automation solution should be under version control. Only authorized members of the team should have access to these scripts and they should be able to develop/modify/update the automation solution. Remember, automation is developed using individual NT accounts, but run thru service accounts. Further more different service accounts should be used for different test environments & for production environment.
- Scheduled: Avoid executing automation manually or thru human intervention. Execution of automation solution should be event driven. Add scheduling capabilities so that execution of the automation can be pre-planned for a particular date/time. As an example, a particular deployment request is created and approvals are sought from the stakeholders and the deployment is scheduled to run over the weekend, with a condition that by then, the deployment request should get fully approved. Make your automation smarter by raising alerts 24 hrs, 12 hrs, 8 hrs beyond the scheduled deployment time about pending approvals. This can help the stakeholders manually coordinate too get the necessary approvals.
- Say 'no' to ad-hoc automation: Every automation script developed should be a part of a properly designed automation solution and should be tested thoroughly. Developing scripts in an adhoc manner to solve smaller problems may not fit into the big-picture of automation solution for your project.
- Automation Development: Automation solution needs to be designed and should carry a development schedule. There are timelines as per the schedule within which automation solution should be developed and these timelines are matched to the project development timelines. Unlike application code, automation code should be unit tested & peer reviewed, with all the resulted being documented.
- Automation Testing: Automation code should go thru multiple iterations of testing. This needs to be planned beforehand and adequate amount of time needs to be allocated for this activity. Capture test results and document them. Identify defects and plan to fix them.
- Logging: Most of the times the best pointers for defects & its fixes are logs (aka, log files). Generate execution logs for automation solution, capture these logs and define a policy for automation log retention.
- Monitoring & alerting: Probably the most important aspect of automation solution is about implementing monitoring and alerts for your automation solution. The team responsible for automation should have complete visibility on whether the automation scripts are getting executed as per plan and appropriate alerts should be raised in case of issues. You might develop automation scripts for the application monitoring & alerting, along with that separate scripts should be developed for the monitoring & alerting of your automation scripts. If you are using packaged apps/tools for the monitoring & alerting of your application, then the automation scripts used for the application should also be configured for monitoring & alerting using that tool.
- Reporting: UI reports highlighting daily/weekly/monthly run of automation, with both success & defect rates.