Bazel: quando usar? (2023)

xguru · 2024-12-13T09:31:01+09:00

Bazel é um sistema de build de código aberto desenvolvido pelo Google para compilar grandes monorepos com eficiência Ele compila projetos complexos com precisão e rapidez, sendo especialmente eficaz ao lidar com codebases grandes e dependências em múltiplas linguagens Conceitos centrais do Bazel Velocidade baseada em correção: o Bazel trata builds como funções puras, garantindo que a mesma entrada gere a mesma saída Cache eficiente: em ambientes de grande escala como os do Google, cache é essencial, e a correção é o que torna isso possível Builds sem limpeza: após mudanças no código-fonte, é possível fazer builds estáveis sem um "clean build" Quando usar o Bazel Recomendado Grandes monorepos: quando há milhões de linhas de código e uso de várias linguagens Gerenciamento de dependências entre diferentes linguagens: por exemplo, treinar modelos em Python e processar dados em Scala Necessidade de CI/CD rápido e preciso: para acelerar o desenvolvimento e evitar conflitos Não recomendado Projetos pequenos: quando há menos de 100 mil linhas de código e uso de uma única linguagem Bibliotecas open source: o Bazel é adequado para gerar artefatos distribuíveis, mas deixa a desejar na distribuição de bibliotecas reutilizáveis Pontos a considerar ao adotar o Bazel A curva de aprendizado inicial é alta, e escrever e manter arquivos de build exige recursos adicionais É essencial montar a infraestrutura, como servidor de cache e configuração de execução remota Casos de sucesso com Bazel Netflix Problema: em um repositório com 250 mil a 300 mil linhas de código, o CI levava de 45 minutos a 1 hora Solução: após adotar o Bazel, o tempo de build caiu de 20 minutos para 6 minutos Efeito: redução de conflitos de merge e melhoria na velocidade de processamento de PRs Open Systems Problema: builds lentos e fluxo de trabalho ineficiente Solução: após migrar para o Bazel, o ciclo de feedback caiu de 20 minutos para 5 minutos Lição: treinamento e comunicação com os desenvolvedores são importantes Vantagens e desvantagens da adoção do Bazel Vantagens Tempos de build mais rápidos: melhoria de velocidade com cache e builds incrementais Correção e reprodutibilidade: representa com precisão grafos complexos de dependência Integração multilíngue: suporte a várias linguagens, como Haskell, TypeScript e Python Desvantagens Alto custo de adoção: configuração inicial e curva de aprendizado íngremes Necessidade de gerenciar arquivos de build: é obrigatório declarar entradas/saídas explicitamente, e vale usar ferramentas de automação Tooling de JavaScript e frontend: dificuldade de compatibilidade com workflows existentes, como hot reloading Dicas para migrar para o Bazel Montar uma equipe central: garantir especialistas capazes de entender e configurar o Bazel Treinamento e comunicação: no início da adoção, é essencial treinar desenvolvedores e alinhar expectativas Complexidade por linguagem: cada linguagem exige configurações de build diferentes Automatização de arquivos de build: usar ferramentas como Gazelle Conclusão O Bazel é excelente para lidar com grandes monorepos e dependências complexas, mas tem alto custo de adoção É indicado para organizações que trabalham com milhões de linhas de código e múltiplas linguagens Para projetos pequenos ou para quem quer uma transição gradual, vale considerar alternativas como Earthly em vez do Bazel

(earthly.dev)

10 pontos por xguru 2024-12-13 | 3 comentários | Compartilhar no WhatsApp

Bazel é um sistema de build de código aberto desenvolvido pelo Google para compilar grandes monorepos com eficiência
Ele compila projetos complexos com precisão e rapidez, sendo especialmente eficaz ao lidar com codebases grandes e dependências em múltiplas linguagens
Conceitos centrais do Bazel
- Velocidade baseada em correção: o Bazel trata builds como funções puras, garantindo que a mesma entrada gere a mesma saída
- Cache eficiente: em ambientes de grande escala como os do Google, cache é essencial, e a correção é o que torna isso possível
- Builds sem limpeza: após mudanças no código-fonte, é possível fazer builds estáveis sem um "clean build"
Quando usar o Bazel
- Recomendado
  - Grandes monorepos: quando há milhões de linhas de código e uso de várias linguagens
  - Gerenciamento de dependências entre diferentes linguagens: por exemplo, treinar modelos em Python e processar dados em Scala
  - Necessidade de CI/CD rápido e preciso: para acelerar o desenvolvimento e evitar conflitos
- Não recomendado
  - Projetos pequenos: quando há menos de 100 mil linhas de código e uso de uma única linguagem
  - Bibliotecas open source: o Bazel é adequado para gerar artefatos distribuíveis, mas deixa a desejar na distribuição de bibliotecas reutilizáveis
Pontos a considerar ao adotar o Bazel
- A curva de aprendizado inicial é alta, e escrever e manter arquivos de build exige recursos adicionais
- É essencial montar a infraestrutura, como servidor de cache e configuração de execução remota
Casos de sucesso com Bazel
- Netflix
  - Problema: em um repositório com 250 mil a 300 mil linhas de código, o CI levava de 45 minutos a 1 hora
  - Solução: após adotar o Bazel, o tempo de build caiu de 20 minutos para 6 minutos
  - Efeito: redução de conflitos de merge e melhoria na velocidade de processamento de PRs
- Open Systems
  - Problema: builds lentos e fluxo de trabalho ineficiente
  - Solução: após migrar para o Bazel, o ciclo de feedback caiu de 20 minutos para 5 minutos
  - Lição: treinamento e comunicação com os desenvolvedores são importantes
Vantagens e desvantagens da adoção do Bazel
- Vantagens
  - Tempos de build mais rápidos: melhoria de velocidade com cache e builds incrementais
  - Correção e reprodutibilidade: representa com precisão grafos complexos de dependência
  - Integração multilíngue: suporte a várias linguagens, como Haskell, TypeScript e Python
- Desvantagens
  - Alto custo de adoção: configuração inicial e curva de aprendizado íngremes
  - Necessidade de gerenciar arquivos de build: é obrigatório declarar entradas/saídas explicitamente, e vale usar ferramentas de automação
  - Tooling de JavaScript e frontend: dificuldade de compatibilidade com workflows existentes, como hot reloading
Dicas para migrar para o Bazel
- Montar uma equipe central: garantir especialistas capazes de entender e configurar o Bazel
- Treinamento e comunicação: no início da adoção, é essencial treinar desenvolvedores e alinhar expectativas
- Complexidade por linguagem: cada linguagem exige configurações de build diferentes
- Automatização de arquivos de build: usar ferramentas como Gazelle
Conclusão
- O Bazel é excelente para lidar com grandes monorepos e dependências complexas, mas tem alto custo de adoção
- É indicado para organizações que trabalham com milhões de linhas de código e múltiplas linguagens
- Para projetos pequenos ou para quem quer uma transição gradual, vale considerar alternativas como Earthly em vez do Bazel

3 comentários

ganadist 2024-12-13

Acho que seria bom mencionar também casos de fracasso na adoção do Bazel.

No caso do AOSP, nos últimos anos houve algumas apresentações na BazelCon sobre a migração do sistema de build existente (Soong) para o Bazel.

https://developers.googleblog.com/en/…

No entanto, na BazelCon deste ano não houve compartilhamento de conteúdo relacionado ao AOSP e, em documentos recentes sobre build do AOSP, apareceu um aviso de que a migração para o Bazel foi interrompida.

Considerando que uma equipe como a do AOSP poderia receber muita ajuda em uma migração para o Bazel, o fato de terem desistido da adoção parece mostrar muitas implicações importantes.

iolothebard 2024-12-13

Provavelmente… seu software não precisa de Bazel.

kandk 2024-12-13

kkk, a Earthly está fazendo propaganda da Earthly.
O bazel coloca a ênfase em builds rápidos e em testes rápidos. Não se fala muito sobre testes aqui.

Bazel: quando usar? (2023)

Leituras relacionadas

3 comentários