CI/CD

CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment). Together, they describe the automated pipeline that moves code from a developer's commit to running in production.

Continuous Integration: every code push is automatically built and tested. Failures surface immediately, not weeks later. Continuous Delivery: the codebase is always in a deployable state. Continuous Deployment goes one step further - every passing build is automatically promoted to production without a human approval gate.

Why it matters in Engineering: Without CI/CD, deployments are manual, infrequent, and high-risk. With it, deploying becomes routine - sometimes dozens of times per day. Smaller, more frequent deploys are easier to reason about, easier to roll back, and expose less surface area when something breaks. CI/CD is the operational foundation that makes everything else - microservices, feature flags, trunk-based development - practical at scale.

Core Concepts

Pipeline
The ordered sequence of automated steps: build, unit test, integration test, deploy to staging, deploy to production. Each step is a gate - failure halts promotion.

Artifacts
The output of a build step: a Docker image, compiled binary, or deployment package. Artifacts are versioned and promoted through environments unchanged.

Branch Strategy
CI/CD pipelines are triggered by git events. Feature branches run tests on push. Merges to main trigger staging or production deploys, depending on your Continuous Delivery vs. Deployment posture.

Rollback
A fast rollback path is non-negotiable. Good pipelines make reverting to the previous artifact a single command or click, not a manual process.

Environment Parity
Staging should mirror production as closely as possible. Configuration drift between environments is the most common cause of "passes staging, fails in prod" incidents.