Running end-to-end tests on every PR seems like an ideal solution, catching issues early and speeding up deployments. However, in practice, PR testing often amplifies noise, slows down development, and reveals hidden weaknesses in the test suite without necessarily resolving them. The alternative: testing release candidates (RCs) on stable, shared environments. When teams use "release trains" and test RCs multiple times a day or on a steady rhythm throughout the week, they shift from reactive to proactive QA. It may seem slower upfront, but it reduces rework and boosts release confidence over time.
Why PR testing often falls short
Pull request environments are a moving target. Even if a build passes, there’s no guarantee that the combination of versions, branches, and dependencies matches what will actually ship. You’re testing a version of the system, but not necessarily the version that matters.
PR testing also amplifies the usual test suite problems: flakiness, infrastructure strain, and buried technical debt. Worse, PRs often move faster than tests can complete, creating a dangerous mismatch:
- Deployments outpace validation: Merged PRs trigger tests that lag behind production, allowing untested code to ship.
- Confusing failures: Ephemeral environments and parallel runs obscure the origin of regressions, turning debugging into guesswork.
Why release trains solve these issues
Release trains introduce a stable checkpoint between the merge and release stages. The RC bundles multiple pull requests into a single build, which is then tested in a controlled environment.
Here's how frequent RC testing specifically addresses the issues PR testing struggles with:
1. Validation on production-like environments
Unlike ephemeral PR environments, RC environments represent exactly what will go live. Tests run on a stable, frozen build, eliminating confusion about the state of the system under test. If a test fails, it's clear that the failure is real, not a flake caused by concurrent changes from multiple PRs.
2. Minimizes the noise from flaky tests
By running tests against a stable build rather than constantly shifting PR states, teams drastically reduce the incidence of intermittent failures. Stable RC testing turns ambiguous flakes into meaningful signals, directly improving reliability and reducing maintenance overhead.
3. Simplifies infrastructure needs
Because an RC environment runs a single, frozen build instead of dozens of parallel PR builds, the infrastructure doesn’t have to juggle competing versions of the same test suite. You can allocate resources more efficiently—enough to run tests quickly and reliably without overprovisioning for concurrency you don’t need. With only one version of the suite running, tests don’t collide. There’s no risk of shared state or data corruption across parallel jobs. That makes test runs faster, more predictable, and easier to diagnose, resulting in cheaper infrastructure, clearer signals, and tighter feedback loops for developers.
4. Clarifies who’s accountable for the regression
When multiple PRs are bundled into a single RC, identifying and resolving regressions becomes straightforward. If a test fails, the entire RC is held back, clearly signaling the team to fix issues before proceeding. This prevents confusion and drastically reduces debugging complexity.
Slowing down to speed up
Teams worry that adding a validation step before releases could slow them down, but the opposite is true. RC testing typically introduces minimal delays—often just a few minutes—to thoroughly validate releases. The long-term benefit outweighs the initial wait:
- Fewer production escapes: Reliable validation before deployment reduces costly, time-consuming production issues.
- Less rework: Fixing bugs at the RC stage prevents the cascading disruptions and context switching that follow production escapes.
- Higher overall velocity: A small upfront validation investment accelerates subsequent releases, streamlining the entire deployment pipeline.
The bottom line: Alignment is key
The core advantage of release trains is alignment—aligning QA, development, and deployment practices around a shared and stable validation checkpoint. Instead of separate timelines and competing priorities, teams gain a unified approach to quality assurance.
By adopting high-cadence RC testing, teams aren't slowing down—they're enabling a smarter, faster, and safer way to ship code. In short, RC testing isn't a compromise. It's a strategy for achieving genuine velocity through sustainable quality.
.svg){kind=logo}
