Capstone · DevOps: Git, Docker, Kubernetes and CI/CD
Capstone: a canteen order API from commit to monitored production
The brief
Build the whole delivery path for a college canteen's order API. You write and test the order maths, keep the code on GitHub, package it as a non-root image, let GitHub Actions test, scan and publish it to GHCR, create the namespace and settings with Terraform, deploy it to Kubernetes with probes and limits, release v1.0.0, and watch it with Prometheus and an alert you have seen fire.
Why it matters
This is the project interviewers ask about: one repository where a commit travels all the way to a running, monitored service. It shows you can connect Git, Docker, CI/CD, infrastructure as code, Kubernetes and monitoring, which is what DevOps, platform and SRE roles in Indian product companies and service firms expect. Put the repository link and the architecture diagram on your CV.
Skills you practise
- JavaScript order logic with tests
- Git and GitHub
- node --test
- non-root Docker images
- GitHub Actions with a Trivy gate
- GHCR
- Terraform with the Kubernetes provider
- Kubernetes Deployments and Services
- versioned releases
- Prometheus and alerting
- README and runbook
You need
- A free GitHub account, with the GitHub CLI (gh) installed and logged in (gh auth login)
- Node.js 24 (or 22), Git, Docker Desktop or Docker Engine
- kind and kubectl; Terraform 1.6 or newer (or OpenTofu)
- A bash-style terminal: on Windows use Git Bash or WSL
What you will have at the end
A public canteen-api repository: tested order logic, a non-root Dockerfile, a CI workflow that tests, scans and publishes to GHCR, Terraform for the namespace and settings, Kubernetes manifests, an in-cluster Prometheus with an alert, a v1.0.0 release, and a README and runbook.
How it is marked (rubric, 100 points)
| End-to-end delivery worksEvery step passes: tests, image, green CI, GHCR image, Terraform with no drift, healthy pods, v1.0.0 live, scraping and a firing alert. | 35 |
|---|---|
| Engineering qualityMoney in paise with tests, input validation, pinned versions, non-root image, least-privilege workflow, probes and limits. | 20 |
| Infrastructure and release practiceState kept out of Git, the provider pinned to the right context, releases from tags, the cluster matching what is in Git. | 15 |
| OperabilityMetrics, an alert on a user-visible symptom, a runbook, and a rollback you have tested. | 15 |
| Documentation and storyA README with a diagram that a stranger can follow, and a two-minute explanation you could give in an interview. | 15 |
0/12 steps done
Step 1 of 12
Create the repository on GitHub
A canteen-api repository on GitHub has your first commit on main, pushed.
Make a folder canteen-api with the files from the tabs (orders.js, server.js, package.json, README.md) and a .gitignore with node_modules/, .terraform/, *.tfstate* and .env. gh repo create makes the GitHub repository, adds it as the remote origin and pushes in one command.
Then protect main in the repository settings (Settings > Rules or Branches): changes arrive only through pull requests whose checks pass. That one rule is what makes the pipeline trustworthy.
$ git remote -v; git status -sb | head -1Also check yourself
Your notes: orders.js, Dockerfile, ci.yml, main.tf, k8s.yaml, README.md
Write down each command you ran. It goes into your project summary.