library / lib09a705d592e223cf
The DevOps Handbook (2nd Edition)
Gene Kim, Jez Humble, Patrick Debois & John Willis · 2021
In a sentence
A comprehensive prescriptive guide showing how any technology organization—from legacy enterprise to digital native—can adopt DevOps principles and practices to simultaneously achieve faster flow, higher reliability, better security, and a more humane workplace.
The DevOps Handbook provides technology leaders, practitioners, and business stakeholders with the theory, principles, and concrete practices needed to transform how software is built, tested, and delivered. Drawing on decades of management science, lean manufacturing, the Toyota Production System, resilience engineering, and hundreds of real-world case studies, the book demonstrates that the chronic conflict between Development and Operations—which produces ever-slower delivery, mounting technical debt, painful deployments, and burned-out employees—can be permanently broken. Through the Three Ways (Flow, Feedback, and Continual Learning and Experimentation), organizations learn to create deployment pipelines that deliver changes in minutes rather than months, build safety into every step of the value stream, instrument everything for fast feedback, and cultivate a generative culture of blameless learning. With evidence from the State of DevOps Reports showing elite performers deploying thirty times more frequently with two hundred times faster lead times and 168 times faster mean time to restore service, the book makes a compelling case that DevOps is not a passing fad but an organizational imperative for every company that depends on technology—which is every company.
The four lenses
- Science
- Statistics
- Systems
- Strategy
Tags
The model
A causal model describing how organizational design choices, technical practices, and cultural conditions combine to produce psychological and behavioral states in teams, which in turn drive software delivery performance outcomes and organizational results. The model integrates the Three Ways (Flow, Feedback, Continual Learning) with structural antecedents (architecture, team design) and cultural mediators (generative culture, psychological safety) to explain how elite performance is achieved and sustained.
Deployment Pipeline Automationdesign lever
The degree to which the end-to-end process of building, testing, and deploying software is automated, repeatable, and self-service, encompassing automated builds, automated test execution, automated environment provisioning, and one-click or fully automated promotion of artifacts from version control to production.
Version Control Comprehensivenessdesign lever
The extent to which all artifacts required to reproduce the production system—including application code, infrastructure configuration, environment definitions, test scripts, deployment scripts, database migration scripts, and toolchain configurations—are stored in a version control system and treated as the single source of truth for the system state.
Trunk-Based Development Practicedesign lever
A source control practice in which all developers integrate their code changes into a shared trunk or main branch at least once per day, maintain three or fewer active branches in the repository, and avoid long-lived feature branches, thereby minimizing merge complexity and enabling continuous integration of the full codebase.
Automated Test Suite Qualitydesign lever
The degree to which the automated test suite reliably and quickly validates that the system is in a deployable state, characterized by high coverage of business-critical paths, low false-positive rates, fast execution times enabling feedback in minutes, and tests that run consistently across environments and are maintained as living specifications of system behavior.
Loosely Coupled Architecturedesign lever
A system architecture in which services are independently testable and deployable, interact only through well-defined versioned APIs, have bounded contexts preventing shared internal data structures, and can be changed and released without requiring coordinated changes to other services, enabling small teams to work autonomously and safely.
Team Structure Market Orientationdesign lever
The degree to which technology teams are organized around customer-facing value streams rather than functional specialties, with cross-functional membership spanning development, operations, quality, and security skills enabling end-to-end ownership of a service from development through production operation without chronic dependency on separate functional departments.
Production Telemetry Coveragedesign lever
The comprehensiveness of instrumentation across all layers of the application stack—business logic, application performance, infrastructure, client software, and deployment pipeline—that generates metrics, logs, and events enabling real-time visibility into system health, user behavior, and security posture, with data centralized and accessible to all value stream members in self-service fashion.
Security Integration (Shift Left)design lever
The practice of integrating information security objectives, controls, and testing into every stage of the software development and delivery lifecycle rather than conducting security reviews only at project end, including automated security testing in the deployment pipeline, security-approved shared libraries, pre-approved environment configurations, and security telemetry in production.
Generative Organizational Culturecontextual condition
An organizational culture characterized by active information seeking and sharing, shared responsibilities across value stream roles, rewarded bridging between teams, inquiry-based responses to failures, and welcoming of new ideas—corresponding to Westrum's generative typology—which creates an environment of psychological safety enabling honest communication about problems and experiments.
Blameless Learning Practicesbehavioral pattern
A set of organizational rituals and norms in which failures, incidents, and near-misses are treated as opportunities to improve system design rather than occasions to assign individual blame, including the consistent conduct and publication of blameless post-mortems, the amplification of weak failure signals, and the institutionalization of game days and chaos engineering to proactively surface latent defects.
Work-in-Process and Batch Size Controlbehavioral pattern
Active management of the amount of work simultaneously in progress across the value stream and the size of individual change batches flowing through it, achieved through kanban WIP limits, small commit sizes, frequent integrations, limiting long-lived feature branches, and visualizing queues to surface bottlenecks before they cascade into systemic slowdowns.
Shared Goals Across Development and Operationscontextual condition
The degree to which Development, Operations, QA, and Infosec personnel share a common definition of success oriented toward end-to-end value stream outcomes (deployment frequency, lead time, MTTR, customer satisfaction) rather than local functional metrics, reinforced by shared tooling, shared backlogs, joint rituals, pager rotation, and mutual accountability for production health.
Deployment Frequencyoutcome metric
The rate at which the organization successfully deploys code or configuration changes to production or releases them to end users, ranging from on-demand multiple times per day for elite performers to once per month or less for low performers, serving as the primary throughput measure of the technology value stream.
Deployment Lead Timeoutcome metric
The elapsed time from a code change being committed to version control to that change running successfully in production and delivering value to customers, encompassing all build, test, review, and deployment steps, ranging from minutes for elite performers to months for low performers.
Mean Time to Restore Service (MTTR)outcome metric
The average elapsed time between a service incident or production failure beginning and the service being restored to normal operation, reflecting the organization's ability to detect problems quickly through telemetry and resolve them through fast deployment, roll-back, or feature toggle mechanisms.
Change Failure Rateoutcome metric
The proportion of production deployments or changes that result in a service degradation, outage, or require remediation such as a hotfix, rollback, or patch, reflecting the quality of the deployment pipeline, the effectiveness of pre-production testing, and the safety of the release process.
Employee Well-being and Job Satisfactionoutcome metric
The psychological and experiential state of technology workers characterized by engagement, sense of meaning and autonomy, low levels of burnout and chronic stress, willingness to recommend the organization as a workplace, and experience of joy and pride in their craft, as influenced by the degree to which the system of work is humane and enables rather than impedes their effectiveness.
Organizational Performanceoutcome metric
The degree to which the technology organization contributes to enterprise-level outcomes including profitability, revenue growth, market share, customer satisfaction, productivity, and market capitalization growth, as mediated by the speed and reliability of software delivery and the organization's ability to experiment and respond to competitive dynamics.
Technical Debt Levelcontextual condition
The accumulated burden of deferred fixes, undocumented workarounds, fragile infrastructure, missing automation, and suboptimal architectural decisions that must be serviced in the form of unplanned work, reduced velocity, and increased defect rates, growing over time when not actively managed through dedicated improvement capacity and refactoring.
Value Stream Constraint Locationcontextual condition
The identification of which work center or process step is currently the binding constraint on end-to-end deployment lead time and throughput in the technology value stream, which typically progresses through a predictable sequence (environment creation, code deployment, test execution, architecture) during DevOps transformation toward the desired state where the constraint is product development itself.
Feedback Loop Speedbehavioral pattern
The elapsed time between an engineer taking an action (committing code, deploying a change, releasing a feature) and receiving meaningful signal about whether that action achieved its intended effect—spanning developer unit test execution time, deployment pipeline cycle time, production telemetry alert latency, and customer behavior signal latency—with shorter loops enabling faster learning and correction.
How they connect
- deployment pipeline automation → predicts deployment frequency
- deployment pipeline automation − predicts deployment lead time
- automated test suite quality → predicts deployment frequency
- automated test suite quality − predicts change failure rate
- loosely coupled architecture → predicts deployment frequency
- loosely coupled architecture − predicts deployment lead time
- trunk based development − predicts deployment lead time
- version control comprehensiveness − predicts deployment lead time
- production telemetry coverage − predicts mean time to restore
- production telemetry coverage → predicts deployment frequency
- generative organizational culture → predicts deployment frequency
- generative organizational culture → predicts employee wellbeing satisfaction
- blameless learning practices → predicts generative organizational culture
- blameless learning practices − predicts mean time to restore
- wip and batch size control − predicts deployment lead time
- wip and batch size control − predicts change failure rate
- shared goals dev ops → predicts generative organizational culture
- team structure market orientation → predicts deployment frequency
- technical debt level → predicts deployment lead time
- technical debt level − predicts employee wellbeing satisfaction
- deployment frequency → predicts organizational performance
- deployment lead time − predicts organizational performance
- feedback loop speed − predicts technical debt level
- feedback loop speed → predicts employee wellbeing satisfaction
- security shift left − predicts change failure rate
- constraint location → moderates deployment lead time
- deployment pipeline automation → influences wip and batch size control
- generative organizational culture → mediates deployment frequency
The process
This book provides a comprehensive playbook for implementing DevOps principles, structured around the 'Three Ways.' The First Way focuses on optimizing the flow of work from development to operations to the customer. This involves visualizing work, reducing batch sizes, limiting work-in-progress, and building a robust continuous integration and delivery pipeline with automated testing and secure deployment patterns. The goal is to deliver value quickly, safely, and reliably. The Second Way emphasizes creating fast, constant feedback loops from all stages of the value stream. This is achieved by establishing comprehensive telemetry and monitoring to detect problems as they occur, enabling rapid incident response, and fostering shared ownership between development and operations. By amplifying feedback, teams can see and solve problems earlier, improving quality and system resilience. The Third Way is about creating a culture of continual learning and experimentation. This involves conducting blameless post-mortems to learn from failures, institutionalizing daily improvement, proactively testing system resilience through practices like chaos engineering, and sharing knowledge across the organization. This culture of high trust and disciplined experimentation allows the organization to innovate, adapt, and continuously improve its performance.
Initiate a DevOps Transformation
To identify a starting point for a DevOps transformation, build momentum with early wins, and establish the organizational structure and goals needed for success.
When to use: At the beginning of a DevOps adoption journey, when an organization recognizes the need to improve its software delivery performance.
Step 1Form a coalition of like-minded professionals and leaders across Business, Product, Development, QA, IT Operations, and Information Security to champion the transformation.
Entry: Recognition of inefficiencies or pain points in the current value stream.
Exit: A cross-functional coalition is formed with leadership buy-in.
- Who to involve in the initial coalition.
- How to approach leadership for support.
In: Awareness of DevOps principles, Willingness of team members to collaborate · Out: A guiding coalition for DevOps transformation
ch26
Step 2Select a value stream for the initial transformation effort, focusing on areas with significant pain points or opportunities for high-impact wins.
Entry: A guiding coalition is in place.
Exit: A target value stream and team are selected for the pilot transformation.
- Focus on a greenfield (new) vs. brownfield (existing) project.
- Which value stream offers the best chance for an early, visible success.
In: Pain point data, Customer feedback, Business goals · Out: Identified value stream for transformation
ch05
Step 3Create a dedicated, cross-functional transformation team to lead the pilot effort, freeing them from rules that may hinder progress.
Entry: A target value stream has been selected.
Exit: A dedicated team is assembled and empowered to drive the transformation.
- Team composition and leadership.
- Specific goals and metrics for the team.
In: Team members with diverse skills, Clear transformation goals · Out: An empowered transformation team
ch06
Step 4Establish clear, measurable improvement goals and an iterative planning cadence for the transformation.
Entry: The transformation team is in place.
Exit: A set of high-level goals and an iterative work plan are defined.
- Which metrics to target for improvement.
- The length of the iteration cycle.
In: Leadership goals, Team assessments · Out: Defined improvement goals, A structured iteration plan
ch06
Step 5Execute the pilot project, demonstrate early successes, and communicate them effectively to build momentum and organizational buy-in.
Entry: Goals and iteration plan are defined.
Exit: The pilot project is complete, and results are shared.
- Which teams to engage next.
- When to address more resistant groups.
In: Initial transformation goals, Metrics for success · Out: Increased buy-in from other teams, A broader base of support for the transformation
ch05
Optimize Workflow with Lean Principles
To increase the throughput and predictability of work by applying Lean principles to the technology value stream, making work visible, identifying constraints, and reducing waste.
When to use: Continuously, after a transformation has begun, to improve the flow of work.
Step 1Conduct a Value Stream Mapping workshop to visualize the current workflow.
Entry: A team or value stream has been identified for improvement.
Exit: A documented map of the current value stream, with bottlenecks and inefficiencies identified.
- Which stakeholders to include in the workshop.
In: Cross-functional team of stakeholders, Knowledge of the work processes · Out: A documented value stream map, Identified bottlenecks and inefficiencies
ch06
Step 2Make all work visible using a visual work board, such as a Kanban board.
Entry: Work items and process steps are understood.
Exit: All work is tracked on a shared visual board.
- What stages to represent on the board.
In: Work items to be completed · Out: Increased visibility of work, A shared understanding of workflow status
ch02
Step 3Limit Work in Process (WIP) for each stage of the workflow.
Entry: Work is visible on a Kanban board.
Exit: WIP limits are established and enforced for each workflow stage.
- What the initial WIP limits should be for each stage.
- How and when to adjust WIP limits.
In: Defined workflow stages · Out: Reduced context switching, Clearer visibility of bottlenecks
ch02
Step 4Reduce batch sizes to enable faster flow and quicker feedback.
Entry: Work items are defined.
Exit: Team is consistently working on and delivering small batches of work.
- The optimal batch size for different types of work.
In: Larger projects or work items · Out: Faster turnaround on tasks, Quicker detection of problems
ch02 · ch11
Step 5Identify and elevate the system's constraints.
Entry: Workflow is visible and WIP limits are in place.
Exit: A process for continuous constraint identification and resolution is established.
- How to allocate resources to address the identified constraint.
In: Workflow data, Team feedback on constraints · Out: Enhanced workflow efficiency, Reduced lead times
ch02
Step 6Continuously eliminate waste and hardships in the value stream.
Entry: The value stream is mapped and visible.
Exit: A culture of continuous waste reduction is fostered.
- Which forms of waste to prioritize for elimination.
In: Workflow analysis reports, Team input on challenges · Out: More efficient processes, Improved employee satisfaction
ch02
Design High-Performing Teams and Architecture
To structure teams and system architecture to optimize for fast, independent delivery of value, guided by Conway's Law.
When to use: During a DevOps transformation, when optimizing for flow reveals organizational or architectural constraints.
Step 1Evaluate existing team and communication structures against Conway’s Law.
Entry: A desire to improve team autonomy and delivery speed.
Exit: An understanding of how the current organizational structure impacts the system architecture.
- Whether the current structure supports the desired architectural outcomes.
In: Current organizational chart, System architecture diagrams · Out: Analysis of alignment with Conway's Law
ch07
Step 2Organize teams to be market-oriented and autonomous, such as using the 'two-pizza team' model.
Entry: Leadership has committed to organizational restructuring.
Exit: Teams are restructured to be small, autonomous, and market-oriented.
- How to define service boundaries and team responsibilities.
In: Business objectives, Product portfolio · Out: Agile, responsive, and autonomous teams
ch07
Step 3Embed functional expertise (e.g., Operations, QA, Infosec) within product teams.
Entry: Autonomous teams are being formed.
Exit: Cross-functional expertise is integrated into product teams.
- Whether to fully embed experts or use a liaison model.
- How to maintain functional excellence across embedded experts.
In: List of required functional skills, Product team charters · Out: Cross-functional product teams
ch07 · ch08
Step 4Integrate Ops personnel and work into the daily rituals of development teams.
Entry: Ops engineers are embedded or assigned to product teams.
Exit: Ops is an integral part of the development team's daily work.
- Which rituals are most important for Ops to attend.
In: Development team meeting schedules, Shared Kanban board · Out: Improved Dev-Ops collaboration, Better visibility of operational work
ch08
Step 5Evolve the system architecture towards a loosely-coupled, service-oriented model.
Entry: The existing architecture is identified as a constraint to fast flow.
Exit: A plan for architectural evolution is being executed.
- Which functionalities to decouple first.
- The design of the new service APIs.
In: Existing legacy system, New architecture design · Out: A modernized, loosely coupled architecture
ch13
Build Foundational DevOps Infrastructure
To create the technical foundation required for fast, reliable, and repeatable software delivery by automating environment creation and centralizing configuration management.
When to use: Early in the DevOps transformation, as a prerequisite for building a deployment pipeline.
Step 1Establish a single, shared repository as the source of truth for all code and configuration.
Entry: A version control system (e.g., Git) is in place.
Exit: All production artifacts are stored and versioned in a central repository.
- How to organize artifacts within the repository.
In: Application source files, Environment configurations, Version control system · Out: A single source of truth for the system's state
ch09 · ch20
Step 2Automate the creation of production-like environments on demand.
Entry: Configurations are stored in version control.
Exit: Environments can be created automatically and reliably.
- Choice of automation tools and technologies (e.g., VMs, containers, cloud services).
In: Version-controlled configuration scripts, Automation tools · Out: Production-like environments available on demand
ch09
Step 3Create self-service capabilities for developers to access necessary infrastructure and tools.
Entry: Key operational services are identified.
Exit: Developers can independently access required services via a self-service platform.
- Which services to offer as self-service first.
In: Technical infrastructure for automation, List of essential Operations services · Out: Increased developer independence and productivity
ch08
Step 4Adopt a practice of rebuilding infrastructure rather than repairing it.
Entry: Environment creation is fully automated.
Exit: A policy of immutable infrastructure is enforced.
- When to rebuild versus repair based on the issue.
In: Automated environment creation system · Out: Consistent, reliable, and easily reproducible production environments
ch09
Implement a Continuous Integration and Delivery Pipeline
To automate the build, test, and deployment process, enabling fast, low-risk releases and providing rapid feedback to developers on the quality of their work.
When to use: After establishing foundational infrastructure, this becomes the core engine of the technology value stream.
Step 1Establish a trunk-based development practice where all developers commit code to a single main branch at least once per day.
Entry: A single source code repository is in use.
Exit: All developers are committing to the trunk daily.
In: Version control system · Out: A constantly integrating and up-to-date main branch
ch11
Step 2Build an automated deployment pipeline triggered by every commit to the trunk.
Entry: Trunk-based development is practiced.
Exit: Every commit automatically triggers a build and test cycle.
- Which tool to use for the CI/CD pipeline (e.g., Jenkins, CircleCI, GitHub Actions).
In: Code changes checked into version control · Out: Validated and deployable code packages
ch10 · ch12
Step 3Implement a gated commit or pull request process to ensure the trunk always remains in a green, deployable state.
Entry: An automated deployment pipeline exists.
Exit: The main branch is protected from changes that would break the build or tests.
- The criteria for passing the gate (e.g., which tests must pass).
In: Code to be committed, Automated deployment pipeline · Out: A consistently stable and deployable main branch
ch11 · ch18
Step 4Expand the definition of 'done' to mean code is integrated, tested, and running successfully in a production-like environment.
Entry: Automated environments and a deployment pipeline are available.
Exit: Work is only considered complete after successful validation in a production-like environment.
In: Development code, Production-like test environments · Out: High confidence in the release readiness of code
ch09
Step 5Create a culture where the team stops all new work to fix a broken pipeline.
Entry: The deployment pipeline is operational.
Exit: A team-wide policy for handling broken builds is established and followed.
- Whether to fix forward or revert the change that caused the failure.
In: Build failure notification · Out: A green build state restored in the deployment pipeline
ch10 · ch11
Integrate Comprehensive Automated Testing
To build confidence in code quality, provide rapid feedback to developers, and enable safe, frequent deployments by creating a reliable and fast automated test suite.
When to use: In parallel with the development of the CI/CD pipeline, as a critical component of it.
Step 1Create a comprehensive and reliable automated test suite.
Entry: A testing framework is chosen and available to developers.
Exit: New features are accompanied by automated tests.
- Which testing frameworks and tools to use.
In: New code changes · Out: A comprehensive and evolving test suite
ch10
Step 2Integrate the automated test suite into the deployment pipeline.
Entry: An automated test suite exists.
Exit: Tests are executed automatically as part of the CI/CD pipeline.
In: Deployment pipeline configuration · Out: Automated feedback on code quality for every commit
ch10
Step 3Integrate performance and other non-functional testing into the pipeline.
Entry: A baseline of functional tests is running in the pipeline.
Exit: Non-functional requirements are validated automatically.
- Performance and security acceptance criteria.
- How to simulate production load.
In: Performance testing tools, Non-functional requirements · Out: Reports on system performance and security posture
ch10
Step 4Use automated tests as a form of living documentation and a tool for knowledge sharing.
Entry: Teams are writing automated tests.
Exit: Test suites are used as a primary source of documentation.
In: Testing frameworks, Libraries and services · Out: Self-documenting systems
ch20
Implement Safe Deployment Strategies
To enable low-risk releases into production, allowing for rapid delivery of features while minimizing the impact of potential failures on users.
When to use: Once a reliable deployment pipeline is in place, these strategies are used for every production release.
Step 1Implement feature toggles to decouple deployment from release.
Entry: A new feature is ready for deployment.
Exit: The feature is deployed to production behind a toggle.
- The granularity of the toggle (e.g., per user, percentage of users, global).
- When to enable the feature.
In: Application code, Feature toggle management system · Out: Ability to control feature availability dynamically
ch12
Step 2Use the Canary release pattern for incremental rollouts.
Entry: A new version is ready for release.
Exit: The new version is either fully deployed or rolled back based on performance.
- The size of the canary group.
- The performance criteria for a successful canary.
In: New software version, Monitoring tools · Out: Gradual and controlled rollout of features
ch12
Step 3Use the Blue-Green deployment pattern to minimize downtime and risk.
Entry: Two identical production environments are available.
Exit: User traffic is seamlessly switched to the new version.
- When to switch traffic to the new environment.
- The criteria for a successful switch.
In: Two separate but identical environments, New application code · Out: Seamless update process with minimal disruption
ch12
Establish Comprehensive Telemetry and Monitoring
To create fast and effective feedback loops by instrumenting systems to generate continuous telemetry, enabling teams to monitor performance, detect deviations, and diagnose problems.
When to use: Continuously, as a core practice to provide visibility into the health and performance of services.
Step 1Design systems to create telemetry as a standard practice.
Entry: A service or application is being developed or maintained.
Exit: The system is generating comprehensive telemetry data.
- Which monitoring tools and libraries to use (e.g., Prometheus, OpenTelemetry).
In: Application code, Server configurations · Out: A stream of telemetry data (logs, metrics, traces)
ch14
Step 2Centralize telemetry data for easy access and analysis.
Entry: Telemetry data is being generated.
Exit: All telemetry is aggregated in a central monitoring system.
- The choice of centralized logging and monitoring tools.
In: Telemetry data streams · Out: Centralized and aggregated telemetry data
ch14
Step 3Create self-service access to telemetry data for all engineers.
Entry: Telemetry data is centralized.
Exit: All stakeholders can easily access and visualize telemetry data.
- Which metrics are most important to display on shared dashboards.
In: Centralized telemetry system · Out: Accessible telemetry data via dashboards and APIs
ch14
Step 4Use statistical methods to set intelligent alerting thresholds.
Entry: Historical telemetry data is available.
Exit: Alerts are configured based on statistical analysis.
- The threshold for a significant deviation (e.g., three standard deviations).
- Which statistical methods to apply for non-Gaussian data.
In: Historical production metrics data · Out: Alerts on significant variances from normal performance
ch15
Step 5Continuously identify and fill telemetry gaps.
Entry: An incident has occurred and been resolved.
Exit: New telemetry is added to improve future monitoring.
- Which additional metrics to introduce based on incident analysis.
In: Incident reports, Existing telemetry data · Out: More comprehensive telemetry coverage
ch14 · ch15
Manage Incidents and Feedback Loops with Shared Ownership
To rapidly detect and resolve production incidents by fostering a culture of shared responsibility between Development and Operations, and to establish mechanisms for immediate, collaborative problem-solving.
When to use: When any problem is detected in the workflow or a production system, from a broken build to a customer-facing outage.
Step 1Establish a mechanism to immediately signal a problem and halt new work, such as an 'Andon cord'.
Entry: A problem is detected in the workflow or a system.
Exit: The team is alerted and has stopped new work to address the issue.
- The severity of an issue that warrants pulling the cord.
In: Build failure notification, Automated test failure, Production alert · Out: A halt to new work, Team-wide focus on the current problem
ch03 · ch10
Step 2Swarm on the problem to diagnose and resolve it collaboratively.
Entry: The Andon cord has been pulled.
Exit: The problem is diagnosed and resolved.
In: Team members with relevant expertise, Telemetry data · Out: Quick resolution of the problem, Increased collective knowledge of the system
ch03
Step 3Implement shared on-call responsibilities for developers.
Entry: A service is running in production.
Exit: Developers are participating in the on-call rotation for their services.
- The structure and frequency of the on-call rotation.
In: On-call schedules, Incident management systems · Out: Faster resolution of production issues, More resilient and operable services
ch16
Step 4Develop countermeasures to prevent the problem from recurring.
Entry: The incident has been resolved.
Exit: A countermeasure is implemented and documented.
In: Root cause analysis of the incident · Out: Reduced likelihood of problem recurrence
ch03
Step 5Establish a formal service handback mechanism from Operations to Development.
Entry: A service repeatedly fails to meet stability criteria.
Exit: Responsibility for the service is transferred back to the development team.
- The specific criteria that define an unstable service.
In: Service stability criteria, Performance metrics · Out: Improved service stability, Clear accountability for service operability
ch16
Foster a Culture of Continuous Learning and Improvement
To create a high-trust, generative culture where mistakes are treated as learning opportunities, improvement is part of daily work, and knowledge is shared freely across the organization.
When to use: Continuously, as the foundation for all other DevOps practices.
Step 1Conduct blameless post-mortems after every incident.
Entry: A production incident or failure has been resolved.
Exit: A post-mortem report with actionable countermeasures is created and shared.
- Which incidents warrant a formal post-mortem.
- Which countermeasures to prioritize.
In: Incident reports, Involved team members · Out: Lessons learned from the incident, Systemic improvements to prevent recurrence
ch04 · ch19
Step 2Institutionalize the improvement of daily work by reserving capacity for it.
Entry: Work is planned in iterations or sprints.
Exit: Time is consistently dedicated to non-functional requirements and process improvements.
- What percentage of capacity to reserve.
- How to prioritize technical debt items.
In: Identified technical debt, Team capacity · Out: Reduced technical debt, More efficient and sustainable processes
ch04 · ch06
Step 3Hold regular improvement blitzes (Kaizen Blitzes) to focus on solving specific problems.
Entry: A set of known problems or areas for improvement has been identified.
Exit: Specific improvements are implemented and documented.
- The focus area for the blitz.
In: Identified problems or improvement opportunities · Out: New solutions for improving processes, Actionable to-do lists for future work
ch21
Step 4Create mechanisms to transform local discoveries into global improvements.
Entry: A team or individual makes a useful discovery or improvement.
Exit: The knowledge is documented and made accessible to the entire organization.
- Which discoveries warrant wider dissemination.
In: Local discovery reports, Team feedback · Out: Enhanced collective knowledge, Organizational best practices
ch04 · ch20
Step 5Reserve time for learning and knowledge sharing.
Entry: A desire to improve organizational skills and knowledge.
Exit: Regular, dedicated time for learning is integrated into the work week.
- The format and frequency of learning events.
In: Scheduled time commitment, Employee expertise · Out: Enhanced skills and knowledge among employees, A more collaborative work environment
ch21
Implement Resilience Engineering
To enhance organizational resilience and system robustness by proactively testing for failures and rehearsing responses to catastrophic events.
When to use: Once a system has reached a baseline level of stability and monitoring is in place.
Step 1Inject controlled stressors into systems to stimulate resilience.
Entry: A system is operational and monitored.
Exit: Resilience testing is part of routine operations.
- The type and scale of stressors to introduce.
In: Current operational procedures · Out: Increased system resilience
ch04
Step 2Implement Chaos Engineering practices to proactively find weaknesses.
Entry: Systems are designed to be fault-tolerant.
Exit: The system can withstand random failures without significant user impact.
- The scope and timing of chaos experiments.
In: Chaos engineering tools, Access to production environments · Out: Increased resilience and operational awareness of failure modes
ch19
Step 3Schedule regular 'Game Day' exercises to simulate large-scale failures.
Entry: Incident response plans are documented.
Exit: Teams are familiar with disaster response processes and have identified areas for improvement.
- Which catastrophic events to simulate based on risk assessment.
In: Predefined disaster scenarios, Team readiness · Out: Improved disaster response capabilities, Increased organizational resilience
ch19
Step 4Analyze the outcomes of resilience tests and document findings.
Entry: A resilience test has been completed.
Exit: Learnings are documented and used to drive improvements.
In: System response data, Team observations · Out: Improved system design and response strategies
ch04 · ch19
Integrate Security and Compliance into the DevOps Workflow
To embed security and compliance into the daily work of Development and Operations, enabling fast and safe delivery while satisfying governance and audit requirements.
When to use: Throughout the DevOps transformation, to ensure security and compliance are not afterthoughts.
Step 1Integrate Information Security (Infosec) into the start of the development cycle.
Entry: A new project or feature is being planned.
Exit: Security requirements are understood and integrated into the backlog.
- How to prioritize security stories alongside feature stories.
In: Collaboration with Infosec teams, Existing work tracking tools · Out: Enhanced visibility of security issues, Proactive identification of security risks
ch22 · ch23
Step 2Automate security testing within the deployment pipeline.
Entry: A deployment pipeline is in place.
Exit: Security tests are run automatically for every change.
- Which security testing tools to use.
- Whether a failed security test should block the deployment.
In: Automated security testing tools, CI/CD pipeline infrastructure · Out: Automated feedback on security issues, Reduced chance of deploying vulnerable code
ch23
Step 3Create a shared repository of pre-approved, secure libraries and tools.
Entry: Commonly used libraries and tools are identified.
Exit: A repository of pre-approved, secure components is available to developers.
- The criteria for approving a component.
In: Shared source code repositories · Out: Improved developer productivity and application security
ch23
Step 4Integrate compliance and change approval into the automated workflow.
Entry: A reliable deployment pipeline exists.
Exit: Change approval processes are streamlined for low-risk changes.
- The criteria for classifying a change as Standard.
In: Historical data on deployment success rates, Change management systems · Out: Faster deployment processes, Reduced approval bottlenecks, Auditable trail of changes
ch24
Step 5Implement preventative controls like peer review and pair programming to satisfy separation of duty requirements.
Entry: A collaborative team culture exists.
Exit: All production changes are reviewed by a peer.
In: Tools for code review (e.g., GitHub Pull Requests) · Out: Enhanced code quality, Reduced risk of fraudulent or erroneous changes
ch18 · ch24
Step 6Provide auditors with self-service access to documentation and evidence.
Entry: Telemetry and deployment automation systems are in place.
Exit: Auditors can independently verify compliance controls.
In: Telemetry systems, Deployment pipeline logs · Out: Streamlined audit process, Improved trust between auditors and engineering
ch24
Drive Product Development with Hypothesis-Driven Experimentation
To validate that new features will achieve desired business outcomes and meet user needs before, during, and after development, fostering a culture of continuous learning and data-informed decision-making.
When to use: When planning and developing new user-facing features or changes.
Step 1Formulate a clear, testable hypothesis for any proposed feature.
Entry: An idea for a new feature or change is proposed.
Exit: A clear, measurable hypothesis is documented.
In: User research, Business goals · Out: A testable hypothesis
ch17
Step 2Conduct the cheapest and fastest experiments possible to test the hypothesis.
Entry: A hypothesis has been formulated.
Exit: Initial user feedback is gathered and analyzed.
- Whether the initial feedback validates proceeding to development.
In: A clear hypothesis · Out: Early validation of a feature's value
ch17
Step 3Implement A/B testing to validate feature performance in production.
Entry: A feature has been developed and is ready for release.
Exit: Statistically significant data on the performance of each version is collected.
- Which version to roll out to all users based on the results.
In: Two versions of a feature, A/B testing infrastructure · Out: Data-driven insights into user preferences and feature performance
ch17
Step 4Analyze the impact of all changes on key performance metrics.
Entry: A change has been deployed to production.
Exit: The impact of the change is understood and documented.
- Whether to iterate on the feature, roll it back, or consider it complete.
In: Production telemetry data, Business metrics · Out: Faster learning cycles, Improved product decisions
ch17
Measure DevOps Performance and Productivity
To assess the performance of the software delivery process and developer productivity using meaningful, outcome-oriented metrics, enabling data-driven continuous improvement.
When to use: Continuously, to track the progress of the DevOps transformation and identify areas for improvement.
Step 1Measure the four key metrics of software delivery performance.
Entry: A deployment pipeline and incident management process are in place.
Exit: The four key metrics are being tracked and reported.
In: Version control system data, Deployment pipeline data, Incident management data · Out: Quantified software delivery performance
ch01
Step 2Measure flow metrics to understand the health of the workflow.
Entry: Work is visualized on a Kanban board.
Exit: Flow metrics are being tracked and analyzed.
- Which process improvement actions to take based on the metrics.
In: Historical performance data from the work board · Out: Data-driven insights into workflow health
ch01
Step 3Adopt a holistic framework like SPACE to measure developer productivity.
Entry: A desire to understand and improve developer productivity.
Exit: A multi-dimensional set of productivity metrics is being tracked.
- Which dimensions of the SPACE framework to measure.
- What specific metrics to collect for each dimension.
In: Developer feedback (surveys), Data collection tools · Out: A comprehensive view of developer productivity and team health
ch27p01
Step 4Analyze metrics to gain insights and drive continuous improvement.
Entry: Performance and productivity metrics are being collected.
Exit: Metrics are regularly used to inform decision-making.
In: Performance and productivity data · Out: Actionable insights for improvement
ch01 · ch27p01
The story
The reader Technology leaders, engineers, and practitioners in Development, Operations, QA, Infosec, and business management who want to deliver software faster, more reliably, and more safely—and who want their organizations and people to thrive rather than burn out.
External problem
Software releases are slow, risky, and painful; deployment lead times stretch to weeks or months; production incidents are frequent; and competitive responsiveness is severely limited.
Internal problem
Engineers feel powerless, burned out, and trapped in a system that preordains failure—where heroics are required just to keep the lights on and where their best work is undone by the next release disaster.
Philosophical problem
It is fundamentally wrong that organizations investing billions in technology consistently produce worse outcomes the larger and longer they run, and that the humans doing the work suffer for it; there must be a better way that rewards craftsmanship and creates joy in work.
The plan
- Understand the core chronic conflict and downward spiral that makes the status quo self-reinforcing and recognize it as a solvable system design problem.
- Learn the Three Ways—Flow, Feedback, and Continual Learning—as the principled foundation for all DevOps practices.
- Select the right value stream and team to start with, using value stream mapping to reveal constraints and waste.
- Design your organization and architecture in accordance with Conway's Law so that team boundaries enable rather than impede fast, safe flow.
- Build the deployment pipeline foundations: on-demand environments, version control for all artifacts, and automated build and test infrastructure.
- Implement continuous integration with trunk-based development, automated tests, and an Andon cord culture that stops the line when quality breaks.
- Enable low-risk releases through automated deployment, environment-based and application-based release patterns, and decoupling deployment from release.
- Create comprehensive production telemetry and fast feedback loops so problems are detected and resolved in minutes rather than days.
- Integrate security and compliance into daily work as automated pipeline controls rather than end-of-project gates.
- Institutionalize continual learning through blameless post-mortems, game days, improvement blitzes, shared repositories, and communities of practice.
- Expand DevOps practices across the organization by building on demonstrated successes, winning early adopters, and accumulating a silent majority before engaging holdouts.
Success
- Deployment lead times measured in minutes or hours rather than weeks or months.
- Deployments that are routine, low-stress, daytime events rather than weekend fire drills.
- Engineers who are energized, learning, and proud of their work rather than burned out and fearful.
- A culture where problems surface early and are solved collaboratively rather than hidden and blamed.
- Security and compliance achieved continuously as a byproduct of daily work rather than as painful end-of-project audits.
- Business leaders and technology teams aligned on shared outcomes with a common vocabulary and shared metrics.
- The organization able to out-experiment competitors and respond to market changes in days rather than quarters.
At stake
- Continued downward spiral: longer lead times, more frequent outages, growing technical debt, and eventual loss of market position to more nimble competitors.
- Engineers continue to burn out and leave, taking institutional knowledge with them, replaced by people who face the same broken system.
- Security breaches and compliance failures that could have been prevented surface catastrophically rather than being caught early.
- The organization becomes unable to respond to competitive threats or customer needs at the pace the market requires, risking the survival of the business itself.
Chapter by chapter
ch01Agile, Continuous Delivery, and the Three Ways
This chapter introduces the foundational theory of Lean Manufacturing and the Three Ways underpinning DevOps, detailing how these principles enhance value delivery in technology and manufacturing contexts.
ch02The First Way: The Principles of Flow
The chapter explores the critical importance of work flow across Development and Operations to enhance value delivery in technology environments, emphasizing visibility, limiting work in process, and reducing batch sizes as key strategies.
ch03The Second Way: The Principles of Feedback
The chapter presents the Second Way of creating a safer and more resilient system of work by emphasizing fast, reciprocal feedback throughout complex systems, thus averting catastrophic failures and fostering continual learning.
- A fast feedback culture is crucial for maintaining safety and quality in complex systems.
- Swarming and rapid response to issues prevent minor problems from escalating to catastrophic failures.
- Effective feedback loops should operate at all levels, allowing for quick detection and corrective measures.
- Psychological safety must be fostered to encourage open discussions about problems and failures.
ch04The Third Way: The Principles of Continual Learning and Experimentation
The chapter advocates for creating a culture of continual learning and experimentation within organizations, emphasizing its role in achieving high performance and enhancing employee satisfaction.
- Fostering a culture of continual learning and experimentation creates an engaging and fulfilling workplace environment.
- High-trust organizations see significantly better employee recommendations and reduced burnout, as evidenced by the State of DevOps Reports.
- Removing blame from failure narratives enhances psychological safety, fostering an environment ripe for growth and learning.
- By establishing blameless post-mortems, organizations can turn failures into opportunities for systemic improvements.
ch05Selecting Which Value Stream to Start With
Choosing the right value stream for DevOps transformation is critical, impacting not only the transformability but also team dynamics and organizational success.
- Selecting the right value stream for DevOps transformation is critical and directly influences the organization's ability to adapt and thrive.
- Early successes in transformation not only increase confidence but also pave the way for broader organizational buy-in and future initiatives.
- There is a distinct difference between greenfield and brownfield projects; understanding these can inform the strategic choice of where to begin transformation.
- The ability to transform legacy systems is as vital as innovating new workflows; both can coexist to serve business objectives.
ch06Understanding the Work in Our Value Stream, Making It Visible, and Expanding It Across the Organization
The chapter argues for the importance of mapping value streams to identify inefficiencies in how value is delivered to customers, highlighting case studies from Nordstrom and LinkedIn to illustrate practical applications and transformations.
- Value stream mapping is an essential practice for uncovering inefficiencies and enhancing the delivery of customer value across organizational teams.
- Incremental improvements often yield significant results; targeted experiments can drastically reduce lead times with minimal investment.
- Collaboration among cross-functional teams is vital, as disjointed silos can obscure critical insights and solutions.
- Establishing a dedicated transformation team helps organizations navigate the conflicts between existing operational norms and new agile methodologies.
ch07How to Design Our Organization and Architecture with Conway’s Law in Mind
This chapter argues that the organizational structure and architecture must align to enhance software development effectiveness, underlining the principles of Conway's Law which states that the design of systems reflects the communication structures of organizations.
- The way we organize our teams is intrinsically linked to the effectiveness of the systems we develop, as posited by Conway's Law.
- Tightly coupled architectures that require extensive inter-team communication can lead to system failures and inefficiencies.
- Empowering teams means eliminating bureaucratic dependencies, allowing for quicker changes and higher stability.
- Market-oriented organizations have a distinct advantage in speed and responsiveness by embedding cross-functional skills directly into teams.
ch08HOW TO GET GREAT OUTCOMES BY INTEGRATING OPERATIONS INTO THE DAILY WORK OF DEVELOPMENT
This chapter argues that integrating Operations into Development teams enhances productivity and leads to user-oriented outcomes, addressing the challenges of centralized Operations.
- Integrating Operations into Development workflows enhances team productivity and speeds up delivery times.
- Centralized Operations can create bottlenecks; embedding Ops engineers into Development or assigning liaisons alleviates this constraint.
- Self-service capabilities empower Development teams, allowing them to manage infrastructure without excessive waits.
- The Ops liaison model fosters better communication, understanding, and prioritization between Development and Ops.
ch09CREATE THE FOUNDATIONS OF OUR DEPLOYMENT PIPELINE
In this chapter, the author argues that establishing production-like environments throughout the development and operations value stream is crucial for reducing deployment risks and improving software delivery performance.
- Automating the creation of environments allows for a dramatic reduction in deployment delays, shifting the lead time from weeks to mere days.
- A single source of truth provided by comprehensive version control is necessary for translating development efforts into production-ready outcomes.
- Transitioning to a disposable infrastructure mindset eliminates significant risks associated with manual interventions and outdated configurations.
- Ensuring that code can run successfully in production-like environments during development is essential for minimizing release-time defects.
ch10ENABLE FAST AND RELIABLE AUTOMATED TESTING
This chapter addresses the critical need for automated testing within fast-paced development environments, emphasizing how structured testing processes can prevent costly errors and enhance software productivity.
- Fast and reliable automated testing is crucial to maintaining the quality and integrity of software in a fast-paced development environment.
- The deployment pipeline must be an integral part of the development process, ensuring that code changes remain in a deployable state.
- A culture prioritizing rapid feedback and error resolution is essential for high-performing teams; halting new work during failures is a best practice.
- Collaboration across development, QA, and business teams can enhance the effectiveness and relevance of automated testing efforts.
ch11ENABLE AND PRACTICE CONTINUOUS INTEGRATION
This chapter argues for the necessity of continuous integration (CI) in software development to prevent integration difficulties among multiple code branches, positing it as essential for elevating productivity and innovation.
- Continuous integration is essential for managing the complexity that arises in large development teams and codebases, simplifying the integration process.
- Smaller batch sizes lead to increased integration efficiency and allow teams to identify and rectify issues faster.
- Daily commits to a common trunk transform the development workflow, fostering collaboration and reducing the reliance on isolated branches.
- Gated commits enhance code quality by preventing broken code from entering the trunk, ensuring stability throughout the development cycle.
ch12AUTOMATE AND ENABLE LOW-RISK RELEASES
This chapter argues for the necessity of automating deployment processes to reduce risks and enhance the reliability and frequency of software releases.
- Automating the deployment process transforms what is traditionally a high-risk, stressful event into a routine activity within the software development cycle.
- Organizations like Facebook have successfully increased their deployment frequency by adopting continuous integration and automated testing practices.
- The shift from manual, tedious deployments to automated processes is key to reducing errors and improving overall software release quality.
- Empowering developers to self-deploy increases accountability and accelerates feedback on the functionality of new code in production.
ch13ARCHITECT FOR LOW-RISK RELEASES
This chapter addresses the architectural evolution necessary for organizations to facilitate safe and effective changes in software development, emphasizing the significance of transitioning from tightly coupled systems to more loosely coupled architectures.
- Evolutionary architecture is critical for organizations seeking to enable rapid changes without compromising system integrity or developer productivity.
- The Strangler Fig application pattern offers a practical framework for progressively decoupling legacy systems, allowing teams to innovate safely amidst necessary transformations.
- Organizations like Amazon demonstrate that transitioning to a service-oriented architecture enhances autonomy and improves deploy frequencies, which is crucial for competitive agility.
- Designing loosely coupled architectures is essential for maximizing developer productivity, as it allows small teams to execute changes independently and efficiently.
ch14Create Telemetry to Enable Seeing and Solving Problems
In order to effectively diagnose and resolve issues in complex systems, organizations must implement robust telemetry frameworks that enable real-time monitoring and data analysis.
- High-performing organizations utilize telemetry to diagnose issues efficiently, resulting in 168 times faster resolution of production incidents.
- A culture of causality enhances understanding of incident causes, fostering swift and informed responses.
- Automated telemetry collection is crucial for real-time insight into application performance and health.
- Developers should be empowered to instrument their applications easily, transforming telemetry into a natural part of their workflow.
ch15Analyze Telemetry to Better Anticipate Problems and Achieve Goals
This chapter explores how analyzing telemetry through various statistical techniques enables organizations to proactively identify and address system issues before they affect customers, thus enhancing service delivery and operational efficiency.
- The ability to analyze telemetry data effectively can lead to significant reductions in service disruptions and improved customer experiences.
- Implementing outlier detection techniques can enable organizations to autonomously kick problematic nodes from production, preserving overall service quality.
- Alert fatigue can cripple operational efficiency; hence, refining alert strategies to focus on actionable variances is critical.
- Non-Gaussian data sets require unique statistical approaches; traditional methods like standard deviations may not suffice in these cases.
ch16Enable Feedback So Development and Operations Can Safely Deploy Code
This chapter explores how integrating feedback mechanisms into Development and Operations can alleviate fears associated with code deployment, enhancing both safety and productivity.
- Emphasizing feedback during code deployment can significantly reduce the fear associated with production changes.
- Smaller batch sizes and more frequent deployments lead to greater stability and success in production environments.
- Developers who engage in operational responsibilities develop better empathy and accountability for their code.
- Integrating telemetry into deployment processes is crucial for proactive problem detection and resolution.
ch17Integrate Hypothesis-Driven Development and A/B Testing into Our Daily Work
In a landscape where developers often build features without validating if they meet business goals, this chapter advocates for integrating hypothesis-driven development and A/B testing to drive better product decisions and outcomes.
- Integrating hypothesis-driven development into your process can prevent the waste of resources on ineffective features.
- A/B testing reveals that up to two-thirds of newly developed features could provide negligible value, emphasizing the need for user research.
- Speed in experimentation correlates with the ability to outlearn and outdo competitors in a dynamic market environment.
- Establishing a culture of rapid experimentation is key to fostering innovation and improving team morale.
ch18Create Review and Coordination Processes to Increase Quality of Our Current Work
This chapter argues for the urgent need to shift from traditional, bureaucratic change approval processes to agile, peer-driven review mechanisms that enhance production quality and reduce change-related risks in tech environments.
- Organizations must transition from bureaucratic approval processes to agile, peer-driven reviews to foster faster software delivery.
- Pre-deployment inspections and approvals often create friction and slow down the development cycle; integration into daily work is crucial.
- GitHub's pull request model showcases a successful method for incorporating continuous feedback and quality assurance without excessive delays.
- The Knight Capital incident exemplifies the catastrophic consequences of ineffective change management practices.
ch19Enable and Inject Learning into Daily Work
The chapter argues that the integration of learning into everyday work processes is essential for handling complexity and unpredictability in organizations, proposing systematic ways to turn failures into opportunities for growth.
- A resilient organization continuously learns from its failures, turning them into opportunities for improvement rather than sources of shame.
- Implementing a just culture fosters open dialogue about mistakes, enabling organizations to enhance safety and learning.
- Chaos engineering and controlled experiments can significantly improve operational resilience in complex systems.
- Retrospectives serve not only to address past failures but as critical tools for future learning and ongoing organizational development.
ch20Convert Local Discoveries into Global Improvements
This chapter discusses mechanisms for transforming localized learning and improvements within organizations into globally applicable knowledge, which can reinforce collective practices and efficiencies.
- Instituting mechanisms for capturing local learning transforms individual insights into a collective organizational asset.
- When knowledge is automated and easily shared, organizations can both increase their resilience and enhance performance.
- The choice of tools and platforms fundamentally affects how knowledge flows within an organization—centralization fosters efficiency.
- The development of communities of practice can accelerate propagation of learnings and innovations across teams.
ch21Reserve Time to Create Organizational Learning and Improvement
This chapter emphasizes the critical importance of allocating time for dedicated improvement efforts within organizations, showcasing various methods such as improvement blitzes to foster ongoing learning and innovation.
- Improvement blitzes are essential tools that empower team members to address pressing challenges collaboratively.
- Organizations that prioritize dedicated time for improvement experience significant boosts in operational efficiency and morale.
- A culture of continuous learning fosters a sense of pride and ownership, enabling teams to innovate and solve problems proactively.
ch22Information Security is Everyone’s Job Every Day
This chapter argues that integrating information security into the DevOps process is essential for ensuring safety and compliance while fostering productivity among development and operations teams.
- Security must be everyone’s job, integrated into the daily rhythms of software development and operations.
- The conventional view of security as a blocker should give way to a collaborative model where security is a shared responsibility among all team members.
- Delaying security conversations until the end of a project significantly increases costs and risks.
- “Compliance by demonstration” can streamline the integration of security measures, making them a natural part of the development process.
ch23Integrate Information Security into the Daily Work of Development and Operations
Integrating information security into the ongoing processes of development and operations not only mitigates risks but also enhances productivity and ensures compliance within fast-paced environments.
- Integrating Infosec into DevOps workflows enhances both security posture and operational efficiency.
- Visibility of security issues within project management tools enables quicker prioritization and resolution.
- Successful organizations leverage automated testing within deployment pipelines to detect vulnerabilities in real time.
- Establishing shared security libraries helps developers adhere to security standards effortlessly.
ch24Protecting the Deployment Pipeline
This chapter explores the critical methods for securing deployment pipelines while balancing the necessities of rapid change management and compliance with security objectives.
ch25Conclusion
This chapter reinforces the integration of DevOps principles into Information Security, asserting that better security practices must be a collective responsibility throughout an organization.
- Security is not just the responsibility of a single team; it must be woven into the fabric of every role within the organization.
- Embedding security within the DevOps processes leads to better protection of data and systems.
- The shift from viewing security as a compliance issue to an ethical collective responsibility is essential.
- Collaboration among development, operations, and security is key to effective risk management.
ch26A Call to Action: Conclusion to The DevOps Handbook
This chapter emphasizes the imperative of adopting DevOps principles to overcome the chronic conflict between Development and Operations, ultimately transforming organizations into dynamic learning entities that excel in the marketplace.
- DevOps serves as a crucial mechanism for dismantling the inherent conflicts between Development and Operations, speeding up product delivery and enhancing quality.
- Cultural and technical shifts are necessary; effective change requires collaboration across multiple organizational functions, including Product Management, IT Operations, and Marketing.
- DevOps not only benefits organizational performance but enhances employee satisfaction by creating a more humane working environment.
- Ignoring the call for a DevOps transformation could result in long-term stagnation and competitive disadvantage in a rapidly evolving landscape.
ch27p01Afterword to the Second Edition (part 1/2)
The Afterword underscores the importance of sustainable productivity and performance in software development, emphasizing that true improvement requires a multi-dimensional understanding of productivity beyond mere activity metrics.
- Productivity in software development is complex and must be measured more holistically beyond simplistic metrics.
- The SPACE framework provides a multi-faceted approach to understanding developer productivity.
- Organizations that prioritize developer well-being alongside performance metrics will see more sustainable improvements.
- High activity levels may mask underlying exhaustion and systemic issues, leading to short-term gains without long-term sustainability.
ch27p02Afterword to the Second Edition (part 2/2)
The Afterword emphasizes the evolution of the DevOps movement and its crucial role in shaping modern software development practices, underscoring its relevance as organizations navigate ongoing technological changes.
- DevOps is not a fleeting trend; it is an essential movement for modernizing the software delivery process.
- The continuous delivery pipeline is a transformative approach that necessitates new cultural norms and operational frameworks.
- Organizations that adopt DevOps principles consistently outperform their counterparts in speed, reliability, and innovation potential.
- Metrics beyond velocity, including quality and developer happiness, are crucial for holistic organizational performance.
Questions this book answers
- How do we break the core chronic conflict between Development and Operations that creates a downward spiral of slow delivery, poor quality, and burnout?
- What principles and practices enable small teams to deploy safely and frequently while maintaining stability, security, and compliance?
- How do we create fast feedback loops at every stage of the value stream so problems are found and fixed when they are small and cheap?
- How do we build a generative, high-trust learning culture that turns failures into organizational knowledge?
- How do we integrate security and compliance into daily work rather than treating them as end-of-project gates?
Related in the library
- The Phoenix Projectshared: Systems
- Accelerate The Science of DevOpsshared: Systems
- Lib1a8e30089d691487
- Bootstrapping Microservices, Second Edition (MEAP) With Docker, Kubernetes, GitHub Actions, and Terraformshared: Systems
- Bootstrapping Microservices, Second Edition With Docker, Kubernetes, GitHub Actions, and Terraformshared: Systems
- Microservices Patternsshared: Systems
Tools these methods power