Package it as a Helm chart
Continues from the last build: TaskFlow runs on EKS via a pile of raw YAML you copy-edit per environment.
Last rung you got TaskFlow running on EKS. It works, but the way you got there does not scale.
What you'll build
You will have a single versioned Helm chart that renders the full TaskFlow stack (frontend Deployment + Service, backend Deployment + Service, ConfigMap, Secret, Ingress) on EKS, driven by a shared values.yaml plus thin values-staging.yaml and values-prod.yaml overlays. You can install staging and prod from the same chart, see exactly what will be applied with helm template, upgrade in place, and roll back a bad release to the previous revision with one atomic command.
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
apiVersion: v2 name: taskflow description: TaskFlow task tracker - frontend, backend, and config for EKS type: application # version is the CHART version, bumped whenever templates or defaults change version: 0.1.0 # appVersion tracks the TaskFlow app release the chart ships by default appVersion: "1.0.0" maintainers: - name: platform-team
Reading this file
apiVersion: v2v2 marks this as a Helm 3 chart; v1 was the old Helm 2 format.type: applicationThis chart deploys an app, as opposed to type library which only shares template helpers.version: 0.1.0The chart's own version; you bump this every time you change templates or defaults.appVersion: "1.0.0"The version of TaskFlow itself that the chart installs by default, separate from the chart version.
Chart metadata. apiVersion v2 is Helm 3. Bump version on every chart change.
That's 1 of 8 explained code blocks in this single project.
The build, milestone by milestone
- 1
Scaffold the chart and define shared labels in _helpers.tpl
3 guided stepsRaw manifests duplicate metadata across every file, so labels drift and selectors silently stop matching pods. Named helpers centralize that boilerplate. selectorLabels in particular must stay immutable, mixing them into both the Deployment selector and the Pod template guarantees they agree.
- 2
Template the full stack: Deployments, Services, ConfigMap, Secret, Ingress
4 guided stepsThis is the core conversion: the shape of TaskFlow now lives in templates once, not duplicated per environment. Splitting config into a ConfigMap (non-secret) and a Secret (DATABASE_URL) keeps the 12-factor contract and keeps creds out of plain ConfigMaps.
- 3
Write per-environment overlays: values-staging.yaml and values-prod.yaml
3 guided stepsThis is the payoff for templating. Two thin overlays replace two full copied manifest folders. A reviewer can see the entire staging-vs-prod difference in a few lines instead of diffing two directories, and the shared shape can never drift because it is defined once.
- 4
Enforce required values with values.schema.json, add NOTES.txt, then install, upgrade, and roll back
4 guided stepsA schema turns the no-real-creds and correct-shape rules from advisory comments into a gate Helm enforces before the cluster ever sees the values, catching a missing DATABASE_URL or a typo at lint time. Helm also tracks every release as a revision: upgrade --install is idempotent (it installs if absent, upgrades if present), and rollback restores the exact previous revision's manifests in one step. That atomic undo is the capability raw kubectl apply never gave you.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building