Book Club: The DevOps Handbook (Chapter 9. Create the Foundations of our Deployment Pipeline )

This entry is part [part not set] of 25 in the series DevOps Handbook

The following is a chapter summary for “The DevOps Handbook” by Gene Kim, Jez Humble, John Willis, and Patrick DeBois for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on The DevOps Handbook

More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater―whether it’s the debacle, cardholder data breaches, or missing the boat with Big Data in the cloud.

And yet, high performers using DevOps principles, such as Google, Amazon, Facebook, Etsy, and Netflix, are routinely and reliably deploying code into production hundreds, or even thousands, of times per day.

Following in the footsteps of The Phoenix Project, The DevOps Handbook shows leaders how to replicate these incredible outcomes, by showing how to integrate Product Management, Development, QA, IT Operations, and Information Security to elevate your company and win in the marketplace.

The DevOps Handbook

Chapter 9

The goal is to create the technical practices and architecture required to enable and sustain the fast flow of work from Development into Operations without causing chaos and disruption to the production environment or customers.

Continuous Delivery (CD) includes:

  • Creating the foundations of the automated deployment pipeline.
  • Ensuring that the team has automated tests that constantly validate the application is in a deployable state.
  • Having developers integrate their code into trunk daily.
  • Architecting the environments and code to enable low-risk releases.

Outcomes of CD:

  • Reduces the lead time to get production-like environments.
  • Enables continuous testing that gives everyone fast feedback on their work.
  • Enables small teams to safely and independently develop, test, and deploy their code into production.
  • Makes production deployments and releases a routine part of daily work.

Ensure the team always use production-like environments at every stage of the value stream. The environments must be created in an automated manner, ideally on demand from scripts and configuration information stored in version control and entirely self-serviced.

Enable On-Demand Creation of Dev, Test, and Production Environments

Instead of documenting the specifications of the production environment in a document or on a wiki page, the organization should create a common build mechanism that creates all environments, such as for development, test, and production. By doing this, any team can get production-like environments in minutes, without opening up a ticket, let alone having to wait weeks.

Automation can help in the following ways:

  • Copying a virtualized environment
  • Building an automated environment creation process
  • Using “infrastructure as code” configuration management tools
  • Using automated operating system configuration tools
  • Assembling an environment from a set of virtual images or containers
  • Spinning up a new environment in a public cloud, private cloud, or other PaaS (platform as a service)

By providing developers an environment they fully control, teams are enabled to quickly reproduce, diagnose, and fix defects, safely isolated from production services and other shared resources. Teams can also experiment with changes to the environments, as well as to the infrastructure code that creates it (e.g., configuration management scripts), further creating shared knowledge between Development and Operations.

Create a Single Repository of Truth For The Entire System

Use of version control has become a mandatory practice of individual developers and development teams. A version control system records changes to files or sets of files stored within the system. This can be source code, assets, or other documents that may be part of a software development project.

Version Control Recommendations:

  • All the environment creation tools and artifacts described in the previous step
  • Any file used to create containers
  • All supporting automated tests and any manual test scripts
  • Any script that supports code packaging, deployment, database migration, and environment provisioning
  • All project artifacts
  • All cloud configuration files
  • Any other script or configuration information required to create infrastructure that supports multiple services

Make Infrastructure Easier To Rebuild Than Repair


Any script used to create database schemas or application reference data Bill Baker, a distinguished engineer at Microsoft, quipped that we used to treat servers like pets: “You name them and when they get sick, you nurse them back to health. [Now] servers are [treated] like cattle. You number them and when they get sick, you shoot them.”

The DevOps Handbook, Chapter 9

Instead of manually logging into servers and making changes, make changes in a way that ensures all changes are replicated everywhere automatically and that all changes are put into version control.

Teams can rely on automated configuration systems to ensure consistency, or they can create new virtual machines or containers from an automated build mechanism and deploy them into production, destroying the old ones or taking them out of rotation. This is known as immutable infrastructure.

Modify The Definition of Development “Done” To Include Running in Production-Like Environments

By having developers write, test, and run their own code in a production-like environment, the majority of the work to successfully integrate code and environments happens during daily work, instead of at the end of the release.

Ideally, team will use the same tools, such as monitoring, logging, and deployment, in pre-production environments as they do in production.

Series Navigation

Leave a Reply

%d bloggers like this: