CI/CD Pipeline Optimization Template

Under 10 minutes for PR checks, under 15 minutes for merge builds. Google's research on developer productivity shows that build times over 10 minutes significantly reduce the number of daily integrations per developer. Under 5 minutes is excellent and enables true continuous integration. Track your P50 and P95 separately since P95 catches the occasional slow run that frustrates developers.

Start with pipeline optimization (caching, parallelization, selective execution). These give you 50-80% improvement at zero incremental cost. Faster runners give you linear improvement (2x faster runner = 2x faster build) but at higher cost. Use both: optimize the pipeline first, then right-size runners for the remaining workload. Track [pipeline efficiency](/glossary/prioritization) as a team health metric.

Set alerting thresholds on P50 and P95 duration. When a PR increases pipeline duration by more than 10%, flag it in the PR review. Run a weekly "top 10 slowest tests" report and assign owners to investigate. Treat pipeline performance like production latency: it needs ongoing monitoring, not a one-time fix.

Quarantine flaky tests into a separate non-blocking test suite. Track the quarantine list and assign owners. Set a policy: flaky tests get 1 week to be fixed or deleted. Flaky tests that block CI erode trust in the pipeline. Engineers start ignoring failures, and real bugs slip through. The [Technical PM Handbook](/technical-pm-guide) covers engineering health metrics including flaky test rates.

Usually not. The overhead of splitting, distributing, and merging results adds 30-60 seconds. If your suite takes 4 minutes, parallelizing into 4 shards might reduce it to 2 minutes. The effort to maintain time-balanced sharding probably is not worth the 2-minute gain unless you run hundreds of builds per day. ---