EXIN DevOps Foundation key terms

A way of organizing IT work in which development and operations staff share responsibility for a product across its whole life, supported by automation, measurement and a culture of cooperation rather than handovers between separate teams.

The guiding ideas behind DevOps practice: flow of work from request to customer, feedback loops that inform the team, and a culture of continual experimentation and learning. They describe intent, while practices describe how the intent is carried out day to day.

A common summary of DevOps thinking: first, optimize the flow of work from development to operations and the customer; second, create fast, frequent feedback from right to left; third, foster continual experimentation and learning in the team.

The smooth, uninterrupted movement of work items through the delivery process. Good flow means short queues, small batches and few handoffs, so that work reaches the customer quickly instead of waiting between departments.

A mechanism that returns information about the effect of an action to the people who took it, quickly enough for them to act on it. In DevOps, automated tests, monitoring and user telemetry are typical loops that shorten the time to detect and correct problems.

The sequence of activities that takes a customer request from idea to delivered service, including waiting time. Mapping it exposes delays, rework and handoffs that add no value and shows where improvement will pay off most.

A workshop technique in which the people involved draw the steps, queues and decision points a work item passes through, then mark the time spent waiting versus working. The resulting map is used to choose improvements to flow.

The total elapsed time from the moment a customer raises a request until it is fulfilled. It includes all waiting, so it reflects the customer's experience and is a common measure of whether flow is improving.

The time a team actually spends on a work item from the moment it starts active work until it is done, excluding time spent waiting in a queue before work began. It is used to forecast how much work can be finished.

The number of work items a team or system completes in a given period, such as items per week. Combined with cycle time, it helps predict delivery and reveals whether changes to the process actually increased output.

A cap on how many items may be in a stage at once. Limiting work in progress reduces multitasking and queues, makes bottlenecks visible, and usually shortens the time each item takes to finish.

The amount of work released together, for example the number of changes in one deployment. Smaller batches reduce risk, make testing and rollback easier, and shorten the time before feedback arrives.

Shared norms in which people across development, operations and business roles trust each other, share goals and learn from failure instead of assigning blame. Culture is what makes tooling and process changes stick.

A structured review after an incident that focuses on how systems and processes allowed the failure, not on punishing individuals. The goal is honest reporting and concrete preventive actions that reduce repeat incidents.

An organization that treats experimentation as normal, treats failures as information, and deliberately spreads new knowledge. It invests in training, safe-to-fail trials and sharing results so improvement continues without external pressure.

A team whose members together hold all the skills needed to take a product from idea to running service, such as development, testing and operations knowledge. Such teams need fewer handoffs and can decide and act quickly.

A team given a clear goal and the authority to decide how to reach it, including technology choices and working methods. Autonomy speeds up decisions but must be paired with transparency about outcomes and alignment with business aims.

The arrangement in which the team that builds a service also operates and supports it, often called 'you build it, you run it'. Ownership creates direct feedback about quality and encourages designs that are easy to run.

A practice in which developers merge their work into a shared mainline frequently, and each merge triggers an automated build and test run. Problems surface within minutes rather than at a late integration phase.

A practice that keeps the product in a state where it could be released to users at any time. It relies on automated build, test and deployment pipelines, with the final decision to release left to people or policy.

An extension of continuous delivery in which every change that passes all automated checks is released to users without a manual approval step. It requires strong automated testing, monitoring and fast rollback capability.

A shorthand covering continuous integration and continuous delivery or deployment: the automated pipeline that builds, tests and releases changes. It is the technical backbone that lets teams release small changes often and safely.

An automated sequence of stages, such as build, unit test, integration test and release, that every change passes through. Each stage gives fast feedback, and a failure stops the change before it reaches users.

Using scripts and tools to check software behavior without manual effort, from unit tests to end-to-end checks. Automation makes frequent releases feasible because regression checks run in minutes and give consistent results.

A guideline for test portfolios: many fast unit tests at the base, fewer service or integration tests in the middle, and very few slow end-to-end tests at the top. It balances confidence against speed of feedback.

Managing servers, networks and other infrastructure through versioned definition files rather than manual configuration. It makes environments reproducible, reviewable and testable, and lets teams rebuild identical environments quickly.

The practice of defining and enforcing the desired state of systems and software settings automatically, so that environments stay consistent. Tools apply these definitions repeatedly and correct drift from the intended configuration.

A property of an operation that produces the same result whether run once or many times. Automated configuration and deployment steps should be idempotent so repeated runs are safe and do not create duplicated or altered state.

An approach in which servers or containers are never modified after deployment; changes are made by replacing them with newly built versions. This removes configuration drift and makes rollback a matter of switching back to a previous image.

A lightweight, isolated unit that packages an application with its dependencies and runs consistently across environments. Containers support immutable deployment patterns and are commonly orchestrated by tools such as Kubernetes.

An architectural style that splits a system into small, independently deployable services communicating over networks. It allows teams to release separately, but adds complexity in monitoring, testing and handling failures between services.

A system that records changes to files over time so any earlier state can be recovered and changes can be merged and reviewed. It is the shared source of truth for code, configuration and infrastructure definitions.

A branching approach in which developers integrate small changes into a single shared mainline at least daily, using short-lived branches if any. It avoids long-lived branches and the painful merges that delay integration.

A configuration switch that turns a feature on or off at runtime without redeploying. It lets incomplete work ship hidden, supports gradual rollout to selected users, and provides a fast way to disable a faulty feature.

Releasing a change to a small subset of users or servers first, watching error rates and other signals, then expanding if results are healthy. It limits the impact of defects and provides real-world feedback before full rollout.

Running two identical environments, one live and one idle, and switching traffic to the newly deployed version after verification. Rollback is quick because the previous environment is still available and unchanged.

Collecting and displaying data about running systems, such as error rates, latency and resource use, so teams can detect problems and understand behavior. Effective monitoring alerts people to symptoms that matter to users.

The degree to which a system's internal state can be inferred from its outputs, typically logs, metrics and traces. High observability lets teams diagnose unfamiliar failures without guessing or redeploying code.

A target for a measurable service characteristic, such as the share of requests answered within a set time. Objectives make reliability expectations explicit and guide decisions about when to slow releases and fix stability.

A discipline that applies software engineering to operations work, using automation to reduce manual effort and error budgets to balance reliability against change. It often defines how much unreliability is acceptable for a service.

The defined process for detecting, responding to, resolving and reviewing service disruptions, including roles, communication and escalation. Good incident management shortens outages and produces learning that prevents recurrence.

The connected set of tools supporting planning, version control, build, test, deployment, monitoring and collaboration. Tools matter, but they only deliver value when chosen to support agreed practices and a culture of shared responsibility.

A visual method for managing work on a board with columns representing stages and explicit limits on work in progress. It exposes bottlenecks and helps teams improve flow without reorganizing into fixed iterations.

A planned change program that improves flow, feedback and culture across an organization, usually starting with a value stream assessment, pilot teams and measurable goals. It addresses people and process, not only tool adoption.