Principle: Keep the build green

Broken CI builds become normalized. Developers ignore test failures and merge despite red builds, leading to cascading quality issues.

Treat a broken build as the highest-priority issue:

1. Rules:

- Never merge with a failing build
- Fix broken builds immediately (or revert)
- Don't add new work on top of broken builds
- The person who broke it fixes it (or reverts)

1. Make builds fast:

- Slow builds (>10 min) get ignored
- Target: < 5 minutes for feedback
- Use caching, parallelism, incremental builds
- Split slow tests into separate pipelines

1. Make builds reliable:

- No flaky tests (fix or quarantine them)
- Pin dependencies (no random version changes)
- Use deterministic builds (same input = same output)
- Infrastructure failures should retry, not fail

1. Make failures visible:

- Slack/Teams notification for failures
- Build status badge in README
- Block merges when build is red
- Dashboard showing build health

1. Metrics to track:

- Build pass rate (target: > 99%)
- Time to fix broken builds (target: < 30 min)
- Build duration (target: < 10 min)
- Flaky test rate (target: < 1%)

1. If a test is flaky:

- Don't delete it — fix the flakiness
- Quarantine: move to non-blocking pipeline
- Track flaky test rate as a metric

A consistently green build is the foundation of continuous delivery. When broken builds are normal, nobody trusts the CI and quality degrades.