The Philosophy
Why Bazel, and what makes it different
Decide whether Bazel fits the project in front of you. Learn the trade-off: explicit build structure in exchange for correctness, reuse, scale, and a shared model across languages and teams.
Use the prelude before Bazel becomes a command you type every day. This level is for the adoption question: what kind of build problem is Bazel trying to solve, what structure does it ask a team to maintain, and when is that trade worth it?
What To Evaluate
P.1 Why Bazel starts with fit. Bazel can improve correctness, speed, scalability, polyglot integration, and CI consistency, but those benefits matter most when the repository has enough scale or coordination pain to pay for the extra structure.
P.2 How Bazel Thinks gives the model behind those benefits. Bazel is less interested in running a sequence of tasks and more interested in declared targets, inputs, outputs, tools, and dependency edges. Once that structure exists, caching, slicing, parallelism, and remote execution have something reliable to reason about.
P.3 Ecosystem & Alternatives widens the decision beyond the core binary. Real projects need rulesets, registries, generators, formatters, IDE support, and conventions. It also explains why alternatives exist: different tools choose different trade-offs around metadata, compatibility, local speed, inference, and language scope.
P.4 Bazel as a Project makes the word "Bazel" concrete. In practice, Bazel means a pinned version, release cadence, ruleset owners, registry metadata, and community-maintained pieces.
Decide How Deep To Go
Read the prelude linearly if the team is still deciding whether Bazel belongs in the project. If the decision is already made, skim P.1 Why Bazel and spend more time on P.2 How Bazel Thinks. That model explains most of the friction you will feel in the first real BUILD files.
Bazel is worth learning when coordination and scale problems justify its explicit structure. After the prelude, you can evaluate that fit, explain why a declared graph enables reuse and parallelism, and include rulesets and ownership costs in the adoption decision.
Next: learn to read the repository, packages, labels, and BUILD declarations in 0.1 Filesystem Hierarchy.
