Automating the build, deploy, test, and release process means that changes to your systems can be checked in to your version control system and taken through to production in a completely automated fashion using a pattern called the deployment pipeline. The automated scripts for configuration and build of an environment become part of the code base, going through the same checks and balances applied to application source code (a technique known as “infrastructure as code”).
Using this pattern, the configuration and build of environments is under the same controls that are applied to application code, such as approval to do the work, approval on the requirements, approval on test results and approval to deploy the system to production.
As “owners” of the technical side of the systems, the operations team works with the development team to continuously improve the systems to ensure all releases can be deployed with minimal defects and no manual processes.
DevOps enables continuous delivery
In a recent Forrester report, “Five Ways to Streamline Release Management,” Jeffrey Hammond reveals that survey respondents “rated their release environments with an average score of 5.19 [out of 10]”. The root cause of these problems is often the fact that development, test and operations teams are separated, and often incentivized based on metrics that put them into conflict.
It is common for developers to be measured on how fast they complete features, but not on the quality of delivered code. Features can be “dev complete” but buggy and undeployable. Testers are often measured according to how many bugs they find, but not on the completeness and effectiveness of the tests completed. A release can pass all tests completed, but still have significant defects.
Operations teams are measured on the stability of the production environment, but not on their ability to support the rest of the IT service pipeline. They are usually so busy firefighting issues resulting from changes that they are unable to accept new releases and build new environments — let alone work with developers to make sure the software is deployable and maintainable.
Thus, multiple barriers are created, which work to prevent IT from releasing new functionality rapidly and reliably in response to the business needs.
Many organizations have already discovered the benefits of having developers and testers work together, and demonstrated that removing the “checks and balances” that a separate testing organization supposedly provides actually leads to higher quality systems. The same mentality needs to extend out to operations. Instead of separating the functions involved in delivering software and requiring them to optimize locally, measure the cycle time from concept to cash and require the whole organization to optimize for this metric.
How do I implement DevOps?
Start thinking about your portfolio of strategic IT services as a set of products. These products have owners, customers and a team that manages, develops and operates them throughout their lifecycle. It’s instructive to examine Eric Ries’ work on lean startups to consider how products evolve over time.
Ries argues that teams should focus on rapidly creating a minimum viable product and then pivot over time by continuously delivering new functionality based on feedback from real customers. In order to deliver these products, teams need to be multi-disciplinary, including developers, testers, operations people and managers; changing in composition over time to meet changing needs.
Along with other teams, the operations group also needs to change the way it works.