In a previous post, I discussed how Jez Humble made the case for the need for continuous delivery and DevOps. In this post I’ll cover the changes that need to be implemented to enable DevOps.Below is how Jez describes the 4 parts to delivery:
1. Culture
2. Automation
3. Measurement
4. Sharing
Culture is the most important part of DevOps. We need to make sure development and Ops are not treating each other as rivals and are instead working together frequently and efficiently. Ops need to be involved early on in the development process. They need to be in the inception meetings and in the demos. They need to know what is coming down the pipeline and provide their requirements in terms of monitoring, scalability, archiving, etc… Developers also need to rotate through the operations department. They need to be on call in case of production problems. They need to feel the pain and impact of not delivering production ready applications. Incentives between the development and operations department need to be reversed. Development needs to be measure on stability and operations needs to be measured on throughput. This gives development incentive to deliver production ready applications while encouraging operations to push applications into production.
Through automation, we can reduce the cost of making changes to the application and thus enable frequent delivery of software. This enables us to make smaller incremental changes that are less risky than big bang approaches. We want to create a deployment pipeline and automate the entire delivery process from build, deploy, test to release. Provisioning of infrastructure as well as database migrations and deployments need to be also automated so that we can always test in production like environment. All this creates transparency with a complete audit trail from when a change was introduced into source control until it was released into production.
Measurements are key to continuous improvement. We need measurements for all teams.
Are we generating business value? How many new users do we have? How many new orders?
Are we producing quality products? How many bugs are there? What changes are breaking things?
Do we have the right infrastructure? How often does a failure happen? How long to restore service? From these different measures we can decide on what areas need improvement.
Techniques like CI, TDD, and refactoring that developers use to improve their code can also be used to improve the Ops environment. Having the development team sharing and working with the operations team to improve their environment further builds trust and improves the relationship between the two until gradually the border between the two disappears.
All this is a major improvement on the traditional silo in the organizations. By building trust, aligning incentives, building a deployment pipeline, and measuring our processes, we can now eliminate the hardening and stabilization phases that tend to extend project plans. As the 2 groups move closer together, done no longer means dev complete but instead means released and in use. Developers now write production ready code and deploy to production like environments from day one. The conception to production cycle gets dramatically reduced to a matter of days and the business can now receive fast feedback and plan based on real user data.
In my next post I’ll describe how this enables organizations to align themselves around products instead of projects. Stay tuned...
Adapted from Enterprise DevOps: Breaking Down the Barriers between Development and IT Operations @ADP East 2011
