- Book Club: The DevOps Handbook (Conclusion)
- Book Club: The DevOps Handbook (Chapter 11. Enable and Practice Continuous Integration)
- Book Club: The DevOps Handbook (Chapter 1. Agile, Continuous Delivery, and the Three Ways)
- Book Club: The DevOps Handbook (Chapter 2. The First Way: The Principles of Flow)
- Book Club: The DevOps Handbook (Chapter 3. The Second Way: The Principles of Feedback)
- Book Club: The DevOps Handbook (Chapter 4. The Third Way: The Principles of Continual Learning and Experimentation)
- Book Club: The DevOps Handbook (Chapter 5. Selecting Which Value Stream to Start With)
- Book Club: The DevOps Handbook (Chapter 6. Understanding the Work in Our Value Stream, Making it Visible, and Expanding it Across the Organization)
- Book Club: The DevOps Handbook (Chapter 7. How to Design Our Organization and Architecture with Conway’s Law in Mind)
- Book Club: The DevOps Handbook (Chapter 8. How to Get Great Outcomes by Integrating Operations into the Daily Work of Development)
- Book Club: The DevOps Handbook (Chapter 9. Create the Foundations of our Deployment Pipeline )
- Book Club: The DevOps Handbook (Chapter 10. Enable Fast and Reliable Automated Testing)
- Book Club: The DevOps Handbook (Chapter 12. Automate and Enable Low-Risk Releases)
- Book Club: The DevOps Handbook (Chapter 23. Protecting the Deployment Pipeline and Integrating Into Change Management and Other Security and Compliance Controls)
- Book Club: The DevOps Handbook (Chapter 13. Architect for Low-Risk Releases)
- Book Club: The DevOps Handbook (Chapter 14. Create Telemetry to Enable Seeing and Solving Problems)
- Book Club: The DevOps Handbook (Chapter 15. Analyze Telemetry to Better Anticipate Problems and Achieve Goals)
- Book Club: The DevOps Handbook (Chapter 16. Enable Feedback So Development and Operations Can Safely Deploy Code)
- Book Club: The DevOps Handbook (Chapter 17. Integrate Hypothesis-Driven Development and A/B Testing into Our Daily Work)
- Book Club: The DevOps Handbook (Chapter 18. Create Review and Coordination Processes to Increase Quality of Our Current Work)
- Book Club: The DevOps Handbook (Chapter 19. Enable and Inject Learning into Daily Work)
- Book Club: The DevOps Handbook (Chapter 20. Convert Local Discoveries into Global Improvements)
- Book Club: The DevOps Handbook (Chapter 21. Reserve Time to Create Organizational Learning and Improvement)
- Book Club: The DevOps Handbook (Chapter 22. Information Security as Everyone’s Job, Every Day)
- Book Club: The DevOps Handbook (Introduction)
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
The Manufacturing Value Stream
In manufacturing operations, the value stream is often easy to see and observe: it starts when a customer order is received and the raw materials are released onto the plant floor.
Value Stream: “the sequence of activities an organization undertakes to deliver upon a customer request” or “the sequence of activities required to design, produce, and deliver a good or service to a customer, including the dual flows of information and material.” – Value Stream Mapping by Karen Martin & Mike Osterling
To enable fast and predictable lead times in any value stream:
- Create a smooth and even flow of work
- Using techniques such as small batch sizes
- Reducing work in process (WIP)
- Preventing rework to ensure defects are not passed to downstream work centers
- Constantly optimizing the system toward global goals
The Technology Value Stream
The same principles and patterns that enable the fast flow of work in physical processes are equally applicable to technology work.
In DevOps, the technology value stream as the process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer. Value is created only when services run in production.
Focus on Deployment Lead Time
Deployment Lead Time begins when a developer checks a change into version control. Deployment Lead Time ends when that change is successfully running in production, providing value to the customer and generating useful feedback and telemetry.
Instead of work going sequentially through the design/development value stream and then through the test/operations value stream, testing and operation happens simultaneously with design/development.
Defining Lead Time vs. Processing Time:
- The lead time clock starts when the request is made and ends when it is fulfilled.
- The process time clock starts only when work begins on the customer request—specifically, it omits the time that the work is in queue, waiting to be processed.
The Common Scenario: Deployment Lead Times Requiring Months
When we have long deployment lead times, heroics are required at almost every stage of the value stream. We may discover that nothing works at the end of the project when we merge all the development team’s changes together.
Our DevOps Ideal: Deployment Lead Times of Minutes
Developers receive fast, constant feedback on their work, which enables them to quickly and independently implement, integrate, and validate their code, and have the code deployed into the production environment.
Achieved by checking in small code changes to version control repository, performing automated and exploratory testing against it, and deploying it into production. Achieved when we have architecture that is modular, well encapsulated, and loosely-coupled.
Teams capable of working with high degrees of autonomy, with failures being small and contained, and without causing global disruptions. Deployment lead time is measured in minutes or, in the worst case, hours.
The below is the Value Stream Map:
Observing “%C/A” As A Measure of Rework
The third key metric in the technology value stream is percent complete and accurate (%C/A). This metric reflects the quality of the output of each step in our value stream.
“The %C/A can be obtained by asking downstream customers what percentage of the time they receive work that is ‘usable as is,’ meaning that they can do their work without having to correct the information that was provided, add missing information that should have been supplied, or clarify information that should have and could have been clearer.”Value Stream Mapping
The Three Ways: The Principles Underpinning DevOps
The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.
The First Way
Goal: Speed up flow through technology value stream, reduce lead time to fulfill requests, increase throughput.
- Continuous build, integration, test, and deployment processes
- Creating environments on demand
- Limiting work in process (WIP)
- Building systems and organizations that are safe to change
The Second Way
Goal: Creation of a generative, high-trust culture that supports a dynamic, disciplined, and scientific approach to experimentation and risk-taking, facilitating the creation of organizational learning, both from our successes and failures.
- System design to multiple effects of new knowledge (local discoveries into global improvements)
The Third Way
Goal: fast and constant flow of feedback from right to left at all stages of our value stream.
- Amplify feedback to prevent problems
- Enable faster detection and recovery
Chapter One covered the concepts of value streams, lead time as one of the key measures of the effectiveness for technology, and the high-level concepts behind each of the Three Ways. The following chapter summaries will cover each of the Three Ways in greater detail.