Renovate vs Dependabot: la scelta si decide alla ventesima pull request

  • VersionDude
  • guides
  • 8 min di lettura

Entrambi sorvegliano le vostre dipendenze e aprono una PR. Questa parte è identica, quindi non può essere il criterio. Ciò che li separa sono il raggruppamento, la pianificazione e il luogo in cui girano; e uno dei due è già attivo nel vostro repository.

I due strumenti fanno la stessa cosa visibile: sorvegliano le dipendenze, notano una nuova versione e aprono una pull request. Se fosse tutto qui, la scelta non conterebbe. Conta per ciò che succede dopo, quando di quelle pull request ne avete venti aperte, e i due strumenti prendono posizioni opposte su questo problema.

Dependabot è quello che avete già. È integrato in GitHub, non costa nulla e attivarlo significa un file `.github/dependabot.yml` di circa sei righe. Nessun account da creare, nessuna app da installare, nessun runner da ospitare. Per un repository che oggi non ha alcuna automazione, è la via più breve per averne una.

Renovate è quello a cui si passa quando le pull request diventano il problema. È open source, gira come app ospitata, in self-hosting o nella vostra CI, e funziona su GitLab, Bitbucket e Azure DevOps oltre che su GitHub. La sua configurazione è un motore di regole più che un file di impostazioni, ed è insieme il suo vantaggio e il suo costo.

La vera linea di separazione sono il raggruppamento e il rumore. Un progetto con quaranta dipendenze produce molti aggiornamenti di versione singoli, e rivederli uno per uno è un lavoro che sembra manutenzione senza esserlo. Dependabot ha aggiunto gli aggiornamenti raggruppati, e aiutano. Le `packageRules` di Renovate restano molto più espressive: raggruppare per schema di pacchetto, per tipo di aggiornamento, per cartella, applicare calendari diversi a ogni gruppo, fare il merge automatico delle patch delle dipendenze di sviluppo trattenendo le major per la revisione. Se il vostro problema è il *volume*, è questa espressività che state comprando.

La pianificazione è la seconda differenza che si sente. Renovate permette di dire quando gli aggiornamenti possono comparire (fuori dall'orario di lavoro, in un giorno preciso, al massimo ogni tanto) con regole diverse per gruppo. Il calendario di Dependabot è più semplice. In un repository piccolo la semplicità è un pregio; in uno molto attivo significa che le PR arrivano quando arrivano.

Il Dependency Dashboard è la funzione sottovalutata di Renovate. Apre nel repository un'unica issue con tutto ciò che vuole fare, compreso ciò per cui ha deliberatamente scelto di non aprire una PR. Vedete lo stato del vostro debito di dipendenze in una pagina invece di dedurlo da una casella di posta. In Dependabot non c'è nulla di equivalente.

Dove Dependabot è davvero avanti: gli avvisi di sicurezza. La parte degli aggiornamenti di versione è solo metà del prodotto. L'altra metà è collegata al database di avvisi di sicurezza di GitHub e segnala le dipendenze vulnerabili come avvisi, con aggiornamenti di sicurezza attivabili indipendentemente da quelli di versione. Anche Renovate può intervenire sulle vulnerabilità, ma se la vostra priorità è *la postura di sicurezza dentro GitHub*, Dependabot è la via nativa e richiede pochi minuti.

La piattaforma è la risposta quando è la risposta. Se il vostro codice non è su GitHub, il confronto finisce qui: Renovate è lo strumento che gira dove siete voi. E se vi servono aggiornamenti gestiti dalla vostra infrastruttura invece che da un'app di terze parti, Renovate si può ospitare in proprio; dall'altra parte questa opzione non esiste.

Il costo di configurazione è reale e va detto chiaramente. La flessibilità di Renovate nasce da uno schema così ampio che quasi tutti partono da un preset e lo adattano. Mettete in conto un pomeriggio perché si comporti come volete, e mettete in conto di tornarci. Dependabot si configura bene al primo colpo perché c'è meno da sbagliare. È un vero argomento a suo favore, non un premio di consolazione.

Una scelta predefinita ragionevole: iniziate con Dependabot, soprattutto per gli aggiornamenti di sicurezza. Passate a Renovate quando sapete nominare con precisione ciò che vi infastidisce: troppe PR, momento sbagliato, nessun raggruppamento, fuori da GitHub, bisogno di regole di merge automatico. Migrare dopo costa poco. Configurare un motore di regole prima di avere il problema che risolve è il modo per finire a mantenere l'automazione delle dipendenze invece del progetto.

Qualunque scegliate, lo strumento si limita a proporre. Ciò che vi protegge davvero è la stessa cosa che ha reso possibili questi strumenti: un lockfile committato, perché la versione proposta dal bot sia quella installata dalla vostra CI, e una suite di test abbastanza buona perché una pull request verde significhi qualcosa.

Progetto correlato