Package it with Helm
Continues from the last build: Stage 1 left the Storefront web service running healthy on Kubernetes with probes, ConfigMap/Secret config, resource bounds, and a working HPA, but every object lives in hand-maintained raw YAML.
The Storefront web service runs well, but the manifests are raw YAML that you copy-paste per environment.
What you'll build
A versioned Helm chart for the Storefront web service whose Deployment, Service, ConfigMap, and HPA are templated from values, with separate dev/stage/prod values files that differ only in the knobs that should differ. You can install a release, upgrade it to a new image tag, roll it back to the previous revision, and preview any change with --dry-run before it ever touches the cluster.
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: storefront description: The Storefront web service, packaged as a chart type: application version: 0.1.0 appVersion: "1.0.0"
Reading this file
apiVersion: v2Marks this as a Helm 3 chart, v2 is the current chart schema and what helm create emits.version: 0.1.0The chart’s own semantic version, bump this whenever you change the templates, independent of the app.appVersion: "1.0.0"Tracks the Storefront image version the chart deploys, quoted so it is read as a string not a number.
Chart identity. version is the chart’s own version; appVersion tracks the Storefront image.
That's 1 of 9 explained code blocks in this single project.
The build, milestone by milestone
- 1
Scaffold the chart and template the easy objects first
5 guided stepsTemplating the simplest objects first teaches the Go templating mechanics (.Values, includes, the quote filter) without the noise of the Deployment, so when you hit the hard manifests the syntax is already muscle memory.
- 2
Template the Deployment and HPA from values
5 guided stepsThe Deployment is where promotion pain actually lives: image tag, replica count, and resource numbers all change per environment. Once these read from .Values, promoting an environment is a values edit, not a manifest rewrite.
- 3
Split values per environment without forking templates
5 guided stepsThe whole point of the chart is that environments share templates and differ only in values. If a manifest still changes per environment, that drift is exactly the copy-paste problem you set out to kill.
- 4
Install, upgrade, and preview with --dry-run
5 guided stepsHelm’s value over kubectl apply is that a release is a tracked unit: one command installs the whole set, one upgrades it atomically, and --dry-run shows exactly what will change first. This is the release-engineer workflow the raw YAML never gave you.
- 5
Break it, then roll back to a good revision
5 guided stepsRollback is the payoff of tracked releases: when an upgrade goes wrong, you restore the last good rendered manifest with one command instead of reconstructing YAML under pressure. You only trust it once you have done it on purpose.
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