Perguntas frequentes

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Se você tiver dúvidas ou precisar de suporte, consulte Como receber ajuda.

O que é o Bazel?

O Bazel é uma ferramenta que automatiza builds e testes de software. As tarefas de build compatíveis incluem a execução de compiladores e linkers para produzir programas e bibliotecas executáveis, além da montagem de 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 adequar à forma como o software é desenvolvido no Google. Ele tem os seguintes recursos:

  • Suporte a vários idiomas: o Bazel é compatível com muitos idiomas e pode ser estendido para oferecer suporte a linguagens de programação arbitrárias.
  • Linguagem de build 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, é necessário descrever arquivos individuais e invocações de compilador.
  • Suporte multiplataforma: a mesma ferramenta e os mesmos arquivos BUILD podem ser usados para criar software para diferentes arquiteturas e até mesmo plataformas. No Google, usamos o Bazel para criar tudo, desde aplicativos de servidor executados em sistemas nos nossos data centers até apps de cliente executados em smartphones.
  • Reprodução: nos arquivos BUILD, cada biblioteca, teste e binário precisa especificar completamente as dependências diretas. O Bazel usa essas informações de dependência para saber o que precisa ser recriado quando você faz mudanças em um arquivo de origem e quais tarefas podem ser executadas em paralelo. Isso significa que todos os builds são incrementais e sempre produzem 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 builds em que nenhum arquivo foi alterado levam cerca de 200 ms.

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

  • Make, Ninja: essas ferramentas oferecem controle muito preciso sobre quais comandos são invocados para criar arquivos, mas cabe ao usuário escrever regras corretas.
    • Os usuários interagem com o Bazel em um nível mais alto. Por exemplo, o Bazel tem regras integradas para "teste Java", "binário C++" e noções como "plataforma de destino" e "plataforma de host". Essas regras foram testadas em batalha para serem infalíveis.
  • Ant e Maven: são voltados principalmente para Java, enquanto o Bazel processa várias linguagens. O Bazel incentiva a subdivisão de bases 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 os do Gradle, permitindo que o Bazel entenda exatamente o que cada ação faz. Isso permite mais paralelismo e melhor reprodutibilidade.
  • Pants, Buck: ambas as ferramentas foram criadas e desenvolvidas por ex-funcionários do Google no Twitter, Foursquare e Facebook, respectivamente. Eles foram modelados com base no Bazel, mas os conjuntos de recursos são diferentes, então não são alternativas viáveis para nós.

De onde surgiu o Bazel?

O Bazel é uma versão da ferramenta que o Google usa para criar o software de servidor internamente. Ele também foi expandido 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 dele são usadas em milhões de builds todos os dias.

Por que o Google criou o Bazel?

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

O Bazel exige um cluster de build?

Por padrão, o Bazel executa operações de build localmente. No entanto, o Bazel também pode se conectar a um cluster de build para builds e testes 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 nosso código de servidor está em um único sistema de controle de versão gigantesco.
  • Todo mundo cria software com o Bazel.
  • Equipes diferentes são proprietárias de partes diferentes da árvore de origem e disponibilizam os componentes como destinos BUILD.
  • O ramificação é usado principalmente para gerenciar lançamentos, então todos desenvolvem o software na revisão principal.

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

Saiba mais sobre o processo de desenvolvimento no Google no blog de ferramentas de engenharia (em inglês).

Por que você abriu o Bazel?

Criar software deve ser divertido e fácil. Builds lentos e imprevisíveis tiram a diversão da programação.

Por que eu usaria o Bazel?

  • O Bazel pode oferecer tempos de build mais rápidos porque recompila apenas os arquivos que precisam ser recompilados. Da mesma forma, ele pode pular a nova execução de testes que não foram alterados.
  • O Bazel produz resultados deterministas. Isso elimina a distorção 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, você pode mudar um protocolo cliente/servidor em um único commit e testar se o app móvel atualizado funciona com o servidor atualizado, criando os dois com a mesma ferramenta e aproveitando todos os benefícios mencionados do Bazel.

Posso ver exemplos?

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

Qual é a especialidade do Bazel?

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

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

Onde posso executar o Bazel?

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

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

Para que não devo usar o Bazel?

  • O Bazel tenta ser inteligente sobre o armazenamento em cache. Isso significa que não é bom para executar operações de build cujos resultados não devem ser armazenados 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 muda a configuração de nuvem do seu site.
  • Se o build consistir em algumas etapas longas e sequenciais, o Bazel não poderá ajudar muito. Você vai ganhar mais velocidade dividindo etapas longas em metas menores e discretas que o Bazel pode executar em paralelo.

Quão estável é o conjunto de recursos do Bazel?

Os recursos principais (C++, Java e regras de shell) são muito usados no Google. Por isso, são testados exaustivamente e têm pouquíssima rotatividade. 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 várias vezes por mês.

Em resumo, exceto pelos recursos marcados como experimentais, o Bazel deve funcionar normalmente. As mudanças nas regras não experimentais serão compatíveis com versões anteriores. Confira uma lista mais detalhada dos status de suporte a recursos no nosso documento de suporte.

Quão estável é o Bazel como um binário?

No Google, garantimos que as falhas do Bazel sejam muito raras. Isso também deve valer para nossa base de código 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 de SOs, como Ubuntu 12.04 e Fedora 21. Isso resolve o problema de reprodutibilidade do ambiente do sistema, ou seja, "qual versão de /usr/bin/c++ eu preciso?"

O Docker não aborda a capacidade de reprodução em relação a mudanças no código-fonte. Executar o Make com um Makefile escrito de forma imperfeita dentro de um contêiner do Docker ainda pode gerar resultados imprevisíveis.

No Google, verificamos as ferramentas no controle de origem para garantir a capacidade de reprodução. Dessa forma, podemos analisar mudanças em ferramentas ("fazer upgrade do GCC para 4.6.1") com o mesmo mecanismo das mudanças em bibliotecas básicas ("corrigir verificação de limites no OpenSSL").

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

Com o Bazel, é possível criar binários autônomos e vinculados estaticamente em C/C++, além de arquivos jar independentes para Java. Eles são executados com poucas dependências em sistemas UNIX normais e, portanto, são 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 que possam ser implantados em diferentes sistemas, incluindo imagens do Docker.

Posso criar imagens do Docker com o Bazel?

Sim, você pode usar nossas regras do Docker para criar imagens reproduzíveis do Docker.

O Bazel vai tornar minhas builds reproduzíveis automaticamente?

Sim, para binários Java e C++, desde que você não mude o conjunto de ferramentas. Se você tiver etapas de build que envolvam receitas personalizadas (por exemplo, execução de binários por um script shell em uma regra), tome alguns cuidados extras:

  • Não use dependências que não foram declaradas. A execução em sandbox (–spawn_strategy=sandboxed, somente no Linux) pode ajudar a encontrar dependências não declaradas.
  • Evite armazenar carimbos de data/hora e IDs de usuários em arquivos gerados. Arquivos ZIP e outros arquivos compactados são especialmente propensos a isso.
  • Evite se conectar à rede. A execução em sandbox também pode ajudar.
  • Evite processos que usam números aleatórios. Em particular, a travessia de dicionário é aleatória 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 consultar nossa política de lançamento.

Uso Eclipse/IntelliJ/XCode. Como o Bazel interopera com IDEs?

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

Para o XCode, confira o Tulsi.

Para o Eclipse, confira o plug-in E4B.

Para outros IDEs, confira a postagem do blog sobre como esses plug-ins funcionam.

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

O Bazel retorna um código de saída diferente de zero se a invocação de build ou teste falhar, o que é suficiente para a integração básica de CI. Como o Bazel não precisa de builds limpos para correção, o sistema de CI não deve ser configurado para limpar antes de iniciar uma execução de build/teste.

Mais detalhes sobre códigos de saída estão no Manual do usuário.

Quais recursos futuros podemos esperar no Bazel?

Confira nossos roteiros.

Posso usar o Bazel no meu projeto INSERT LANGUAGE HERE?

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

Se 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 o desenvolvimento é feito de forma aberta?

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

Você já terminou de abrir o código do Bazel?

O projeto de código aberto do Bazel ainda está em desenvolvimento. Em particular, ainda estamos trabalhando para abrir o código-fonte de:

  • Muitos dos nossos testes de unidade e integração (que facilitam a contribuição de patches).
  • Integração completa com o ambiente de desenvolvimento integrado.

Além do código, queremos que todas as revisões de código, o rastreamento de bugs e as decisões de design sejam feitos publicamente, com a participação da comunidade do Bazel. Ainda não chegamos lá, então algumas mudanças vão aparecer no repositório do Bazel sem uma explicação clara. Apesar dessa falta de transparência, queremos apoiar e colaborar com desenvolvedores externos. Por isso, estamos abrindo o código, mesmo que parte do desenvolvimento ainda esteja acontecendo internamente no Google. Informe se algo não estiver claro ou justificado durante a transição para um modelo aberto.

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

Sim, parte da base de código se integra à tecnologia específica do Google, ou estamos procurando uma desculpa para nos livrarmos dela (ou é uma combinação dos dois). Essas partes da base de código não estão disponíveis no GitHub e provavelmente nunca estarão.

Como posso entrar em contato com a equipe?

Entre em contato com bazel-discuss@googlegroups.com.

Onde posso informar bugs?

Abra um problema no GitHub.

O que significa a palavra "Blaze" na base de código?

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

Por que outros projetos do Google (Android, Chrome) usam outras ferramentas de build?

Até o primeiro lançamento (Alfa), o Bazel não estava disponível externamente. Por isso, projetos de código aberto como o Chromium e o Android não podiam usá-lo. Além disso, a falta de suporte para Windows era um problema para a criação de aplicativos desse sistema operacional, como o Chrome. Como o projeto amadureceu e se tornou 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" (o tempero) em inglês dos EUA: "BAY-zel". Rima com "hazel". IPA: /ˈbeɪzˌəl/