Isolated End-to-End Testing System

Shared test databases were making CI unreliable

End-to-end tests ran against a shared, long-lived environment. State leaked between runs, tests interfered with each other, and failures were often impossible to reproduce locally. The team had started ignoring red builds.

The underlying cause sat below the tests: no run had a clean, isolated stack to execute against.

Real budgets, real pipelines, no rewrites

The suite had to run inside the existing GitHub Actions pipeline without extending build times past what the team would tolerate, and without rewriting the Cypress tests themselves. Provisioning also had to stay cheap enough to run on every pull request instead of only nightly.

Provision a full stack per run, then tear it down

Each CI job spins up its own containerized application stack (app server, MySQL, and dependencies) seeded to a known baseline. Real user flows run against that isolated stack, and everything is destroyed on completion regardless of pass or fail.

Because every run starts from an identical baseline, nothing about a failure is unique to CI.

Trade-offs that shaped the architecture

Seeding from fixtures instead of production snapshots kept runs fast and deterministic, at the cost of maintaining the fixture set, a cost the team could see and own. Docker Compose was chosen over a Kubernetes-based setup because it matched what developers already ran locally.

Teardown runs unconditionally, even on failure, so no half-alive environment survives to debug against.

Isolated runs, and a suite the team trusts again

Runs stopped sharing state, so tests could no longer interfere with each other. The same provisioning script doubled as the local debugging tool: a failed CI run replays on a developer machine with a single command. The team went back to treating a red build as a real signal.