Stop 15 · DevOps & DeploymentTopics · 2/8

CI/CD Pipelines

Part of the Full Stack Developer Roadmap

In short

Right now you probably deploy by copying files to a server and hoping. CI/CD makes every push get tested and shipped the same way, every time, without you babysitting it.

Automatically testing and deploying both halves of your app on every push — often as two coordinated (but independent) pipelines, since frontend and backend usually deploy separately.

The purple blob tastes a laddoo from each tray on a conveyor before the trays roll into gift boxes.

Think of it like this

The mithai shop's tasting line

A good sweet shop tastes a laddoo from every tray before it goes into the box. Bad tray? It never reaches the counter. CI is the tasting, CD is the boxing and sending out, and it happens to every single tray.

Watch it happen

One commit, start to finish

Push

Test

Build

Staging

Production

1/5You push a commit to GitHub. That push is the trigger. No human needs to do anything else.

The big ideas

What you need to know

CI: merge small, merge often

Continuous Integration means everyone merges into main often, and every merge is built and tested automatically.

CD: always ready to ship

Continuous Delivery keeps main deployable at any moment. Continuous Deployment goes further and ships every green commit.

Build once, deploy many

Create one artifact and promote it from staging to production. Rebuilding per environment invites 'but it worked on staging' surprises.

Rollback is part of the plan

Every deploy should have a quick way back, like redeploying the previous image tag.

See it in code

Walk through the code

bash

1#!/usr/bin/env bash2# ci.sh: what every pipeline does, in order3set -euo pipefail          # stop at the first failure4 5npm ci                     # 1. clean install from package-lock.json6npm run lint               # 2. style and obvious bugs7npm test                   # 3. unit + integration tests8npm run build              # 4. produce the build9 10docker build -t registry.example.com/myapi:"$GIT_SHA" .11docker push registry.example.com/myapi:"$GIT_SHA"12echo "Ready to deploy myapi:$GIT_SHA"

1/4set -euo pipefail makes the script stop the moment any command fails.

Tools like GitHub Actions just run steps like these on a fresh machine for every push. The commit SHA tag means you always know exactly what's running.

Save yourself the pain

Common mistakes

Oops

Running tests only on your laptop and trusting that the server matches.

Do this instead

Let the pipeline run tests on a clean machine. 'Works on my machine' stops being an excuse.

Oops

Building a fresh image separately for staging and for production.

Do this instead

Build once, tag it with the commit SHA, and promote that exact image. What you tested is what you ship.

Your mission

Map your own pipeline

~20 min

Quick check

What is the difference between Continuous Delivery and Continuous Deployment?

Go deeper

1Set up a GitHub Actions workflow that tests and deploys your frontend.
2Set up a separate workflow for your backend, since they likely deploy to different places.
3Make sure a failing test in either pipeline blocks that deployment.