DEV Community: Mahendra Singh

Docker vs Kubernetes: Stop Comparing Them Like They Compete

Mahendra Singh — Tue, 02 Jun 2026 20:14:59 +0000

Every developer hitting their first production deployment runs into this question: Do I need Docker, Kubernetes, or both?

It's the wrong framing. They don't compete. They operate at completely different layers of your infrastructure.

Let me be blunt upfront:

Docker = packages and runs your app as a container (single host)
Kubernetes = manages and scales those containers across many hosts

You don't choose between them. You choose when to graduate from one to the other.

What Docker Actually Does

Docker solves the "works on my machine" problem. It bundles your app code, runtime, libraries, and config into a container image — a portable artifact that runs identically everywhere Docker is installed.

Here's the simplest possible Dockerfile:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Build it, push it, run it anywhere:

docker build -t my-api:1.0 .
docker push my-registry/my-api:1.0
docker run -p 3000:3000 my-registry/my-api:1.0

That image behaves the same on your MacBook, a CI runner, or a prod server. That's the whole value prop.

Docker Compose for Multi-Service Dev

For local development with multiple services, Docker Compose is your best friend:

# docker-compose.yml
services:
  api:
    build: ./api
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: pass

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

docker compose up -d     # spin everything up
docker compose logs -f   # follow logs
docker compose down      # tear it all down

One command spins up your entire local stack. This is where most teams should live until they genuinely need orchestration.

What Kubernetes Actually Does

Docker works great on one machine. The moment you need your app running across multiple machines — with auto-scaling, self-healing, load balancing, and zero-downtime deploys — Docker alone doesn't cut it.

Kubernetes (K8s) is the orchestration layer. It doesn't build containers. It runs and manages them across a cluster.

Here's what K8s handles automatically:

Which node to schedule each container on
Restarting crashed containers
Scaling up/down based on CPU/memory load
Distributing traffic across replicas
Rolling out updates without downtime
Managing secrets and config
Network routing between services

The mental model: you declare your desired state, and K8s continuously reconciles reality toward it.

A Real Kubernetes Deployment

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-api
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
        - name: api
          image: my-registry/my-api:1.0
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: my-api-svc
spec:
  selector:
    app: my-api
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

kubectl apply -f deployment.yaml
kubectl get pods
kubectl rollout status deployment/my-api

If one of those 3 pods crashes, K8s replaces it automatically. Scale on demand:

kubectl scale deployment my-api --replicas=10

Or set up auto-scaling based on CPU:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Container vs Pod: The Confusion Cleared Up

This trips up everyone new to K8s.

Container = one packaged process. Docker's unit.

Pod = K8s's deployable unit. Wraps one or more containers that share:

The same network namespace (they talk via localhost)
The same storage volumes
The same lifecycle

Most pods are single-container. But the sidecar pattern is real — you'll use it for logging agents, proxies (like Envoy in a service mesh), or secret injectors:

spec:
  containers:
    - name: app
      image: my-api:1.0
    - name: log-shipper        # sidecar
      image: fluentd:latest
      volumeMounts:
        - name: logs
          mountPath: /var/log/app

Why it matters practically: K8s schedules pods, not individual containers. Resource requests, limits, and self-healing all operate at the pod level. If a pod crashes, K8s replaces the whole pod — not just the container inside it.

How Docker and K8s Fit Together in a Real Pipeline

They're sequential, not overlapping:
Developer writes code

→ Dockerfile defines the build
→ CI runs: docker build + docker push → registry
→ K8s pulls image from registry
→ K8s schedules pods across nodes
→ K8s manages lifecycle, scaling, health

A typical GitHub Actions pipeline wiring both together:

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build and push image
        run: |
          docker build -t $REGISTRY/my-api:$GITHUB_SHA .
          docker push $REGISTRY/my-api:$GITHUB_SHA

      - name: Deploy to K8s
        run: |
          kubectl set image deployment/my-api \
            api=$REGISTRY/my-api:$GITHUB_SHA
          kubectl rollout status deployment/my-api

Docker handles the build. Kubernetes handles the deploy. Clean handoff.

Note on runtimes: Kubernetes uses containerd as its default runtime, not Docker directly. But Docker-built images follow the OCI standard, so they're fully compatible. You don't need to change your build workflow.

When to Use Docker Without Kubernetes ✅

Use Docker alone when:

You're in early development or pre-PMF
Your app runs on a single server
Your team is 1–3 engineers
You have fewer than ~10 containers total
You're serving under ~10k DAU
You're on a managed PaaS (Railway, Fly.io, Cloud Run) that abstracts orchestration for you
Fast iteration matters more than scaling headroom right now

Docker Compose handles multi-service local dev and even modest production deployments cleanly. Adding K8s at this stage is premature optimization with real engineering cost.

When to Add Kubernetes ✅

Add K8s when:

You're running 5+ microservices that need coordinated deployment and networking
Traffic spikes are real and you need auto-scaling
You have an uptime SLA above 99.9% that requires self-healing
Multiple teams deploy independently to shared infrastructure
You need canary releases, blue/green deploys, or sophisticated rollout strategies
You're serving 100k+ DAU
Your monthly compute spend is high enough that K8s bin-packing efficiency actually saves money

A rough rule of thumb: if your compute bill is under $5k/month and you have fewer than 15 services, K8s will likely cost more in engineering time than it saves in ops.

When NOT to Use Kubernetes ❌

Avoid K8s when:

No one on your team has real K8s operational experience
You're a solo dev or very small startup
Your stack is a monolith or 2–3 services
Feature velocity is the priority and K8s YAML would slow you down
A managed PaaS already gives you what you need
You're adding it because it looks good on the architecture diagram

I've seen small teams burn weeks configuring ingress controllers, cert-manager, and RBAC for a 3-service app. The overhead is real. Don't add it until the pain of not having orchestration is specific and concrete.

Quick Comparison

Factor	Docker	Kubernetes
Primary job	Build + run containers	Orchestrate at scale
Scope	Single host	Multi-host cluster
Setup time	Minutes	Hours to days
Auto-scaling	❌	✅
Self-healing	❌	✅
Rolling updates	Manual	Automated
Learning curve	Days	Weeks–months
Best for	Dev, small scale	Production, microservices

Learning Path

Docker learning curve: days.
Kubernetes learning curve: weeks to months.

The progression that actually works:

Get fluent with docker build, docker run, image layers, multi-stage builds
Master Docker Compose for local multi-service dev
Understand container networking (bridge, host, overlay)
Then introduce K8s concepts: pods → deployments → services → ingress → namespaces → RBAC
Run locally with kind or minikube before touching production

# Spin up a local K8s cluster for learning
kind create cluster --name dev
kubectl cluster-info --context kind-dev

Managed K8s options when you're ready for production:

Cloud	Service
AWS	EKS
GCP	GKE
Azure	AKS

They manage the control plane. You manage your workloads.

Takeaways

Docker and Kubernetes aren't rivals. They're different layers of the same stack.
Docker Compose in production is a legitimate, underrated choice for small/medium workloads.
The Docker → K8s transition is a natural graduation, not a required step.
Before rolling your own cluster, check if Cloud Run, App Runner, or Container Apps gives you 80% of K8s for 20% of the complexity.
Master Docker deeply first. The mental models (images, layers, networking, volumes) carry directly into K8s.
Add K8s when the pain of not having orchestration is specific and real — not theoretical.

Originally published at akoode.com.

GitHub Actions vs Jenkins vs GitLab CI: A Developer's Honest Comparison (2026)

Mahendra Singh — Tue, 26 May 2026 18:49:48 +0000

GitHub Actions vs Jenkins vs GitLab CI: A Developer's Honest Comparison (2026)

This article is a technical rewrite of the original comparison published at akoode.com. Code examples and architecture breakdowns added for Dev.to readers.

I've set up pipelines on all three. Migrated a team off Jenkins to GitHub Actions. Watched a startup pick GitLab CI because the security scanning was bundled. Watched another stay on Jenkins because their infra literally couldn't reach the internet.

Here's the honest breakdown — no vendor spin, just the practical trade-offs.

The Core Philosophical Difference

Before the feature tables, get this mental model right:

GitHub Actions — pipeline-as-code that lives inside your repo, triggered by GitHub events. No server to manage.
Jenkins — a self-hosted automation server you fully control. Maximum flexibility, maximum maintenance cost.
GitLab CI — pipeline engine inside a complete DevOps platform. If you want one tool for code + CI + security scanning + registry, this is it.

The rule of thumb in 2026: pipeline tools follow platform gravity. The best CI/CD tool is usually the one closest to where your code lives. That's why GitHub Actions and GitLab CI have eaten Jenkins' lunch for new projects.

How Each Tool Actually Works

GitHub Actions

Workflows live at .github/workflows/*.yml. Triggered by any GitHub event — push, PR, release, schedule, manual dispatch, or an external webhook.

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

Jobs run on runners — GitHub-hosted VMs (Ubuntu, Windows, macOS) or self-hosted machines you register. The Marketplace has 20,000+ reusable actions. Most integrations are already there.

Jenkins

Jenkins uses a controller-agent architecture. The controller handles scheduling and the UI. Agents run the actual build jobs — you can scale to hundreds of distributed agents.

Pipelines are Jenkinsfiles written in Groovy (or declarative syntax):

// Jenkinsfile
pipeline {
  agent any

  stages {
    stage('Install') {
      steps {
        sh 'npm ci'
      }
    }
    stage('Test') {
      steps {
        sh 'npm test'
      }
    }
    stage('Build') {
      steps {
        sh 'npm run build'
      }
    }
    stage('Deploy') {
      when {
        branch 'main'
      }
      steps {
        sshPublisher(publishers: [
          sshPublisherDesc(configName: 'prod-server',
            transfers: [sshTransfer(sourceFiles: 'dist/**')])
        ])
      }
    }
  }
}

Groovy is a real programming language — loops, conditionals, shared libraries. YAML tools hit ceilings on complex logic. Jenkins doesn't.

Over 1,800 plugins cover basically every tool in the DevOps ecosystem. If it exists, Jenkins can probably integrate with it.

The cost: you run the server. Security patches, plugin compatibility, scaling — all yours.

GitLab CI

Config lives at .gitlab-ci.yml in the repo root. Syntax is YAML, similar feel to GitHub Actions:

# .gitlab-ci.yml
stages:
  - test
  - build
  - deploy

test:
  stage: test
  image: node:20
  cache:
    paths:
      - node_modules/
  script:
    - npm ci
    - npm test

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

deploy:
  stage: deploy
  script:
    - rsync -avz dist/ user@prod-server:/var/www/app/
  only:
    - main
  environment:
    name: production
    url: https://myapp.com

What makes GitLab different is the platform depth. One installation gives you:

Source code management
CI/CD runners
Container registry
Package registry
Built-in SAST, DAST, dependency scanning
Kubernetes deployment integration
Feature flags

For regulated industries, that bundled security scanning is a real compliance lever.

Side-by-Side Comparison

Factor	GitHub Actions	Jenkins	GitLab CI
Setup time	Minutes	Hours–Days	Minutes
Config language	YAML	Groovy / Declarative	YAML
Hosting	Cloud-managed	Self-hosted	Cloud or self-hosted
Maintenance overhead	Very low	High	Low–Medium
Ecosystem	20,000+ Actions	1,800+ plugins	Built-in suite
Multi-SCM support	GitHub only	Any VCS	GitLab only
Security scanning	Via 3rd-party actions	Via plugins	Built-in SAST/DAST
Kubernetes integration	Via actions	Via plugins	Native
Free tier (private)	2,000 min/month	Free (infra costs)	400 min/month
Vendor lock-in	Medium	Low	High
Learning curve	Low	High	Low–Medium

Jenkins vs GitHub Actions: Where Each Wins

GitHub Actions wins on:

Zero-to-pipeline time (seriously, under an hour)
Maintenance burden (GitHub manages the infra)
Developer experience and discoverability
Marketplace ecosystem
Cost for standard workloads

Jenkins wins on:

Air-gapped / private network environments
Multi-SCM support (GitHub + GitLab + Bitbucket + SVN simultaneously)
Complex pipeline logic that YAML can't cleanly express
Full infrastructure control

The honest take: Jenkins teams in 2026 are there because their infra requires it, or because migrating 200+ existing pipelines isn't worth the effort yet. For new projects with no constraints, GitHub Actions is almost always the faster path.

GitLab CI vs Jenkins: Platform vs Flexibility

GitLab CI only works natively with GitLab repos. If your code is elsewhere, it's not a practical choice.

Where GitLab CI beats Jenkins:

Integration depth — no plugin wrangling, everything's built-in
Security tooling — SAST, DAST, secret detection, dependency scanning without configuring separate tools
Single auth model — one platform, one login, one audit trail

Where Jenkins beats GitLab CI:

True flexibility — Jenkins doesn't care where your code lives
Data isolation — a Jenkins controller on-prem means your pipeline data, secrets, and logs never leave your network. GitLab Self-Managed achieves similar isolation but you're now maintaining a full GitLab installation.

Can You Use GitHub Actions + Jenkins Together?

Yes, and it's a legitimate architecture.

Common hybrid model:

GitHub PR opened
      │
      ▼
GitHub Actions  ←── Runs unit tests, lint, builds Docker image
      │                 pushes to registry
      │
      ▼
Jenkins (self-hosted) ←── Handles deploy to internal infrastructure,
                           legacy systems, compliance environments

Wire them together using GitHub Actions self-hosted runners registered on Jenkins agents. GitHub-triggered workflows execute on your Jenkins infrastructure. Cloud-native triggers, on-prem execution.

Pricing: Total Cost of Ownership

Tool	Free Tier	Paid Entry	Real Cost Driver
GitHub Actions	2,000 min/month (private)	$4/user/month	Extra minutes @ $0.008/min (Linux)
Jenkins	Free (open source)	Infra costs only	Engineer time for maintenance
GitLab CI	400 min/month	$29/user/month (Premium)	$99/user/month (Ultimate) for security

Jenkins looks free. It isn't.

If a DevOps engineer spends 20% of their time on Jenkins maintenance — plugin updates, security patches, agent scaling — that's easily $20–40K/year in burdened labour cost at typical engineering salaries. GitHub Actions or GitLab CI Premium is almost certainly cheaper at any team size over 5 people.

The breakeven point where Jenkins makes economic sense: you need the flexibility, you have dedicated platform engineering capacity, and cloud-managed runners genuinely can't reach your deployment targets.

When to Use Each

✅ Use GitHub Actions when:

Your code is on GitHub
You're a startup or small-to-mid team without a dedicated platform team
You want minimum setup and maximum focus on shipping product
You're building web apps, APIs, open-source libraries
You want to scale without hiring a CI/CD specialist

✅ Use Jenkins when:

Your environment is air-gapped or on-premises
You have code across multiple VCS (GitHub + GitLab + Bitbucket + SVN)
You have complex, multi-stage pipeline logic that YAML can't express
You have a dedicated DevOps team to own the infra
You're deeply embedded in an existing Jenkins ecosystem

✅ Use GitLab CI when:

Your code already lives on GitLab
You want one platform for source control + CI/CD + security scanning
You're in a regulated industry where built-in SAST/DAST reduces compliance overhead
You want self-hosted DevOps infra but don't want to depend on GitHub

Practical Takeaways

Platform gravity is real — pick the CI/CD tool that lives closest to your code
Jenkins is free to license, not free to run — factor engineering maintenance time into your TCO calculation
GitHub Actions + Jenkins hybrid is a legitimate middle ground, not a compromise
GitLab Ultimate's bundled security scanning can replace multiple standalone tool subscriptions — do the math before assuming it's expensive
For new projects in 2026 with no infra constraints: GitHub Actions is the default. It's not even close
Matrix builds are underused — test across Node 18/20/22, Python 3.11/3.12 in parallel without duplicating jobs
Self-hosted runners solve the "GitHub Actions can't reach my private network" problem without switching tools entirely

Quick Decision Flowchart

Is your code on GitHub?
├── Yes → GitHub Actions (unless air-gapped)
└── No
    ├── Is your code on GitLab?
    │   └── Yes → GitLab CI
    └── Multiple VCS / air-gapped / complex logic?
        └── Yes → Jenkins

The right tool is the one that matches where your code lives, how much operational overhead your team can absorb, and what your compliance requirements demand.

There's no universal winner. But there is a clear default for most teams.

"Building a CI/CD Pipeline From Scratch: A Practical Guide for Developers (with GitHub Actions)"

Mahendra Singh — Mon, 25 May 2026 19:49:06 +0000

Building a CI/CD Pipeline From Scratch: A Practical Guide for Developers

Originally inspired by Akoode's CI/CD pipeline guide — rewritten here with more depth, code, and less hand-waving.

I've seen teams spend hours manually running tests, zipping build artifacts, SSHing into servers, and crossing fingers before every deploy. CI/CD pipelines exist to kill that workflow. This guide skips the theory lecture and gets into how to actually build one.

We'll use GitHub Actions as the CI/CD platform — it's free for public repos, tightly integrated with GitHub, and requires zero external infrastructure to get started.

What CI/CD Actually Does (Plain English)

CI (Continuous Integration): Every time code is pushed or a PR is opened, automatically run your build and tests. Catch breakage early, not in prod.
CD (Continuous Delivery/Deployment): After CI passes, automatically ship the artifact to staging or production — no human clicking "deploy" required.

The pipeline is just a sequence of automated steps triggered by a git event.

Pipeline Architecture

git push / PR open
│
▼
┌─────────────┐
│ Trigger │ ← GitHub webhook fires
└─────┬───────┘
│
▼
┌─────────────┐
│ Build │ ← Install deps, compile, bundle
└─────┬───────┘
│
▼
┌─────────────┐
│ Test │ ← Unit, integration, lint
└─────┬───────┘
│
▼
┌─────────────┐
│ Deploy │ ← Push to staging/prod
└─────────────┘
Each stage is a job. Jobs run on runners (GitHub-hosted VMs or your own). They can run in parallel or sequentially with dependencies between them.

Setting Up Your First Pipeline with GitHub Actions

Create this file in your repo:

.github/
workflows/
ci-cd.yml

Minimal CI Pipeline (Node.js Example)

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

That's it. Push this file, and every PR gets auto-tested. No server, no webhook config.

Adding CD: Deploy to a Server

After CI passes, deploy to production. Here we'll SSH into a VPS and pull + restart:

  deploy:
    needs: build-and-test       # only runs if CI passes
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'   # only on main branch

    steps:
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          script: |
            cd /var/www/myapp
            git pull origin main
            npm ci --omit=dev
            pm2 restart myapp

Store your SSH key and server IP in GitHub Secrets (Settings → Secrets and variables → Actions). Never hardcode credentials in the YAML.

Docker-Based Deploy (More Portable)

If you're deploying containers:

  build-and-push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: yourusername/myapp:${{ github.sha }}

Using the commit SHA as the image tag gives you a clean audit trail — every deploy is traceable to a specific commit.

Environment Separation

Don't deploy everything to production. Use branch-based environment targeting:

on:
  push:
    branches:
      - main       # → production
      - staging    # → staging env
      - 'feat/**'  # → preview envs (optional)

Pair with GitHub Environments (Settings → Environments) to add manual approval gates before production:

  deploy-prod:
    environment:
      name: production
      url: https://myapp.com

GitHub will pause and require an approver before proceeding. Useful for regulated teams or high-stakes deploys.

Caching Dependencies

Don't reinstall node_modules from scratch on every run. Cache it:

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'        # ← this line handles caching automatically

For Python:

      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
          cache: 'pip'

This alone can cut pipeline runtime by 60–70% on most projects.

Matrix Testing: Test Across Multiple Versions

Need to support Node 18 and 20? Don't write two jobs:

  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci && npm test

GitHub runs these in parallel — fast and zero duplication.

Secrets Management

Rules:

Store secrets in GitHub Secrets, not in .env files committed to the repo
Use environment-scoped secrets for prod vs staging differences
Rotate secrets regularly (SSH keys, API tokens)
Never echo secrets in run steps — they'll be masked in logs, but it's still bad practice

      - name: Deploy
        env:
          API_KEY: ${{ secrets.PROD_API_KEY }}
        run: ./deploy.sh

When to Use CI/CD

✅ Any team with more than one developer

✅ Frequent deploys (more than once a week)

✅ You have a test suite (even a small one)

✅ Multiple environments (dev, staging, prod)

✅ Open source projects where contributors submit PRs

When NOT to Use (or Keep It Simple)

❌ Solo hobby project with no test suite — a basic deploy script is fine

❌ Legacy monolith where builds take 45 minutes — fix the build first

❌ Highly regulated environments where automated prod deploys are prohibited — use CD to staging only, with manual prod promotion

Common Mistakes

1. Not pinning action versions

# Bad — can break silently when the action updates
uses: actions/checkout@main

# Good — locked to a specific version
uses: actions/checkout@v4

2. Running everything on every push

Use path filters to skip unnecessary runs:

on:
  push:
    paths:
      - 'src/**'
      - 'package.json'

3. Storing secrets in env files

Don't commit .env.production to the repo. Use GitHub Secrets + a secrets manager (HashiCorp Vault, AWS Secrets Manager) for anything sensitive.

4. No rollback plan

Tag your Docker images with the git SHA. If prod breaks, you can redeploy the previous image in 30 seconds.

Full Pipeline at a Glance

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to registry
        run: |
          echo ${{ secrets.DOCKER_TOKEN }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
          docker push myapp:${{ github.sha }}
      - name: Deploy
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          script: |
            docker pull myapp:${{ github.sha }}
            docker stop myapp || true
            docker run -d --name myapp -p 3000:3000 myapp:${{ github.sha }}

Practical Takeaways

Start small: even a single npm test in CI adds real value
needs: keyword is your sequencing primitive — use it
Branch protection rules + required CI checks = no broken code on main
Commit SHA tagging on Docker images = instant rollback capability
Cache dependencies — it's free performance
Use GitHub Environments for approval gates before prod

The goal isn't a perfect pipeline on day one. It's getting something automated, then adding stages as your confidence and test coverage grow.