Perguntas frequentes

Informar um problema Ver código-fonte

Se você tiver dúvidas ou precisar de suporte, consulte a seção Receber ajuda.

O que é o Bazel?

O Bazel é uma ferramenta que automatiza builds e testes de softwares. As tarefas de compilação compatíveis incluem compiladores e vinculadores em execução para produzir programas e bibliotecas executáveis e montar pacotes implantáveis para Android, iOS e outros ambientes de destino. O Bazel é semelhante a outras ferramentas, como Make, Ant, Gradle, Buck, Pants e Maven.

O que o Bazel tem de especial?

O Bazel foi projetado para se adaptar à maneira como o software é desenvolvido no Google. Ele tem os seguintes recursos:

  • Suporte a várias linguagens: o Bazel é compatível com muitas linguagens e pode ser estendido para oferecer suporte a linguagens de programação arbitrárias.
  • Linguagem de compilação de alto nível: os projetos são descritos na linguagem BUILD, um formato de texto conciso que descreve um projeto como conjuntos de pequenas bibliotecas, binários e testes interconectados. Já com ferramentas como o Make, é preciso descrever arquivos individuais e invocações do compilador.
  • Suporte multiplataforma: a mesma ferramenta e os mesmos arquivos BUILD podem ser usados para criar software para diferentes arquiteturas e plataformas. No Google, nós usamos o Bazel para criar tudo, desde aplicativos de servidor executados em sistemas nos nossos data centers até aplicativos clientes executados em smartphones.
  • Reprodutibilidade: nos arquivos BUILD, cada biblioteca, teste e binário precisa especificar completamente as próprias dependências diretas. O Bazel usa essas informações de dependência para saber o que precisa ser recriado quando você altera um arquivo de origem e quais tarefas podem ser executadas em paralelo. Isso significa que todos os builds são incrementais e sempre geram o mesmo resultado.
  • Escalonável: o Bazel pode lidar com builds grandes. No Google, é comum que um binário de servidor tenha 100 mil arquivos de origem, e os builds em que nenhum arquivo foi alterado levam cerca de 200 ms.

Por que o Google não usa...?

  • Make, Ninja: essas ferramentas fornecem controle muito preciso sobre quais comandos são invocados para criar arquivos, mas cabe ao usuário criar regras corretas.
    • Os usuários interagem com o Bazel em um nível superior. Por exemplo, o Bazel tem regras integradas para "teste Java", "binário C++" e noções como "plataforma de destino" e "plataforma host". Essas regras foram testadas para não serem enganadas.
  • Ant e Maven: Ant e Maven são voltados principalmente para Java, enquanto Bazel lida com várias linguagens. O Bazel incentiva subbases de código em unidades reutilizáveis menores e pode recriar apenas aquelas que precisam ser recriadas. Isso acelera o desenvolvimento ao trabalhar com bases de código maiores.
  • Gradle: os arquivos de configuração do Bazel são muito mais estruturados do que o do Gradle. Assim, o Bazel entende exatamente o que cada ação faz. Isso permite um maior paralelismo e uma melhor reprodutibilidade.
  • Pants, Buck: as duas ferramentas foram criadas e desenvolvidas por ex-Googlers no Twitter, Foursquare e Facebook, respectivamente. Elas foram modeladas com base no Bazel, mas os conjuntos de atributos delas são diferentes, portanto não são alternativas viáveis para nós.

De onde vieram o Bazel?

O Bazel é uma variação da ferramenta que o Google usa para criar internamente o próprio software de servidor. Ela também expandiu para criar outros softwares, como apps para dispositivos móveis (iOS, Android) que se conectam aos nossos servidores.

Você reescreveu sua ferramenta interna como código aberto? É um garfo?

O Bazel compartilha a maior parte do código com a ferramenta interna, e as regras dela são usadas para milhões de compilações todos os dias.

Por que o Google criou o Bazel?

Há muito tempo, o Google criou um software usando Makefiles grandes e gerados. Isso levou a builds lentos e não confiáveis, que começaram a interferir na produtividade dos desenvolvedores e na agilidade da empresa. O Bazel era uma maneira de resolver esses problemas.

O Bazel precisa de um cluster de build?

O Bazel executa operações de versão localmente por padrão. No entanto, ele também pode se conectar a um cluster de build para realizar testes e compilações ainda mais rápidos. Consulte nossa documentação sobre execução e armazenamento em cache remotos e armazenamento em cache remoto para mais detalhes.

Como funciona o processo de desenvolvimento do Google?

Para nossa base de código do servidor, usamos o seguinte fluxo de trabalho de desenvolvimento:

  • Todo o código do servidor está em um único sistema de controle de versão gigante.
  • Todos desenvolvem seus softwares com o Bazel.
  • Diferentes equipes têm diferentes partes da árvore de origem e disponibilizam os componentes como destinos BUILD.
  • A ramificação é usada principalmente para gerenciar versões. Assim, todos desenvolvem seus softwares na revisão principal.

O Bazel é a base dessa filosofia: como o Bazel exige que todas as dependências sejam totalmente especificadas, é possível prever quais programas e testes são afetados por uma mudança e verificá-las antes do envio.

Para saber mais sobre o processo de desenvolvimento no Google, acesse o blog de ferramentas de engenharia.

Por que você abriu o Bazel?

Criar software deve ser fácil e divertido. Compilações lentas e imprevisíveis eliminam a diversão.

Por que eu usaria o Bazel?

  • O Bazel pode oferecer tempos de compilação mais rápidos porque pode recompilar somente os arquivos que precisam ser recompilados. Da mesma forma, ele pode pular a execução de testes que não foram alterados.
  • O Bazel produz resultados determinísticos. Isso elimina o desvio entre builds incrementais e limpos, laptop e sistema de CI etc.
  • O Bazel pode criar diferentes apps cliente e servidor com a mesma ferramenta no mesmo espaço de trabalho. Por exemplo, é possível alterar um protocolo cliente/servidor em uma única confirmação e testar se o app para dispositivos móveis atualizado funciona com o servidor atualizado, criando ambos com a mesma ferramenta, colhendo todos os benefícios do Bazel mencionados acima.

Posso ver exemplos?

Sim. Veja um exemplo simples ou leia o código-fonte do Bazel para ver um exemplo mais complexo.

Qual é a melhor opção para o Bazel?

O Bazel é excelente para criar e testar projetos com as seguintes propriedades:

  • Projetos com uma grande base de código
  • Projetos escritos em várias linguagens compiladas
  • Projetos que são implantados em várias plataformas
  • Projetos com testes abrangentes

Onde posso executar o Bazel?

O Bazel é executado no Linux, macOS (OS X) e Windows.

A portabilidade para outras plataformas UNIX precisa ser relativamente fácil, desde que um JDK esteja disponível na plataforma.

Para que não devo usar o Bazel?

  • O Bazel tenta ser inteligente sobre o armazenamento em cache. Isso significa que ele não é bom para executar operações de build com saídas que não podem ser armazenadas em cache. Por exemplo, as etapas a seguir não devem ser executadas no Bazel:
    • Uma etapa de compilação que busca dados da Internet.
    • Uma etapa de teste que se conecta à instância de controle de qualidade do seu site.
    • Uma etapa de implantação que altera a configuração da nuvem do site.
  • Se a versão consiste em algumas etapas longas e sequenciais, o Bazel pode não ser muito útil. Você vai ganhar mais velocidade ao dividir passos longos em destinos menores e discretos que o Bazel pode executar em paralelo.

O conjunto de recursos do Bazel é estável?

Os principais recursos (regras C++, Java e shell) têm amplo uso dentro do Google. Por isso, eles foram completamente testados e têm pouco desligamento de usuários. Da mesma forma, testamos novas versões do Bazel em centenas de milhares de destinos todos os dias para encontrar regressões, e lançamos novas versões todos os meses.

Em resumo, exceto os recursos marcados como experimentais, o Bazel deve funcionar. As alterações em regras não experimentais serão compatíveis com versões anteriores. Veja uma lista mais detalhada dos status de suporte do recurso no documento de suporte.

O Bazel é estável como um binário?

Dentro do Google, garantimos que as falhas do Bazel sejam muito raras. Isso também se aplica à nossa base de código aberto.

Como posso começar a usar o Bazel?

Consulte Primeiros passos.

O Docker não resolve os problemas de reprodutibilidade?

Com o Docker, é fácil criar sandboxes com versões fixas do SO, como Ubuntu 12.04 e Fedora 21. Isso resolve o problema da reprodutibilidade do ambiente do sistema, ou seja, “de qual versão do /usr/bin/c++ preciso?”

O Docker não aborda a reprodutibilidade em relação às mudanças no código-fonte. A execução do Make com um Makefile gravado incorretamente em um contêiner do Docker ainda pode gerar resultados imprevisíveis.

No Google, verificamos a reprodutibilidade das ferramentas no controle de origem. Dessa forma, podemos verificar as mudanças nas ferramentas ("fazer upgrade do GCC para a versão 4.6.1") com o mesmo mecanismo das alterações nas bibliotecas de base ("verificar os limites no OpenSSL").

Posso criar binários para implantação no Docker?

Com o Bazel, você pode criar binários autônomos e vinculados estaticamente no C/C++ e arquivos jar independentes para Java. Eles são executados com poucas dependências em sistemas UNIX normais e, portanto, precisam ser simples de instalar em um contêiner do Docker.

O Bazel tem convenções para estruturar programas mais complexos, por exemplo, um programa Java que consome um conjunto de arquivos de dados ou executa outro programa como subprocesso. É possível empacotar esses ambientes como arquivos independentes para serem implantados em diferentes sistemas, inclusive imagens do Docker.

Posso criar imagens do Docker com o Bazel?

Sim, é possível usar nossas regras do Docker para criar imagens reproduzíveis do Docker.

O Bazel vai tornar minhas construções reproduzíveis automaticamente?

Para binários Java e C++, sim, supondo que você não mude o conjunto de ferramentas. Se você tiver etapas de versão que envolvam roteiros personalizados (por exemplo, executar binários por meio de um script de shell dentro de uma regra), será necessário tomar alguns cuidados:

  • Não use dependências que não foram declaradas. A execução no sandbox (–spawn_strategy=sandboxed, somente no Linux) pode ajudar a encontrar dependências não declaradas.
  • Evite armazenar carimbos de data/hora e User-IDs em arquivos gerados. Arquivos ZIP e outros arquivos são especialmente propensos a isso.
  • Evite se conectar à rede. A execução no sandbox também pode ajudar aqui.
  • Evite processos que usam números aleatórios, especialmente a travessia de dicionários em muitas linguagens de programação.

Você tem versões binárias?

Sim, você pode encontrar os binários de lançamento mais recentes e revisar nossa política de lançamento.

Uso Eclipse/IntelliJ/XCode. Como o Bazel interopera com ambientes de desenvolvimento integrado?

Para o IntelliJ, confira o plug-in do IntelliJ com Bazel.

Para o XCode, confira Tulsi.

Para o Eclipse, confira o plug-in E4B.

Para outros ambientes de desenvolvimento integrado, confira a postagem do blog (em inglês) sobre como esses plug-ins funcionam.

Uso Jenkins/CircleCI/TravisCI. Como o Bazel interopera com sistemas de CI?

O Bazel retornará um código de saída diferente de zero se a invocação do build ou do teste falhar. Isso deve ser suficiente para a integração básica de CI. Como o Bazel não precisa de versões limpas para correção, o sistema de CI não deve ser configurado para limpar antes de iniciar uma execução de versão/teste.

Veja mais detalhes sobre códigos de saída no Manual do usuário.

Quais recursos vamos esperar no Bazel?

Consulte nossas estradas.

Posso usar o Bazel no meu projeto INSERT LANGUAGE HERE?

O Bazel é extensível. Qualquer pessoa pode adicionar suporte para novos idiomas. Muitos idiomas são compatíveis: consulte a enciclopédia de criação para ver uma lista de recomendações e awesomebazel.com para ver uma lista mais abrangente.

Se você quiser desenvolver extensões ou saber como elas funcionam, consulte a documentação sobre como estender o Bazel.

Posso contribuir com a base de código do Bazel?

Consulte nossas diretrizes de contribuição.

Por que nem todo desenvolvimento é feito ao ar livre?

Ainda temos que refatorar as interfaces entre o código público do Bazel e nossas extensões internas com frequência. Isso dificulta muito o desenvolvimento aberto.

Você terminou o código aberto do Bazel?

O código aberto do Bazel é um trabalho em andamento. Especificamente, ainda estamos trabalhando com código aberto:

  • Muitos dos nossos testes de unidade e integração, o que deve facilitar os patches de contribuição.
  • Integração completa com o ambiente de desenvolvimento integrado.

Além do código, queremos que todas as revisões de código, rastreamento de bugs e decisões de design aconteçam publicamente, com a comunidade do Bazel envolvida. Como ainda não chegamos lá, algumas alterações aparecerão no repositório do Bazel sem uma explicação clara. Mesmo com essa falta de transparência, queremos apoiar desenvolvedores externos e colaborar. Por isso, estamos abrindo o código, mesmo que parte do desenvolvimento ainda esteja acontecendo internamente. Entre em contato conosco se alguma coisa parecer pouco clara ou infundada durante a transição para um modelo aberto.

Há partes do Bazel que nunca terão código aberto?

Sim, parte da base do código pode ser integrada à tecnologia específica do Google ou estamos procurando uma desculpa para nos livrarmos (ou é uma combinação das duas). Essas partes da base do código não estão disponíveis no GitHub e provavelmente nunca estarão.

Como entro em contato com a equipe?

Você também está disponível em bazel-discuss@googlegroups.com.

Onde posso informar bugs?

Abra um problema no GitHub.

O que está escrito com "Blaze" na base de código?

Esse é um nome interno para a ferramenta. Consulte o Blaze como Bazel.

Por que outros projetos do Google (Android, Chrome) usam outras ferramentas de compilação?

Até a primeira versão (Alfa), o Bazel estava indisponível externamente, então não era possível usar projetos de código aberto, como Chromium e Android. Além disso, a falta original de suporte do Windows era um problema para criar aplicativos do Windows, como o Chrome. Como o projeto amadureceu e ficou mais estável, o Android Open Source Project está em processo de migração para o Bazel.

Como se pronuncia "Bazel"?

Da mesma forma que "basil" (a erva) em inglês americano: "BAY-zel". Ele rimas com "hazel". IPA: /➘beɪz➘əl/