Project 1 takes your tiny app and gives it the first two pillars of production: it’s containerised so it runs anywhere, and it’s shipped by a CI/CD pipeline so every push is automatically built, tested, and published. No manual steps.

🎯 Learning Objectives

• Write a production-quality Dockerfile (multi-stage, non-root)
• Build a CI pipeline that tests on every push
• Automatically build and publish an image to a registry
• Tag images meaningfully for traceability

Step 1 — A Production Dockerfile

A good image is small, secure, and cached well. Use a multi-stage build (build tools stay out of the final image) and run as a non-root user:

# ---- build stage ----
FROM node:20-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci                 # install deps (cached unless package files change)
COPY . .
RUN npm run build

# ---- runtime stage ----
FROM node:20-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node                  # never run as root
EXPOSE 3000
HEALTHCHECK CMD curl -f http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]

Verify it locally before automating:

docker build -t myapp:dev .
docker run -p 3000:3000 myapp:dev

Step 2 — The CI Pipeline (Test on Every Push)

Using GitHub Actions, the first job runs your tests on every push and pull request — the safety net that lets you move fast:

# .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"
    - run: npm ci
    - run: npm test

Now a red X on a pull request means “don’t merge this” — automated, every time.

Step 3 — Build & Publish the Image

Add a second job that builds the Docker image and pushes it to a registry (here, GitHub Container Registry) — but only on main, and only after tests pass:

  build-and-push:
  needs: test                      # only if tests pass
  if: github.ref == 'refs/heads/main'
  runs-on: ubuntu-latest
  permissions:
    contents: read
    packages: write
  steps:
    - uses: actions/checkout@v4
    - uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}
    - uses: docker/build-push-action@v6
      with:
        push: true
        tags: |
          ghcr.io/${{ github.repository }}:latest
          ghcr.io/${{ github.repository }}:${{ github.sha }}

Step 4 — Tag for Traceability

Notice the two tags above: latest and the commit SHA. This matters more than it looks:

Deploying by SHA (not latest) means you always know exactly what code is running, and rollback is just deploying a previous SHA. This is the foundation Project 3’s GitOps will build on.

CI ✓ test        (12s)
CI ✓ build-and-push
 → pushed ghcr.io/you/myapp:latest
 → pushed ghcr.io/you/myapp:a1b2c3d
Deploy-ready image published.

🧪 Hands-on Lab

🧠 Knowledge Check

💼 Interview Preparation

Summary

Project 1 is done: your app is containerised with a solid Dockerfile and shipped by a CI/CD pipeline that tests, builds, and publishes traceable images automatically. Next, Project 2 provisions real infrastructure with Terraform and deploys the app to Kubernetes.