Phase 05 · Production & GitOpsChapter 31 of 33

Phase 05Read time ~15 minDifficulty intermediate

Kubernetes + CI/CD 🚀

Warrior, this is where Kubernetes becomes part of a real software delivery system.

In this chapter (68 sections)

Until now, you've mostly learned:

Developer
   ↓
Docker
   ↓
Kubernetes
   ↓
Application

Now we'll build:

Developer
   ↓
Git
   ↓
CI/CD
   ↓
Docker Image
   ↓
Container Registry
   ↓
Kubernetes
   ↓
Production

1. What is CI/CD?#

CI/CD stands for:

CI — Continuous Integration#

Whenever developers push code:

Git Push
   ↓
Build
   ↓
Test
   ↓
Quality checks

The goal is to catch problems early.

CD — Continuous Delivery / Deployment#

After CI succeeds:

Build Image
   ↓
Push Image
   ↓
Deploy
   ↓
Kubernetes

Depending on the organization, "CD" can mean:

Continuous Delivery — production-ready changes are prepared, but deployment may require approval.
Continuous Deployment — successful changes are automatically deployed.

2. Without CI/CD#

Imagine manually deploying:

Developer
   ↓
docker build
   ↓
docker push
   ↓
kubectl set image
   ↓
kubectl rollout status

This becomes painful.

Every deployment requires manual work.

And humans make mistakes.

3. With CI/CD#

Instead:

Developer
    │
    │ git push
    ↓
GitHub
    │
    ↓
CI/CD Pipeline
    │
    ├── Test
    ├── Build
    ├── Security Scan
    ├── Docker Build
    ├── Push Image
    └── Deploy
            │
            ↓
        Kubernetes

You push code.

The pipeline handles the repetitive work.

4. The complete pipeline#

For your Node.js application:

                 Developer
                     │
                  git push
                     │
                     ↓
                  GitHub
                     │
                     ↓
              GitHub Actions
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
        Test       Lint       Build
          │          │          │
          └──────────┼──────────┘
                     ↓
                Docker Build
                     │
                     ↓
              Container Registry
                     │
                     ↓
                Kubernetes
                     │
                 Deployment
                     │
                     ↓
                Rolling Update
                     │
                     ↓
                  Pods

5. Example Node.js project#

Suppose:

node-api/
│
├── src/
│   └── server.js
│
├── package.json
├── package-lock.json
├── Dockerfile
└── k8s/
    ├── deployment.yaml
    └── service.yaml

Application:

const express = require("express");
 
const app = express();
 
app.get("/", (req, res) => {
  res.json({
    message: "Hello Kubernetes"
  });
});
 
app.get("/health", (req, res) => {
  res.json({
    status: "ok"
  });
});
 
app.listen(3000, "0.0.0.0", () => {
  console.log("Server running on port 3000");
});

6. Dockerfile#

FROM node:22-alpine
 
WORKDIR /app
 
COPY package*.json ./
 
RUN npm ci --omit=dev
 
COPY . .
 
EXPOSE 3000
 
CMD ["node", "src/server.js"]

Now:

Source code
    ↓
Dockerfile
    ↓
Docker image

7. Why do we need a container registry?#

Your CI server builds:

node-api:1.0.0

But Kubernetes needs to retrieve that image.

So:

CI
 ↓
Docker Image
 ↓
Container Registry
 ↓
Kubernetes

Examples:

AWS      → ECR
Google   → Artifact Registry
Azure    → ACR
GitHub   → GHCR
Docker   → Docker Hub

8. Image tagging#

Never rely on:

latest

for production deployments.

Instead use:

node-api:1.0.0
node-api:1.0.1
node-api:1.1.0

or a Git commit SHA:

node-api:a84f92c

Even better, production systems can deploy immutable image digests:

node-api@sha256:...

Why?

Suppose:

node-api:latest

today means:

Version 1

Tomorrow someone pushes another image:

node-api:latest

Now the same tag points somewhere else.

That makes debugging and rollback harder.

9. Better image strategy#

Use:

Git commit
      ↓
Docker image
      ↓
Tag with commit SHA

For example:

node-api:8f31ac2

Then Kubernetes knows exactly which build you're running.

A common pattern is to use both:

node-api:1.5.0
node-api:8f31ac2

and deploy by immutable digest where appropriate.

10. GitHub Actions#

Let's use GitHub Actions as our CI/CD example.

Create:

.github/
└── workflows/
    └── deploy.yml

A basic CI workflow:

name: Node API CI
 
on:
  push:
    branches:
      - main
 
jobs:
  test:
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
 
      - name: Install dependencies
        run: npm ci
 
      - name: Run tests
        run: npm test

Now:

git push
   ↓
GitHub
   ↓
GitHub Actions
   ↓
npm ci
   ↓
npm test

11. CI should fail fast#

Suppose the test fails:

npm test
   ↓
FAIL

Then:

Docker build ❌
Deployment ❌

You don't want broken code reaching production.

So:

Test
 ↓
FAIL
 ↓
STOP

This is fundamental CI behavior.

12. Build Docker image in CI#

Add:

- name: Build Docker image
  run: |
    docker build \
      -t node-api:${{ github.sha }} .

Now:

Git commit SHA
      ↓
Docker tag

For example:

node-api:8e7f32a...

13. Push to registry#

Suppose you're using GHCR.

The general architecture becomes:

GitHub Actions
      ↓
Docker Build
      ↓
GHCR
      ↓
Kubernetes

The workflow needs credentials/permissions to push.

Never write credentials directly into:

run: docker login ... --password mypassword

Use GitHub Actions secrets or supported workload identity/OIDC approaches.

14. Secrets in CI/CD#

Common secrets:

AWS credentials
Registry credentials
Kubernetes credentials
API keys
Database credentials

Do not put them in:

Git repository
Dockerfile
source code

Use:

GitHub Actions Secrets
OIDC / workload identity
Cloud secret managers

15. Modern cloud authentication#

A particularly important production pattern is:

GitHub Actions
       ↓
OIDC
       ↓
Cloud IAM
       ↓
AWS / GCP / Azure

Instead of storing long-lived cloud access keys in GitHub.

For AWS, GitHub Actions can use OIDC to assume an IAM role.

Conceptually:

GitHub
   ↓
OIDC identity
   ↓
AWS IAM Role
   ↓
ECR / EKS

This reduces long-lived credential exposure.

16. CI vs CD#

Separate the concepts.

CI#

Checkout
 ↓
Install
 ↓
Lint
 ↓
Test
 ↓
Build

CD#

Build image
 ↓
Push registry
 ↓
Update Kubernetes
 ↓
Rollout
 ↓
Verify

Combined:

CI
 ↓
CD

17. Deploying Kubernetes from CI#

There are several strategies.

Strategy 1 — `kubectl set image`#

For example:

kubectl set image deployment/node-api \
  node-api=registry.example.com/node-api:${GITHUB_SHA}

Then:

kubectl rollout status deployment/node-api

This is simple.

18. Strategy 2 — Update YAML#

Your Deployment contains:

image: registry.example.com/node-api:1.0.0

CI changes it to:

image: registry.example.com/node-api:1.1.0

Then:

kubectl apply -f deployment.yaml

19. Strategy 3 — Kustomize#

Since you've just learned Kustomize, this is a natural fit.

Production:

images:
  - name: registry.example.com/node-api
    newTag: "8f31ac2"

CI updates the image tag.

Then:

kubectl apply -k k8s/overlays/production

Architecture:

Git
 ↓
CI
 ↓
Build image
 ↓
Registry
 ↓
Update Kustomize image
 ↓
kubectl apply -k
 ↓
Kubernetes

20. Strategy 4 — Helm#

You can also update:

image:
  repository: registry.example.com/node-api
  tag: "1.5.0"

Then:

helm upgrade node-api ./chart

So:

Kustomize

and:

Helm

both integrate naturally with CI/CD.

21. A complete pipeline#

Let's design one:

Developer
    │
    ↓
git push
    │
    ↓
GitHub
    │
    ↓
GitHub Actions
    │
    ├── Checkout
    ├── npm ci
    ├── Lint
    ├── Unit tests
    ├── Security scan
    ├── Docker build
    └── Docker push
             │
             ↓
       Container Registry
             │
             ↓
       Update Kustomize
             │
             ↓
       kubectl apply -k
             │
             ↓
          Kubernetes
             │
             ↓
       Rolling Deployment
             │
             ↓
       Readiness probes
             │
             ↓
           Success

22. Deployment verification#

Don't stop after:

kubectl apply

You need to verify.

Use:

kubectl rollout status deployment/node-api

If successful:

deployment "node-api" successfully rolled out

Then:

kubectl get pods

Then:

kubectl get svc

Then check application health.

23. What if deployment fails?#

Suppose the new image has a bug.

You might get:

CrashLoopBackOff

or:

Readiness probe failed

The pipeline should detect rollout failure.

For example:

kubectl rollout status deployment/node-api --timeout=5m

If it fails:

Deployment ❌

Then you can rollback.

24. Rollback#

You've already learned:

kubectl rollout undo deployment/node-api

So:

v1
 ↓
v2
 ↓
v2 broken
 ↓
rollback
 ↓
v1

A CI/CD system should make this process controlled and observable.

25. Kubernetes Deployment as the safety mechanism#

Suppose you deploy:

v2

with:

readinessProbe:
  httpGet:
    path: /health
    port: 3000

If new Pods aren't ready:

v2 Pod
   ↓
Readiness FAIL
   ↓
Not ready
   ↓
Service doesn't route normal traffic to it

This is why Chapter 14 and Chapter 24 were important.

CI/CD and Kubernetes features work together.

26. Deployment pipeline with readiness#

New image
   ↓
Deployment
   ↓
New Pod
   ↓
Startup
   ↓
Startup probe
   ↓
Readiness probe
   ↓
Ready
   ↓
Service traffic

If readiness fails:

New Pod
   ↓
NotReady
   ↓
Traffic not sent normally

27. Blue-Green deployment#

Another deployment strategy.

Suppose:

Blue = v1
Green = v2

You run both:

Deploy green:

       ┌──────── Service
       │
       ├── Blue v1
       │
       └── Green v2

Test green.

Then switch Service traffic:

Blue remains available for rollback.

28. Canary deployment#

Instead of sending everyone to v2:

100% → v1

you might gradually shift traffic:

95% → v1
5%  → v2

then:

90% → v1
10% → v2

then:

50% → v1
50% → v2

then:

0% → v1
100% → v2

This reduces deployment risk when implemented with suitable traffic-routing tooling.

29. Rolling vs Blue-Green vs Canary#

Strategy	Idea
Rolling	Gradually replace old Pods
Blue-Green	Run two environments and switch traffic
Canary	Gradually shift traffic
Recreate	Stop old before starting new

Simple mental model:

Rolling
v1 → v1/v2 → v2

Blue-Green
v1 + v2 → switch

Canary
v1 100% → 95/5 → 90/10 → 100% v2

30. CI/CD and environments#

You shouldn't necessarily deploy every branch directly to production.

A common structure:

feature branch
      ↓
Pull Request
      ↓
CI
      ↓
Tests
      ↓
merge main
      ↓
staging
      ↓
approval
      ↓
production

Example:

Development
     ↓
Staging
     ↓
Production

31. Git branch strategy#

A simple model:

feature/*
    ↓
Pull Request
    ↓
main
    ↓
Staging
    ↓
Production

Or some teams use:

main
 ↓
Production
 
feature/*
 ↓
Preview environments

There isn't one universally correct branching model.

The important thing is that the deployment process is predictable.

32. Environment-specific configuration#

Never do:

if production:
    hardcoded password

Instead:

Kubernetes ConfigMap
Kubernetes Secret
External Secret Manager

For example:

Development
 ↓
values-dev.yaml
 
Staging
 ↓
values-staging.yaml
 
Production
 ↓
values-prod.yaml

Or Kustomize:

base
 ↓
dev overlay
staging overlay
production overlay

33. CI/CD + Helm#

Suppose:

helm/
└── node-api/
    ├── Chart.yaml
    ├── values.yaml
    └── templates/

CI builds:

node-api:1.5.0

Then:

helm upgrade --install node-api ./node-api \
  --set image.tag=1.5.0

Then:

kubectl rollout status deployment/node-api

Architecture:

CI
 ↓
Docker
 ↓
Registry
 ↓
Helm
 ↓
Kubernetes

34. CI/CD + Kustomize#

Alternatively:

CI
 ↓
Docker
 ↓
Registry
 ↓
Kustomize
 ↓
kubectl apply -k

Example:

images:
  - name: registry.example.com/node-api
    newTag: "1.5.0"

Then:

kubectl apply -k k8s/overlays/production

35. GitOps#

Now we reach a very important concept.

Traditional CI/CD:

CI
 ↓
kubectl
 ↓
Kubernetes

GitOps changes the model.

Git
 ↓
Desired state
 ↓
GitOps controller
 ↓
Kubernetes

We'll study this deeply in Chapter 31 with Argo CD.

For now:

Git becomes the source of truth for the desired Kubernetes state.

36. Traditional CI/CD vs GitOps#

Traditional#

GitHub Actions
      │
      ↓
kubectl apply
      │
      ↓
Kubernetes

GitOps#

Git
 │
 │ desired state
 ↓
Argo CD
 │
 │ reconcile
 ↓
Kubernetes

This connects directly to Kubernetes' fundamental desired state + reconciliation model from Chapter 1.

37. Security in CI/CD#

A production pipeline should consider:

Dependency security#

npm audit

or specialized scanners.

Container scanning#

Scan:

Docker image

for vulnerabilities.

Secret scanning#

Detect accidentally committed:

API keys
passwords
tokens
private keys

Kubernetes manifest scanning#

Check for:

privileged: true
runAsRoot
excessive permissions

Tools vary by organization.

38. Don't deploy on every successful test blindly#

Imagine:

Developer pushes code
      ↓
Tests pass
      ↓
Production

This may be fine for some teams, but not all systems.

For critical production environments, you may require:

Tests
 ↓
Security
 ↓
Staging
 ↓
Smoke tests
 ↓
Approval
 ↓
Production

39. Smoke testing#

After deployment:

Deployment
   ↓
Health check
   ↓
GET /
   ↓
GET /health
   ↓
Verify response

Example:

curl https://api.example.com/health

Expected:

{
  "status": "ok"
}

If it fails:

Deployment verification ❌

40. Production CI/CD architecture#

A strong production pipeline can look like:

                         Git
                          │
                          ↓
                    Pull Request
                          │
                          ↓
                   ┌─────────────┐
                   │ CI Pipeline │
                   └──────┬──────┘
                          │
             ┌────────────┼────────────┐
             ↓            ↓            ↓
           Lint          Test       Security
             │            │            │
             └────────────┼────────────┘
                          ↓
                    Docker Build
                          ↓
                  Container Scan
                          ↓
                     Registry
                          ↓
                       Staging
                          ↓
                    Smoke Tests
                          ↓
                    Approval
                          ↓
                    Production
                          ↓
                    Kubernetes
                          ↓
                 Rolling/Canary
                          ↓
                    Monitoring

41. What happens when deployment fails?#

Let's trace it.

New image
   ↓
Deployment
   ↓
Pod starts
   ↓
Readiness probe
   ↓
FAIL

Kubernetes:

Pod = NotReady

CI:

rollout status
      ↓
timeout/failure

Pipeline:

Deployment failed

Then:

Rollback
   ↓
Previous ReplicaSet
   ↓
Healthy Pods

Monitoring should also alert the team.

42. The relationship between everything you've learned#

This is the most important architecture in the entire course so far:

                    Git
                     │
                     ↓
                    CI
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
       Testing                Docker
                                │
                                ↓
                         Container Registry
                                │
                                ↓
                           Kubernetes
                                │
                         ┌──────┴──────┐
                         ↓             ↓
                    Deployment       Service
                         │             │
                         ↓             ↓
                       Pods ←───────────┘
                         │
                 ┌───────┼────────┐
                 ↓       ↓        ↓
                HPA    Probes   NetworkPolicy
                 │
                 ↓
          Node Autoscaling
                 │
                 ↓
               Nodes

Then:

Monitoring
    ↓
Prometheus/Grafana
    ↓
Alerts

and:

Logging
    ↓
Centralized logs

43. A practical GitHub Actions pipeline#

Here's a simplified example.

name: Node API CI/CD
 
on:
  push:
    branches:
      - main
 
jobs:
 
  test:
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
 
      - name: Install
        run: npm ci
 
      - name: Test
        run: npm test
 
  build:
    needs: test
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Build Docker image
        run: |
          docker build \
            -t node-api:${{ github.sha }} .

Notice:

needs: test

This means:

test
 ↓
success
 ↓
build

If tests fail:

test ❌
 ↓
build doesn't run

44. Why Git SHA is useful#

Suppose production currently runs:

node-api:a81f2d1

Then new deployment:

node-api:b73ac92

If something breaks:

Which version?

Answer:

b73ac92

You can trace it back to Git.

This gives:

Git commit
    ↕
Docker image
    ↕
Kubernetes deployment

That's extremely valuable for debugging.

45. Image immutability#

Better:

node-api@sha256:abc123...

than relying only on:

node-api:latest

because the digest identifies the exact image content.

Production systems often use immutable image references or otherwise enforce immutable versioning.

46. Interview questions#

Q1. What is CI?#

Continuous Integration automatically builds and tests code changes so integration problems are detected early.

Q2. What is CD?#

Continuous Delivery/Deployment automates or streamlines delivery of validated changes to environments such as staging or production.

Q3. Why use a container registry?#

Kubernetes needs a reliable location from which nodes can pull container images.

Q4. Why avoid `latest`?#

Because it is mutable and makes deployments, auditing, reproducibility and rollback harder.

Q5. How does CI/CD deploy to Kubernetes?#

Typical flow:

Git
 ↓
CI
 ↓
Test
 ↓
Docker build
 ↓
Registry
 ↓
Update manifest/Helm/Kustomize
 ↓
kubectl/Argo CD
 ↓
Kubernetes

Q6. How do you verify deployment?#

kubectl rollout status deployment/node-api

plus:

kubectl get pods
kubectl logs
health/smoke tests
monitoring

Q7. What happens if a new version fails readiness?#

The new Pod is not considered ready and normally won't receive regular Service traffic; the rollout can stall or fail depending on Deployment configuration.

Q8. CI/CD vs GitOps?#

Traditional:

CI → kubectl → Kubernetes

GitOps:

Git → GitOps controller → Kubernetes

🧠 Chapter 30 Cheat Sheet#

CI
 ↓
Build + Test + Security
 
CD
 ↓
Deliver/Deploy
 
Docker
 ↓
Build image
 
Registry
 ↓
Store image
 
Kubernetes
 ↓
Run image
 
Deployment
 ↓
Rolling update
 
Readiness
 ↓
Safe traffic
 
Rollout status
 ↓
Deployment verification
 
Rollback
 ↓
Previous version

Best production flow to remember:#

Developer
   ↓
Git Push
   ↓
CI
   ├── Test
   ├── Lint
   ├── Security
   └── Build
          ↓
      Docker Image
          ↓
      Registry
          ↓
       Deploy
          ↓
     Kubernetes
          ↓
   Readiness Probes
          ↓
     Smoke Tests
          ↓
      Production

And the next evolution:#

Traditional CI/CD
 
Git → CI → kubectl → Kubernetes
 
GitOps
 
Git → Argo CD → Kubernetes

Next → Chapter 31 — GitOps + Argo CD 🔄#

This is one of the most important production Kubernetes concepts.

We'll learn:

What GitOps actually means
Why kubectl apply can become problematic at scale
Argo CD architecture
Desired state vs actual state
Reconciliation
Applications
Projects
Sync
Auto-sync
Self-healing
Drift detection
Rollback
Git repository structure
Helm + Argo CD
Kustomize + Argo CD
Multi-environment deployment
Complete GitOps architecture for your Next.js + Node.js + Redis + PostgreSQL system.

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 29 — Kubernetes on GCP & Azure ☁️Next ChapterChapter 31 — GitOps + Argo CD 🔄

Prev Next

In this chapter (68 sections)

Until now, you've mostly learned:

Developer
   ↓
Docker
   ↓
Kubernetes
   ↓
Application

Now we'll build:

Developer
   ↓
Git
   ↓
CI/CD
   ↓
Docker Image
   ↓
Container Registry
   ↓
Kubernetes
   ↓
Production

1. What is CI/CD?#

CI/CD stands for:

CI — Continuous Integration#

Whenever developers push code:

Git Push
   ↓
Build
   ↓
Test
   ↓
Quality checks

The goal is to catch problems early.

CD — Continuous Delivery / Deployment#

After CI succeeds:

Build Image
   ↓
Push Image
   ↓
Deploy
   ↓
Kubernetes

Depending on the organization, "CD" can mean:

Continuous Delivery — production-ready changes are prepared, but deployment may require approval.
Continuous Deployment — successful changes are automatically deployed.

2. Without CI/CD#

Imagine manually deploying:

Developer
   ↓
docker build
   ↓
docker push
   ↓
kubectl set image
   ↓
kubectl rollout status

This becomes painful.

Every deployment requires manual work.

And humans make mistakes.

3. With CI/CD#

Instead:

Developer
    │
    │ git push
    ↓
GitHub
    │
    ↓
CI/CD Pipeline
    │
    ├── Test
    ├── Build
    ├── Security Scan
    ├── Docker Build
    ├── Push Image
    └── Deploy
            │
            ↓
        Kubernetes

You push code.

The pipeline handles the repetitive work.

4. The complete pipeline#

For your Node.js application:

                 Developer
                     │
                  git push
                     │
                     ↓
                  GitHub
                     │
                     ↓
              GitHub Actions
                     │
          ┌──────────┼──────────┐
          ↓          ↓          ↓
        Test       Lint       Build
          │          │          │
          └──────────┼──────────┘
                     ↓
                Docker Build
                     │
                     ↓
              Container Registry
                     │
                     ↓
                Kubernetes
                     │
                 Deployment
                     │
                     ↓
                Rolling Update
                     │
                     ↓
                  Pods

5. Example Node.js project#

Suppose:

node-api/
│
├── src/
│   └── server.js
│
├── package.json
├── package-lock.json
├── Dockerfile
└── k8s/
    ├── deployment.yaml
    └── service.yaml

Application:

const express = require("express");
 
const app = express();
 
app.get("/", (req, res) => {
  res.json({
    message: "Hello Kubernetes"
  });
});
 
app.get("/health", (req, res) => {
  res.json({
    status: "ok"
  });
});
 
app.listen(3000, "0.0.0.0", () => {
  console.log("Server running on port 3000");
});

6. Dockerfile#

FROM node:22-alpine
 
WORKDIR /app
 
COPY package*.json ./
 
RUN npm ci --omit=dev
 
COPY . .
 
EXPOSE 3000
 
CMD ["node", "src/server.js"]

Now:

Source code
    ↓
Dockerfile
    ↓
Docker image

7. Why do we need a container registry?#

Your CI server builds:

node-api:1.0.0

But Kubernetes needs to retrieve that image.

So:

CI
 ↓
Docker Image
 ↓
Container Registry
 ↓
Kubernetes

Examples:

AWS      → ECR
Google   → Artifact Registry
Azure    → ACR
GitHub   → GHCR
Docker   → Docker Hub

8. Image tagging#

Never rely on:

latest

for production deployments.

Instead use:

node-api:1.0.0
node-api:1.0.1
node-api:1.1.0

or a Git commit SHA:

node-api:a84f92c

Even better, production systems can deploy immutable image digests:

node-api@sha256:...

Why?

Suppose:

node-api:latest

today means:

Version 1

Tomorrow someone pushes another image:

node-api:latest

Now the same tag points somewhere else.

That makes debugging and rollback harder.

9. Better image strategy#

Use:

Git commit
      ↓
Docker image
      ↓
Tag with commit SHA

For example:

node-api:8f31ac2

Then Kubernetes knows exactly which build you're running.

A common pattern is to use both:

node-api:1.5.0
node-api:8f31ac2

and deploy by immutable digest where appropriate.

10. GitHub Actions#

Let's use GitHub Actions as our CI/CD example.

Create:

.github/
└── workflows/
    └── deploy.yml

A basic CI workflow:

name: Node API CI
 
on:
  push:
    branches:
      - main
 
jobs:
  test:
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
 
      - name: Install dependencies
        run: npm ci
 
      - name: Run tests
        run: npm test

Now:

git push
   ↓
GitHub
   ↓
GitHub Actions
   ↓
npm ci
   ↓
npm test

11. CI should fail fast#

Suppose the test fails:

npm test
   ↓
FAIL

Then:

Docker build ❌
Deployment ❌

You don't want broken code reaching production.

So:

Test
 ↓
FAIL
 ↓
STOP

This is fundamental CI behavior.

12. Build Docker image in CI#

Add:

- name: Build Docker image
  run: |
    docker build \
      -t node-api:${{ github.sha }} .

Now:

Git commit SHA
      ↓
Docker tag

For example:

node-api:8e7f32a...

13. Push to registry#

Suppose you're using GHCR.

The general architecture becomes:

GitHub Actions
      ↓
Docker Build
      ↓
GHCR
      ↓
Kubernetes

The workflow needs credentials/permissions to push.

Never write credentials directly into:

run: docker login ... --password mypassword

Use GitHub Actions secrets or supported workload identity/OIDC approaches.

14. Secrets in CI/CD#

Common secrets:

AWS credentials
Registry credentials
Kubernetes credentials
API keys
Database credentials

Do not put them in:

Git repository
Dockerfile
source code

Use:

GitHub Actions Secrets
OIDC / workload identity
Cloud secret managers

15. Modern cloud authentication#

A particularly important production pattern is:

GitHub Actions
       ↓
OIDC
       ↓
Cloud IAM
       ↓
AWS / GCP / Azure

Instead of storing long-lived cloud access keys in GitHub.

For AWS, GitHub Actions can use OIDC to assume an IAM role.

Conceptually:

GitHub
   ↓
OIDC identity
   ↓
AWS IAM Role
   ↓
ECR / EKS

This reduces long-lived credential exposure.

16. CI vs CD#

Separate the concepts.

CI#

Checkout
 ↓
Install
 ↓
Lint
 ↓
Test
 ↓
Build

CD#

Build image
 ↓
Push registry
 ↓
Update Kubernetes
 ↓
Rollout
 ↓
Verify

Combined:

CI
 ↓
CD

17. Deploying Kubernetes from CI#

There are several strategies.

Strategy 1 — `kubectl set image`#

For example:

kubectl set image deployment/node-api \
  node-api=registry.example.com/node-api:${GITHUB_SHA}

Then:

kubectl rollout status deployment/node-api

This is simple.

18. Strategy 2 — Update YAML#

Your Deployment contains:

image: registry.example.com/node-api:1.0.0

CI changes it to:

image: registry.example.com/node-api:1.1.0

Then:

kubectl apply -f deployment.yaml

19. Strategy 3 — Kustomize#

Since you've just learned Kustomize, this is a natural fit.

Production:

images:
  - name: registry.example.com/node-api
    newTag: "8f31ac2"

CI updates the image tag.

Then:

kubectl apply -k k8s/overlays/production

Architecture:

Git
 ↓
CI
 ↓
Build image
 ↓
Registry
 ↓
Update Kustomize image
 ↓
kubectl apply -k
 ↓
Kubernetes

20. Strategy 4 — Helm#

You can also update:

image:
  repository: registry.example.com/node-api
  tag: "1.5.0"

Then:

helm upgrade node-api ./chart

So:

Kustomize

and:

Helm

both integrate naturally with CI/CD.

21. A complete pipeline#

Let's design one:

Developer
    │
    ↓
git push
    │
    ↓
GitHub
    │
    ↓
GitHub Actions
    │
    ├── Checkout
    ├── npm ci
    ├── Lint
    ├── Unit tests
    ├── Security scan
    ├── Docker build
    └── Docker push
             │
             ↓
       Container Registry
             │
             ↓
       Update Kustomize
             │
             ↓
       kubectl apply -k
             │
             ↓
          Kubernetes
             │
             ↓
       Rolling Deployment
             │
             ↓
       Readiness probes
             │
             ↓
           Success

22. Deployment verification#

Don't stop after:

kubectl apply

You need to verify.

Use:

kubectl rollout status deployment/node-api

If successful:

deployment "node-api" successfully rolled out

Then:

kubectl get pods

Then:

kubectl get svc

Then check application health.

23. What if deployment fails?#

Suppose the new image has a bug.

You might get:

CrashLoopBackOff

or:

Readiness probe failed

The pipeline should detect rollout failure.

For example:

kubectl rollout status deployment/node-api --timeout=5m

If it fails:

Deployment ❌

Then you can rollback.

24. Rollback#

You've already learned:

kubectl rollout undo deployment/node-api

So:

v1
 ↓
v2
 ↓
v2 broken
 ↓
rollback
 ↓
v1

A CI/CD system should make this process controlled and observable.

25. Kubernetes Deployment as the safety mechanism#

Suppose you deploy:

v2

with:

readinessProbe:
  httpGet:
    path: /health
    port: 3000

If new Pods aren't ready:

v2 Pod
   ↓
Readiness FAIL
   ↓
Not ready
   ↓
Service doesn't route normal traffic to it

This is why Chapter 14 and Chapter 24 were important.

CI/CD and Kubernetes features work together.

26. Deployment pipeline with readiness#

New image
   ↓
Deployment
   ↓
New Pod
   ↓
Startup
   ↓
Startup probe
   ↓
Readiness probe
   ↓
Ready
   ↓
Service traffic

If readiness fails:

New Pod
   ↓
NotReady
   ↓
Traffic not sent normally

27. Blue-Green deployment#

Another deployment strategy.

Suppose:

Blue = v1
Green = v2

You run both:

Deploy green:

       ┌──────── Service
       │
       ├── Blue v1
       │
       └── Green v2

Test green.

Then switch Service traffic:

Blue remains available for rollback.

28. Canary deployment#

Instead of sending everyone to v2:

100% → v1

you might gradually shift traffic:

95% → v1
5%  → v2

then:

90% → v1
10% → v2

then:

50% → v1
50% → v2

then:

0% → v1
100% → v2

This reduces deployment risk when implemented with suitable traffic-routing tooling.

29. Rolling vs Blue-Green vs Canary#

Strategy	Idea
Rolling	Gradually replace old Pods
Blue-Green	Run two environments and switch traffic
Canary	Gradually shift traffic
Recreate	Stop old before starting new

Simple mental model:

Rolling
v1 → v1/v2 → v2

Blue-Green
v1 + v2 → switch

Canary
v1 100% → 95/5 → 90/10 → 100% v2

30. CI/CD and environments#

You shouldn't necessarily deploy every branch directly to production.

A common structure:

feature branch
      ↓
Pull Request
      ↓
CI
      ↓
Tests
      ↓
merge main
      ↓
staging
      ↓
approval
      ↓
production

Example:

Development
     ↓
Staging
     ↓
Production

31. Git branch strategy#

A simple model:

feature/*
    ↓
Pull Request
    ↓
main
    ↓
Staging
    ↓
Production

Or some teams use:

main
 ↓
Production
 
feature/*
 ↓
Preview environments

There isn't one universally correct branching model.

The important thing is that the deployment process is predictable.

32. Environment-specific configuration#

Never do:

if production:
    hardcoded password

Instead:

Kubernetes ConfigMap
Kubernetes Secret
External Secret Manager

For example:

Development
 ↓
values-dev.yaml
 
Staging
 ↓
values-staging.yaml
 
Production
 ↓
values-prod.yaml

Or Kustomize:

base
 ↓
dev overlay
staging overlay
production overlay

33. CI/CD + Helm#

Suppose:

helm/
└── node-api/
    ├── Chart.yaml
    ├── values.yaml
    └── templates/

CI builds:

node-api:1.5.0

Then:

helm upgrade --install node-api ./node-api \
  --set image.tag=1.5.0

Then:

kubectl rollout status deployment/node-api

Architecture:

CI
 ↓
Docker
 ↓
Registry
 ↓
Helm
 ↓
Kubernetes

34. CI/CD + Kustomize#

Alternatively:

CI
 ↓
Docker
 ↓
Registry
 ↓
Kustomize
 ↓
kubectl apply -k

Example:

images:
  - name: registry.example.com/node-api
    newTag: "1.5.0"

Then:

kubectl apply -k k8s/overlays/production

35. GitOps#

Now we reach a very important concept.

Traditional CI/CD:

CI
 ↓
kubectl
 ↓
Kubernetes

GitOps changes the model.

Git
 ↓
Desired state
 ↓
GitOps controller
 ↓
Kubernetes

We'll study this deeply in Chapter 31 with Argo CD.

For now:

Git becomes the source of truth for the desired Kubernetes state.

36. Traditional CI/CD vs GitOps#

Traditional#

GitHub Actions
      │
      ↓
kubectl apply
      │
      ↓
Kubernetes

GitOps#

Git
 │
 │ desired state
 ↓
Argo CD
 │
 │ reconcile
 ↓
Kubernetes

This connects directly to Kubernetes' fundamental desired state + reconciliation model from Chapter 1.

37. Security in CI/CD#

A production pipeline should consider:

Dependency security#

npm audit

or specialized scanners.

Container scanning#

Scan:

Docker image

for vulnerabilities.

Secret scanning#

Detect accidentally committed:

API keys
passwords
tokens
private keys

Kubernetes manifest scanning#

Check for:

privileged: true
runAsRoot
excessive permissions

Tools vary by organization.

38. Don't deploy on every successful test blindly#

Imagine:

Developer pushes code
      ↓
Tests pass
      ↓
Production

This may be fine for some teams, but not all systems.

For critical production environments, you may require:

Tests
 ↓
Security
 ↓
Staging
 ↓
Smoke tests
 ↓
Approval
 ↓
Production

39. Smoke testing#

After deployment:

Deployment
   ↓
Health check
   ↓
GET /
   ↓
GET /health
   ↓
Verify response

Example:

curl https://api.example.com/health

Expected:

{
  "status": "ok"
}

If it fails:

Deployment verification ❌

40. Production CI/CD architecture#

A strong production pipeline can look like:

                         Git
                          │
                          ↓
                    Pull Request
                          │
                          ↓
                   ┌─────────────┐
                   │ CI Pipeline │
                   └──────┬──────┘
                          │
             ┌────────────┼────────────┐
             ↓            ↓            ↓
           Lint          Test       Security
             │            │            │
             └────────────┼────────────┘
                          ↓
                    Docker Build
                          ↓
                  Container Scan
                          ↓
                     Registry
                          ↓
                       Staging
                          ↓
                    Smoke Tests
                          ↓
                    Approval
                          ↓
                    Production
                          ↓
                    Kubernetes
                          ↓
                 Rolling/Canary
                          ↓
                    Monitoring

41. What happens when deployment fails?#

Let's trace it.

New image
   ↓
Deployment
   ↓
Pod starts
   ↓
Readiness probe
   ↓
FAIL

Kubernetes:

Pod = NotReady

CI:

rollout status
      ↓
timeout/failure

Pipeline:

Deployment failed

Then:

Rollback
   ↓
Previous ReplicaSet
   ↓
Healthy Pods

Monitoring should also alert the team.

42. The relationship between everything you've learned#

This is the most important architecture in the entire course so far:

                    Git
                     │
                     ↓
                    CI
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
       Testing                Docker
                                │
                                ↓
                         Container Registry
                                │
                                ↓
                           Kubernetes
                                │
                         ┌──────┴──────┐
                         ↓             ↓
                    Deployment       Service
                         │             │
                         ↓             ↓
                       Pods ←───────────┘
                         │
                 ┌───────┼────────┐
                 ↓       ↓        ↓
                HPA    Probes   NetworkPolicy
                 │
                 ↓
          Node Autoscaling
                 │
                 ↓
               Nodes

Then:

Monitoring
    ↓
Prometheus/Grafana
    ↓
Alerts

and:

Logging
    ↓
Centralized logs

43. A practical GitHub Actions pipeline#

Here's a simplified example.

name: Node API CI/CD
 
on:
  push:
    branches:
      - main
 
jobs:
 
  test:
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
 
      - name: Install
        run: npm ci
 
      - name: Test
        run: npm test
 
  build:
    needs: test
    runs-on: ubuntu-latest
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Build Docker image
        run: |
          docker build \
            -t node-api:${{ github.sha }} .

Notice:

needs: test

This means:

test
 ↓
success
 ↓
build

If tests fail:

test ❌
 ↓
build doesn't run

44. Why Git SHA is useful#

Suppose production currently runs:

node-api:a81f2d1

Then new deployment:

node-api:b73ac92

If something breaks:

Which version?

Answer:

b73ac92

You can trace it back to Git.

This gives:

Git commit
    ↕
Docker image
    ↕
Kubernetes deployment

That's extremely valuable for debugging.

45. Image immutability#

Better:

node-api@sha256:abc123...

than relying only on:

node-api:latest

because the digest identifies the exact image content.

Production systems often use immutable image references or otherwise enforce immutable versioning.

46. Interview questions#

Q1. What is CI?#

Continuous Integration automatically builds and tests code changes so integration problems are detected early.

Q2. What is CD?#

Continuous Delivery/Deployment automates or streamlines delivery of validated changes to environments such as staging or production.

Q3. Why use a container registry?#

Kubernetes needs a reliable location from which nodes can pull container images.

Q4. Why avoid `latest`?#

Because it is mutable and makes deployments, auditing, reproducibility and rollback harder.

Q5. How does CI/CD deploy to Kubernetes?#

Typical flow:

Git
 ↓
CI
 ↓
Test
 ↓
Docker build
 ↓
Registry
 ↓
Update manifest/Helm/Kustomize
 ↓
kubectl/Argo CD
 ↓
Kubernetes

Q6. How do you verify deployment?#

kubectl rollout status deployment/node-api

plus:

kubectl get pods
kubectl logs
health/smoke tests
monitoring

Q7. What happens if a new version fails readiness?#

The new Pod is not considered ready and normally won't receive regular Service traffic; the rollout can stall or fail depending on Deployment configuration.

Q8. CI/CD vs GitOps?#

Traditional:

CI → kubectl → Kubernetes

GitOps:

Git → GitOps controller → Kubernetes

🧠 Chapter 30 Cheat Sheet#

CI
 ↓
Build + Test + Security
 
CD
 ↓
Deliver/Deploy
 
Docker
 ↓
Build image
 
Registry
 ↓
Store image
 
Kubernetes
 ↓
Run image
 
Deployment
 ↓
Rolling update
 
Readiness
 ↓
Safe traffic
 
Rollout status
 ↓
Deployment verification
 
Rollback
 ↓
Previous version

Best production flow to remember:#

Developer
   ↓
Git Push
   ↓
CI
   ├── Test
   ├── Lint
   ├── Security
   └── Build
          ↓
      Docker Image
          ↓
      Registry
          ↓
       Deploy
          ↓
     Kubernetes
          ↓
   Readiness Probes
          ↓
     Smoke Tests
          ↓
      Production

And the next evolution:#

Traditional CI/CD
 
Git → CI → kubectl → Kubernetes
 
GitOps
 
Git → Argo CD → Kubernetes

Next → Chapter 31 — GitOps + Argo CD 🔄#

This is one of the most important production Kubernetes concepts.

We'll learn:

What GitOps actually means
Why kubectl apply can become problematic at scale
Argo CD architecture
Desired state vs actual state
Reconciliation
Applications
Projects
Sync
Auto-sync
Self-healing
Drift detection
Rollback
Git repository structure
Helm + Argo CD
Kustomize + Argo CD
Multi-environment deployment
Complete GitOps architecture for your Next.js + Node.js + Redis + PostgreSQL system.

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 29 — Kubernetes on GCP & Azure ☁️Next ChapterChapter 31 — GitOps + Argo CD 🔄

1. What is CI/CD?#

CI — Continuous Integration#

CD — Continuous Delivery / Deployment#

2. Without CI/CD#

3. With CI/CD#

4. The complete pipeline#

5. Example Node.js project#

6. Dockerfile#

7. Why do we need a container registry?#

8. Image tagging#

9. Better image strategy#

10. GitHub Actions#

11. CI should fail fast#

12. Build Docker image in CI#

13. Push to registry#

14. Secrets in CI/CD#

15. Modern cloud authentication#

16. CI vs CD#

CI#

CD#

17. Deploying Kubernetes from CI#

Strategy 1 — kubectl set image#

18. Strategy 2 — Update YAML#

19. Strategy 3 — Kustomize#

20. Strategy 4 — Helm#

21. A complete pipeline#

22. Deployment verification#

23. What if deployment fails?#

24. Rollback#

25. Kubernetes Deployment as the safety mechanism#

26. Deployment pipeline with readiness#

27. Blue-Green deployment#

28. Canary deployment#

29. Rolling vs Blue-Green vs Canary#

30. CI/CD and environments#

31. Git branch strategy#

32. Environment-specific configuration#

33. CI/CD + Helm#

34. CI/CD + Kustomize#

35. GitOps#

36. Traditional CI/CD vs GitOps#

Traditional#

GitOps#

37. Security in CI/CD#

Dependency security#

Container scanning#

Secret scanning#

Kubernetes manifest scanning#

38. Don't deploy on every successful test blindly#

39. Smoke testing#

40. Production CI/CD architecture#

41. What happens when deployment fails?#

42. The relationship between everything you've learned#

43. A practical GitHub Actions pipeline#

44. Why Git SHA is useful#

45. Image immutability#

46. Interview questions#

Q1. What is CI?#

Q2. What is CD?#

Q3. Why use a container registry?#

Q4. Why avoid latest?#

Q5. How does CI/CD deploy to Kubernetes?#

Q6. How do you verify deployment?#

Q7. What happens if a new version fails readiness?#

Q8. CI/CD vs GitOps?#

🧠 Chapter 30 Cheat Sheet#

Best production flow to remember:#

And the next evolution:#

Next → Chapter 31 — GitOps + Argo CD 🔄#

Finished this chapter?

1. What is CI/CD?#

CI — Continuous Integration#

CD — Continuous Delivery / Deployment#

2. Without CI/CD#

3. With CI/CD#

4. The complete pipeline#

5. Example Node.js project#

6. Dockerfile#

7. Why do we need a container registry?#

8. Image tagging#

Strategy 1 — `kubectl set image`#

Q4. Why avoid `latest`?#

Strategy 1 — `kubectl set image`#

Q4. Why avoid `latest`?#