Se você tiver dúvidas ou precisar de suporte, consulte Como receber ajuda.
O que é o Bazel?
O Bazel é uma ferramenta que automatiza a criação e os testes de software. As tarefas de build com suporte incluem a execução de compiladores e vinculadores para produzir programas e bibliotecas executáveis e a montagem de pacotes de implantação para Android, iOS e outros ambientes de destino. O Bazel é semelhante a outras ferramentas, como Make, Ant, Gradle, Buck, Pants e Maven.
O que há de especial no Bazel?
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 oferece suporte a várias linguagens 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. Por outro lado, com ferramentas como o Make, é necessário descrever arquivos individuais e invocações do compilador. - Suporte a várias plataformas: a mesma ferramenta e os mesmos arquivos
BUILDpodem ser usados para criar software para diferentes arquiteturas e até plataformas. No Google, usamos o Bazel para criar tudo, desde aplicativos de servidor em execução em sistemas nos nossos data centers até apps cliente em execução em smartphones. - Reprodutibilidade: em 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 vão produzir o mesmo resultado. - Escalável: o Bazel pode lidar com builds grandes. No Google, é comum que um binário do 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 e Ninja: essas ferramentas oferecem um 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 para garantir que sejam infalíveis.
- Ant e Maven: o Ant e o Maven são voltados principalmente para Java, enquanto o Bazel processa vários idiomas. O Bazel incentiva a subdivisão de bases de código em unidades reutilizáveis menores e pode recriar apenas as 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: as duas ferramentas foram criadas e desenvolvidas por ex-funcionários do Google no Twitter e no Foursquare e no Facebook, respectivamente. Eles foram modelados com base no Bazel, mas os conjuntos de recursos são diferentes, então eles não são alternativas viáveis para nós.
De onde veio o Bazel?
O Bazel é uma versão da ferramenta que o Google usa para criar o software do servidor internamente. Ele também se 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 dele são usadas para 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 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 foi uma forma de resolver esses problemas.
O Bazel exige um cluster de build?
O Bazel executa operações de build localmente por padrão. 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 remota e armazenamento em cache e armazenamento em cache remoto para mais detalhes.
Como funciona o processo de desenvolvimento do Google?
Para a 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ões gigantesco.
- Todos criam softwares com o Bazel.
- Equipes diferentes são responsáveis por partes diferentes da árvore de origem e disponibilizam os componentes como destinos
BUILD. - A ramificação é usada principalmente para gerenciar versões, 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 especificadas, podemos prever quais programas e testes são afetados por uma mudança e fazer uma triagem antes do envio.
Confira mais informações sobre o processo de desenvolvimento no Google no blog de ferramentas de engenharia.
Por que você abriu o Bazel?
Criar softwares precisa ser divertido e fácil. Builds lentos e imprevisíveis tiram a diversão da programação.
Por que eu gostaria de usar o Bazel?
- O Bazel pode acelerar o tempo de build porque ele pode recompilar apenas os arquivos que precisam ser recompilados. Da mesma forma, ele pode pular a execução de testes que sabe que não mudaram.
- O Bazel produz resultados determinísticos. Isso elimina a distorção entre builds incrementais e limpos, laptops e sistemas de CI etc.
- O Bazel pode criar diferentes apps de cliente e servidor com a mesma ferramenta no mesmo espaço de trabalho. Por exemplo, é possível mudar um protocolo cliente/servidor em um único commit 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 mencionados do Bazel.
Posso ver exemplos?
Sim. Confira um exemplo simples ou leia o código-fonte do Bazel para conferir um exemplo mais complexo.
Qual é a melhor característica do Bazel?
O Bazel se destaca na criação e no teste de projetos com as seguintes propriedades:
- Projetos com uma base de código grande
- Projetos escritos em (várias) linguagens compiladas
- Projetos 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 deve ser relativamente fácil, desde que um JDK esteja disponível para a plataforma.
Em quais casos não devo usar o Bazel?
- O Bazel tenta ser inteligente em relação ao armazenamento em cache. Isso significa que ele não é bom para executar operações de build cujas saídas não devem 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 muda a configuração do site no Cloud.
- Se o build consistir em algumas etapas longas e sequenciais, o Bazel talvez não ajude muito. Você vai conseguir mais velocidade dividindo etapas longas em metas menores e discretas que o Bazel pode executar em paralelo.
Qual é a estabilidade do conjunto de recursos do Bazel?
Os recursos principais (regras de C++, Java e shell) são usados extensivamente no Google, então são testados de forma minuciosa e têm pouca 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 os recursos marcados como experimentais, o Bazel deve funcionar. 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.
O quão estável é o Bazel como binário?
No Google, garantimos que os travamentos do Bazel sejam muito raros. Isso também deve ser válido 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, é possível criar sandboxes facilmente com versões fixas do SO, por exemplo, Ubuntu 12.04, Fedora 21. Isso resolve o problema de reprodutibilidade para o ambiente do sistema, ou seja, "de qual versão do /usr/bin/c++ eu preciso?"
O Docker não aborda a reprodutibilidade em relação a mudanças no código-fonte. A execução do Make com um Makefile escrito de forma imperfeita em um contêiner do Docker ainda pode gerar resultados imprevisíveis.
No Google, verificamos as ferramentas no controle de origem para reprodução. Dessa forma, podemos verificar as mudanças nas ferramentas (“atualizar o GCC para 4.6.1”) com o mesmo mecanismo que as mudanças nas bibliotecas de base (“corrigir a verificação de limites no OpenSSL”).
Posso criar binários para implantação no Docker?
Com o Bazel, você pode criar binários independentes e vinculados estaticamente em C/C++ e arquivos JAR independentes para Java. Eles são executados com poucas dependências em sistemas UNIX normais e, portanto, são fáceis 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 autônomos para que possam ser implantados em sistemas diferentes, 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 meus builds reproduzíveis automaticamente?
Para binários Java e C++, sim, desde que você não mude o conjunto de ferramentas. Se você tiver etapas de build que envolvem receitas personalizadas (por exemplo, a execução de binários usando um script de shell em uma regra), precisará tomar 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 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.
Eu uso o Eclipse/IntelliJ/XCode. Como o Bazel interage com os IDEs?
Para o IntelliJ, confira o plug-in IntelliJ com o Bazel.
Para o XCode, confira o Tulsi.
Para Eclipse, confira o plug-in E4B.
Para outros ambientes de desenvolvimento integrados, consulte a postagem do blog sobre como esses plug-ins funcionam.
Eu uso o Jenkins/CircleCI/TravisCI. Como o Bazel interage 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, e isso deve ser 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.
Confira mais detalhes sobre os códigos de saída no Manual do usuário.
Quais recursos futuros podemos esperar no Bazel?
Consulte nossos planos.
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 aceitos: consulte a enciclopédia de build para conferir uma lista de recomendações e awesomebazel.com para 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 todo o desenvolvimento não é feito em público?
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 público.
Você já terminou de abrir o código do Bazel?
O Bazel de código aberto está em desenvolvimento. Em particular, ainda estamos trabalhando no código aberto:
- 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, gostaríamos de fazer com que todas as revisões de código, o rastreamento de bugs e as decisões de design aconteçam publicamente, com a comunidade do Bazel envolvida. 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 ajudar os desenvolvedores externos e colaborar. Por isso, estamos disponibilizando o código, mesmo que parte do desenvolvimento ainda esteja acontecendo internamente no Google. Informe se algo parecer incerto ou injustificado durante a transição para um modelo aberto.
Há partes do Bazel que nunca serão de código aberto?
Sim, parte do código-base se integra à tecnologia específica do Google ou estamos procurando uma desculpa para nos livrarmos dele (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 entro em contato com a equipe?
Entre em contato com a equipe em 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é a primeira versão (Alfa), o Bazel não estava disponível externamente, então projetos de código aberto como o Chromium e o Android não podiam usá-lo. Além disso, a falta de suporte original do Windows era um problema para criar aplicativos do Windows, 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" (a erva) em inglês americano: "BAY-zel". Rima com "hazel". IPA: /ˈbeɪzˌəl/