Lesson 1 · CI/CD & GitHub Actions fundamentals

What CI/CD is & why

The machine that turns a git push into a tested, running deployment — and this repo's specific shape.

Your win: define CI vs CD precisely, explain push-based vs GitOps delivery, and — the part that surprises people — trace how this repo actually gets your code to production (a merge does not deploy directly).

CI and CD — two different promises

Term	The promise
CI — Continuous Integration	every change is automatically built and tested on merge, so integration bugs surface in minutes, not at release.
CD — Continuous Delivery	every change that passes CI is ready to release — a human clicks deploy.
CD — Continuous Deployment	every change that passes CI releases automatically — no human in the loop.

The distinction interviewers listen for "CD" is ambiguous on purpose. Delivery stops at "deployable"; Deployment goes all the way to "deployed." The difference is exactly one thing: is there a manual gate before production? Most real systems mix the two — auto to staging, manual to prod — which is precisely what this repo does.

Push-based vs GitOps

There are two ways to get desired state into a cluster:

Push-based — the CI/CD pipeline runs the deploy (helm upgrade / skaffold deploy) from a workflow. The cluster changes only when a deploy runs.
GitOps (pull-based) — a controller in the cluster (Argo CD, Flux) watches git and continuously reconciles the cluster to match it.

Anchor — this repo is push-based No Argo/Flux here. The GitHub Actions pipeline runs skaffold deploy (= helm upgrade --install, Course 3) against GKE. The consequence you met in the Helm course: the cluster only reconciles when a deploy runs, so a manual kubectl edit persists until the next deploy overwrites it (drift). Push-based is simpler to reason about; GitOps self-heals drift. Know the trade-off.

How your code actually ships here (the surprise)

A merge does NOT deploy directly It's tempting to assume "merge to trunk → deploy." Not here. The real chain (.github/workflows/):

push to `develop` └─ tbd.create_release_tag → cuts a release tag └─ cron every 2h (Mon–Fri) → picks the latest tag └─ tbd.build.yaml → builds + pushes the image └─ tbd.deploy.yml → deploys per org └─ skaffold deploy → helm upgrade (GKE)

So merging cuts a release tag; a scheduled cron (every two hours on weekdays) picks up the latest tag, builds it, and auto-deploys to staging. Production is a manual workflow_dispatch — a human triggers it. That makes this repo continuous deployment to staging, but continuous delivery (manual) to prod — the mix from the callout above, made concrete.

Why this matters for you When you merge a fix, it won't be in staging instantly — it waits for the next 2-hourly build. And it won't reach prod until someone dispatches a deploy. Knowing the real cadence saves you from "why isn't my change live yet?" And it's the honest answer to "walk me through how your code reaches production" — a very common interview question.

GitHub — Understanding GitHub Actions + the CI/CD guide

The CI/CD concepts, and the workflow model this course builds on.

→ docs.github.com — Understanding GitHub Actions
→ github.com — What is CI/CD?

Check yourself (from memory)

Q1. Continuous Delivery differs from Continuous Deployment by…

Delivery = "ready, human clicks deploy"; Deployment = "auto, no human." The gap is the manual gate.

Q2. This repo's delivery is push-based, meaning…

A workflow runs skaffold deploy/

helm
      upgrade

. GitOps (Argo/Flux) would pull-and-reconcile instead.

Q3. After you merge to develop, your change reaches staging…

Merge cuts a tag; a 2-hourly cron builds + auto-deploys it to staging. Prod is a separate manual dispatch.

CI vs CD, push vs GitOps, and how this repo ships.

recall, then click to reveal

CI = auto BUILD + TEST every change on merge. CD = DELIVERY (every green change is deployable; human clicks deploy) vs DEPLOYMENT (auto-releases). Difference = the MANUAL GATE. PUSH-BASED (this repo) = the pipeline RUNS skaffold deploy/

helm
    upgrade

; GITOPS = a controller PULLS git + reconciles (self-heals drift). REPO CHAIN: a MERGE DOES NOT DEPLOY — push to develop → tbd.create_release_tag → a 2h cron (Mon–Fri) picks the latest tag → tbd.build → tbd.deploy →

skaffold
    deploy

. Staging = cron-AUTO; PROD = manual workflow_dispatch. So: CDeployment to staging, CDelivery (manual) to prod.

Want to see the exact cron schedule, or why push-based vs GitOps matters for drift? Ask me — the deploy chain is Part 2.

1. GitHub — Understanding GitHub Actions; What is CI/CD?