CI/CD pipelines

This is a GitHub Actions workflow — a YAML config file (not a program you run) that lives in your repo at .github/workflows/. GitHub reads it and does what it says. YAML uses indentation to show what belongs to what, just like Python. Read it as three questions: when should this run, what jobs are there, and what steps does each job take.

1. on: { push: { branches: [main] } } is the trigger: run this workflow whenever code is pushed to the main branch.
2. jobs: lists the units of work. The first job, test, runs-on: ubuntu-latest — GitHub spins up a fresh Linux machine for it.
3. A job's steps: run top to bottom. uses: pulls in a prebuilt action (check out the code, install Python); run: executes a shell command. Here the steps install dependencies then run pytest -q — that is the test stage.
4. The second job, build-deploy, has needs: test — it waits for the test job and only starts if tests passed. Its steps log in to the registry, docker build an image tagged with the exact commit (github.sha), docker push it, then deploy.

What the output means: Nothing prints locally — GitHub runs this in the cloud on every push. In the Actions tab you'd see two boxes: test (green), then build-deploy (green). If pytest failed, build-deploy would be skipped and nothing would ship.

Try this: Notice the values wrapped in ${{ ... }} — those are filled in by GitHub at run time (the repo name, the commit SHA, and a secret token). secrets.GHCR_TOKEN is a password stored safely by GitHub, never written in the file.

This tiny Python program models what a pipeline does: run a list of stages in order and stop the moment one fails. Seeing it as plain code makes the 'gate' idea concrete — a real deploy tool does exactly this under the hood.

1. run_pipeline(stages) takes a list of (name, fn) pairs — each stage has a label and a function to call. fn returns True for pass, False for fail.
2. The for loop runs each stage in turn: ok = fn() runs it, then it prints PASS or FAIL next to the stage name.
3. if not ok: return False, name is the short-circuit — the first failing stage stops the loop immediately and reports which stage broke. Any stages listed after it never run.
4. The two example lists show both paths: ok passes every stage; broken fails at test, so deploy is never reached.

What the output means: First run prints PASS for all four stages and (True, None) — the whole pipeline succeeded. Second run prints PASS lint, FAIL test, then (False, 'test') — it stopped at test and deploy never ran, exactly like a real CI gate.

Try this: Flip the first lambda:True to lambda:False and run again — the pipeline should stop at lint and never print the later stages.

Before shipping, professional pipelines scan the container image for known security holes (CVEs). This function is the gate that decides: given a list of findings, is the image safe enough to deploy? It counts the serious ones and says pass or fail.

1. scan_gate(findings, max_high=0, max_critical=0) takes the scan results plus two thresholds — how many HIGH and CRITICAL issues you will tolerate. The defaults are 0: zero tolerance.
2. highs = sum(1 for f in findings if f["severity"] == "HIGH") counts how many findings are HIGH severity; the next line counts CRITICAL the same way.
3. passed = highs <= max_high and crits <= max_critical is the decision — True only if both counts stay within the allowed limits. It returns that verdict plus the counts.
4. The two calls show both outcomes: a clean image with only LOW/MEDIUM findings passes; a vuln image with a CRITICAL and a HIGH fails.

What the output means: clean image: (True, {'high': 0, 'critical': 0}) — safe to ship. vulnerable image: (False, {'high': 1, 'critical': 1}) -> block deploy — the gate said no, so the pipeline stops before deploy.

Try this: Raise the bar with scan_gate(findings, max_high=5) and see the vulnerable image pass — that is how teams temporarily accept known risks. Setting limits to 0 is the strict, safe default.

This config adds a safety layer for real deploys: ship to a staging copy automatically, but require a human to click 'approve' before touching production. It is two more jobs chained onto the pipeline with needs:.

1. deploy-staging has needs: test and environment: staging — once tests are green it auto-deploys to a staging environment (a production-like sandbox) and runs smoke tests there.
2. deploy-prod has needs: deploy-staging — it can only start after staging succeeded. This chains the jobs into a strict order.
3. Under environment: the name production is special: GitHub can be configured so a named environment requires a human approval before its job runs. That is the manual gate before real users are affected.
4. The steps: [ ... ] are shown as placeholders — the real deploy commands (a canary rollout, from lesson CD4) would go there.

Try this: The pattern is automatic to staging, approved to prod. Staging catches problems safely; the human approval is your last chance to say 'not yet' before customers see a change.

The DORA metrics are the industry-standard way to score how well a team delivers software. This function takes four numbers and classifies the team as Elite, High, or Medium/Low — turning a fuzzy 'are we good at shipping?' into a concrete answer.

1. The four inputs are the four DORA metrics: deploys_per_week (how often you ship), lead_time_h (hours from commit to live), change_fail_pct (percent of deploys that break something), and restore_h (hours to recover from a failure).
2. elite = ... checks all four against the toughest bar at once with and — every condition must be true to qualify as Elite. high = ... checks a looser bar the same way.
3. return "Elite" if elite else "High" if high else "Medium/Low" picks the best tier the team qualifies for, top-down.
4. The two example teams contrast the extremes: team A ships often and recovers in minutes; team B does rare, large releases and recovers slowly.

What the output means: team A: Elite (frequent, fast, reliable) and team B: Medium/Low. The last line names the fix for B: ship smaller changes more often and make recovery (rollback) faster.

Try this: Change team B's deploys_per_week from 0.5 to 3 and its restore_h from 72 to 10 — watch it climb toward High. Small, frequent, reversible changes are what move the needle.