Library / Glossary / The craft glossary
DevOps and continuous delivery glossary
48 terms from R12, DevOps and continuous delivery — 23 defined in the guide itself and 25 more from the field around it. Every term the guide teaches links to the slide that teaches it.
R12 · How to build
DevOps and continuous delivery
How do we release often without breaking a school day?
Every term below is defined in the words of devops and continuous delivery, guide R12 of craft guides for educational technologists, and opens the guide at the slide where it is taught. 25 of the 48 are the field’s vocabulary rather than the guide’s own: words a reader will meet around this subject, defined here because the guide assumes them. 2 terms are also defined by another guide in the series; where the two differ, both wordings are given. The whole craft glossary holds all of them together.
| Term | Definition | Referred to in | Read further |
|---|---|---|---|
| B | |||
| Blue-green deployment | Running two identical production environments and switching traffic between them, so a release can be reversed quickly (Fowler, 2010). |
| |
| Build artefact | The packaged, versioned output of a build. The pipeline creates it once and deploys that same package to every environment, so what reaches users is exactly what was tested. |
|
|
| C | |||
| Canary release | Rolling a change out to a small group of users first, and widening it only if the signals hold (Sato, 2014). |
| |
| Change advisory board | A group that reviews and approves changes before they go live. Often called a CAB. |
| |
| Change fail rate | The share of deployments that need immediate intervention afterwards (DORA, 2026). |
| |
| Change freeze | A period in which no changes may be deployed, except agreed urgent fixes. |
| |
| Change lead time | The time from a change being committed to version control to it running in production (DORA, 2026). |
| |
| Chaos engineering | Deliberately injecting failures, such as shutting down a server, into a system under controlled conditions to check that it copes as designed before a real failure tests it. |
|
|
| Configuration drift | The gradual divergence of servers or environments that are meant to be identical, caused by manual, unrecorded changes. It makes releases behave differently from one environment to the next. |
|
|
| Configuration management | Keeping everything needed to build and run a system, including code, settings, scripts and environment definitions, identified, versioned and reproducible, so that any release can be recreated exactly. |
|
|
| Container orchestration | Software that starts, places, scales, restarts and updates containers across a group of servers automatically, to match a declared desired state. Kubernetes is the most widely used. |
|
|
| Continuous delivery | Building software so that it can be released to production at any time (Fowler, 2013). |
| |
| Continuous deployment | Sending every change that passes the pipeline to production automatically, with no human release decision. |
| |
| Continuous integration | Merging every developer's work into the main line at least daily, with each merge built and tested automatically (Fowler, 2024). |
| |
| D | |||
| Dark launch | Running new code in production for real users without them being able to tell (Fowler, 2020). |
| |
| Deploy | To put a new version of software into production. It need not be visible to users. |
| |
| Deployment frequency | A count of deployments over a period; one of the three DORA measures of throughput (DORA, 2026). |
| |
| Deployment pipeline | The automated stages a change passes through from commit to production (Humble & Farley, 2010). |
| |
| Deployment rework rate | The share of deployments that are unplanned and made because of an incident in production (DORA, 2026). | ||
| DevOps | A movement of developers and operations staff working together, with automation, feature flags, shared measures and a culture that avoids blame, to make releasing so ordinary that it stops being dangerous (Allspaw & Hammond, 2009). |
| |
| DORA measures | Five measures of software delivery performance, three of throughput and two of instability, read together and never as targets (DORA, 2026). |
| |
| E | |||
| Error budget | The amount of unreliability a service may have in a period before releases pause (Beyer et al., 2016). R11 The amount of failure a reliability target allows over a period; one minus the target. |
| |
| F | |||
| Failed deployment recovery time | How long it takes to recover from a deployment that fails and needs immediate intervention (DORA, 2026). R22 The time it takes to recover from a deployment that fails and requires immediate intervention (DORA, 2026). |
| |
| Feature flag | A setting that switches a feature on or off, or for some users only, without changing code (Hodgson, 2017). |
| |
| Flaky test | An automated test that sometimes passes and sometimes fails on the same code. Flaky tests teach a team to ignore failures, which undermines the pipeline. |
|
|
| I | |||
| Infrastructure as code | Defining servers, networks and their settings in files kept under version control, so that environments are created and changed by running tested scripts, not by hand. |
|
|
| M | |||
| Maintenance window | A period agreed and announced in advance during which a service may be changed or taken offline, chosen for when the fewest people need it. |
|
|
| O | |||
| Observability (of a system) | How well a team can work out what is happening inside a running system from the logs, metrics and traces it emits, including for problems nobody predicted. |
|
|
| On-call | A rota under which a named engineer is reachable for a set period and must respond within an agreed time when the live system raises an alert. |
|
|
| P | |||
| Platform team | A team that provides shared tools and services, such as the deployment pipeline, hosting and monitoring, as an internal product, so that product teams can release without building these themselves. |
|
|
| Production environment | The live system that real users rely on, as distinct from the environments used for development and testing. Often shortened to 'production' or 'prod'. |
|
|
| R | |||
| Recovery point objective (RPO) | The most data, measured as time before a failure, that an organisation accepts losing. An RPO of one hour requires backups or replication at least hourly. |
|
|
| Recovery time objective (RTO) | The longest a service may stay unavailable after a major failure before the harm becomes unacceptable. It sets how fast recovery arrangements must work. |
|
|
| Release | To make a change visible and available to users. |
| |
| Release candidate | A specific build judged potentially fit for release, which goes to users unchanged unless the remaining stages of testing find a reason to reject it. |
|
|
| Rollback | Returning a service to its previous version after a faulty release. |
| |
| Runbook | Written step-by-step instructions for a routine operational task or for responding to a particular alert, so that whoever is on call can act without working it out afresh. |
|
|
| S | |||
| Site reliability engineering (SRE) | Google's approach to operations, which treats running a service as a software engineering problem: reliability targets are explicit, releases are governed by error budgets and repetitive work is automated away. |
|
|
| Small batches | Work broken into pieces that take hours to a couple of days, which shortens the time to feedback and makes problems easier to find and fix (DORA, 2025). |
| |
| Smoke test | A short set of checks run straight after a deployment to confirm the system starts and its most important functions respond, before anything more thorough is tried. |
|
|
| Staged rollout | Opening a deployed change by feature flag to staff, then pilot schools, then half of schools, then everyone, and switching the flag off if a signal goes wrong. |
| |
| Staging environment | A copy of the live system, made as similar to it as practical, where a release is rehearsed and checked before it goes to production. |
|
|
| T | |||
| Test automation | Having software run the tests, on every change and without a person starting them, so that a fault is reported within minutes of being introduced. |
|
|
| The Three Ways | The principles said to underlie DevOps: fast flow of work from development to operations, fast feedback in the other direction, and a culture of continual experimentation and learning. |
|
|
| Toil | Operational work that is manual, repetitive, automatable and without lasting value, and that grows as the service grows. Reliability teams cap the share of their time spent on it. |
|
|
| Trunk-based development | A way of working in which developers merge small changes into one shared main branch at least daily, keeping any other branches short-lived. |
|
|
| V | |||
| Virtual machine | A software imitation of a whole computer, with its own operating system, running alongside others on shared physical hardware. Cloud servers are usually virtual machines. |
|
|
| Z | |||
| Zero-downtime release | A release that moves users from the old version to the new one without the service becoming unavailable, so it need not wait for an overnight or weekend slot. |
|
|
No term matches. Try fewer letters.
Nearby