Real CI optimisation case studies with real numbers

Migrated to Bazel

• ●C++/Python codebase, 300+ engineers at time of migration
• ●Build time for large binaries: 10x faster with full Bazel adoption
• ●CI compute: ~50% reduction from remote caching and affected-only builds

WHAT YOU CAN COPY

The phased migration model. Dropbox converted one sub-system at a time, building Bazel expertise before committing the full codebase. They invested in internal tooling to ease the migration path. The investment was justified by their scale.

HONEST COUNTERPOINT

Dropbox had 300+ engineers and a dedicated build-tools team. The Bazel migration was a multi-year investment. Most teams under 100 engineers will get better ROI from Turborepo or Nx in a fraction of the time.

Intelligent triggering and deep caching

• ●Majority-JVM codebase with extensive Scala services
• ●50% reduction in CI wall-clock time via affected-only triggering
• ●Deep Maven/Gradle dependency caching reduced cold-build overhead by 60-70%

WHAT YOU CAN COPY

Affected-only workflow triggering at the service level. Spotify built a custom service dependency graph and used it to determine which services needed rebuilding on a given PR. Their approach is more sophisticated than Turborepo/Nx, but the principle applies at any scale.

HONEST COUNTERPOINT

Spotify's scale (thousands of services) justified a bespoke solution. For smaller orgs, Nx Cloud or Turborepo provides 80% of the benefit at 5% of the implementation cost.

Test impact analysis adoption

• ●Large monorepo with several thousand test files
• ●90%+ reduction in tests executed per PR (running only affected tests)
• ●Published Launchable partnership in AirBnB engineering blog

WHAT YOU CAN COPY

The CI-as-platform investment model. AirBnB treated their CI as internal infrastructure worth engineering investment, not just a vendor subscription. They measured the cost of slow CI in developer productivity terms, not just billing terms.

HONEST COUNTERPOINT

Test impact analysis pays back best when: (a) test suite runtime exceeds 10 minutes, (b) team size exceeds 20 engineers, and (c) you have a dense enough test history for the ML model to be accurate. Below these thresholds, simpler path-filter approaches are sufficient.

CircleCI to Buildkite migration

• ●$2M/year saved from migration (published by Shopify)
• ●Faster build times from Buildkite BYO-agent infrastructure
• ●~4,000 engineers at time of migration

WHAT YOU CAN COPY

The Buildkite + BYO-agents model at scale. Shopify ran their agents on AWS EC2 with auto-scaling. Their published architecture is a template for any org evaluating the Buildkite model.

HONEST COUNTERPOINT

Shopify had ~4,000 engineers. The fixed cost of running their own Buildkite agent fleet amortised well at this scale. For a 50-person team, Buildkite at $30/user plus EC2 typically costs more than GitHub Actions or an external runner.