Se você tiver dúvidas ou precisar de suporte, consulte 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 vinculadores para produzir programas e bibliotecas 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 à forma como o software é desenvolvido no Google. Ele tem os seguintes recursos:
- Suporte a vários idiomas: o Bazel oferece suporte a 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. Em contraste, com ferramentas como o Make, é necessário 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 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. - Reprodutibilidade: nos 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 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 produzem o mesmo resultado. - Escalonável: o Bazel pode processar 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 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 segmentada" e "plataforma de host". Essas regras foram testadas em batalha para serem à prova de falhas.
- Ant e Maven: o Ant e o Maven são direcionados principalmente ao 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 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 e no Foursquare, e no Facebook, respectivamente. Elas foram modeladas 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?
O Bazel é uma versão da ferramenta que o Google usa para criar o software do servidor internamente. Ele foi expandido para criar outros softwares também, como apps para dispositivos móveis (iOS, Android) que se conectam aos nossos servidores.
Você reescreveu sua ferramenta interna como código aberto? É um fork?
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 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 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 código do servidor está em um único sistema de controle de versões gigantesco.
- Todos criam o 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 versões, então todos desenvolvem o software na revisão principal.
O Bazel é uma pedra angular 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 verificá-los antes do envio.
Mais informações sobre o processo de desenvolvimento no Google podem ser encontradas no blog de ferramentas de engenharia (link 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 só recompila os arquivos que precisam ser recompilados. Da mesma forma, ele pode pular a nova execução de testes que ele sabe que não foram alterados.
- O Bazel produz resultados determinísticos. Isso elimina a distorção entre builds incrementais e limpos, laptop e sistema de CI etc.
- O Bazel pode criar diferentes apps de cliente e servidor com a mesma ferramenta do 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 os dois com a mesma ferramenta, 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.
O que o Bazel faz de melhor?
O Bazel se destaca na criação e teste de 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 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 é 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 ele não é adequado 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 QA do seu site.
- Uma etapa de implantação que muda a configuração da nuvem do seu site.
- Se o build consistir em algumas etapas longas e sequenciais, o Bazel talvez não consiga ajudar muito. Você terá mais velocidade dividindo etapas longas em destinos menores e discretos que o Bazel pode executar em paralelo.
Quão estável é o conjunto de atributos do Bazel?
Os recursos principais (regras C++, Java e shell) são amplamente usados no Google, então são totalmente testados e têm muito 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 para recursos marcados como experimentais, o Bazel deve funcionar. As mudanças nas regras não experimentais serão compatíveis com versões anteriores. Uma lista mais detalhada dos status de suporte a recursos pode ser encontrada no nosso documento de suporte.
Quão estável é o Bazel como um binário?
Por dentro do Google, garantimos que as falhas do Bazel sejam muito raras. 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 Introdução.
O Docker não resolve os problemas de reprodutibilidade?
Com o Docker, é possível criar sandboxes com versões fixas do SO, por exemplo, Ubuntu 12.04, 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 reprodutibilidade em relação a mudanças no código-fonte. A execução do Make com um Makefile escrito de forma imperfeita dentro de um contêiner do Docker ainda pode gerar resultados imprevisíveis.
Por dentro do Google, verificamos as ferramentas no controle de origem para reprodutibilidade. Dessa forma, podemos verificar mudanças nas ferramentas ("fazer upgrade do GCC para 4.6.1") com o mesmo mecanismo de 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, é 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, portanto, devem 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 que possam ser implantados em diferentes sistemas, incluindo 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 meus builds 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 build que envolvam receitas personalizadas (por exemplo, executar binários usando 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 IDs de usuário 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 aqui.
- Evite processos que usam números aleatórios. Em particular, a travessia de dicionário é aleatória em muitas linguagens de programação.
Vocês têm 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 Eclipse/IntelliJ/XCode. Como o Bazel interopera com os ambientes de desenvolvimento integrado?
Para o IntelliJ, confira o plug-in IntelliJ com Bazel.
Para o XCode, confira o Tulsi.
Para o Eclipse, confira o plug-in E4B.
Para outros ambientes de desenvolvimento integrado, confira a postagem do blog sobre como esses plug-ins funcionam.
Eu uso Jenkins/CircleCI/TravisCI. Como o Bazel interopera com os 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 a correção, o sistema de CI não precisa 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?
Consulte nossos roteiros.
Posso usar o Bazel para 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 você quiser desenvolver extensões ou aprender como elas funcionam, consulte a documentação sobre como 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 abertamente?
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 aberto.
Vocês já terminaram de abrir o código-fonte do Bazel?
A abertura do código-fonte do Bazel é um trabalho em andamento. Em particular, ainda estamos trabalhando na abertura do código-fonte de:
- Muitos dos nossos testes de unidade e integração (o que deve facilitar a contribuição de patches).
- Integração completa do ambiente de desenvolvimento integrado.
Além do código, gostaríamos de ter todas as revisões de código, rastreamento de bugs e decisões de design 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 oferecer suporte a desenvolvedores externos e colaborar. Assim, estamos abrindo o código, mesmo que parte do desenvolvimento ainda esteja acontecendo internamente no Google. Informe se algo parecer confuso ou injustificado à medida que fazemos 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 é integrada à tecnologia específica do Google ou estamos procurando uma desculpa para nos livrarmos dela (ou é alguma combinação das duas). Essas partes da base de código não estão disponíveis no GitHub e provavelmente nunca estarão.
Como faço para entrar em contato com a equipe?
Estamos disponíveis em bazel-discuss@googlegroups.com.
Onde posso informar bugs?
Abra um problema no GitHub.
O que há de novo na palavra "Blaze" na base de código?
Esse é um nome interno da ferramenta. Consulte o Bazel 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, então projetos de código aberto, como o Chromium e o Android, não puderam usá-lo. Além disso, a falta original de suporte ao Windows era um problema para a criação de 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/