Ship Better Code, Faster

Appearance

Workshop 3: Slide Content ​

Deck title: CI/CD Pipeline Design & Configuration Duration: 60 minutes · ~22 slides

Slide 1: Title [lavender title slide] ​

Title: Automate the pipeline. Eyebrow: Session 3 of 8 · CI/CD with GitHub Actions

Slide 2: Recap [white, headline + body] ​

Title: You measured. You diagnosed. Now you fix. Subtitle: Where we are in the arc Body: The OrbitTasks pipeline runs only on your laptop today. There is no CI. That's the next thing we change. By the end of this session you'll have a working GitHub Actions workflow that does what your laptop does, and does it faster.

Slide 3: Agenda [dark blue, agenda layout] ​

Title: Agenda Bullets (6):

  • 10 min: CI/CD architecture and how to choose tools
  • 10 min: GitHub Actions structure and syntax
  • 15 min: Write your CI workflow from the broken starter
  • 10 min: Add caching and measure the difference
  • 10 min: Parallelize tests with a matrix strategy
  • 5 min: Group debrief and the Platform Engineer career angle

Slide 4: Section divider [dark blue] ​

Big text: What CI/CD / actually is.

Slide 5: CI vs CD [white, 2-col] ​

Title: Two letters. Two ideas. / Often confused. Left subhead: Continuous Integration Left body: Every change merges into the main branch frequently, and every change is automatically built and tested. The goal is to keep the main branch in a known-good state at all times. This is the part you build today. Right subhead: Continuous Delivery / Deployment Right body: Delivery means the build is always ready to ship. Deployment means it actually ships, automatically. Most teams do CI + manual deploy first, then graduate to CD when they trust their tests.

Slide 6: Why pipelines exist [white, headline + body] ​

Title: Why pipelines exist at all Subtitle: The first principle Body: A pipeline is a deal: developers commit code, and in return the system tells them whether the code is safe to merge. The deal only works if the answer comes back fast and is trustworthy. Slow pipelines break the deal. Flaky pipelines break the deal worse, because now the answer is sometimes a lie.

Slide 7: Industry tools [dark, title + body + bullets] ​

Title: Industry tools, / and how to choose Body: You'll meet many CI tools over your career. The good news: they all share the same building blocks. The differences are surface-level. Pick whatever your team already uses. Bullets (4):

  • GitHub Actions: what we use today. Free for public repos. Tight GitHub integration.
  • CircleCI / Buildkite: premium options, faster on big builds.
  • Jenkins: older, self-hosted. Everywhere in enterprise.
  • GitLab CI / Bitbucket Pipelines: if your team is on those platforms.

Slide 8: Section divider [dark blue] ​

Big text: GitHub Actions / in 10 minutes.

Slide 9: Anatomy of a workflow [white, headline + body] ​

Title: A GitHub Actions workflow has four parts Subtitle: The mental model Body: A workflow is a YAML file in .github/workflows/. It defines when it runs (events), where it runs (runners), what it runs (jobs and steps), and with what (env vars, secrets, caches). Everything else is variation on those four ideas. Master those and any CI system looks familiar.

Slide 10: A minimal workflow [white, headline + body] ​

Title: The smallest workflow that does anything Subtitle: Six lines, on a real codebase Body: on: pull_request triggers the workflow when a PR opens. jobs.test.runs-on: ubuntu-latest picks a Linux runner. jobs.test.steps is the list of things to run: typically check out the code, install Node, install dependencies, run tests. We'll see this on the next slide.

Slide 11: Worked example [dark, headline + body] ​

Title: What you've already got, together Subtitle: Read it together; we'll improve it in place Body: Open .github/workflows/ci.yml. Walk through it line by line. Note what's deliberately missing: no caching, no parallelism, no matrix. This is the workflow that's been running on every PR, and a cold run takes ~13 minutes, almost all of it in one stage: the serial test:api suite, which makes real HTTP calls. Today's steps get that to ~5–7 minutes; the order-of-magnitude collapse comes in Workshop 5 when we mock the clients. We improve this file in place together, one commit at a time, with students mirroring in their own forks.

Slide 12: Section divider [dark blue] ​

Big text: Now you / write yours.

Slide 13: Workshop: read your baseline [white, headline + body] ​

Title: Workshop, 15 minutes, together Subtitle: See the baseline run on GitHub Body: We push the repo to your fork together and watch .github/workflows/ci.yml execute in the Actions tab. Note the wall-clock duration of each step. A cold run is ~13 minutes, and you'll see almost all of it land on test:api, and that's the stage to keep your eye on. We record the per-step durations in your logbook as we go; we compare against them at the end of the session.

Slide 14: Common pitfalls [white, title + body + bullets] ​

Title: Things that will / trip you up. Body: I've seen all of these. Don't be alarmed. Bullets (4):

  • Indentation matters. YAML is whitespace-sensitive. Use spaces, not tabs.
  • "It works locally but not in CI" usually means a missing env var or a different Node version.
  • Test order can hide bugs. CI runs in a fresh environment every time; your laptop doesn't.
  • If you see a step pass on green when you expect failure, you may have a missing exit 1.

Slide 15: Section divider [dark blue] ​

Big text: Now make it / faster.

Slide 16: Caching [white, headline + body] ​

Title: Caching: the first big optimization Subtitle: Often a 2-3× speedup for free Body: Every job starts on a fresh runner with no node_modules. Without caching, every job re-downloads everything from npm. With actions/setup-node's cache: npm option, the runner restores ~/.npm from the previous run. Add one line, save 30–60 seconds per run. Measure it.

Slide 17: Workshop: add caching [white, headline + body] ​

Title: Workshop, 10 minutes, together Subtitle: Add caching and re-run Body: Together we add cache: npm to your actions/setup-node step. Push, wait for the run to complete, then run it again. Compare the install duration on run 1 vs run 2. The second run should be noticeably faster. We record both numbers in your logbook; your improvement proposal in Session 6 wants them.

Slide 18: Parallelization [dark, headline + body] ​

Title: Parallelization with matrix strategies Subtitle: The second big speedup Body: A strategy.matrix runs the same job multiple times with different inputs. We use it two ways: (a) run apps/api and apps/web as separate jobs that execute simultaneously, and (b) shard the test suite across two parallel runners so 90 seconds of tests becomes 45.

Slide 19: Workshop: matrix [white, headline + body] ​

Title: Workshop, 10 minutes, together Subtitle: Run jobs in parallel Body: Together we split your CI into two parallel jobs, one for apps/api and one for apps/web. Run it. Note that the total pipeline duration is now roughly the longer of the two jobs, not the sum. That's the win.

Slide 20: Group debrief [dark, title + body + bullets] ​

Title: Compare your before / and after. Body: Around the room: what was your original duration, and what is it now? Bullets (4):

  • Most students see 40–60% improvement from caching alone.
  • Add matrix and parallel jobs and you often hit 70%+.
  • The number that matters is not "% faster" but "minutes saved per PR": multiply by team size and PR volume.
  • A Platform Engineer would now pitch this improvement to leadership. We do that in Session 6.

Slide 21: Career angle [white, headline + body] ​

Title: This is exactly the Platform Engineer job Subtitle: The work you just did is what you get paid for Body: A platform engineer at Stripe or Shopify spends a meaningful fraction of their week iterating on CI pipelines. Caching strategies, matrix configs, smart sharding. The job is partly mechanical and partly judgment: judgment about which 5% of the codebase is worth optimizing because it runs on every PR.

Slide 22: Session 4 preview [white, title + body + bullets] ​

Title: Session 4: Developer Experience / and tooling. Body: CI/CD makes the pipeline fast. DevEx makes the whole job faster. Next session you'll find onboarding pain points and fix them. Bullets (3):

  • Examine the repo from a brand-new developer's perspective.
  • Write a Makefile / npm scripts that turn three commands into one.
  • Improve documentation and add automation that removes daily friction.

Slide 23: Questions [dark blue, Big Stat layout] ​

Big text: Questions?