DevOps Foundation 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 structured review after an incident that focuses on understanding contributing causes and improving systems rather than punishing individuals. It encourages honest reporting and helps prevent similar failures.

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.

An extension of continuous delivery in which every change that passes automated tests is released to production automatically, without a separate manual approval step.

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.

Four widely used delivery performance measures: deployment frequency, lead time for changes, change failure rate, and time to restore service. They balance speed with stability.

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

How often an organization successfully releases software to production. Higher frequency generally indicates smaller batches, smoother flow, and more reliable delivery.

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

The average time needed to recover service after an incident or failed change. Shorter restoration times reduce customer impact and indicate effective detection and response.

The ability to understand a system's internal state from its external outputs, such as logs, metrics, and traces, so teams can diagnose problems and verify behavior.

The amount of unreliability a service can tolerate within a period, derived from its service level objective. It gives teams a shared basis for balancing release speed and stability.

A target level of reliability for a service, such as availability or latency, expressed as a measurable goal over a period. It helps teams decide when to prioritize stability work.

A process in which information about the results of an action returns quickly to the people who can act on it, enabling them to correct course and improve outcomes.

A recurring team meeting where members reflect on recent work, identify what helped or hindered progress, and agree on small improvements to try next.

An ongoing effort to make small, incremental enhancements to processes, products, and practices by learning from results and feedback rather than waiting for large redesigns.

The practice of making information, skills, and context available across teams through documentation, pairing, communities, and open communication so knowledge does not remain siloed.

A collaboration approach that brings operational actions and notifications into team chat channels, making work visible and enabling shared, auditable responses to events.