DevOps Vocabulary Every Software Engineer Should Know

Learn the essential DevOps English vocabulary: CI/CD pipelines, infrastructure as code, SLOs, error budgets, and on-call language for modern engineering teams.

Even if you are not a DevOps engineer, the vocabulary of continuous delivery and infrastructure management permeates modern software teams. Stand-ups, architecture discussions, and incident reviews all draw on this language. This guide gives you the vocabulary you need to participate confidently.

CI/CD Vocabulary

Pipeline — an automated sequence of steps that transforms source code into a deployed, running service. A typical pipeline includes build, test, and deploy stages. “The pipeline failed at the integration test stage.”

Artifact — the output of a build step, such as a compiled binary, a Docker image, or a JAR file. Artifacts are versioned and stored in an artifact registry. “The deployment job pulls the artifact from the registry and pushes it to the cluster.”

Deployment gate — a check or approval step that must pass before a pipeline proceeds to the next environment. Gates may be automated (test coverage threshold) or manual (change approval). “We have a deployment gate that requires sign-off from a senior engineer before production releases.”

Rollback — reverting a deployed version to a previously known-good state. Distinct from a roll-forward, where you fix forward by deploying a corrected version. “When error rates spiked, the on-call engineer triggered a rollback within three minutes.”

Blue-green deployment — a release strategy that runs two identical production environments (blue and green); traffic switches from the old version to the new without downtime. “Blue-green deployments let us release without a maintenance window.”

Canary release — gradually routing a small percentage of traffic to a new version to detect issues before a full rollout. “We ran a 5% canary for 30 minutes before promoting to 100%.”

Infrastructure Vocabulary

Provisioning — the process of creating and configuring infrastructure resources such as virtual machines, databases, or networking components. Often automated with tools like Terraform or Ansible.

Infrastructure as Code (IaC) — managing and provisioning infrastructure through machine-readable configuration files rather than manual processes.

Drift — the difference between the actual state of infrastructure and the desired state defined in IaC. “We detected drift in the staging environment — someone had manually changed a security group rule.”

Idempotent — an operation that produces the same result whether it is run once or multiple times. Idempotency is a key property of reliable infrastructure automation scripts.

Immutable infrastructure — an approach where servers are never modified after deployment; instead, new images are built and old instances replaced. This eliminates configuration drift.

State file — in Terraform and similar tools, a file that records the current state of managed infrastructure, used to calculate what changes need to be applied.

Monitoring and Reliability Vocabulary

SLO (Service Level Objective) — an internal target for service reliability, such as 99.9% availability over a rolling 30-day window. SLOs are agreed within the engineering team.

SLA (Service Level Agreement) — a contractual commitment to customers about service performance. Violating an SLA may have financial consequences.

Error budget — the acceptable amount of unreliability within an SLO period. If your SLO is 99.9% availability, your error budget is 0.1% (about 43 minutes per month). “We have burned 80% of our error budget this month; we should pause non-essential releases.”

On-call — a rotation where engineers are available outside business hours to respond to incidents. “I am on-call this weekend; please avoid deploying large changes on Friday afternoon.”

Alerting fatigue — a state where too many low-quality alerts desensitise the on-call engineer, causing important alerts to be missed. “We need to audit our alert thresholds — the team is experiencing alerting fatigue.”

Runbook — a documented set of steps for responding to a specific operational event or alert, allowing any on-call engineer to handle known scenarios.

Example Sentences in Context

  1. “The CI pipeline builds a Docker artifact on every push to main; a deployment gate requires passing all integration tests before the artifact is promoted to staging.”

  2. “Our Terraform state showed significant drift after a manual hotfix last month — we spent a sprint reconciling the infrastructure code with reality.”

  3. “We set our SLO at 99.5% request success rate, giving us an error budget of about 3.6 hours per month to absorb planned and unplanned downtime.”

  4. “The idempotent design of our provisioning scripts means we can safely re-run them during recovery without risking duplicate resource creation.”

  5. “After the rollback, the on-call engineer updated the runbook with a new step to check the database migration status before triggering any future deployments.”

Building Your DevOps Vocabulary

The best way to internalise DevOps vocabulary is to read your team’s deployment pipeline documentation and runbooks critically — note every term you are unsure about. When you are on-call and something goes wrong, narrate your actions aloud in English. This practise reinforces both the technical concepts and the language simultaneously.