Book Club: The DevOps Handbook (Chapter 11. Enable and Practice Continuous Integration)

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 healthcare.gov 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 11

The ability to “branch” in version control systems enables developers to work on different parts of the software system in parallel, without the risk of individual developers checking in changes that could destabilize or introduce errors into trunk. Integration problems result in rework to get the application into a deployable state, including conflicting changes that must be manually merged or merges that cause test failures, which can require multiple developers to resolve.

Development Practices to Support Innovation Time:

• Continuous integration and trunk-based development
• Investment in test automation
• Creation of a hardware simulator so tests could be run on a virtual platform
• The reproduction of test failures on developer workstations
• Architecture to support running off a common build and release

“Without automated testing, continuous integration is the fastest way to get a big pile of junk that never compiles or runs correctly.”

DevOps Handbook, Chapter 11

Small Batch Development and What Happens When Code is Committed to Trunk Infrequently

Significant problems result when developers work in long-lived private branches (also known as “feature branches”), only merging back into trunk sporadically, resulting in a large batch size of changes.

Jeff Atwood, founder of the Stack Overflow site and author of the Coding Horror blog, observes that while there are many branching strategies they can all be put on the following spectrum:

• Optimize for individual productivity – Every single person on the project works in their own private branch. Everyone works independently, and nobody can disrupt anyone else’s work; however, merging becomes a nightmare.
• Optimize for team productivity – Everyone works in the same common area. There are no branches, just a long, unbroken straight line of development. There’s nothing to understand, so commits are simple, but each commit can break the entire project and bring all progress to a screeching halt.

When merging is difficult, teams become less able and motivated to improve and refactor code because refactorings are more likely to cause rework for everyone else. When this happens, teams are more reluctant to modify code that has dependencies throughout the codebase, which is where they could have the highest payoffs.

“When we do not aggressively refactor our codebase, it becomes more difficult to make changes and to maintain over time, slowing down the rate at which we can add new features.”

Ward Cunningham on Technical Debt

Solving the merge problem was one of the primary reasons behind the creation of continuous integration and trunk-based development practices — to optimize for team productivity over individual productivity.

Adopt Trunk-Based Development Practices

One countermeasure to large batch size merges is to institute continuous integration and trunk-based development practices, where all developers check in their code to trunk at least once per day.

Frequent code commits to trunk means each team can run all automated tests on their application as a whole and receive alerts when a change breaks some other part of the application or interferes with the work of another developer.

Gated Commits – the deployment pipeline first confirms that the submitted change will successfully merge, build as expected, and pass all the automated tests before actually being merged into trunk.

Series Navigation