Matrix Builds and Parallelism — CI/CD with GitHub Actions

A pipeline that runs one test suite on one platform provides one signal. A pipeline that runs the same suite on Node.js 18, 20, and 22, on Ubuntu and macOS, against PostgreSQL 14 and 16 provides twelve signals in the same wall-clock time — because each combination runs in parallel on a separate runner. GitHub Actions' matrix strategy enables this: you define variables and their possible values, and GitHub Actions generates one job instance per combination. This is how major open-source projects guarantee compatibility across their supported versions without maintaining dozens of near-identical workflow files. Matrix builds also solve computationally expensive single suites: sharding a 10,000-test suite across 10 parallel runners reduces 30 minutes to 3 minutes.

Analogy🏏Cricket

🏏 Think of it like cricket: A cricket series is structured in three tiers: the series schedule (which matches are played and when), individual match plans (batting order, bowling rotations, fielding strategy), and specific delivery plans (which balls to bowl to which batsman in which over). The series schedule is the workflow — it defines the overall event. Each match is a job — it runs independently but contributes to the series outcome. Each delivery plan is a step — a specific action with a discrete result. Just as a Test captain doesn't redesign the series schedule for every match but does adjust the bowling plan for each innings, GitHub Actions separates what triggers the automation (workflow) from how independent tasks are parallelised (jobs) from the individual commands executed (steps). The insight is that this separation of concerns is what allows large, complex pipelines to remain manageable — just as a well-structured series plan keeps a touring team organised across multiple venues and formats.