What is a CI/CD pipeline? A plain explanation with a first build

Short answer: a CI/CD pipeline is an automated sequence that runs every time someone pushes code — it builds the application, runs the tests, packages it, and deploys it. Continuous integration is the build-and-test half; continuous delivery keeps a deployable artefact ready; continuous deployment releases it automatically.

Most explanations of CI/CD start with a diagram of arrows and end with a tool comparison, and the reader still cannot answer the practical question: what should actually happen between my git push and a running application?

Here is that answer, stage by stage, and how to build a working pipeline in an afternoon.

The three terms, distinguished properly

They are frequently used as one word, and they are three different commitments.

Continuous integration (CI) — every change is merged into the main branch frequently, and every merge triggers an automated build and test run. The commitment is that the main branch always compiles and passes its tests. This is the part with the highest return, and the part teams most often stop at.

Continuous delivery (CD) — every change that passes CI produces a deployable artefact, and deploying it is a button someone presses. The commitment is that you could release at any moment. Regulated industries and mobile applications usually live here, deliberately.

Continuous deployment (also CD) — every change that passes the pipeline goes to production automatically, with no human gate. The commitment is much stronger: your tests, monitoring and rollback have to be good enough that a bad change is caught and reversed by machines.

Most teams should aim for continuous delivery, then earn continuous deployment by first building the safety net. Teams that skip to automatic production deployment without monitoring discover the gap on a Friday.

What a pipeline actually does, stage by stage

A realistic pipeline for a containerised web application:

1. Trigger. A push to a branch, or a pull request being opened. Fast feedback beats complete feedback: pull request builds should finish in minutes, not tens of minutes.

2. Checkout and dependency install. Pulls the code and restores dependencies, with a cache. Uncached dependency installation is the single most common reason pipelines feel slow.

3. Static checks. Linting, formatting, type checking, and a secrets scan. These take seconds and catch the class of mistakes that would otherwise consume a reviewer's attention.

4. Unit tests. Fast, isolated, and run on every change without exception. If they are slow, they will be skipped, and a skipped test suite is worse than no test suite because it produces confidence without evidence.

5. Build. Compile, bundle, and produce a container image. Tag it with the commit SHA rather than latest, so that every deployment names exactly what it is running.

6. Integration tests. The application against a real database and its real dependencies, started as containers by the pipeline itself. Slower, so often reserved for merges to main.

7. Security scan. The image scanned for vulnerable packages, and dependencies checked against advisories. Fail on critical, warn on the rest, or the pipeline becomes noise everyone ignores.

8. Push to a registry. The image, immutable, tagged with that same commit SHA.

9. Deploy to staging. Automatically. An environment that nobody deploys to is an environment nobody trusts.

10. Deploy to production. On approval for continuous delivery, automatically for continuous deployment — with a rollback that has been tested, not just written down.

Stages 5 through 10 are the reason containers and CI/CD arrived together: an image is the artefact that makes "build once, deploy anywhere" true rather than aspirational.

What belongs in a pipeline, and what does not

Belongs: anything that must happen every time and that a human would eventually forget. Tests, linting, security scanning, building, tagging, deploying, database migrations, smoke checks after deployment.

Does not belong: anything requiring judgement. Deciding whether a feature is ready, choosing what to release, approving a risky migration. Automate the mechanical, keep the judgement human, and be honest about which is which.

Does not belong, second category: long-running work that could happen elsewhere. A forty-minute end-to-end suite on every commit trains developers to stop reading the results. Move it to a nightly run and keep the commit pipeline under ten minutes.

Jenkins or GitHub Actions?

The honest comparison for someone choosing what to learn:

	GitHub Actions	Jenkins
Setup	None — it is in the repository	You run and maintain the server
Configuration	YAML in the repository	Groovy pipelines, plugins
Best for	Projects already on GitHub, small to mid-size teams	Complex, self-hosted, regulated or legacy estates
Cost	Free minutes then usage-based	Free software, you pay for infrastructure and maintenance
In job postings	Growing fast, especially in startups	Still very common in large enterprises

Learn the concepts on GitHub Actions because the feedback loop is immediate, then learn Jenkins because a large share of enterprise infrastructure still runs on it and those jobs pay. Our Jenkins and CI/CD course covers pipelines as code, agents, credentials and deployment patterns — the parts that transfer to any tool.

Build your first pipeline this week

A concrete exercise, worth more than any amount of reading:

• Day 1. Take a small application you already have. Add a Dockerfile with a multi-stage build. Confirm the image runs locally.
• Day 2. Add a pipeline that installs dependencies, runs the linter and runs the tests on every push. Make it fail on purpose — break a test — and watch it turn red.
• Day 3. Add the build and push the image to a registry, tagged with the commit SHA.
• Day 4. Deploy automatically to a staging environment. Anything: a container on a small server, a managed container service, a cluster.
• Day 5. Add a manual approval step to production, and write the rollback procedure. Then use it once, deliberately.

By Friday you have the thing every DevOps interview asks about, and a project worth a paragraph on your CV. Containers are the prerequisite — if that part is shaky, start with Docker before the pipeline.

The habits that separate working pipelines from ceremonial ones

Fast, or ignored. Under ten minutes for the commit pipeline. Cache dependencies, parallelise, move slow suites to a schedule.

Deterministic. A pipeline that fails one run in five for unrelated reasons teaches everyone to press retry, and after that a genuine failure gets retried too.

One artefact, promoted. Build the image once and promote the same image through staging to production. Rebuilding per environment means you tested something you did not ship.

Configuration outside the image. Same image everywhere, environment supplied at runtime. Secrets from a secret store, never from the repository — and a scanner in the pipeline to catch the day someone forgets.

A rollback you have used. Untested rollback is a rumour.

Frequently asked questions

What is a CI/CD pipeline in simple terms?

An automated sequence that runs whenever code changes: it fetches the code, checks it, runs the tests, builds a deployable artefact such as a container image, and deploys it. It replaces the manual steps a person would otherwise perform, and performs them identically every time.

What is the difference between continuous delivery and continuous deployment?

Continuous delivery means every change that passes the pipeline is ready to release, and a human decides when. Continuous deployment removes the human: anything that passes goes straight to production. Delivery is a good default; deployment requires strong tests, monitoring and rollback first.

Should I learn Jenkins or GitHub Actions?

Learn the concepts on GitHub Actions because it needs no setup and the feedback is immediate, then learn Jenkins because a large share of enterprise infrastructure still runs on it. The stages, artefacts and promotion patterns are the same in both, which is what interviews actually test. The Jenkins and CI/CD course covers both mental models.

How long should a CI/CD pipeline take?

Under ten minutes for the pipeline that runs on every commit, ideally under five. Beyond that, developers stop waiting for results and start ignoring them. Move long end-to-end suites to a nightly schedule and keep the commit path fast.

Do I need Docker for CI/CD?

Not strictly, but almost everyone uses it. A container image is the artefact that makes “build once, deploy anywhere” real: the same image runs in the pipeline, in staging and in production, which removes an entire category of environment bugs. Start with the Docker course.

What should a beginner automate first?

Tests on every push. It is the cheapest stage to add and the one that changes team behaviour most, because the main branch stops breaking. Build and deployment automation is worth much more once that foundation exists.

Where to go next

Pipelines sit between containers and infrastructure, so learn them alongside both: Docker, then Jenkins and CI/CD, then Terraform on AWS so the environment you deploy to is code as well. The full sequence is on the roadmap.