Lesson 7 · This repo's local dev

Skaffold: build, render, deploy

The tool that turns "source code" into "running in Kubernetes" — three verbs you should be able to name cold.

Your win: explain what Skaffold does, its build → render → deploy pipeline, and how this repo composes ~15 Skaffold configs into one local deployment.

What Skaffold is for

Deploying to Kubernetes by hand is a chore: build each image, tag it, push it, edit the image tag into every manifest, kubectl apply. Skaffold automates exactly that loop for container/Kubernetes apps — it handles building, tagging, and deploying so you run one command instead of ten.¹

The three verbs

Command	Does
`skaffold build`	build (and optionally push) the images from your artifacts
`skaffold render`	produce the final K8s manifests — template Helm, stamp in the built image tags — without deploying²
`skaffold deploy` / `run`	apply manifests to the cluster; `run` = build + render + deploy in one
`skaffold dev`	watch files, rebuild + redeploy on change (the continuous loop)

Why render matters most here render is the step that hydrates templates: it expands the Helm charts with the right {env}-{org}-values.yaml and replaces the untagged image name with the exact built tag.² Remember Lesson 6's surprise — this repo runs render to generate the docker-compose configs too. So render is the bridge between "Helm templates" and "concrete config both stacks consume."

How this repo wires Skaffold

Skaffold is configured by skaffold.*.yaml files — about 27 of them at the repo root, one per stack area (backend, gateway, airflow, monitoring, runner, …). One top-level file stitches them together.

Anchor — skaffold.local.yaml apiVersion: skaffold/v4beta9. Its requires: block (lines 5–19) composes ~15 other configs — emulator, backbone, data-warehouse, backend, ml-service, airflow, gateway, monitoring, frontend, … — so one deploy brings up the whole world. Its build.local block sets push: false and useDockerCLI: true (lines 20–23) — build locally, don't push to a remote registry.

Anchor — the deploy invocation sk.bash assembles the command in deployments/sk.bash:199+: default verb run, with --default-repo=asia.gcr.io/student-coach-e1e95 --skip-tests --status-check=false and --filename=${SKAFFOLD_FILE} (default skaffold.local.yaml). Anything after -- is passed straight through — which is how run.bash calls

sk.bash -- render -f skaffold.backend.yaml -p
    local-docker-compose,-local

(Lesson 6). Those -p … flags select Skaffold profiles — named config overrides, e.g. the local-docker-compose profile that shapes output for the compose stack.

artifacts (Dockerfile) ──► skaffold BUILD ──► image :tag │ Helm charts + values ──────────────────────────┼──► skaffold RENDER ──► hydrated manifests │ skaffold DEPLOY ──► kubectl apply → cluster (skaffold RUN = build + render + deploy, in one command)

Skaffold docs — the pipeline & render

The quickstart (dev/run) and the render page (how it templates Helm and stamps image tags). The concepts map straight onto this repo.

→ skaffold.dev/docs · Quickstart
→ skaffold.dev — Render

Check yourself (from memory)

Q1. skaffold render produces…

Render hydrates templates (Helm values + built image tags) and prints manifests; deploy is a separate step.

Q2. skaffold run is best described as…

run does the whole pipeline once; dev is the watch-and-repeat version.

Q3. In this repo, skaffold.local.yaml's requires: block…

It stitches per-area configs (backend, gateway, monitoring, …) so one deploy brings up the whole stack.

Skaffold in one breath — what it does, the verbs, how this repo uses it.

recall, then click to reveal

SKAFFOLD automates build → tag → deploy for Kubernetes apps. VERBS: build (make images), render (hydrate manifests: expand Helm with {env}-{org}-values + stamp image tags, NO deploy), deploy (apply), run = build+render+deploy once, dev = watch + repeat. Repo: ~27 skaffold.*.yaml (one per area); skaffold.local.yaml (v4beta9) requires: ~15 of them, build.local with push:false. sk.bash runs skaffold run --default-repo=… --skip-tests; args after -- pass through, and -p selects PROFILES (e.g. local-docker-compose). render also feeds the compose configs (Lesson 6).

Want to see a profile definition, or how --default-repo rewrites image names? Ask me — Helm's side of render is Course 3.

1. Skaffold documentation; Quickstart.

2. Skaffold — Render (templates Helm, stamps image tags into manifests).