DevOps Foundations

Executive summary

Software delivery has a recurring failure mode: changes are slow to reach production, risky when they arrive, and followed by blame when they break. The usual cause is a boundary between the people who build software and the people who operate it, with work handed across that boundary in large batches and little feedback returning. DevOps, a contraction of development and operations, is the response: a set of principles and practices that make delivery a continuous, shared flow rather than a sequence of handoffs.

The discipline rests on a small number of ideas that do not change with the size of the organization. Work moves in small batches along a value stream that everyone can see. Feedback returns quickly from production to the people who made the change. Teams own what they build, express their systems and environments as code, and treat failure as a source of learning rather than punishment. What changes with size is the implementation, not the principles.

• DevOps is principles and practices, not a role or a product, and it removes handoffs between building and operating software.
• Three ideas carry it: fast flow to production, fast feedback back, and continual learning.
• Three size bands, small, medium and large, are a convention for applying each practice at the right weight, not a maturity ladder.
• Delivery is measured with DORA's five software delivery metrics and reliability with service level objectives, read as trends and never as targets.
• Culture, team design and governance decide whether the practices hold, and adoption proceeds one constraint at a time.

The sections that follow define the terms, principles, value stream, practices, metrics, culture and governance that reliable delivery rests on, and close with a staged path that a team of any size can begin.

Why DevOps, and why size matters

Delivery that is slow, risky and prone to blame is rarely a problem of effort; it is a problem of flow, and flow is what DevOps sets out to improve.

In many organizations, software moves from development to operations across a wall. Developers write code and consider their work done when it is merged; a separate operations group deploys it, keeps it running and is paged when it fails. Work crosses the wall in large batches, at the end of long cycles, with little feedback returning. The result is familiar: releases are infrequent and tense, failures are hard to trace, and each side blames the other.

DevOps removes the wall. The term, generally credited to Patrick Debois, who organized the first devopsdays conference, names a set of principles and practices that make building and running software one continuous, shared activity. A single team, or a few closely cooperating teams, take a change from idea to production and remain responsible for it there. DevOps is therefore not a role to hire, a team to stand up beside the others, or a product to purchase.

DevOps defined

A working definition is useful. DevOps is the combination of cultural norms, practices and tools that shortens the time from a committed change to that change running safely in production, while improving the reliability of what is already there. The emphasis on both delivery and reliability matters: speed without stability produces outages, and stability without speed produces stagnation. The practices in this paper pursue both at once, because in a well-run system they reinforce rather than oppose each other.

Three size bands

Organizations differ enormously in scale, and advice that suits a two-person startup can sink a bank. This paper therefore reads every practice through three size bands, adopted as a convention rather than as empirical categories. The bands describe the shape of an organization's delivery, not its revenue or headcount, and many enterprises contain all three at once in different parts of the estate.

The bands are a lens, not a ladder. A small system is not an immature large one, and growth is not the goal; a product served well by one team should stay there. The purpose of the lens is to ask, for each practice, what it looks like when there is no platform team and the same people carry the pager, what it looks like when a platform is forming, and what it looks like under formal audit. The section on what changes with scale collects the answers in one table.

Principles: flow, feedback and learning

Practices change with technology; principles change slowly. Gene Kim described the principles from which DevOps practices can be derived as the Three Ways, a model developed at length in The Phoenix Project and The DevOps Handbook. It is worth stating plainly, because every later practice in this paper serves one of the three.

The Three Ways

The First Way is flow, or systems thinking: work moves smoothly from left to right, from idea through development to the customer, and the performance of the whole value stream matters more than the performance of any single team or step. The Second Way is feedback: information flows quickly from right to left and is amplified, so that problems are seen and corrected close to where they arise and quality is built in at the source. The Third Way is a culture of continual experimentation and learning: the organization treats daily work as a chance to improve the system that produces it, takes deliberate and bounded risks, and rehearses and absorbs failure instead of hiding it.

Flow depends on small batches. A large change is hard to review, hard to test and hard to diagnose when it fails, and it waits behind other large changes. Small changes move faster, fail more cheaply and make the cause of a failure obvious. Working in small batches is the single habit that most improves flow, and it is why trunk-based development, continuous integration and frequent deployment appear together throughout this paper.

Ownership, everything as code and shifting left

Two further principles recur. Teams own what they build, carrying responsibility through to production and operation, because the people who feel the consequences of a design are the people most able to improve it. And as much of the system as possible is expressed as code: application, tests, configuration, infrastructure and the pipeline itself, all version-controlled, reviewed and reproducible. Expressing work as code is what lets feedback be fast and change be safe.

A final idea, shifting left, places quality and security activities as early in the stream as possible rather than at the end. Testing, review and security checks that run on every change catch defects when they are cheapest to fix and keep them from reaching production. Shifting left is not extra work added at the start; it is the same work moved to where it costs less.

CALMS: a second lens

Another widely used summary of DevOps is CALMS: culture, automation, lean, measurement and sharing. John Willis and Damon Edwards proposed the original CAMS model, and Jez Humble added lean to it. The two lenses agree. The Three Ways describe how work and information should move; CALMS names the capabilities an organization needs for them to move that way, and it makes a useful checklist when an adoption seems to be stalling for reasons that tooling cannot explain.

The delivery value stream

A change spends far more of its life waiting than being worked on, so improving delivery is mostly a matter of finding and removing the waiting.

DevOps improves a specific thing: the value stream that carries an idea to running, observed software. A value stream is the sequence of steps, people and systems a change passes through, from the moment work begins to the moment a customer benefits. Making that stream visible is the first step to improving it, because most delay hides in the gaps between steps rather than in the steps themselves.

Mapping the stream

Value stream mapping draws each step, the work done in it and the handoffs between steps. Three measures are commonly recorded for each step, following Karen Martin and Mike Osterling's treatment of the method, which The DevOps Handbook also uses. Process time is how long the work itself takes if it can be done without interruption. Lead time is how long an item takes to get through the step, including the time it spends waiting in a queue. Percent complete and accurate is the share of the time the next step can use the output as received, without correcting it, adding missing information or asking for clarification. The ratio of total process time to total lead time, sometimes called the activity ratio or flow efficiency, shows how much of an item's life is spent being worked on.

In this illustration, a change is worked on for under four hours and waits for eleven days, and fewer than half of changes pass every step without being sent back. The map points straight at the constraints: the approval queue and the shared environment, not the speed of the engineers. Note that this end-to-end lead time, from the start of work to its delivery, is longer than the change lead time DORA measures, which starts when a change is committed; both are useful, and they answer different questions.

Queues, work in progress and handoffs

Delay comes mostly from queues and handoffs, not from slow work. Every handoff loses context and adds waiting, and every item in progress competes for attention with every other. Limiting work in progress, so that fewer items are open at once, speeds the whole, because items finish instead of aging. Little's law, from queueing theory, makes the relationship exact for a stable system: average lead time equals average work in progress divided by average throughput. A team that finishes five items a week with twenty in progress should expect each item to take about four weeks; halving the work in progress halves the wait without anyone working faster.

A handoff that can be removed, by giving a team the ability to do for itself what it used to request, removes a queue with it. The bottleneck sits in different places by size band. In a small system it is often a manual step that one person performs, such as a release done by hand. In a medium system it is commonly the shared environment or the ticket queue to another team. In a large system it is frequently the change approval process and the coordination across many teams. Finding the one constraint that limits the stream, and improving it before anything else, is the heart of the method, an idea drawn from Eliyahu Goldratt's theory of constraints.

Technical practices at a glance

A handful of technical practices carry the principles into daily work. Each removes a specific source of delay or risk, and none delivers its full value alone. This section introduces them in one place.

Version control for everything is the base. Application code, tests, configuration, infrastructure definitions and pipeline definitions all live in version control, giving every change a history, an author and a review. Trunk-based development keeps changes small and integrated: developers work in short-lived branches, typically lasting hours and at most a day or two, and merge to a shared trunk frequently, avoiding the painful, risky merges that long-lived branches accumulate. These two practices are the foundation on which the rest stand.

Continuous integration (CI) builds and tests every change against the trunk automatically, so that integration problems surface within minutes rather than at the end of a cycle. Automated testing gives CI something to assert: fast unit tests, service tests and a thin layer of end-to-end tests that together let a change be trusted without manual regression. Continuous delivery (CD) extends this by keeping the trunk always releasable and automating the path to production, so that releasing becomes a routine, low-drama event and a business decision rather than a technical project. Continuous deployment goes one step further, releasing every change that passes the pipeline automatically.

Infrastructure as code (IaC) defines servers, networks and environments in version-controlled files that are applied automatically, replacing hand-built, unreproducible systems, and it is the basis of most platform engineering. Observability makes a running system explain itself through logs, metrics and traces, so that operators diagnose problems from evidence rather than guesswork. Incident learning turns every failure into a durable improvement through blameless review.

The practices depend on one another, which is why they should be adopted as a set rather than picked from a menu. Continuous integration without automated tests asserts nothing. Continuous delivery without infrastructure as code stalls on environments that cannot be reproduced. Frequent deployment without observability raises risk, because failures arrive faster than anyone can see them. And none of it survives a culture that punishes the people who report failure.

Measuring delivery and operations

What gets measured shapes what gets done, so the choice of metrics is itself a design decision. DevOps measurement favors a few indicators that reflect the outcomes that matter, delivery throughput and operational stability, over many that reflect activity. The research program known as DevOps Research and Assessment (DORA), not to be confused with the EU Digital Operational Resilience Act that shares its acronym, introduced the best-known set: four key metrics, described in the book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim and refined through DORA's annual research reports.

DORA's software delivery metrics

The model has evolved from the original four keys. DORA renamed time to restore service as failed deployment recovery time and narrowed it to failures caused by a deployment, so that outages with external causes, such as the loss of a data center, no longer distort a measure of delivery. It then added a fifth metric, deployment rework rate, to test whether change fail rate was standing in for the amount of rework a team performs. The five metrics fall into two groups.

Three measure throughput: change lead time, from a commit to that change running in production; deployment frequency; and failed deployment recovery time. Two measure instability: change fail rate, the share of deployments that need immediate intervention such as a rollback or a hotfix, and deployment rework rate, the share of deployments that were not planned but happened because of an incident in production. The table below defines each, with where its data comes from and how it is most often distorted. Read together, the measures resist the usual trade-off between speed and safety: DORA's research has consistently found that the strongest performers do well on throughput and stability at the same time.

Reliability and the operational view

Reliability is the operational counterpart to the delivery metrics: whether the service actually meets the expectations its users depend on, expressed as service level objectives (SLOs) on measured indicators such as availability and latency. DORA treats reliability as a measure of operational performance rather than as another delivery metric, and the distinction is worth keeping: delivery metrics describe how changes move, reliability describes what users experience.

All of these can be instrumented from systems the organization already runs. Change lead time and deployment frequency come from version control and the pipeline. Change fail rate, rework rate and recovery time come from deployment, incident and monitoring records, provided that deployments and incidents are linked. The data is a by-product of delivery, not a separate reporting burden, and a team of any size can start by reading a few of the measures by hand.

Developer productivity and the SPACE framework

Delivery metrics describe the system, not the people, and they should never be used to rank individuals. For the broader question of developer productivity, the SPACE framework, published by Nicole Forsgren and colleagues, offers a more honest frame. It names five dimensions (satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow) and argues that productivity cannot be captured by any single one. Activity counts, such as commits or lines of code, are the most misleading when used alone, and the authors recommend combining measures from several dimensions, including what developers themselves report, rather than relying on system data alone.

Culture, teams and organization

Practices and tools are necessary but not sufficient; culture decides whether they take hold. The question is how an organization handles information, especially bad news, because fast feedback is useless if people are afraid to send it.

Generative culture

The sociologist Ron Westrum described three organizational cultures by how they treat information. A pathological culture is oriented to power: it hoards information and punishes the messenger. A bureaucratic culture is oriented to rules: it routes information through departments and procedures. A generative culture is oriented to performance: it actively seeks information and uses it to improve. DORA's research has repeatedly linked generative culture to better software delivery and organizational performance, because information flows to where it is needed, failures are surfaced early, and ideas are tried rather than blocked.

Building a generative culture is largely a matter of how leaders respond when something goes wrong. Blameless postmortems are its practical expression. After an incident, the people involved reconstruct what happened and why, on the assumption that everyone acted reasonably given what they knew at the time, and the output is improvements to the system rather than names to blame. This depends on psychological safety: the shared belief that speaking up about a mistake or a risk will not be punished. Without it, incidents are hidden, the same failures recur, and the feedback loop on which the Second Way depends is broken.

Conway's law and Team Topologies

Organization shapes architecture. Conway's law, from Melvin Conway's paper How Do Committees Invent?, observes that a system's design tends to mirror the communication structure of the organization that built it. Teams that cannot easily communicate will build systems that integrate poorly, so team boundaries should be drawn deliberately to match the architecture wanted, a move often called the inverse Conway maneuver.

Team Topologies, by Matthew Skelton and Manuel Pais, gives a vocabulary for drawing those boundaries, with the team's cognitive load as the main design constraint. It names four fundamental team types. Stream-aligned teams own a flow of work for a product, service or segment of the business end to end. Platform teams provide internal services, run as products, that reduce the load on stream-aligned teams. Enabling teams help other teams acquire missing capabilities for a time. Complicated-subsystem teams own parts that need rare, deep expertise. The types interact in three modes: collaboration, working closely together for a defined period to discover something new; X-as-a-Service, consuming something another team provides with minimal coordination; and facilitating, one team helping and coaching another.

Team structure changes with band. In a small system a single stream-aligned team does everything, including its own platform work. In a medium system an enabling or nascent platform team begins to form as the number of teams grows. In a large system a dedicated platform organization provides paved paths to many stream-aligned teams. The aim at every size is the same: keep the stream-aligned teams able to deliver with as little waiting on others as possible, and use the interaction modes deliberately, so that a collaboration meant to last a quarter does not quietly become a permanent dependency.

What changes with scale

The constants are the principles and the practices that implement them; the variables are the structures and controls around them. The table below separates the two.

Some things hold at every size, and letting them lapse as an organization grows is a common and costly mistake. The principles of flow, feedback and learning do not scale away. Trunk-based development and continuous integration remain correct whether there are two developers or two thousand. Automated testing is as necessary for a small team as for a large one. And the delivery and operations metrics are read as trends at every size.

Other things legitimately change. A small team owns its whole pipeline directly; a large one consumes a pipeline as a service from a platform team, using a paved path. Environments move from one or two manual setups to many codified ones. Change control moves from informal peer review to standard, pre-authorized changes and then to formal, audited change enablement. On-call moves from everyone on best effort to defined rotations with service level objectives. Specialization increases: roles that one person holds in a small system become whole teams in a large one.

The error in both directions is to confuse the two. Imposing large-organization change control on a small team adds cost without reducing risk. Running a large estate with small-team informality invites the failures that formal controls exist to prevent. The size lens is a reminder to apply each practice at the weight the system actually needs, and to revisit that judgment as the system moves between bands.

Governance, compliance and DevOps

Governance and DevOps are often seen as opponents: one demands control, the other speed. In a well-designed pipeline they are the same thing, because the controls auditors want are produced automatically by the practices that make delivery fast.

Separation of duties without handoffs

Traditional control separates duties by having one person perform a change and another approve it, usually in a separate team and a separate step. The same separation is achieved in a pipeline without a handoff: peer review requires that a change be approved by someone other than its author, and automated gates enforce rules no person needs to check by hand. The reviewer and the gate are the control, and both run inside the flow rather than beside it. Direct access to production is reserved for break-glass situations, and its use is itself recorded and reviewed.

A pipeline also produces audit evidence as a by-product. Every change carries a record of who wrote it, who approved it, which tests and scans ran and passed, and when and where it was deployed. This record is more complete and more trustworthy than evidence assembled by hand after the fact, because it is generated by the system that did the work and cannot be back-filled. Asked to show that a change was reviewed and tested, a team built this way answers with a query, not a scramble. A simplified deployment record might look like this:

{
  "service": "orders-api",
  "version": "4.18.2",
  "commit": "9f2c1e7",
  "author": "developer-a",
  "approved_by": ["developer-b"],
  "pipeline_run": 48213,
  "checks": {
    "unit_tests": "passed",
    "acceptance_tests": "passed",
    "dependency_scan": "passed"
  },
  "change_type": "standard",
  "deployed_to": "production",
  "deployed_by": "pipeline"
}

Standards and regulated change

Established frameworks map onto these practices. ITIL, the widely used IT service management framework whose name originated as the Information Technology Infrastructure Library, replaced heavyweight change management with change enablement in ITIL 4 and provides for standard changes: low-risk, pre-authorized changes that follow a known procedure and need no separate approval each time. A mature pipeline is exactly the mechanism that makes a class of changes standard, because it enforces the same tests, reviews and checks on every change that passes through it. For security, the Secure Software Development Framework (SSDF), published by the National Institute of Standards and Technology (NIST) as Special Publication 800-218, describes practices for building software securely, many of which a pipeline can enforce and evidence directly.

The weight of governance follows the size band. A small regulated team may satisfy its obligations with peer review, an automated gate and the pipeline's own records. A large organization adds formal change advisory for the riskiest changes, segregated environments and retained evidence across hundreds of services. In both, the principle is constant: the control lives in the pipeline, and compliance is demonstrated from what the pipeline already records. Whether a particular obligation applies to a given organization is a question for its own risk and compliance partners.

Starting and sustaining the change

No organization adopts DevOps all at once; the ones that succeed start small, improve the constraint that matters, and spread what works.

Adoption begins with the value stream, not the tools. Mapping how a change actually reaches production, with its queues and handoffs, shows where the delay really is and gives a baseline to improve against. From that map, the first target is the single constraint that most limits flow, because improving anything else leaves the whole unchanged.

A path that sustains itself

A durable adoption follows a recognizable path. Assess the value stream and make its delay visible. Pick a pilot: one team and one service where a win is achievable and instructive. Make the work visible on a board so that queues and blockers are seen by everyone, including the people who can remove them. Improve one constraint at a time, measure the effect and move to the next. Then expand, not by decree, but by having an enabling team carry the proven practices to the next stream, and by sharing what the pilot learned, failures included. Each step produces evidence that funds the next.

Anti-patterns to avoid

Adoption fails in predictable ways, and naming the failures helps a review catch them early. The most common is to create a DevOps team as a new group between development and operations, which adds a handoff instead of removing one. Close behind is tool-first adoption, buying a pipeline or a platform before changing how work flows, so that the old process runs on new tools. Big-bang reorganizations disrupt delivery while teaching little, and renaming the operations team without changing ownership, feedback or automation changes nothing at all.

The thread through the anti-patterns is that structure and tools are downstream of flow. A reorganization or a purchase that is not driven by a specific constraint in the value stream tends to add motion without progress. Sustaining the change means returning to the stream repeatedly, finding the next constraint and improving it, so that improvement becomes a habit of the organization rather than a one-time project.

Pitfalls and a maturity path

The failures of DevOps adoption are repetitive, and most invert a principle from the earlier sections. They are collected here so that a review can check for each, with the remedy beside it.

A maturity path

No team arrives at all of this at once. A staged path puts first the practices that are expensive to retrofit and defers the rest until scale justifies them.

1. Foundations. Everything in version control, trunk-based development, continuous integration with automated tests, and a culture that reviews failure without blame.
2. Continuous delivery. A pipeline that keeps the trunk releasable, automates the path to production and deploys small changes routinely, with basic delivery metrics read from it.
3. Operate what you deliver. Infrastructure as code, observability, service level objectives and blameless incident management, so that teams own their services in production.
4. Scale and govern. Platform and enabling teams, paved paths, change enablement with standard changes, and metrics read as trends across the organization, applied at the weight each system needs.

Conclusion

DevOps is not a tool, a team or a title; it is a set of principles and the practices that carry them into daily work. Work flows in small batches along a value stream everyone can see, feedback reaches the people who made a change quickly, and teams own what they build, express it as code and learn from failure without blame. These ideas do not change with the size of the organization, and letting them lapse in the name of control or speed is the recurring source of trouble.

What changes with scale is the implementation: the team structures, the platforms, the degree of formal change control and the way metrics are gathered. A small team and a large enterprise run the same principles at different weights, and the size lens is the reminder to choose the right weight and to revisit it as a system grows. The practical next step is the same for both: map how one change reaches production, find the constraint that holds it back, and improve that first. The principles in this paper extend naturally into continuous integration and delivery, infrastructure as code and platform engineering, security in the pipeline, observability and incident management, and the governance of delivery at scale.

Glossary

DevOps

The combination of principles, practices and culture that joins building and operating software into one continuous, shared flow.

The Three Ways

Gene Kim's principles of flow, feedback, and continual experimentation and learning, developed in The Phoenix Project and The DevOps Handbook.

CALMS

A summary of DevOps capabilities: culture, automation, lean, measurement and sharing.

Value stream

The sequence of steps, people and systems a change passes through from idea to running, observed software.

Process time

The time the work in a step takes if it can be done without interruption.

Lead time (value stream)

The time an item takes to pass through a step or a whole stream, including time spent waiting.

Percent complete and accurate

The share of the time a step's output can be used by the next step without correction, addition or clarification.

Work in progress (WIP)

The number of items started but not finished; limiting it shortens lead time.

Trunk-based development

Merging small changes to a shared trunk frequently, from branches that live hours or a day or two, avoiding long-lived branches.

Continuous integration (CI)

Building and automatically testing every change against a shared trunk so that integration problems surface early.

Continuous delivery (CD)

Keeping software always in a releasable state and automating the path to production so that releasing is routine and low-risk.

Continuous deployment

Automatically releasing to production every change that passes the pipeline.

Infrastructure as code (IaC)

Defining infrastructure in version-controlled files that are applied automatically, making environments reproducible.

Change lead time

The time a change takes to go from commit to running in production.

Deployment frequency

The number of deployments in a period, or the time between deployments.

Failed deployment recovery time

The time it takes to recover from a deployment that fails and needs immediate intervention.

Change fail rate

The share of deployments that need immediate intervention, such as a rollback or a hotfix.

Deployment rework rate

The share of deployments that are unplanned and happen because of an incident in production.

Service level objective (SLO)

A target for a measured indicator of a service's behavior, such as availability or latency, over a window of time.

Generative culture

In Westrum's typology, a performance-oriented culture that actively seeks and shares information to improve.

Blameless postmortem

An incident review that seeks system improvements rather than individuals to blame.

Stream-aligned team

In Team Topologies, a team that owns a flow of work for a product, service or business segment end to end.

Platform team

A team that provides internal services, run as products, that reduce the load on stream-aligned teams.

Standard change

A low-risk, pre-authorized change that follows a known procedure and needs no separate approval each time.