---
layout: documentation
title: Bazel vision
category: getting-started
---

# Bazel Vision

<p><font size='+1'>Any software developer can efficiently build, test, and package
any project, of any size or complexity, with tooling that's easy to adopt and
extend.</font></p>

*   **Engineers can take build fundamentals for granted.** Software developers
    focus on the creative process of authoring code because the mechanical
    process of build and test is solved. When customizing the build system to
    support new languages or unique organizational needs, users focus on the
    aspects of extensibility that are unique to their use case, without having
    to reinvent the basic plumbing.

*   **Engineers can easily contribute to any project.** A developer who wants to
    start working on a new project can simply clone the project and run the
    build. There's no need for local configuration - it just works. With
    cross-platform remote execution, they can work on any machine anywhere and
    fully test their changes against all platforms the project targets.
    Engineers can quickly configure the build for a new project or incrementally
    migrate an existing build.

*   **Projects can scale to any size codebase, any size team.** Fast,
    incremental testing allows teams to fully validate every change before it is
    committed. This remains true even as repos grow, projects span multiple
    repos, and multiple languages are introduced. Infrastructure does not force
    developers to trade test coverage for build speed.

**We believe Bazel has the potential to fulfill this vision.**

Bazel was built from the ground up to enable builds that are reproducible (a
given set of inputs will always produce the same outputs) and portable (a build
can be run on any machine without affecting the output).

These characteristics support safe incrementality (rebuilding only changed
inputs doesn't introduce the risk of corruption) and distributability (build
actions are isolated and can be offloaded). By minimizing the work needed to do
a correct build and parallelizing that work across multiple cores and remote
systems, Bazel can make any build fast.

Bazel's abstraction layer — instructions specific to languages, platforms, and
toolchains implemented in a simple extensibility language — allows it to be
easily applied to any context.

## Bazel core competencies

1.  Bazel supports **multi-language, multi-platform** builds and tests. You can
    run a single command to build and test your entire source tree, no matter
    which combination of languages and platforms you target.
1.  Bazel builds are **fast and correct**. Every build and test run is
    incremental, on your developers' machines and on CI.
1.  Bazel provides a **uniform, extensible language** to define builds for any
    language or platform.
1.  Bazel allows your builds **to scale** by connecting to remote execution and
    caching services.
1.  Bazel works across **all major development platforms** (Linux, MacOS, and
    Windows).
1.  We accept that adopting Bazel requires effort, but **gradual adoption** is
    possible. Bazel interfaces with de-facto standard tools for a given
    language/platform.

## Serving language communities

Software engineering evolves in the context of language communities — typically,
self-organizing groups of people who use common tools and practices.

To be of use to members of a language community, high-quality Bazel rules must be
available that integrate with the workflows and conventions of that community.

Bazel is committed to be extensible and open, and to support good rulesets for
any language.

###  Requirements of a good ruleset

1.  The rules need to support efficient **building and testing** for the
    language, including code coverage.
1.  The rules need to **interface with a widely-used "package manager"** for the
    language (such as Maven for Java), and support incremental migration paths
    from other widely-used build systems.
1.  The rules need to be **extensible and interoperable**, following
    ["Bazel sandwich"](https://bazel.build/designs/2016/08/04/extensibility-for-native-rules.html)
    principles.
1.  The rules need to be **remote-execution ready**. In practice, this means
    **configurable using the [toolchains](toolchains.html) mechanism**.
1.  The rules (and Bazel) need to interface with a **widely-used IDE** for the
    language, if there is one.
1.  The rules need to have **thorough, usable documentation,** with introductory
    material for new users, comprehensive docs for expert users.

Each of these items is essential and only together do they deliver on Bazel's
competencies for their particular ecosystem.

They are also, by and large, sufficient - once all are fulfilled, Bazel fully
delivers its value to members of that language community.