Whatever definition you prefer for DevOps, it's certain to include the concept of automation in order to ensure fast feedback throughout the DevOps pipeline. The sooner you get feedback, the quicker you can take action to resolve problems. Ideally, a DevOps process is infused with automation in order to more quickly and consistently accomplish tasks like:
- Developing the code
- Testing it
- Deploying the test infrastructure
- Running end-to-end tests
- Deploying the code
- Collecting metrics from production
- End-to-end orchestration of the DevOps pipeline
Liran Levy, R&D Lifecycle DevOps Manager at HPE Software, says that the ability to reduce your time to market is directly correlated to the ability to obtain fast feedback at every stage of the pipeline, and this can only be done with automation.
The range of opportunities for automation in DevOps, along with the choice of tools that you can use, can seem complex, especially for smaller teams with limited time and resources. You might already be doing some automation today, but how do you prioritize what to focus on next? If you're beginning a new DevOps project from scratch, where do you start?
Where are you now with automation?
Most DevOps projects start out as agile projects. If you're not there yet, make sure you get trained, and enlist an agile coach. Start working on defining your backlog, executing sprints, and producing content regularly. The goal with agile development and particularly with DevOps is continuous delivery.
JezHumble, co-author of the book "Continuous Delivery" and UC Berkeley lecturer, has two golden rules for continuous delivery:
- Software (trunk) is always deployable;
- Everyone is checking into trunk daily (at least)
He cites three ingredients in achieving these golden rules: configuration management, continuous integration, and automated testing.
Once you're working according to agile principles, your developers should be using configuration management, doing continuous integration, and running automated unit tests as part of the build. Automated functional tests, with perhaps some manual ones as well, are being developed and run concurrently with development. There might also be some non-functional tests, such as performance and security tests. The automated tests might be configured to run automatically, but some may need to be kicked off manually. The build process is probably configured to package the software so that it can be deployed for further testing.
So if you're doing all that, what automation do you need to add to get to DevOps?
- Defend the source base from check-ins that break the build, so that the code is always releasable
- Conversion of existing manual tests to automated tests
- Provisioning of a test environment
- Execution of functional and non-functional tests
- Deployment of the code
- Rolling back a deployment to the last working version
- Gathering production metrics
- Orchestrating the pipeline
- Continuously updating the DevOps dashboard
As Humble and David Farley say in their book, "Continuous Delivery", you don't need to automate everything at once, and you can, and should, automate gradually, over time.
4 steps to help you prioritize DevOps automation
Here are four simple steps to prioritizing your automation.
1. Evaluate your needs
The first step is to understand what you want to achieve, so that you can focus on your goals. You might already have some of these in place, although they might need a little more investment:
- Release software changes frequently into production
- Get quick feedback at any stage of the pipeline about a change before it goes into production
- Reduce the cost of downtime
- Monitor the software in production
- Have a single status report for the whole team by feeding production metrics back to a single dashboard for developers and operations staff
This isn't an exhaustive list. But once you have your own list, you need to prioritize it, and then work out what's blocking you from achieving each of the goals.
2. Identify your bottlenecks
Once you've identified the most important goal to achieve, you need to diagnose the reason why you've not achieved it yet so that you can treat it. For example, if your primary goal is to release small software changes frequently into production, there are many possible reasons that you're not there yet:
- Do your developers often cause delay by checking in bad code and breaking the build?
- Do your developers need to take time out to explain to the testers how to deploy software changes for testing?
- Does it take your testers a long time to test a small change?
- Do you need to manually prepare and load data for testing?
- ...
Once you've found the bottlenecks, think about the reasons they exist:
- If you have build issues, you need to be using continuous integration. Use a gated check-in solution, to prevent code getting to the main branch if it's going to break the build.
- Are you spending a lot of time testing? If you're running the same manual tests over and over again, automate them. If you're spending most of your time setting up test environments, automate the provisioning of test machines and deploying the software to be tested. If preparing the data is the problem, automate the process of extracting and scrubbing data, and populating the database.
- If it takes time to begin testing because a tester needs to start the tests manually, the tests need to be configured to run automatically as soon as the build succeeds and the test environment is available.
- Testers and developers work very closely together as part of the same team, but developers must do sufficient testing of their own work before allowing others to test it.
- If you need to shut your production environment down every time you find a problem in a new change, you should automate the process of reverting the build back to a stable version, and make sure that this process is tested before the change is deployed.
3. Consider the return on investment
By this point, you have created a list of tasks that you can add to your project's backlog. This lets you prioritize them relative to your other backlog items, and affords full visibility of the automation improvements. You know your team's capacity, and by including these automation items in the backlog, you ensure that these 'support' activities are being factored into the team's workload.
As with any backlog item, large items can be broken down into smaller items, and implemented in stages, with each stage providing value. Evaluate the cost of implementing each item, and by estimating the relative cost of delaying their implementation, you can use a weighted shortest job first approach to compare the return on investment of each item.
The advantage of this approach is that you can gradually phase your automation improvements into the backlog while minimizing delay in implementing the rest of your backlog items.
Keep in mind though that test automation should be part of the definition of done for all new code. John Jeremiah, a digital researcher for Hewlett Packard Enterprise, puts it very clearly: "In the old world, automation is 'nice to have', or 'support'. In the new world, automation is essential to achieving velocity without sacrificing quality. In fact, NO new code should be written without the automation to test it."
4. Continuously assess and reevaluate
Once you've cleared one of your bottlenecks, you can move on to the next one. But circumstances may have changed since you last investigated what was holding up your DevOps pipeline, so you need to reexamine the pipeline. There might be a new bottleneck that needs to be resolved, or perhaps an existing one has become more critical. Levy says that constantly reevaluating the pipeline and prioritizing the most serious hold-up alongside the rest of the items to be developed, will lead to an efficient DevOps pipeline, but you need to keep re-evaluating throughout the life of the project.
DevOps automation = Continuous monitoring and improving
DevOps automation isn't something that is done once and forgotten about. Just like security and performance, it's something you need to continuously monitor and improve as long as the DevOps pipeline is still active.
The first step to DevOps automation is to be agile. Once you're there, you can start on a gradual journey towards full-blown DevOps. Look at the DevOps goals that you want to achieve, and work out what's stopping you from getting there. Once you know what the bottlenecks are, you can figure out what you need to do to resolve them, and make that part of your backlog. If you continuously prioritize and reevaluate these items relative to the other items on the backlog, you'll be able to introduce automation gradually and effectively.
Anything you would add to this list? Please let me know in the comments below.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
