Home Roadmaps CI/CD Pipelines
Stage 6 of 7 · The Core Skill

Set Up CI/CD Pipelines

A plain-English guide to the beating heart of DevOps — automating the journey from a developer's code commit all the way to users' screens, with zero manual steps.

Updated May 2026 · 5–6 Weeks · 7 Stages

← Previous
Next →

What is CI/CD? Before automated pipelines existed, deploying software meant a team of engineers spending entire weekends manually copying files, running tests by hand, crossing their fingers, and praying nothing broke. Releases happened once a month — sometimes once a quarter. It was slow, stressful, and error-prone.

CI/CD changed all of that. Continuous Integration means every code change is automatically tested the moment it's pushed. Continuous Deployment means code that passes those tests is automatically shipped to users — no human intervention needed. Today, companies like Amazon deploy code thousands of times per day. That is the power of a well-built pipeline, and building those pipelines is the core job of a DevOps engineer.

Your 7-Stage CI/CD Roadmap

1

Understand the Pipeline Concept

Mental Model

A pipeline is a series of automated steps that code passes through on its way from a developer's laptop to production. Think of it like a factory assembly line — raw code goes in one end, and a tested, packaged, deployed application comes out the other. The typical stages are: build (compile or package the code), test (run automated checks), and deploy (ship it to a server). Every CI/CD tool — GitHub Actions, Jenkins, GitLab CI — is just a different way to define and run this same assembly line.

Build → Test → Deploy flow What triggers a pipeline? Pipeline stages & jobs Pass vs fail conditions
2

GitHub Actions — Your First Pipeline

Start Here

GitHub Actions is the best place to start because it lives directly inside GitHub — no separate tool to install or pay for. You write a YAML file inside your repository and GitHub runs it automatically every time you push code. Create your first workflow: on every push to main, install your project's dependencies and run a test. When you see that green checkmark appear next to your commit, you've built your first CI pipeline. It's one of the most satisfying moments in this entire roadmap.

.github/workflows/*.yml on: push / pull_request triggers jobs & steps runs-on: ubuntu-latest Marketplace actions (uses:)
3

Automated Testing — The Safety Net

Never Ship Broken Code

A pipeline without tests is just automation that ships broken code faster. Automated tests are the safety net — code that checks your code. You don't need to write complex tests at this stage, but you do need to understand the types: unit tests check individual functions, integration tests check that components work together, and linting catches formatting and syntax errors before they cause problems. Hook these into your pipeline so any failure automatically blocks a deployment. This is the CI in CI/CD — integration is only trustworthy when tests back it up.

pytest (Python testing) Jest (JavaScript testing) Linting (flake8, eslint) Unit vs integration tests Failing a pipeline on test failure
4

Build & Push Docker Images in a Pipeline

Everything Connects

This is where Stage 5 (Docker) and Stage 6 (CI/CD) collide — and it's a genuinely exciting moment. Extend your GitHub Actions workflow to automatically build a Docker image of your app and push it to a registry (Docker Hub or AWS ECR) every time code passes its tests. No human needs to run docker build or docker push ever again — the pipeline does it. This pattern — test, build image, push to registry — is the foundation of almost every modern deployment system in the world.

docker/build-push-action Secrets (storing credentials safely) Tagging images with commit SHA Push to Docker Hub / ECR Multi-stage Docker builds in CI
5

Continuous Deployment — Ship It Automatically

Close the Loop

You've built. You've tested. You've packaged. Now close the loop: automatically deploy the new container to your server whenever the pipeline succeeds. This is the CD in CI/CD. Add a final pipeline step that SSHes into your cloud VM and pulls the latest Docker image, or triggers a deployment on a platform like AWS ECS, Render, or Railway. When a developer pushes code and — with no other human action — users are running the new version minutes later, you've built a real continuous deployment pipeline. This is the goal.

Deploy via SSH in pipeline AWS ECS / App Runner Render / Railway (beginner-friendly) Environment-based deployments Rollback on failure
6

Jenkins & GitLab CI — Enterprise Tools

Industry Standard

GitHub Actions is perfect for learning, but many companies — especially large enterprises — use Jenkins or GitLab CI. Jenkins is the most widely deployed CI/CD tool in the world: self-hosted, endlessly customisable, and found in nearly every large engineering organisation. GitLab CI is tightly integrated with GitLab repositories and popular in DevOps-heavy teams. You don't need to master both — just understand how they differ from GitHub Actions. Install Jenkins locally using Docker, create a simple Jenkinsfile, and run a pipeline. That's enough to speak confidently about it in any interview.

Jenkins (via Docker) Jenkinsfile (declarative pipeline) GitLab CI (.gitlab-ci.yml) Agents & runners Pipeline as Code concept
7

Advanced Patterns — Environments & Approvals

Production-Grade

Real production pipelines are more than just build-test-deploy. They have multiple environments — code flows through dev, then staging (a copy of production for final testing), then production (what real users see). They have manual approval gates — a human must sign off before code reaches production. They have blue/green deployments — spinning up a new version alongside the old one and switching traffic only when ready. These patterns are what separate a beginner pipeline from a production-grade one. Learn them and you graduate from junior to mid-level DevOps engineer.

Dev / Staging / Production environments Manual approval gates Blue/green deployments Canary releases Secrets management (Vault, AWS SSM)

Realistic Timeline (1 Hour a Day)

Day 1–3 Day 4–9 Day 10–15 Day 16–21 Day 22–27 Day 28–33 Day 34–40

4 Rules to Master CI/CD Fast

🟢

Start With the Green Checkmark

Your first pipeline doesn't need to be impressive — it just needs to run. Even a workflow that only runs echo "Hello CI" teaches you the structure. Build complexity one step at a time from there.

🔐

Never Hardcode Secrets

API keys, passwords, and tokens must never be written directly into a workflow file. Use your platform's secrets store — GitHub Secrets, GitLab CI Variables, or Jenkins Credentials. This is non-negotiable in any professional environment.

Keep Pipelines Fast

A pipeline that takes 30 minutes to run is a pipeline developers will try to skip. Cache dependencies, run jobs in parallel where possible, and ruthlessly remove steps that don't add value. Speed is a feature.

📋

Build a Portfolio Pipeline

Take a personal project — even a simple one from earlier stages — and wire up a complete CI/CD pipeline for it. Push code, watch it test, build, and deploy automatically. Record a short demo of it. That demo is worth more than any certificate in an interview.

"

Every skill you've learned so far — Linux, Git, scripting, cloud, Docker — has been building toward this moment. A CI/CD pipeline is where it all plugs together into one automated system. When you build one from scratch and watch it run end-to-end without you touching a thing, you'll understand exactly why DevOps engineers are so valued.

One pipeline, built properly, changes how you think about software forever.

Ready for the next stage?

Continue to Infrastructure as Code & Monitoring →

Continue to Stage 7: IaC & Monitoring →