Capstone project: from commit to monitored production: DevOps: Git, Docker, Kubernetes and CI/CD (Expert)

Why one end-to-end project beats ten tutorials

Interviewers see many CVs that list Docker, Kubernetes, Terraform and Jenkins. What they rarely see is proof that the person can connect them. A capstone project is that proof: one public repository where a commit travels all the way to a running, monitored service. It also gives you real stories for interviews: the bug that broke the pipeline, the alert that fired, the rollback you tested.

The app: a college canteen order API

Keep the app small so the effort goes into delivery, not features. Use a language you already know: Node.js with Express, Python with FastAPI, or Go. Five endpoints are enough:

GET /menu: today's items and prices
POST /orders: place an order (validate items and quantity; the server calculates the price)
GET /orders/{id}: order status
GET /healthz: returns 200 when the app is ready (for Kubernetes probes)
GET /metrics: Prometheus metrics, such as request counts and durations by route and status code

Store orders in PostgreSQL. Write a handful of unit tests and one test that calls the API.

The pipeline, stage by stage

Stage	What you build	Done when
1. Git repository	Repo with README, .gitignore, branch protection on main	Direct pushes to main are blocked; pull requests need passing checks
2. Dockerfile	Multi-stage build, non-root user, .dockerignore, health check endpoint	Image under about 200 MB, runs as a non-root user
3. CI (GitHub Actions)	Lint, test, scan (dependencies and image), build, push image tagged with the commit SHA	A pull request shows green checks; main pushes ghcr.io/you/canteen-api:<sha>
4. Infrastructure (Terraform)	A cluster or a VM running k3s, with remote state	terraform plan shows no changes after apply; terraform destroy works
5. Kubernetes	Deployment, Service, Ingress, ConfigMap, Secret (or a Helm chart), probes and resource limits	kubectl rollout status succeeds; the API answers through the Ingress
6. Delivery	Argo CD Application watching a deploy folder, or a deploy job in CI	Changing the image tag in Git updates the cluster
7. Observability	Prometheus scraping /metrics, a Grafana dashboard, one SLO and an alert	You can show the alert firing when you break the app on purpose
8. Docs	Runbook and README with a diagram	A stranger can run it and fix the main alert by following your docs

A Dockerfile that passes review

dockerfile

FROM node:22-slim AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM node:22-slim
ENV NODE_ENV=production
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
USER node
EXPOSE 8080
CMD ["node", "dist/server.js"]

Build tools stay in the first stage. The final image runs as the built-in non-root user "node".

The CI workflow

yaml

name: ci
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
  packages: write
jobs:
  build:
    runs-on: ubuntu-latest
    env:
      IMAGE: ghcr.io/your-user/canteen-api:${{ github.sha }}   # image names must be lowercase
    steps:
      - uses: actions/checkout@v7          # pin by commit SHA in your real repo (module 11)
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: docker build -t "$IMAGE" .
      - uses: aquasecurity/trivy-action@v0.36.0  # pin by commit SHA in your real repo
        with:
          image-ref: ${{ env.IMAGE }}
          severity: HIGH,CRITICAL
          exit-code: '1'
      - if: github.ref == 'refs/heads/main'
        run: |
          echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin
          docker push "$IMAGE"

Every pull request is linted, tested and scanned. Only main pushes an image, tagged with the exact commit.

Infrastructure without a surprise bill

Managed Kubernetes services charge for the control plane and the nodes even when idle. For a learning project, a free local cluster (kind, k3d or minikube) is perfectly acceptable, or one small cloud VM running k3s created by Terraform. If you use a cloud account, set a budget alert first, keep Terraform state in a remote backend, and run terraform destroy when you finish a session. Check current pricing and free tiers before you start.

One SLO and one alert

Pick one SLI (service level indicator) that matters to a hungry student: the share of POST /orders requests that succeed. Set an SLO (service level objective) such as 99% over 7 days. Then alert when the error rate is clearly too high for long enough to matter.

yaml

groups:
  - name: canteen-slo
    rules:
      - alert: CanteenOrdersFailing
        expr: |
          sum(rate(http_requests_total{job="canteen-api",route="/orders",code=~"5.."}[5m]))
            /
          sum(rate(http_requests_total{job="canteen-api",route="/orders"}[5m])) > 0.05
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "More than 5% of order requests are failing"
          runbook_url: "https://github.com/your-user/canteen-api/blob/main/docs/runbook.md"

A simple threshold alert that links to the runbook. A burn-rate alert (module 10) is a good stretch goal.

A six-week plan (about 6 to 8 hours a week)

Week	Goal
1	App with tests, repository, branch protection, README skeleton
2	Dockerfile, Docker Compose with PostgreSQL, CI for lint and test
3	Scanning, image build and push in CI; Terraform for the cluster or VM
4	Kubernetes manifests or Helm chart; Argo CD or a deploy job
5	Prometheus, Grafana dashboard, SLO and alert; break it on purpose and watch the alert
6	Runbook, README with diagram, a short demo recording, tidy commit history, destroy cloud resources

Careful: Common mistakes: building a huge app and never reaching deployment; committing a kubeconfig or .env file; leaving a cloud cluster running for a month; a README that says only "my DevOps project". Keep the app tiny, scan for secrets, destroy resources after each session, and write the README for a busy interviewer.

Tip: Record a 3-minute screen video: open a pull request, watch the checks pass, merge, watch Argo CD sync, then break the app and show the alert. Link it at the top of the README.

Capstone project: from commit to monitored production

Explanation

Why one end-to-end project beats ten tutorials

The app: a college canteen order API

The pipeline, stage by stage

A Dockerfile that passes review

The CI workflow

Infrastructure without a surprise bill

One SLO and one alert

A six-week plan (about 6 to 8 hours a week)

Need help?

Watch the lesson

In real life: A final-year student in Nagpur gets shortlisted with one project

Practice (0/4 done)

Quick quiz

Read more (free)

Before this, learn

Related topics

Next steps

Capstone project: from commit to monitored production

Explanation

Why one end-to-end project beats ten tutorials

The app: a college canteen order API

The pipeline, stage by stage

A Dockerfile that passes review

The CI workflow

Infrastructure without a surprise bill

One SLO and one alert

A six-week plan (about 6 to 8 hours a week)

Need help?

Watch the lesson

In real life: A final-year student in Nagpur gets shortlisted with one project

Practice (0/4 done)

Quick quiz

Read more (free)

Related help

Before this, learn

Related topics

Questions people ask about this

Next steps