Session 3: Facilitator Notes

Duration: 60 min · Deliverable: a working GitHub Actions CI workflow with documented optimization decisions

Before the session

• I've test-run the shipped .github/workflows/ci.yml on a fork so I know exactly what students will see.
• I've measured baseline CI durations (uncached, cached, parallel) on a clean repo for reference.
• Have a reference solution ready (don't share unless someone is hopelessly stuck).
• The course logbook link is pinned in chat for students to record durations as we go.
• If any student doesn't have a GitHub account / hasn't forked: handle that before this session.

Time budget

Block	Mins	Slides
1. CI/CD architecture + industry tools	10	1–7
2. GitHub Actions structure	10	8–11
3. Write your CI workflow	15	12–14
4. Add caching + measure	10	15–17
5. Parallelize with matrix	10	18–19
6. Group debrief + career	5	20–22

Block-by-block

Block 1. Anchor: every CI tool is the same five building blocks. Don't dwell on the tool comparison. Get to GitHub Actions fast.

Block 2. Walk the starter file line by line on slide 11. Use slide 9 ("four parts") as the recall framework; students will refer back to it later.

Block 3 (workshop, 15 min). This is the longest block, and we do it together: I drive on screen while students mirror in their own forks. Students push to their fork, watch the baseline workflow run in the Actions tab, and capture per-step durations in the W3 section of their logbook as we go. Many will hit small YAML issues as they edit the workflow alongside me, so be visible in chat. The common ones:

• Indentation: 2 spaces, no tabs.
• Missing uses: actions/checkout@v4 at the top.
• Wrong Node version pinned (node-version: 20 is fine).
• Forgetting to install before running tests.

Number story (read before Block 4). The cold pipeline is ~13 min and ~95% of that (~12 min) is the serial real-HTTP test:api suite (apps/api/tests/integration/* plus the billing rollup in reports.test.ts). Everything else is small: install ~7–90s, lint ~2s, typecheck ~2–3s, test:web ~2–10s, builds ~1s each, deploy ~18s. This is a two-stage story: Workshop 3's steps (caching, incremental tsc, no coverage, parallel workers, matrix/sharding, faster deploy) get the pipeline to ~5–7 min; they can't collapse test:api because the round-trips are real. The order-of-magnitude collapse to ~30s–2 min is Workshop 5, when students mock the six SDK clients. Don't let anyone leave today thinking caching fixed the pipeline.

Block 4 (caching). Set expectations honestly. Caching takes install from ~90s cold to ~7–10s warm: real hygiene, but against a ~12-min test:api it's a rounding error. The point of Block 4 is the technique and the measurement discipline, not the wall-clock win. We run it twice together and record both install numbers in the logbook (Session 6's proposal wants the delta), but make clear the pipeline is still ~12 min after caching.

Block 5 (matrix + workers). Some students will be confused about matrix.app syntax. Show my screen if needed. The point: api and web run in parallel (total = max, not sum), and sharding + parallel jet/vitest workers fan the api suite across cores. Heads-up: bumping workers will surface the documented flaky test(s) (e.g. the timing race in reports.test.ts). That's expected and is the teaching moment: pull it up, find the shared/timing-dependent state, fix it live.

Block 6 (debrief). Around the room: original vs new pipeline duration. The honest pattern is ~13 min → ~5–7 min from W3, most of which is the parallel-workers/sharding step on test:api, not caching. Name the cliff: the real collapse is Workshop 5's client mocking. Career line: "this is the actual work of a Platform Engineer, and knowing which 5% to optimize is the judgment part."

Anticipated questions

"Why GitHub Actions and not CircleCI/Jenkins/etc.?"

Free for public repos, tight GitHub integration, the building blocks transfer. Pick whatever your team uses in industry.

"My CI passed but tests are skipping locally, why?"

Almost always a Jest config or an env var. Show me the run; I'll help.

"How do I cache pnpm / yarn instead of npm?"

Same idea, different cache: value in actions/setup-node (or use actions/cache directly).

"Should we run the same workflow on push to main and PR?"

Yes, on: [push, pull_request]. Standard pattern. Cheap.

If I run short

• Cut block 6 (debrief) to 2 min: quick around-the-room.
• Combine blocks 4 and 5: students do caching and matrix together if time allows.
• Never cut block 3. The deliverable is the workflow file.

Post-session

Ask students to share their final CI duration in chat and confirm the before/after numbers are in their logbook. Note who saved the most time, and call out the technique they used. Remind them: keep the logbook current; we reuse these numbers in Workshop 6, and everything in Workshop 8.