IBM DevOps and Software Engineering key terms

A working culture and set of practices that merges software development and IT operations so teams build, test, release, and run software collaboratively with fast feedback and shared ownership of production outcomes.

Continuous integration merges code frequently and verifies each change with automated builds and tests; continuous delivery keeps every build releasable, while continuous deployment automatically ships passing builds to production.

A lean technique that diagrams each step from idea to customer delivery, measuring wait and work time so teams can find bottlenecks and reduce lead time.

The elapsed time from a work item being requested or committed to it reaching the customer, including queue and wait time. It measures responsiveness rather than effort spent.

The time from when work actively starts on an item until it is finished. Teams track it to forecast throughput and spot process friction, and it excludes time spent waiting before work began.

A 2001 statement of four values and twelve principles favoring individuals, working software, customer collaboration, and response to change over rigid process, documentation, contracts, and fixed plans.

A lightweight agile framework using fixed-length sprints, three accountabilities (Product Owner, Scrum Master, Developers), five events, and three artifacts to deliver increments of value iteratively.

A timeboxed iteration, typically one to four weeks, during which a Scrum team turns selected backlog items into a potentially releasable product increment. Its length stays fixed for predictability.

An ordered, evolving list of everything that could improve the product, owned and prioritized by the Product Owner. It is the single source of work for the Scrum team.

The Scrum event that opens a sprint. The team agrees on a sprint goal, selects backlog items it can finish, and plans how the work will be done within the timebox.

A closing Scrum event where the team inspects how it collaborated and picks concrete improvements to apply in the next sprint, focusing on people, process, and tools.

A shared checklist describing what completed means for a backlog item, such as code reviewed, tests passing, and documentation updated. It prevents partial work being counted as finished.

A short, user-centered description of desired functionality, often phrased as a role wanting a capability so that a benefit is gained, with acceptance criteria attached for verification.

The specific, testable conditions a story must satisfy to be accepted by the Product Owner. They guide development and become the basis for automated and manual tests.

A flow-based method using a visualized board, explicit work-in-progress limits, and continuous delivery rather than fixed iterations. It exposes bottlenecks and smooths throughput.

A cap on how many items may occupy a workflow stage at once. Limiting concurrent work shortens queues, reveals constraints, and improves the rate at which items finish.

An architectural style splitting an application into small, independently deployable services that communicate over networks and are organized around business capabilities, each owning its data.

An application packaged and deployed as a single unit, often with one shared database. It is simple to start with but couples release cycles and scaling across all its features.

An incremental modernization approach that routes selected functionality to new services while the legacy system keeps running, gradually replacing it until the old system can be retired.

A methodology for building portable, cloud-ready services, covering configuration in the environment, stateless processes, disposability, logs as event streams, and strict separation of build, release, and run.

An isolated process packaged with its filesystem dependencies that shares the host operating system kernel. Containers start quickly and behave identically across environments.

An immutable, layered artifact containing an application and its runtime dependencies, built from a recipe and stored in a registry so it can be pulled and run repeatedly.

A text file of ordered instructions that a builder executes to produce a container image, defining the base image, copied files, environment settings, and startup command.

A Dockerfile technique using several build stages in one file so compilers and build tools stay in early stages and only the final runtime artifacts reach the shipped image, reducing size and attack surface.

A networked repository that stores and distributes versioned container images, supporting tagging, access control, and vulnerability scanning so clusters and pipelines can pull trusted artifacts.

An open-source orchestration platform that schedules containers across a cluster, restarts failed workloads, scales replicas, and exposes services through declarative configuration.

The smallest deployable unit in Kubernetes: one or more tightly coupled containers sharing a network namespace and storage volumes, scheduled together onto a node.

A Kubernetes resource that declares the desired replica count and pod template for a stateless workload, managing rolling updates and rollbacks as the specification changes.

A release strategy that replaces instances of an application gradually, keeping some old versions serving traffic until new ones pass readiness checks, avoiding full downtime.

A release pattern running two identical environments where traffic switches from the live blue version to the prepared green version, allowing quick rollback by switching back.

A gradual rollout that sends a small share of live traffic to a new version while monitoring error rates and latency, expanding exposure only if metrics stay healthy.

A runtime toggle that enables or disables functionality without redeploying code, supporting gradual rollout, A/B testing, and rapid disabling of a faulty feature.

An automated sequence of stages such as build, test, scan, and deploy that moves a code change from commit to release, failing fast when any stage breaks.

Managing servers, networks, and cloud resources through versioned machine-readable definitions applied by tooling, giving repeatable, reviewable, and auditable environment provisioning.

A practice where servers or containers are never patched in place; instead a new versioned artifact replaces the old one, eliminating configuration drift and making rollbacks predictable.

Using scripts and frameworks to execute tests such as unit, integration, and end-to-end checks without manual effort, enabling fast, repeatable verification inside pipelines.

A discipline applying software engineering to operations, using service level objectives, error budgets, and automation to balance reliability against the pace of change.

The ability to understand a system's internal state from its outputs, chiefly metrics, logs, and traces, so teams can detect and diagnose failures in distributed environments.

A branching practice where developers integrate small changes into a shared mainline at least daily, using short-lived branches or feature flags to keep integration pain low.