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 com suporte incluem a execução de compiladores e vinculadores para produzir bibliotecas e programas executáveis, além de 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 adequar à maneira como o software é desenvolvido no Google. Ele tem os seguintes recursos:
- Suporte a várias linguagens: o Bazel oferece suporte a muitas 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, você precisa 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é para plataformas distintas. No Google, usamos o Bazel para criar tudo, desde aplicativos de servidor executados em sistemas nos nossos data centers até apps clientes executados em smartphones. - Reprodutibilidade: em arquivos
BUILD, cada biblioteca, teste e binário precisa especificar completamente as dependências diretas. Ele usa essas informações de dependência para saber o que precisa ser recriado quando você faz alterações em um arquivo de origem e quais tarefas podem ser executadas em paralelo. Isso significa que todos os builds são incrementais e sempre produzirão 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 dão controle muito exato sobre quais comandos são invocados para compilar arquivos, mas cabe ao usuário escrever as 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 conceitos como "plataforma de destino" e "plataforma de host". Essas regras foram testadas na prática para serem infalíveis.
- Ant e Maven: o Ant e o Maven são voltados principalmente para o Java, enquanto o Bazel lida com várias linguagens. Ele incentiva a subdivisão de bases de código em unidades reutilizáveis menores e pode recriar apenas as que precisam ser refeitas. 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 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-Googlers do Twitter, do Foursquare e do Facebook, respectivamente. Eles foram inspirados no Bazel, mas os conjuntos de recursos são diferentes, então não são alternativas viáveis para nós.
De onde veio o Bazel?
Bazel é uma variação da ferramenta que o Google usa para criar um software de servidor internamente. Ela também cresceu 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 são usadas em milhões de builds todos os dias.
Por que o Google criou o Bazel?
Há muito tempo, o Google desenvolve o software usando Makefiles grandes e gerados. Isso levou a builds lentos e não confiáveis, o que começou a interferir na produtividade dos nossos desenvolvedores e na agilidade da empresa. O Bazel era uma maneira de resolver esses problemas.
O Bazel exige um cluster de build?
O Bazel executa operações de build localmente por padrão. No entanto, ele também pode se conectar a um cluster de build para criar e testar ainda mais rápido. 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 a 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 e gigantesco sistema de controle de versões.
- Todos criam software com o Bazel.
- Equipes diferentes têm partes distintas da árvore de origem e disponibilizam os componentes como destinos
BUILD. - As ramificações são usadas principalmente para gerenciar versões, portanto, todos desenvolvem o software na revisão principal.
Ele é um dos alicerces dessa filosofia: como exige que todas as dependências sejam totalmente especificadas, podemos prever quais programas e testes serão afetados por uma mudança e verificá-los antes do envio.
Para mais informações sobre o processo de desenvolvimento no Google, acesse o blog de ferramentas de engenharia (em inglês).
Por que você abriu o Bazel?
Criar um software deve ser divertido e fácil. Compilações lentas e imprevisíveis tiram a diversão da programação.
Por que eu usaria o Bazel?
- Ele pode gerar tempos de build mais rápidos porque pode recompilar apenas os arquivos que precisam ser recompilados. Da mesma forma, ele pode pular a repetição de testes que sabe que não mudaram.
- O Bazel produz resultados determinísticos. Isso elimina o desvio entre builds incrementais e limpos, laptop e sistema de CI etc.
- Ele pode criar diferentes apps de cliente e servidor com a mesma ferramenta no mesmo espaço de trabalho. Por exemplo, é possível alterar um protocolo de 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 e coletando 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 um exemplo mais complexo.
Qual é a melhor parte do Bazel?
O Bazel se destaca ao 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 podem ser implantados em várias plataformas
- Projetos que têm 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.
Para que 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 compilação em que as saídas não devem ser armazenadas em cache. Por exemplo, as seguintes etapas não podem 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 de nuvem do seu site.
- Se a versão tiver algumas etapas sequenciais e longas, talvez o Bazel não ajude muito. Você vai aumentar a velocidade dividindo etapas longas em destinos menores e discretos que o Bazel pode executar em paralelo.
O conjunto de recursos do Bazel é estável?
Os recursos principais (C++, Java e regras de shell) são muito usados no Google, então são totalmente testados e têm pouquíssima variação. Da mesma forma, testamos novas versões do Bazel em centenas de milhares de destinos todos os dias para encontrar regressões. Além disso, lançamos novas versões várias vezes todos os meses.
Em resumo, exceto para recursos marcados como experimentais, o Bazel deve "Just Work". As mudanças feitas nas regras não experimentais serão compatíveis com versões anteriores. Uma lista mais detalhada dos status de suporte aos recursos pode ser encontrada no nosso documento de suporte.
O Bazel é estável como binário?
No 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 sistema operacional, como Ubuntu 12.04 e Fedora 21. Isso resolve o problema de reprodutibilidade do ambiente do sistema, ou seja, “de qual versão de /usr/bin/c++ eu preciso?”
O Docker não aborda a reprodutibilidade em relação às alterações no código-fonte. Executar o Make com um Makefile escrito de maneira imperfeita dentro de um contêiner do Docker ainda pode gerar resultados imprevisíveis.
No Google, verificamos as ferramentas no controle de origem para reprodutibilidade. Dessa forma, podemos verificar as mudanças nas ferramentas (“faça upgrade do GCC para a versão 4.6.1”) com o mesmo mecanismo das alterações nas bibliotecas de base (“verificação de limites de correção no OpenSSL”).
Posso criar binários para implantação no Docker?
Com ele, é possível 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, por isso, devem ser simples de instalar dentro de um contêiner do Docker.
Ele 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 sistemas diferentes, incluindo imagens Docker.
Posso criar imagens Docker com o Bazel?
Sim, você pode usar nossas regras do Docker para criar imagens reproduzíveis do Docker.
O Bazel vai permitir que meus builds sejam reproduzíveis automaticamente?
Para binários Java e C++, sim, supondo que você não altere o conjunto de ferramentas. Se você tiver etapas de compilação que envolvam roteiros personalizados (por exemplo, a execução de binários por meio de um script de shell dentro de uma regra), será necessário 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 User-IDs 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 ser útil nesse caso.
- Evite processos que usam números aleatórios. A travessia de dicionários é, em especial, aleatória em muitas linguagens de programação.
Você tem versões binárias?
Sim, você pode encontrar os binários da versão mais recentes e analisar nossa política de versão
Eu uso Eclipse/IntelliJ/XCode. Como o Bazel interopera com ambientes de desenvolvimento integrado?
Para o IntelliJ, confira o plug-in do IntelliJ com Bazel (link em inglês).
Para o XCode, confira Tulsi.
Para o Eclipse, confira o plug-in E4B.
Para outros ambientes de desenvolvimento integrado, confira a postagem do blog (link em inglês) sobre como esses plug-ins funcionam.
Uso 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 falha, e isso é suficiente para a integração básica de CI. Como o Bazel não precisa de builds limpos para ter precisão, o sistema de CI não pode ser configurado para ser limpo antes de iniciar uma execução de build/teste.
Mais detalhes sobre códigos de saída estão disponíveis 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 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 aprender como elas funcionam, consulte a documentação para estender o Bazel.
Posso contribuir para a base de código do Bazel?
Veja nossas diretrizes de contribuição.
Por que todo o desenvolvimento não é feito ao ar livre?
Ainda precisamos refatorar as interfaces entre o código público no Bazel e nossas extensões internas com frequência. Isso dificulta muito o desenvolvimento ao ar livre.
Você concluiu o código aberto do Bazel?
O código aberto do Bazel está em fase de desenvolvimento. Ainda estamos trabalhando no código aberto:
- Muitos dos nossos testes de unidade e integração, o que deve facilitar 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, rastreamento de bugs e 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 explicações claras. Apesar dessa falta de transparência, queremos apoiar e colaborar aos desenvolvedores externos. Assim, estamos abrindo o código, embora parte do desenvolvimento ainda esteja acontecendo internamente no Google. Entre em contato se algo parecer pouco ou injustificado 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 pode ser integrada a tecnologias específicas do Google, ou estamos procurando uma desculpa para nos livrarmos (ou é uma combinação dos dois). 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?
Entre em contato pelo e-mail bazel-discuss@googlegroups.com.
Onde posso informar bugs?
Abra um problema no GitHub.
O que está acontecendo com 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. Por isso, projetos de código aberto, como o Chromium e o Android, não podiam usá-lo. Além disso, a falta original de suporte ao Windows era um problema para a criação de aplicativos para 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 "manjericão" (a erva) em inglês americano: "BAY-zel". rima com "hazel". IPA: /Remover / sujeira