The failure mode of continuous delivery is not a broken pipeline. It is a pipeline that people work around: merging with a red build because that test is flaky, deploying manually because the pipeline takes forty minutes. Once overriding becomes routine, the quality gates are decorative.
Fast enough to stay in the loop
Our target is under ten minutes from push to a deployed preview environment. Beyond that, developers context-switch and stop watching. Getting there means parallel jobs, aggressive dependency caching, and running only the tests affected by the change on pull requests while the full suite runs on the main branch.
Delete flaky tests or fix them the same week
A test that fails intermittently trains the team to ignore red builds, which is far more damaging than the coverage it provides. Quarantine it immediately, fix it within the week, or remove it. There is no acceptable third option.
Gate on non-functional requirements too
If performance and accessibility matter, enforce them where they cannot be skipped. Bundle size budgets, Lighthouse thresholds and automated accessibility checks all belong in the pipeline — a regression should fail the build rather than be discovered by a user.
- name: Enforce budgets
run: |
npm run build
npx lighthouse-ci autorun --assert.preset=lighthouse:recommended
npx size-limitFinally, make rollback boring. If reverting a release requires a decision meeting, teams deploy less often and each release carries more risk. One command, rehearsed, changes the whole posture.