A CI/CD pipeline is the automated path your code takes from a git commit to running in production — building it, testing it, and delivering it without anyone hand-carrying each step. This guide is for developers moving into DevOps who keep hearing “check the pipeline” in standup and want a clear mental model instead of buzzwords. I’ll cover what continuous integration and delivery mean, the stages a real pipeline runs, a worked commit-to-production example, and how to build a first pipeline you can trust.
Quick answer: A CI/CD pipeline automatically builds and tests every change, then moves it toward production the same way every time. It replaces slow, manual, error-prone deploys with one repeatable process, so small changes ship often instead of piling up into one scary release.
What CI/CD actually means
The two letters stand for continuous integration (CI) and continuous delivery or deployment (CD). A CI/CD pipeline is the automation that stitches those ideas into one flow: every time someone pushes code, a server checks it out, builds it, runs the tests, and—if everything passes—prepares or performs a release. It exists because manual releases drift, and a pipeline turns “how we ship” from tribal knowledge into a repeatable script that runs identically for everyone.
CI — merge and test small changes constantly, so integration problems surface in minutes, not weeks.
CD (delivery) — keep every passing build packaged and ready to release with one click.
CD (deployment) — release automatically once the checks are green.
Continuous integration vs delivery vs deployment
People blur these three together, but a CI/CD pipeline treats them as distinct phases. Continuous integration is about the code building and passing tests; continuous delivery is about a tested build being ready to release; continuous deployment is about a green build reaching users on its own.
| Term | What it automates | Who pushes the button |
|---|---|---|
| Continuous integration | Build and test on every commit | Automatic on push |
| Continuous delivery | Package a release-ready artifact | A human approves the release |
| Continuous deployment | Release straight to production | No one — green means go |
Most teams start with CI, add delivery once they trust their tests, and reach full deployment only when monitoring and rollback are solid.
The stages of a typical pipeline
A CI/CD pipeline is usually a short chain of stages, each of which must pass before the next begins. The names differ between tools, but the shape is consistent.
Checkout — grab the exact commit that triggered the run.
Build — compile the code or assemble a container image.
Test — run unit and integration tests, and fail fast.
Package — produce one immutable, versioned artifact.
Deploy — push that same artifact to staging, then production.
Verify — run smoke checks and watch your metrics.
The golden rule is build once, deploy many: the artifact that passed your tests is the exact one that reaches production. Rebuilding per environment is how “it worked in staging” turns into a 2am incident.
A worked example: commit to production
Picture a small web app. You fix a bug, commit, and push to a branch — the only manual act in the whole story. The CI/CD pipeline handles the rest:
The push opens a pull request that builds the app and runs the test suite.
Tests pass, a teammate reviews the diff, and it merges to the main branch.
Merging packages a versioned container image and deploys it to staging.
Smoke tests hit staging; if they stay green, the pipeline promotes the same image to production.
Post-deploy checks watch error rates and roll the release back automatically if they spike.
A human wrote code and reviewed a diff. Everything mechanical — and everything easy to fumble at 5pm — was done identically by the pipeline.
Gates: tests, reviews, approvals
A gate is any check that can stop a change from moving forward, and it’s where a CI/CD pipeline earns its keep. Add them deliberately: too few and bad code sails through, too many and people start routing around the pipeline.
Automated tests — the cheapest gate; keep them fast so people actually wait for them.
Code review — a second set of eyes on the diff before it merges.
Security and lint checks — catch obvious vulnerabilities and style drift.
Manual approval — a required human “go” before production in higher-risk systems.
Rollbacks and safety
No pipeline makes bad releases impossible, so the goal isn’t perfection — it’s a fast, boring recovery. The safest teams I’ve worked with ship small, reversible changes and treat rollback as a first-class button. When a deploy is one immutable artifact, rolling back is just redeploying the previous one.
This is why deployment strategy matters. Techniques like blue-green and canary releases let you reverse quickly, and a set of rollback strategies turns a bad night into a short non-event. Wire that path in before you need it, not during the incident.
Your first pipeline, step by step
You don’t need a platform team to start. If your code is on GitHub or GitLab, a usable CI/CD pipeline is a single configuration file in your repository. Begin with the smallest thing that helps — running tests on every push — and grow from there.
Add a workflow file that triggers on every push and pull request.
Have it install dependencies, build, and run your tests.
Make a failing test block the merge, so red never reaches main.
Add a deploy to a staging environment once tests pass.
Automate production last, keeping a manual approval until you trust it.
For a concrete start in one tool, see our walkthrough of GitHub Actions. Whatever you pick, resist automating everything on day one.
Frequently asked questions
What is the difference between CI and CD?
CI (continuous integration) is about merging and testing changes constantly so problems appear early. CD is what happens after tests pass: continuous delivery keeps a release ready for a human to ship, while continuous deployment releases it automatically.
Do I need Docker or Kubernetes to use CI/CD?
No. A pipeline just needs a way to build, test, and deploy, which can be a plain server, a serverless function, or a static site. Containers and Kubernetes help at larger scale, but plenty of teams ship well without either.
How long should a pipeline take?
Fast enough that people wait for it rather than route around it — often a few minutes for the test stage. If runs drag past ten or fifteen minutes, developers start merging without waiting, and splitting slow tests into parallel jobs is the usual fix.
Is CI/CD only for big teams?
Not at all. A solo developer often benefits the most, because the pipeline becomes the teammate who never forgets to run the tests. Every change is built and checked the same way.
A CI/CD pipeline isn’t magic — it’s your release process, written down and run by a machine that never gets tired or skips a step. Start with tests on every push, add a staging deploy, and earn your way to production automation. Once shipping is boring, you’re free to focus on the product itself.
Want the full toolkit? Get DevOps Toolkit on Datanest
Originally published on **The Ship Log* — How software actually ships: CI/CD, containers, cloud, and staying up.*
Read more on The Ship Log →
Prefer a done-for-you toolkit?
Top comments (0)