DOF key terms

A collaborative approach to building and delivering software that unites development and operations teams around shared goals, automation, and rapid feedback so organizations can release reliable changes more frequently.

A framework for assessing DevOps adoption across five areas: Culture, Automation, Lean, Measurement, and Sharing. It emphasizes that tools alone are insufficient and that people and process change matter equally.

A set of DevOps principles describing flow from development to operations, fast feedback loops back to development, and a culture of continual experimentation and learning.

The sequence of activities, people, and systems required to turn a customer request into delivered value. Mapping it reveals delays, handoffs, and waste that slow software delivery.

A team climate in which people feel safe to speak up, admit mistakes, ask questions, and challenge ideas without fear of punishment or humiliation. It supports learning and honest problem solving.

A model classifying organizations by how they handle information: pathological (power-oriented), bureaucratic (rule-oriented), or generative (performance-oriented). Generative cultures share information well and are associated with better safety and innovation.

A group whose members collectively possess the skills needed to deliver a product or service end to end, reducing handoffs and dependencies on other teams.

A practice in which developers frequently merge small code changes into a shared mainline, with automated builds and tests run on each merge to detect integration problems early.

A practice that keeps software in a releasable state at all times by automating build, test, and release processes, so deployments can be performed quickly, safely, and on demand.

Automatically deploying eligible changes that pass the configured delivery checks to production, without a separate release-approval step. User exposure may still be managed with feature controls or rollout policies.

An automated sequence of stages that builds, tests, and prepares software for release. It provides fast feedback on quality and makes the delivery process repeatable and visible.

A version-control practice where developers integrate small changes frequently into a single shared branch, avoiding long-lived feature branches that cause merge conflicts and delay feedback.

A visual work-management method that limits work in progress and makes flow visible on a board, helping teams identify bottlenecks and deliver work steadily.

A cap on how many items may be in progress at a given stage of a workflow. It reduces multitasking and congestion, encouraging the team to finish work before starting more.

A technique for diagramming the steps, wait times, and handoffs in a value stream to expose waste and identify improvements that shorten delivery time.

Moving quality, security, and testing activities earlier in the software lifecycle so defects are found when they are cheaper and faster to fix.

Managing servers, networks, and other infrastructure through machine-readable configuration files that are versioned and applied automatically, rather than through manual setup.

The practice of defining and maintaining consistent settings for systems and applications, often through automated tools, so environments remain reproducible and drift is controlled.

A lightweight, isolated runtime package that bundles an application with its dependencies so it runs consistently across environments. Containers share the host operating system kernel.

Automated scheduling, deployment, scaling, and management of containers across a cluster of hosts, typically performed by a platform such as Kubernetes.

A configuration switch that enables or disables functionality at runtime without redeploying code, allowing controlled releases, experiments, and quick rollback.

A release technique using two identical environments, blue and green, where traffic is switched to the new version after validation, enabling fast rollback if problems appear.

A deployment strategy that exposes a small portion of users to a new version first, monitors behavior, and gradually expands traffic if the release performs well.

A system that records changes to files over time, allowing teams to collaborate, review history, and restore previous versions. It is foundational for code and infrastructure automation.

Using software tools to execute tests, compare results, and report outcomes without manual intervention, making repeated validation fast and consistent within delivery pipelines.

A versioned set of software-delivery performance measures. Current guidance uses deployment frequency, change lead time, failed-deployment recovery time, change fail rate and deployment rework rate; older materials often describe four keys.

The time from a code change being committed to it running in production. It measures how quickly work moves through the delivery process.

The frequency of production deployments measured for a defined service and window. Compare trends with context and other outcomes; a higher count alone does not prove customer value or reliability.

The percentage of production changes that cause degraded service and require remediation such as a hotfix or rollback. It reflects release quality and stability.

An average restoration-duration measure whose population and timestamps must be specified. The historical term is broader than current DORA’s failed-deployment recovery measure, so do not silently treat every incident population as equivalent.