Q35 of 38 · CI/CD & DevOps
How does trunk-based development change your CI/CD testing strategy?
Short answer
Short answer: Trunk-based development means all engineers commit to main on short-lived branches merged within a day. This requires the commit-level pipeline to be fast, reliable, and comprehensive enough that a broken commit never stays in main for more than hours.
Detail
In a long-lived feature-branch model, slow test suites are tolerable because branches merge infrequently. In trunk-based development, main receives 10–50 commits per day and every commit must be deployable. This changes three things.
Speed is non-negotiable. The PR pipeline must complete in under 10 minutes. Anything slower is moved to a post-merge or nightly stage, and QA must accept that trade-off explicitly.
Feature flags replace feature branches. Incomplete code is merged behind a flag so it is dark in production. QA must test both the flag-on and flag-off paths — "dark-launching" is a standard testing practice, not an edge case.
Flaky tests become a first-class incident. A single flaky test that blocks main for 20 minutes affects 30 engineers' workflows. Quarantine and delete flaky tests aggressively; never carry them passively.