CI/CD Pipelines

A test suite that only runs on a laptop is documentation. It becomes a gate the moment it runs automatically, on every change, with the power to stop a merge.

Every platform here does the same four things: check out the code, install dependencies, run the tests, publish the results. The differences are in how they express parallelism, how they cache, how much they cost, and how bad the day is when something breaks inside the platform itself.

#The five

• GitHub Actions — the default for anything on GitHub, and the one every article's sample pipeline is written for.
• Azure DevOps Pipelines — the enterprise .NET default, with the best built-in test reporting of the five.
• Bitbucket Pipelines — simplest model, hard limits on step size, excellent for small suites.
• TeamCity — build chains and real-time test reporting; still the best UI for watching a large suite run.
• Jenkins — the one you inherit. Declarative pipelines, infinite plugins, and total control over the agents.

Each page carries a working pipeline that runs unit tests, then Playwright across shards, publishes coverage and uploads traces and screenshots on failure.

#Making it fast enough to keep

The reason suites get disabled is wall-clock time. Two articles carry most of the weight here: parallel test execution for the correctness problems that parallelism uncovers — shared databases, shared accounts, shared file paths — and Playwright sharding for splitting a suite across machines and merging the reports back into one.

The order matters. Shard a suite that is not safe to run in parallel and you do not get a fast suite; you get a flaky one.

#Infrastructure as part of the suite

Terraform for test infrastructure covers provisioning the environment a test run needs — a database, a queue, a Selenium grid — as code, so that the environment is as reproducible as the tests. For most suites Testcontainers is the better and cheaper answer; for the ones where it is not, this is how.