Disclaimer: Eu trabalho no Bazel e não estou intimamente familiarizado com Gradle. No entanto, um dos meus colegas de trabalho escreveu uma comparação dos dois sistemas, que vou parafrasear aqui:
Bazel e Gradle enfatizam diferentes aspectos da experiência de construção. Até certo ponto, suas prioridades são incompatíveis - o desejo de Gradle por flexibilidade e não-intrusividade limita as restrições que podem ser impostas à estrutura de construção, enquanto o desejo de Bazel por confiabilidade e desempenho impõe necessariamente restrições não-negociáveis.
A Gradle valoriza os mesmos princípios que o Bazel, ou seja, a equipe da Gradle presta muita atenção ao desempenho (compilações incrementais, configuração e execução paralelizadas, o daemon Gradle), correção (verificação “atualizada” baseada em conteúdo) e reprodutibilidade (suporte avançado para sintaxe declarativa, controle de versão de dependência, dependências declaradas explicitamente). E Bazel respeita a necessidade de layouts flexíveis de projetos.
A nuance é que Gradle quer promover boas práticas, enquanto Bazel quer exigir. Gradle busca um meio termo entre a experiência Ant (liberdade para definir sua própria estrutura de projeto com resultados incoerentes) e a experiência Maven (melhores práticas aplicadas sem espaço para necessidades variadas de projeto). Bazel acredita que o suporte flexível a projetos é possível sem sacrificar as fortes garantias que permitem seus poderosos fluxos de trabalho.
Nenhuma filosofia é mais "correta" - a ferramenta que melhor se adequar a um projeto depende dos valores desse projeto em particular.
Visão geral de Gradle
O Gradle é um sistema altamente flexível que facilita a criação de fluxos de construção completos e confiáveis, com restrições mínimas na forma como organizam seus projetos. Isso é feito fornecendo blocos de construção poderosos (por exemplo, rastreamento e recuperação automáticos de dependências, suporte totalmente integrado a plug-ins) com uma interface de script genérica, completa de Turing, que pode combinar esses blocos da maneira que os usuários desejarem.
Gradle enfatiza os seguintes recursos:
- Migração fácil de outros sistemas. Gradle acomoda facilmente qualquer organização de projeto para implementar facilmente estruturas de fluxo de trabalho arbitrárias. Compreende nativamente tarefas Ant e integra-se nativamente com os repositórios Maven e Ivy.
- Modelo de script altamente extensível. Os usuários implementam toda a lógica de construção escrevendo scripts Groovy. Uma “construção” é simplesmente uma execução sequenciada de dependência de tarefas genéricas, que são essencialmente definições de método extensíveis, abertas, substituíveis e extensíveis.
- Gerenciamento de dependência rico. Dependências com versão podem ser declaradas e preparadas automaticamente a partir de repositórios de códigos externos, sistemas de arquivos locais e outros projetos Gradle. As saídas de compilação também podem ser publicadas automaticamente em repositórios e outros locais.
- Sistema de plugins firmemente integrado. Plugins são simplesmente pacotes de tarefas organizadas para facilitar o fluxo de trabalho desejado. Muitos dos recursos "básicos" de Gradle são realmente implementados através de plugins (por exemplo, Java, Android). Os plug-ins interagem (a seu critério) com a lógica do script de construção. Os plug-ins desfrutam de acesso profundo às principais estruturas de dados da Gradle.
Visão geral de Bazel
Bazel evoluiu da necessidade de criar projetos internos do Google de maneira confiável e eficiente. Como o ambiente de desenvolvimento do Google é extraordinariamente grande e complexo, o Bazel oferece garantias extraordinariamente fortes sobre a integridade de suas compilações e a sobrecarga de desempenho incomumente baixa para alcançá-las.
Isso fornece uma base para poderosos fluxos de trabalho de desenvolvimento criados em torno de construções reproduzíveis, em que uma "construção" se torna uma entidade abstrata que pode ser referenciada, repetida, transmitida para máquinas diferentes e transmitida para programas e serviços arbitrários, como se sabe que todas as instâncias são exatamente o mesmo.
Bazel enfatiza os seguintes recursos:
- Correção. As compilações Bazel são projetadas para sempre produzir saída correta, ponto final. Se dois usuários invocarem a mesma construção no mesmo commit com os mesmos sinalizadores Bazel em máquinas diferentes, eles verão resultados idênticos. As compilações incrementais são tão confiáveis quanto as compilações limpas, tornando a última essencialmente desnecessária.
- Atuação. As compilações são projetadas para serem executadas o mais rápido possível intrinsecamente, considerando os recursos disponíveis. As tarefas são tão paralelamente quanto suas cadeias de dependência permitem. Trabalho desnecessário nunca é executado (ou seja, tarefas "atualizadas" são sempre ignoradas). Naturalmente, o trabalho pode ser realizado para executores remotos para superar os limites da máquina local.
- Reprodutibilidade. Qualquer instância de uma compilação pode ser fielmente reproduzida em qualquer ambiente. Por exemplo, se um relatório de bug diz que a versão X do software Y falha no ambiente de produção Z, um desenvolvedor pode recriá-lo fielmente em sua própria máquina, com a confiança de que está depurando a mesma coisa.
Como os links de artigos tendem a desaparecer, aqui está um resumo das opiniões da equipe Gradle sobre Bazel (a maioria é extraída diretamente do artigo, publicado em março de 2015):
Foi projetado para resolver um problema exclusivo do Google; uma base de código monolítica maciça (centenas de milhões de LOC).
A vantagem de paralelização que o Bazel oferece atualmente será comparada com "nosso próximo modelo de configuração e componente" (lembre-se da data do artigo aqui).
O Bazel não possui uma linguagem de compilação declarativa de alto nível que facilita a compilação para desenvolvedores. No Google, isso pode ser compensado com uma equipe de serviço especializada que possui a ferramenta de construção.
O Bazel não foi desenvolvido para extensibilidade (embora a equipe de desenvolvimento do Bazel tenha combatido isso com garantias de que eles estão trabalhando na extensibilidade).
A velocidade é otimizada com base na idéia de que todas as dependências transitivas são armazenadas em um grande repositório; todas as bibliotecas e ferramentas são registradas neste repositório central. A maioria das empresas possui mais requisitos de gerenciamento de dependência distribuídos.
O Bazel é apenas * nix, não é executado no Windows. Isso elimina um grande número de empresas em potencial.
Nenhum ecossistema de plugins.
fonte
Gradle é usado principalmente no sistema eco da JVM (Java, Ggroovy, Scala, Kotlin ...). Se o seu projeto estiver nessa área e você tiver que fazer a pergunta, Gradle ou Maven seriam uma escolha melhor. Para solucionar problemas de uma compilação Gradle, você discordará apenas dos ecossistemas Java e JVM.
O Bazel no coração tem a capacidade de detectar alterações incrementais (assim como o cache de compilação distribuído) e permitir que você reaja, aplique plugins / regras para obter compilações incrementais. Para configurar e manter isso, é necessário um pouco de conhecimento em CPP, Java e Python (Skylark) e conhecimento do administrador do sistema. Novamente, se você tiver que fazer a pergunta, acho que Gradle ou Maven seriam um investimento mais barato. Com o Bazel, você pode criar qualquer idioma, da maneira que definir, mais potência, mas a um custo.
fonte