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 compilação compatíveis incluem a execução de compiladores e vinculadores para produzir programas e bibliotecas executáveis e a 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?
Ele foi projetado para se adequar à maneira como os softwares são desenvolvidos no Google. Ele tem os seguintes recursos:
- Compatibilidade com várias linguagens: o Bazel oferece suporte a muitas linguagens e pode ser estendido para incluir 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 interconectadas, binários e testes. Já com ferramentas como o Make, você precisa descrever arquivos individuais e invocações de compilador. - Suporte a várias plataformas: a mesma ferramenta e os mesmos arquivos
BUILDpodem ser usados para criar software para arquiteturas diferentes e até mesmo plataformas distintas. No Google, usamos o Bazel para criar de tudo, desde aplicativos de servidor em execução nos sistemas dos nossos data centers até aplicativos clientes executados em smartphones. - Reprodutibilidade: em arquivos
BUILD, cada biblioteca, teste e binário precisa especificar as dependências diretas completamente. 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 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 as versões em que nenhum arquivo foi alterado levam cerca de 200 ms.
Por que o Google não usa...?
- Make, Ninja: essas ferramentas dão um controle muito exato 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 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 e são infalíveis.
- Ant e Maven: Ant e Maven são voltados principalmente para Java, enquanto o Bazel lida com várias linguagens. O Bazel incentiva a subdivisão de bases de código em unidades reutilizáveis menores e só 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 que os do Gradle. Assim, ele entende exatamente o que cada ação faz. Isso permite mais paralelismo e melhor reprodução.
- Calças, Buck: ambas as ferramentas foram criadas e desenvolvidas por ex-Googlers do Twitter, Foursquare e Facebook, respectivamente. Eles foram modelados com base no Bazel, mas os conjuntos de atributos deles são diferentes, por isso não são alternativas viáveis.
De onde veio o Bazel?
O Bazel é uma variação da ferramenta que o Google usa para criar o software servidor internamente. Ela se expandiu para criar outros softwares também, como aplicativos para dispositivos móveis (iOS, Android) que se conectam aos nossos servidores.
Você reprogramou sua ferramenta interna como de código aberto? É um garfo?
O Bazel compartilha a maior parte do código com a ferramenta interna, e as regras são usadas para milhões de builds todos os dias.
Por que o Google criou o Bazel?
Há muito tempo, o Google criou um software usando Makefiles grandes e gerados. Isso levava a builds lentos e não confiáveis, o que começou a interferir na produtividade dos desenvolvedores e na agilidade da empresa. O Bazel era uma forma de resolver esses problemas.
O Bazel exige um cluster de build?
Por padrão, o Bazel executa operações de build localmente. No entanto, ele também pode se conectar a um cluster de build para gerar 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 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 gigantesco de controle de versões.
- Todo mundo cria software com o Bazel.
- Equipes diferentes têm partes distintas 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 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.
Mais informações sobre o processo de desenvolvimento no Google podem ser encontradas no blog de ferramentas de engenharia (em inglês).
Por que você abriu o Bazel?
Criar software deve ser fácil e divertido. Builds lentos e imprevisíveis tiram a diversão da programação.
Por que usar o Bazel?
- O Bazel pode oferecer tempos de compilação mais rápidos porque pode recompilar apenas os arquivos que precisam ser recompilados. Da mesma forma, ele pode pular a repetição dos testes que não foram alterados.
- O Bazel produz resultados determinísticos. Isso elimina o desvio entre builds incrementais e limpos, laptops e sistemas de CI etc.
- Ele pode criar diferentes apps de clientes e servidores com a mesma ferramenta no mesmo espaço de trabalho. Por exemplo, você pode mudar 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, aproveitando todos os benefícios do Bazel mencionados acima.
Posso ver exemplos?
Sim. Confira um exemplo simples ou leia o código-fonte do Bazel para ver um exemplo mais complexo.
Qual é a melhor parte do Bazel?
O Bazel se destaca em projetos de criação e teste 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 que têm testes abrangentes
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 posso usar o Bazel?
- O Bazel tenta ser inteligente quanto ao armazenamento em cache. Isso significa que ele não é adequado para executar operações de build cujas saídas não possam ser armazenadas em cache. Por exemplo, as etapas a seguir 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 o build consiste em algumas etapas longas e sequenciais, o Bazel pode não ajudar muito. Para ter mais velocidade, divida etapas longas em destinos menores e discretos que o Bazel possa executar em paralelo.
O conjunto de recursos do Bazel é estável?
Os recursos principais (C++, Java e regras de shell) têm amplo uso no Google, por isso são testados por completo 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.
Resumindo, com exceção dos recursos marcados como experimentais, o Bazel funciona. As mudanças em regras não experimentais serão compatíveis com versões anteriores. Confira uma lista mais detalhada dos status de suporte dos recursos no documento de suporte.
Quão estável é o Bazel como binário?
No Google, garantimos que as falhas do Bazel sejam muito raras. Isso também vale para nossa base de código de código aberto.
Como posso começar a usar o Bazel?
Consulte Como começar.
O Docker não resolve os problemas de reprodutibilidade?
Com o Docker, é fácil criar sandboxes com versões fixas de SO, como Ubuntu 12.04 e Fedora 21. Isso resolve o problema de reprodução 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 a alterações 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 reprodutibilidade. Dessa forma, podemos verificar mudanças nas ferramentas ("fazer upgrade do GCC para a versão 4.6.1") com o mesmo mecanismo que as mudanças nas bibliotecas de base ("verificação dos limites no OpenSSL").
Posso criar binários para implantação no Docker?
Com o Bazel, você pode criar binários autônomos e estaticamente vinculados em C/C++ e arquivos jar independentes para Java. Eles são executados com poucas dependências em sistemas UNIX normais e, portanto, devem ser simples de instalar em 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 diferentes sistemas, incluindo imagens do Docker.
Posso criar imagens do Docker com o Bazel?
Sim, é possível usar as regras do Docker para criar imagens do Docker reproduzíveis.
O Bazel tornará minhas versões 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 receitas personalizadas (por exemplo, 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 no modo 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 nos arquivos gerados. Arquivos ZIP e outros arquivos são especialmente propensos a isso.
- Evite se conectar à rede. A execução no modo sandbox também pode ajudar nessa situação.
- Evite processos que usam números aleatórios. A travessia de dicionário é aleatória em várias linguagens de programação.
Você tem versões binárias?
Sim. É possível 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 interopera com ambientes de desenvolvimento integrado?
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 (em inglês) sobre como esses plug-ins funcionam.
Eu 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 garantir a exatidão, o sistema de CI não precisa ser configurado para limpeza 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?
Veja nossos Roteiros.
Posso usar o Bazel no meu projeto em INSERT LANGUAGE HERE?
O Bazel é extensível. Qualquer pessoa pode adicionar suporte para novos idiomas. Há suporte para vários idiomas: consulte a enciclopédia de build para conferir uma lista de recomendações e awesomebazel.com para conferir uma lista mais completa.
Se você quiser desenvolver extensões ou saber como elas funcionam, consulte a documentação para estender o Bazel.
Posso contribuir para a base de código do Bazel?
Consulte nossas diretrizes de contribuição.
Por que nem todo o desenvolvimento é feito em aberto?
Ainda é necessário refatorar as interfaces entre o código público no Bazel e nossas extensões internas com frequência. Isso dificulta muito o desenvolvimento aberto.
Você terminou de abrir o Bazel de código?
O Bazel de código aberto está em desenvolvimento. Em especial, ainda estamos trabalhando no código aberto:
- Muitos dos nossos testes de unidade e integração, que facilitarão a contribuição de patches.
- Integração completa com o ambiente de desenvolvimento integrado.
Além do código, gostaríamos de que todas as revisões de código, rastreamento de bugs e decisões de design fossem realizadas 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 apoiar desenvolvedores externos e colaborar. Assim, estamos abrindo o código, mesmo que parte do desenvolvimento ainda esteja acontecendo internamente no Google. Avise nossa equipe se algo parecer incerto ou injustificado à medida que fazemos a transição para um modelo aberto.
Há partes do Bazel que nunca vão ter 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 (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?
Estamos disponíveis para contato em bazel-discuss@googlegroups.com.
Onde posso informar bugs?
Abra um problema no GitHub (em inglês).
O que está acontecendo com a palavra "Blaze" na base de código?
Esse é um nome interno para a ferramenta. Consulte o Bazel 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 Chromium e Android não podiam usá-lo. Além disso, a falta de suporte ao Windows original 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"?
Do mesmo jeito que "manjericão" (a erva) em inglês americano: "BAY-zel". rima com "hazel". IPA: /ňbe EntãozAtivadal/