Quali sono le differenze tra Bazel e Gradle?

Google ha appena aperto il suo strumento di costruzione Bazel . Quali sono le differenze tra questo strumento e Gradle ? Cosa può fare Gradle, cosa fa meglio, e cosa fa meglio Gradle?

Disclaimer: lavoro su Bazel e non ho familiarità con Gradle. Tuttavia, uno dei miei colleghi ha scritto un confronto tra i due sistemi, che parafraserò qui:

Bazel e Gradle sottolineano diversi aspetti dell'esperienza di costruzione. In una certa misura, le loro priorità sono incompatibili: il desiderio di Gradle di flessibilità e non invadenza limita le restrizioni che può porre sulla struttura della costruzione, mentre il desiderio di Bazel di affidabilità e prestazioni impone necessariamente restrizioni non negoziabili.

Gradle apprezza gli stessi principi di Bazel, vale a dire il team Gradle presta grande attenzione alle prestazioni (build incrementali, configurazione ed esecuzione parallele, demone Gradle), correttezza (verifica "aggiornata" basata sul contenuto) e riproducibilità (supporto completo per sintassi dichiarativa, controllo delle dipendenze, dipendenze dichiarate esplicitamente). E Bazel rispetta la necessità di layout di progetto flessibili.

La sfumatura è che Gradle vuole promuovere le buone pratiche mentre Bazel vuole richiederlo. Gradle mira a una via di mezzo tra l'esperienza della formica (libertà di definire la propria struttura del progetto con risultati incoerenti) e l'esperienza di Maven (migliori pratiche applicate senza spazio per le diverse esigenze del progetto). Bazel ritiene che sia possibile un supporto flessibile ai progetti senza sacrificare le forti garanzie che consentono i suoi potenti flussi di lavoro.

Nessuna delle due filosofie è più "corretta" - qualunque strumento si adatti meglio ad un progetto dipende dai valori di quel particolare progetto.

Panoramica dei gradi

Gradle è un sistema altamente flessibile che semplifica la costruzione da parte degli utenti di flussi di costruzione completi e affidabili con vincoli minimi su come organizzare i propri progetti. Lo fa fornendo potenti blocchi costitutivi (ad es. Tracciamento e recupero automatici delle dipendenze, supporto plug-in strettamente integrato) con un'interfaccia di scripting generica, completa di Turing, che può combinare questi blocchi come gli utenti lo desiderano.

Gradle sottolinea le seguenti caratteristiche:

• Facile migrazione da altri sistemi. Gradle si adatta facilmente a qualsiasi organizzazione di progetto per implementare facilmente strutture di flusso di lavoro arbitrarie. Comprende nativamente i compiti della formica e si integra nativamente con i repository Maven ed Ivy.
• Modello di scripting altamente estensibile. Gli utenti implementano tutta la logica di compilazione scrivendo script Groovy. Una "build" è semplicemente un'esecuzione in sequenza di dipendenze di attività generiche, che sono essenzialmente definizioni di metodi estendibili, aperte, estendibili.
• Gestione delle dipendenze ricca. Le dipendenze con versione possono essere dichiarate e messe in scena automaticamente da repository di codice esterni, filesystem locali e altri progetti Gradle. Allo stesso modo gli output di build possono essere pubblicati automaticamente in repository e altre posizioni.
• Sistema di plugin strettamente integrato. I plugin sono semplicemente raggruppamenti di attività organizzate per facilitare il flusso di lavoro desiderato. Molte delle funzionalità "core" di Gradle sono effettivamente implementate tramite plugin (ad es. Java, Android). I plugin interagiscono (a loro discrezione) strettamente con la logica dello script di compilazione. I plug-in godono di un accesso profondo alle strutture di dati principali di Gradle.

Panoramica di Bazel

Bazel si è evoluto dalla necessità di costruire progetti Google interni in modo affidabile ed efficiente. Poiché l'ambiente di sviluppo di Google è insolitamente ampio e complesso, Bazel offre garanzie insolitamente forti sull'integrità delle sue build e costi generali insolitamente bassi nel raggiungerle.

Ciò fornisce una base per potenti flussi di lavoro di sviluppo basati su build riproducibili, in cui una "build" diventa un'entità astratta a cui è possibile fare riferimento, ripetere, passare a macchine diverse e passare a programmi e servizi arbitrari in modo tale che ogni istanza è nota per essere esattamente lo stesso.

Bazel sottolinea le seguenti caratteristiche:

• Correttezza. Le build Bazel sono progettate per produrre sempre un output corretto, punto. Se due utenti invocano la stessa build nello stesso commit con gli stessi flag Bazel su macchine diverse, vedranno risultati identici. Le build incrementali sono affidabili in modo affidabile quanto le build pulite, rendendo quest'ultima sostanzialmente non necessaria.
• Prestazione. Le build sono progettate per essere eseguite il più velocemente possibile intrinsecamente, date le risorse a loro disposizione. Le attività sono parallelizzabili quanto le loro catene di dipendenze consentono. Il lavoro non necessario non viene mai eseguito (ovvero le attività "aggiornate" vengono sempre ignorate). Il lavoro può naturalmente essere affidato a esecutori remoti per superare i limiti delle macchine locali.
• Riproducibilità. Qualsiasi istanza di una build può essere riprodotta fedelmente in qualsiasi ambiente. Ad esempio, se una segnalazione di bug indica che la versione X del software Y non riesce nell'ambiente di produzione Z, uno sviluppatore può ricrearlo fedelmente sul proprio computer con la sicurezza di eseguire il debug della stessa cosa.

Dato che i collegamenti agli articoli tendono a morire, ecco un riassunto delle opinioni del team Gradle su Bazel (la maggior parte sono direttamente sollevate dall'articolo, pubblicato a marzo 2015):

È stato progettato per risolvere un problema unico di Google; una massiccia base di codice monolitico (centinaia di milioni di LOC).

Il vantaggio di parallelizzazione attualmente offerto da Bazel sarà accompagnato dal "nostro nuovo modello di configurazione e componente in arrivo" (tenere presente la data dell'articolo qui).

Bazel non ha un linguaggio di compilazione dichiarativo di alto livello che renda la build facile da usare per gli sviluppatori. In Google questo può essere compensato con un team di assistenza specializzato proprietario dello strumento di creazione.

Bazel non è costruito per l'estensibilità (anche se il team di sviluppo di Bazel da allora lo ha contrastato con la certezza che stanno lavorando sull'estensibilità).

La velocità è ottimizzata attorno all'idea che tutte le dipendenze transitive sono archiviate in un unico repository; tutte le librerie e gli strumenti sono archiviati in questo repository centrale. La maggior parte delle imprese ha requisiti di gestione della dipendenza più distribuiti.

Bazel è solo * nix, non funziona su Windows. Ciò elimina un gran numero di potenziali imprese.

Nessun ecosistema di plug-in.

Gradle viene utilizzato principalmente nell'ecosistema JVM (Java, Ggroovy, Scala, Kotlin ...). Se il tuo progetto è in quest'area e devi porre la domanda, Gradle o Maven sarebbe una scelta migliore. Per risolvere un build di Gradle, dovrai affrontare solo l'ecosistema Java e JVM.

Bazel nel cuore ha la capacità di rilevare cambiamenti incrementali (così come cache di build distribuita) e ti consente di reagire, applicare plugin / regole per ottenere build incrementali. Per impostare e mantenere ciò è necessario un po 'di conoscenza di CPP, Java e Python (Skylark) e anche dell'amministratore di sistema. Ancora una volta, se devi porre la domanda, penso che Gradle o Maven sarebbero un investimento più economico. Con Bazel puoi costruire qualsiasi lingua, in qualunque modo tu definisca, più potenza, ma a un costo.