- 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
Chapter 20
Use Chat Rooms and Chat Bots to Automate and Capture Organizational Knowledge
Having work performed by automation in a chat room has numerous benefits, including:
- Everyone sees everything that is happening
- Engineers on their first day of work can see what daily work looks like and how it’s performed
- People are more apt to ask for help when they see others helping each other
- Rapid organizational learning is enabled and accumulated
Automate Standardized Processes in Software Re-use
Instead of putting our expertise into Word documents, teams need to transform these documented standards and processes, which encompass the sum of our organizational learnings and knowledge, into an executable form that makes them easier to reuse.
One of the best ways to make this knowledge re-usable is by putting it into a centralized source code repository, making the tool available for everyone to search and use.
ArchOps: “enables our engineers to be builders, not bricklayers. By putting our design standards into automated blueprints that were able to be used easily by anyone, we achieved consistency as a byproduct.”
Justin Arbuckle
Create a Single, Shared Source Code Repository For The Entire Organization
A firm-wide, shared source code repository is one of the most powerful mechanisms used to integrate local discoveries across the entire organization.
Put into the shared source code repository not only source code, but also other artifacts that encode knowledge and learning, including:
- Configuration standards for libraries, infrastructure, and environments
- Deployment tools
- Testing standards and tools, including security
- Deployment pipeline tools
- Monitoring and analysis tools
- Tutorials and standards
Spread Knowledge By Using Automated Tests As Documentation and Communities of Practice
When team have shared libraries being used across the organization, they should enable rapid propagation of expertise and improvements. Ensuring each of these libraries has significant amounts of automated testing included means the libraries become self-documenting and show other engineers how to use them.
The benefit will be nearly automatic if teams practice test-driven development (TDD), where automated tests are written before the code. This discipline turns test suites into a living, up-to-date specification of the system.
Design For Operations Through Codified Non-Functional Requirements
Examples of non-functional requirements include:
- Sufficient production telemetry in applications and environments
- The ability to accurately track dependencies
- Services that are resilient and degrade gracefully
- Forward and backward compatibility between versions
- The ability to archive data to manage the size of the production data set
- The ability to easily search and understand log messages across services
- The ability to trace requests from users through multiple services
- Simple, centralized runtime configuration using feature flags and so forth
Build Reusable Operations User Stories Into Development
Instead of manually building servers and then putting them into production according to manual checklists, automate as much of this work as possible. Ideally, for all recurring Ops work teams will know the following: what work is required, who is needed to perform it, and what the steps to complete it are.
“We know a high availability rollout takes fourteen steps, requiring work from four different teams, and the last five times we performed this, it took an average of three days.”
The DevOps Handbook
Ensure Technology Choices Help Achieve Organizational Goals
When expertise for a critical service resides only in one team, and only that team can make changes or fix problems, this creates a bottleneck.
The goal is to identify the technologies that:
- Impede or slow down the flow of work
- Disproportionately create high levels of unplanned work
- Disproportionately create large numbers of support requests
- Are most inconsistent with the desired architectural outcomes (e.g. throughput, stability, security, reliability, business continuity)