Uber Tech Stack: CI/CD

Public material about Uber's engineering platform shows a common pattern for very large software organisations: CI/CD is not one pipeline tool, but a chain of systems that standardise source control, enforce code quality, create reproducible builds, provision temporary environments, and then roll changes out with enough visibility to stop a bad release quickly. The exact tools evolve, so it is better to treat this as a representative architecture than a final inventory.

Source control and build graph

Uber has written publicly about using a monorepo and scaling Bazel heavily. That matters because CI starts long before deployment. A large monorepo lets teams share libraries and make cross-service changes atomically, but it only works if the build system can understand dependency boundaries precisely. Bazel helps by modelling builds as a graph. When one library changes, the platform can rebuild and retest only the affected targets instead of everything in the repository.

That optimisation is not optional at Uber's scale. Without it, queue times and compute spend would explode. The tradeoff is that build metadata, ownership rules, and dependency hygiene become part of daily developer life.

Quality gates before merge

Static checks appear to be an important part of Uber's pipeline design. Tools such as NullAway, internal linters like NEAL, and automated clean-up systems like Piranha are all examples of moving failure detection earlier. Null-related bugs, stale feature flags, and style drift are cheaper to catch at review time than after deployment.

This is a core CI/CD lesson: mature delivery systems do not rely on one big integration test at the end. They add many cheaper gates upstream. Each gate removes one class of avoidable failure before the code reaches production-like environments.

Test environments and realistic validation

Uber has also discussed temporary or short-lived environments such as SLATE and traffic replay tools such as Shadower. These address a common gap in ordinary CI pipelines. A unit test can prove that a function works in isolation, but many production failures involve service interaction, schema mismatch, traffic shape, or performance under realistic concurrency.

Ephemeral environments let teams validate a change with the right dependencies without reserving a full permanent staging estate for every branch. Traffic shadowing goes further by replaying real production requests against a candidate system without affecting live users. The operational tradeoff is cost and complexity. These environments and replay systems need strong data controls, cleanup discipline, and enough observability to explain why the candidate behaved differently.

Build, package, deploy, observe

On the build and packaging side, Uber has written about tools such as uBuild alongside hosted or orchestrated build execution. The goal is reproducible artefacts, usually container images, that can move through environments without being rebuilt differently each time.

For deployment, Spinnaker is a widely known example from Uber's public stack. A deployment platform at this scale must handle progressive rollout, rollback, policy checks, and visibility across many services at once. Monitoring platforms such as uMetric, uMonitor, and related observability systems matter here because deployment safety depends on fast feedback. A rollout is only safe if the system can detect increased error rates, latency regressions, or resource saturation quickly enough to stop it.

What this architecture optimises for

The overall design optimises for standardisation with local team autonomy. Product teams can ship often, but only through a platform that encodes dependency analysis, quality rules, test environment provisioning, deployment policy, and production telemetry.

That is the real takeaway from Uber's CI/CD stack. The hard problem is not pressing a deploy button. It is building a delivery system where thousands of engineers can change code every day without turning release engineering into the bottleneck.