Back to path
AdvancedStorefront · Project 6 of 11 ~12h· 5 milestones

Ship it automatically from a CI/CD pipeline

Continues from the last build: The Storefront is packaged with Helm, exposed, durable, and hardened, but every release is still a human driving kubectl/helm from a laptop.

Right now a release means someone on the team opening a terminal, building the image by hand, pushing it, and running `helm upgrade` against prod from their laptop, hoping they grabbed the right values file and the right tag.

GitHub Actions workflowsDocker image build & pushImage tagging by commit SHAHelm upgrade in CIMulti-environment promotion (dev/staging/prod)Protected environments & approval gatesOIDC federation / short-lived credentialsRelease automation & rollback
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A GitHub Actions pipeline that, on every push to main, builds and SHA-tags the Storefront image, pushes it to a registry, and runs `helm upgrade` into dev and staging automatically, then waits at a protected-environment approval gate before promoting the exact same image to prod. The cluster is reached with a short-lived OIDC token federated from the workflow, so no static cluster credential lives in a repo secret, and every environment is a deploy of one immutable, SHA-pinned artifact.

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:

.github/workflows/deliver.yamlyaml
name: deliver
on:
  push:
    branches: [main]

# Least-privilege token scopes for the whole workflow.
permissions:
  contents: read
  packages: write   # push to GHCR
  id-token: write   # request an OIDC token for the cluster

jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "pipeline triggered for ${{ github.sha }}"
      # build, push, and deploy jobs are added in the milestones

Reading this file

  • on:Declares what triggers the workflow, here a push to the main branch, so a merge to main starts a release.
  • permissions:Grants the workflow only the token scopes it needs; id-token: write is what later lets it fetch a short-lived OIDC token.
  • runs-on: ubuntu-latestPicks the hosted runner image the job executes on, a fresh Ubuntu VM per run.
  • jobs:Each entry under jobs is a unit of work; you add build and deploy jobs here and wire dependencies with needs.

A skeleton workflow. It triggers on push and runs one job; you add build, push, and deploy jobs through the milestones.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Trigger a build and tag the image by commit SHA

    5 guided steps

    A pipeline you cannot trust to fire, or that tags everything `latest`, is worse than manual releases. Tagging by SHA makes every running image traceable to one commit and makes "the same artifact everywhere" possible.

  2. 2

    Deploy to dev automatically with helm upgrade

    5 guided steps

    This is the moment the pipeline stops being a build server and starts being a delivery system. Using helm upgrade --install with --wait means the job only goes green when the new pods are actually healthy, not just scheduled.

  3. 3

    Promote through staging behind a manual approval gate to prod

    5 guided steps

    Dev and staging should flow automatically, but a human should consciously decide to touch prod. Protected environments give you that gate (and an audit trail of who approved) without scattering manual steps through the pipeline.

  4. 4

    Reach the cluster with short-lived OIDC credentials

    5 guided steps

    A long-lived kubeconfig in a repo secret is a standing key to prod that never expires and cannot be scoped per run. OIDC federation hands the workflow a token that lives for minutes and is bound to this repo and environment, which is the difference between a credential leak being catastrophic and being a non-event.

  5. 5

    Prove you can roll back a bad release

    5 guided steps

    Automation that can only go forward is a liability. The first time you trust the pipeline with prod is the first time it ships something broken, so you rehearse recovery now, while it is cheap, instead of during the incident.

What's inside when you start

3 starter files, ready to clone
5 guided milestones
5 full reference solutions
8 code blocks explained line-by-line
5 "is it working?" checks
4 interview questions it prepares you for

You'll walk away with

A .github/workflows/deliver.yaml that builds, SHA-tags, and pushes the Storefront image on every push to main
An automatic dev then staging promotion via helm upgrade --install, gated on healthy rollouts (--wait)
A protected prod environment with required reviewers, so production deploys pause for human approval
OIDC federation in place of a static kubeconfig secret, with a trust policy scoped to repo and environment
A one-page release runbook: how to promote, who approves, and the exact helm rollback command for recovery

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