As discussed in Chapter 7, DevOps was designed to empower individuals and allow teams to reduce the time required to bring features into production. This promise always resonates with leaders. But when it comes to reality, development and operations teams often put a lot of effort into introducing DevOps, only to discover that they don’t have the return on the investment that leaders expect.
At its heart, the DevOps process looks like the image above: the product goes through a cycle of Build, Test, Release, Monitor, Repeat. All the team members are encouraged to get involved at each of the stages and ensure the success of the product. Releases are sped up—to speeds reaching one release per day, rather than one release per year—and with greater automation comes higher performance.
But the problem with DevOps is an old one: too many cooks spoil the broth.
Given the modern development desire to release as soon as we have a minimum viable product (MVP) it often happens that corners are cut to get each version out. After a few releases, what was meant to be a square has had so many cut corners that it’s starting to look a lot like a circle.
Now suppose the product has a few rough edges and the development team is empowered to get involved with solving customer issues. Customer issues trickle in, developers help to resolve those issues, and before long, the developers find themselves spending half their week on customer issues rather than the next piece of work on their list. Suddenly, productivity drops dramatically.
Don’t Let Quality Slip
Continuous Integration and Continuous Deployment means that we can get features into the hands of customers quicker than we have ever done before. However, this means that we can quickly force our new bugs upon our customers. While breaking down the barriers between teams and the formal release stages that existed in previous models, developers and operations need to hold themselves to the same or higher standards of quality, and the only way to do this is by incorporating testing into every stage of the DevOps cycle, with tests that run automatically (and, as often as possible, are created automatically too):
DevOps can bring the same benefits to product lifecycle that SCRUM brings to the development lifecycle. Given all the technology advances that delivered true SCRUM, for example continuous integration systems, it’s time for the same advancement in the DevOps world. By ensuring software is tested as rigorously as possible, maintenance headaches will be minimized and the promised productivity enhancement can be delivered.
Deliver a Complete Test Suite
To reap the benefits of DevOps, you can’t afford to stick with manual processes or risk merging regressions late in the build process. By providing a complete, automated test suite, the development team can ensure that the rigorous testing required is delivered.
If there isn’t time for the team to write these tests themselves, the right tools can help. Diffblue Cover provides a way to quickly generate the tests you need for Continuous Integration, and automatically update the tests as the codebase changes over time. Code quality demands a better solution, and that increasingly appears to be automating test creation.
Check out the rest of the guide:
- Intro: What are the different types of tests?
- Chapter 1: How to write your first unit test
- Chapter 2: How to measure code coverage
- Chapter 3: How to build a complete test suite
- Chapter 4: Mocking in unit tests
- Chapter 5: Finding the time and motivation to unit test
- Chapter 6: Unit testing mistakes to avoid
- Chapter 7: How automated unit tests speed up continuous integration
- Chapter 8: How to deliver on the promises of DevOps
- Chapter 9: Why imperfect tests are better than no tests