What Is CI/CD?

"CI/CD" is shorthand for the automation that turns committed code into working software in production. It covers three related ideas — and they're often confused.

Continuous Integration (CI)

CI means every developer integrates their changes into the shared trunk frequently — at least daily — and an automated pipeline builds and tests every push.

Without CI, branches drift apart. Two engineers each refactor the same module on long-lived branches and merging becomes a multi-day puzzle. With CI, the integration happens many times a day, in tiny increments. Conflicts surface immediately while context is fresh.

What CI typically runs on every push:

• Compile / build the code
• Lint and format checks
• Unit tests
• Static analysis and security scans
• Build artefacts (JARs, container images, npm packages)

If any step fails, the build is "broken" and stops the merge. Fixing the broken build is the team's top priority.

Continuous Delivery (CD)

Continuous Delivery extends CI: every build that passes is automatically packaged and deployable to production. The actual release is still a human decision (a button click, a tag, an approval).

Continuous Delivery means:

• Every commit produces a release-quality artefact
• Deployment to a staging environment is automatic
• Deploying to production is one click — no manual config, no surprise scripts
• Rollback is one click

This is where most regulated organisations land — auditors and change-management boards still want a human in the loop, but the loop takes seconds, not weeks.

Continuous Deployment

Continuous Deployment goes one step further: every passing build is released to production automatically, with no human gate.

It requires deep confidence in your tests, observability, and rollback automation. Companies like Etsy, Netflix, and Amazon ship hundreds of times a day this way. It's not appropriate for every domain — banks, medical devices, and avionics generally won't accept it — but where it works, it's the gold standard.

The Pipeline

A pipeline is the concrete chain of automated steps that implements CI/CD. A typical pipeline looks like:

push → checkout → build → unit tests → security scan → package
     → deploy to dev → integration tests
     → deploy to staging → smoke tests → human approval
     → deploy to prod → post-deploy checks

Each stage gates the next. A failure anywhere stops the pipeline and notifies the team.

Why CI/CD Matters

The DORA research consistently shows: teams with mature CI/CD deploy more often, recover faster, and have lower change-failure rates than teams without.

Pipeline-as-Code

Modern CI/CD pipelines are defined as code, checked into the same repo as the application:

• GitHub Actions — .github/workflows/*.yml
• GitLab CI — .gitlab-ci.yml
• CircleCI — .circleci/config.yml
• Jenkins — Jenkinsfile
• Azure Pipelines — azure-pipelines.yml

This means your pipeline is reviewable, versioned, and changes go through the same process as the code itself. No more "the magic build server that nobody can rebuild."

The Vocabulary

What's Next

The next lesson breaks down each stage of a pipeline — what to put in build, what belongs in tests, where to put security scans, and where deploys happen. Then we get hands-on with GitHub Actions.