{"id":47191,"date":"2021-08-27T14:32:32","date_gmt":"2021-08-27T12:32:32","guid":{"rendered":"https:\/\/kinsta.com\/?p=100242"},"modified":"2023-09-12T15:06:55","modified_gmt":"2023-09-12T14:06:55","slug":"monorepo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/it\/blog\/monorepo-vs-multi-repo\/","title":{"rendered":"Monorepo vs Multi-Repo: Pro e Contro delle Strategie di Repository del Codice"},"content":{"rendered":"

Ci sono due strategie principali per ospitare<\/a> e gestire il codice attraverso Git: monorepo vs multi-repo. Entrambi gli approcci hanno i loro pro e contro e possiamo usarli per qualsiasi codebase in qualsiasi lingua. \u00c8 possibile usare una qualsiasi di queste strategie per progetti che contengono da una manciata a migliaia di librerie<\/a>.
\nLa scelta tra monorepo o multi-repo varia in base a molti fattori, e potete optare per l\u2019una o l\u2019altra sia che abbiate pochi membri nel team o centinaia, che vogliate ospitare codice privato o open-source.<\/p>\n

Quali sono i vantaggi e gli svantaggi di ogni approccio? Quando dovremmo usare l’uno o l’altro? Scopriamolo!<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Cosa Sono i Repo?<\/h2>\n

Un repo (abbreviazione di repository) \u00e8 un archivio per tutti i cambiamenti e i file di un progetto che permette a sviluppatrici e sviluppatori di “controllare le versioni” delle risorse del progetto durante tutta la sua fase di sviluppo.<\/p>\n

Di solito ci riferiamo ai repository Git<\/a> (come quelli forniti da GitHub<\/a>, GitLab<\/a>, o Bitbucket<\/a>), ma il concetto si applica anche ad altri sistemi di controllo di versione (come Mercurial).<\/p>\n\n

Cos’\u00c8 un Monorepo?<\/h2>\n

L’approccio monorepo usa un singolo repository<\/a> per ospitare tutto il codice per le molteplici librerie o servizi che compongono i progetti di un’azienda. Al suo estremo, l’intero codebase di un’azienda – che abbraccia vari progetti e codifica in diversi linguaggi – \u00e8 ospitata in un unico repository.<\/p>\n

Vantaggi di Monorepo<\/h2>\n

Ospitare l’intero codebase su un singolo repository offre diversi vantaggi. Li vediamo di seguito:<\/p>\n

Abbassa le Barriere d’Ingresso<\/h3>\n

Quando nuove persone iniziano a lavorare per un\u2019azienda, hanno bisogno di scaricare il codice e installare gli strumenti necessari per iniziare a occuparsi dei loro compiti. Supponiamo che il progetto sia suddiviso su molti repository, ognuno dei quali ha le sue istruzioni di installazione e gli strumenti richiesti. In questo caso, la configurazione iniziale sar\u00e0 complessa e il pi\u00f9 delle volte la documentazione non sar\u00e0 completa, cosa che richiede alle nuove persone del team di rivolgersi ai colleghi per un aiuto.<\/p>\n

Un monorepo semplifica le cose. Dal momento che c’\u00e8 un unico luogo che contiene tutto il codice e la documentazione<\/a>, \u00e8 possibile semplificare la configurazione iniziale.<\/p>\n

Gestione del Codice a Livello Centrale<\/h3>\n

Avere un unico repository permette a tutte le persone del team sviluppo di avere visibilit\u00e0 su tutto il codice. Semplifica la gestione del codice perch\u00e9 possiamo usare un unico issue tracker per controllare tutti i problemi durante il ciclo di vita dell’applicazione.<\/p>\n

Queste caratteristiche sono per esempio preziose quando un problema si estende su due (o pi\u00f9) librerie child con un bug esistente sulla libreria dipendente. Con pi\u00f9 repository, pu\u00f2 essere difficile trovare il pezzo di codice<\/a> in cui si verifica il problema.<\/p>\n

Oltre a questo, avremmo bisogno di capire quale repository usare per creare la issue e poi invitare con cross-tag i membri di altri team per aiutare a risolvere il problema.<\/p>\n

Con un monorepo, per\u00f2, sia la localizzazione dei problemi del codice che la collaborazione per la risoluzione dei problemi diventano pi\u00f9 semplici da realizzare.<\/p>\n

Refactoring Indolore a Livello di Applicazione<\/h3>\n

Quando si crea un refactoring del codice a livello di applicazione, saranno interessate pi\u00f9 librerie. Se le state ospitando tramite repository multipli, gestire tutte le diverse richieste di pull per mantenerle sincronizzate tra loro pu\u00f2 rivelarsi una sfida.<\/p>\n

Un monorepo facilita l\u2019esecuzione di tutte le modifiche su tutto il codice per tutte le librerie per presentarle sotto un\u2019unica pull request.<\/p>\n

\u00c8 Pi\u00f9 Difficile Rompere Funzionalit\u00e0 Adiacenti<\/h3>\n

Con il monorepo possiamo impostare tutti i test per tutte le librerie da eseguire ogni volta che una singola libreria viene modificata. Di conseguenza, la probabilit\u00e0 che le modifiche in alcune librerie abbiano effetti negativi sulle altre si riduce.<\/p>\n

I Team Condividono la Cultura dello Sviluppo<\/h3>\n

Anche se non impossibile, con un approccio monorepo diventa difficile ispirare sottoculture uniche tra diversi team. Dal momento che condivideranno lo stesso repository, molto probabilmente condivideranno le stesse metodologie di programmazione<\/a> e gestione e useranno gli stessi strumenti di sviluppo<\/a>.<\/p>\n

Problemi con l’Approccio Monorepo<\/h2>\n

Usare un unico repository per tutto il nostro codice ha diversi svantaggi.<\/p>\n

Cicli di Sviluppo pi\u00f9 Lenti<\/h3>\n

Quando il codice di una libreria contiene modifiche che fanno fallire i test per le librerie dipendenti, anche il codice va corretto prima di unire le modifiche.<\/p>\n

Se queste librerie dipendono da altri team, che sono occupati a lavorare su qualche altro compito e non sono in grado (o disposti) ad adattare il loro codice per superare i test, lo sviluppo della nuova funzionalit\u00e0 pu\u00f2 bloccarsi.<\/p>\n

Inoltre, il progetto potrebbe iniziare ad avanzare alla velocit\u00e0 del team pi\u00f9 lento dell’azienda. Questo risultato potrebbe essere frustrante per i membri dei team pi\u00f9 veloci, creando condizioni che potrebbero invogliare a lasciare l’azienda.<\/p>\n

Inoltre, una libreria dovr\u00e0 eseguire i test anche per tutte le altre librerie. Pi\u00f9 test ci sono<\/a>, pi\u00f9 tempo ci vuole per eseguirli, e questo rallenta la velocit\u00e0 con cui possiamo iterare il nostro codice.<\/p>\n

Richiede il Download dell’Intero Codebase<\/h3>\n

Quando il monorepo contiene tutto il codice di un\u2019azienda, pu\u00f2 diventare enorme e contenere diversi gigabyte di dati. Per contribuire a qualsiasi libreria ospitata al suo interno, ci sarebbe bisogno di scaricare l’intero repository.<\/p>\n

Avere a che fare con un codebase ingente implica un cattivo uso dello spazio sui nostri dischi rigidi e interazioni pi\u00f9 lente con esso. Per esempio, le azioni quotidiane come l’esecuzione di git status<\/code> o la ricerca nel codebase con una regex possono richiedere molti secondi o addirittura minuti in pi\u00f9 rispetto a quanto accadrebbe con pi\u00f9 repo.<\/p>\n

Le Librerie Non Modificate Possono Essere di Nuova Versione<\/h3>\n

Quando tagghiamo<\/a> il monorepo, tutto il codice al suo interno adotta il nuovo tag. Se questa azione innesca un nuovo rilascio, allora tutte le librerie ospitate nel repository saranno nuovamente rilasciate con il numero di versione del tag, anche se molte di queste librerie potrebbero non aver subito alcun cambiamento.<\/p>\n

Il Forking \u00c8 Pi\u00f9 Difficile<\/h3>\n

I progetti open source devono facilitare il pi\u00f9 possibile il coinvolgimento dei collaboratori. Con repository multipli, i collaboratori possono andare direttamente al repository specifico per il progetto a cui vogliono contribuire. Nel caso di un monorepo che ospita vari progetti, per\u00f2, i collaboratori devono prima orientarsi nel progetto giusto e avranno bisogno di capire come il loro contributo pu\u00f2 influenzare tutti gli altri progetti.<\/p>\n

Cos’\u00c8 il Multi-Repo?<\/h2>\n

L’approccio multi-repo utilizza diversi repository per ospitare le molteplici librerie o servizi di un progetto sviluppato da un’azienda. Al suo estremo, ospiter\u00e0 ogni minimo set di codice riutilizzabile o funzionalit\u00e0 autonoma (come un microservizio) sotto il suo repository.<\/p>\n

Vantaggi del Multi-Repo<\/h2>\n

Ospitare ogni libreria indipendentemente da tutte le altre presenta moltissimi vantaggi.<\/p>\n

Versioning Indipendente della Libreria<\/h3>\n

Quando si tagga un repository, a tutto il suo codebase viene assegnato il tag “new”. Dal momento che solo il codice di una specifica libreria \u00e8 sul repository, la libreria pu\u00f2 essere taggata e messa in versione indipendentemente da tutte le altre librerie ospitate altrove.<\/p>\n

Avere una versione indipendente per ogni libreria aiuta a definire l’albero delle dipendenze per l’applicazione, e ci permette di configurare la versione di ogni libreria da usare.<\/p>\n

Rilascio di Servizio Indipendente<\/h3>\n

Dal momento che il repository contiene solo il codice per qualche servizio e nient’altro, pu\u00f2 avere un proprio ciclo di deployment, indipendentemente da qualsiasi progresso delle applicazioni che vi accedono.<\/p>\n

Il servizio pu\u00f2 usare un ciclo di rilascio veloce come la distribuzione continua (dove il nuovo codice viene distribuito dopo che ha superato tutti i test). Alcune librerie che accedono al servizio possono usare un ciclo di rilascio pi\u00f9 lento, come quelle che producono un nuovo rilascio solo una volta alla settimana.<\/p>\n

Aiuta a Definire il Controllo degli Accessi in Tutta l’Organizzazione<\/h3>\n

Solo i membri del team coinvolti nello sviluppo di una libreria devono essere aggiunti al repository corrispondente e scaricare il suo codice. Di conseguenza, c’\u00e8 una strategia implicita di controllo degli accessi per ogni livello dell’applicazione<\/a>. Le persone coinvolte con la libreria avranno i permessi di modifica, mentre tutte le altre potrebbero non avere accesso al repository. Oppure possono ricevere permessi di lettura ma senza modifica.<\/p>\n

Permette ai Team di Lavorare in Modo Autonomo<\/h3>\n

I membri del team possono progettare l’architettura della libreria e implementare il suo codice lavorando in isolamento da tutti gli altri team. Possono prendere decisioni basate su ci\u00f2 che la libreria fa nel contesto generale senza essere influenzati dai requisiti specifici di qualche team o applicazione esterna.<\/p>\n

Problemi con l’Approccio Multi-Repo<\/h2>\n

L’utilizzo di pi\u00f9 repository pu\u00f2 dare origine a diversi problemi.<\/p>\n

Le Librerie Devono Essere Costantemente Risincronizzate<\/h3>\n

Quando viene rilasciata una nuova versione di una libreria che contiene modifiche, le librerie che dipendono da questa libreria dovranno essere adattate per iniziare a usare l’ultima versione. Se il ciclo di rilascio della libreria \u00e8 pi\u00f9 veloce di quello delle sue librerie dipendenti, esse potrebbero perdere rapidamente la sincronizzazione<\/p>\n

I team avranno bisogno di mettersi costantemente in pari per usare le ultime release degli altri team. Dato che diversi team hanno diverse priorit\u00e0, questo obiettivo pu\u00f2 a volte essere difficile da raggiungere.<\/p>\n

Di conseguenza, un team che non \u00e8 in grado di recuperare il ritardo pu\u00f2 finire con l’attenersi alla versione obsoleta della libreria da cui dipende. Questo risultato avr\u00e0 un certo impatto sull’applicazione (in termini di sicurezza, velocit\u00e0 e altre considerazioni), e il divario nello sviluppo tra le librerie pu\u00f2 solo aumentare.<\/p>\n

Pu\u00f2 Frammentare i Team<\/h3>\n

Quando i diversi team non hanno bisogno di interagire tra loro, finiscono a lavorare nei loro silos. A lungo termine, questo potrebbe portare i team a generare delle sottoculture aziendali, come l’impiego di diverse metodologie di programmazione o di gestione, o l’utilizzo di diversi set di strumenti di sviluppo.<\/p>\n

Se poi qualche membro del team deve passare a un team diverso, potrebbe scontrarsi con un certo shock culturale e dover imparare un nuovo modo di fare il suo lavoro.<\/p>\n

Monorepo vs Multi-Repo: Differenze Principali<\/h2>\n

Entrambi gli approcci alla fine si occupano dello stesso obiettivo: gestire il codebase. Questo significa che entrambi devono risolvere le stesse sfide, tra cui la gestione dei rilasci, la promozione della collaborazione tra i membri del team<\/a>, la gestione dei problemi, l’esecuzione dei test e altro.<\/p>\n

La loro principale differenza riguarda le tempistiche con cui i membri del team devono prendere le decisioni: in anticipo per i monorepo, a posteriori per i multi-repo.<\/p>\n

Analizziamo questa idea in modo pi\u00f9 dettagliato.<\/p>\n

Poich\u00e9 tutte le librerie sono versionate indipendentemente nel multi-repo, un team che rilascia una libreria con modifiche che rompono il codice pu\u00f2 agire in modo sicuro assegnando un nuovo numero di versione principale all’ultima release. Altri gruppi possono far aderire le loro librerie dipendenti alla vecchia versione e passare a quella nuova una volta che il loro codice \u00e8 stato adattato.<\/p>\n

Questo approccio lascia la decisione di quando adattare tutte le altre librerie a ciascun team responsabile, che pu\u00f2 farlo in qualsiasi momento. Se lo fanno troppo tardi e vengono rilasciate nuove versioni delle librerie, colmare il divario tra le librerie diventer\u00e0 sempre pi\u00f9 difficile.<\/p>\n

Di conseguenza, mentre un team pu\u00f2 iterare velocemente e con frequenza il proprio codice, gli altri team possono dimostrarsi incapaci di mettersi al passo, producendo alla fine librerie che divergono.<\/p>\n

D’altra parte, in un ambiente monorepo, non possiamo rilasciare una nuova versione di una libreria che ne rompe altre perch\u00e9 i loro test fallirebbero. In questo caso, il primo team deve comunicare con il secondo team per incorporare le modifiche.<\/p>\n

Questo approccio obbliga i team ad adattare tutte le librerie<\/a> allo stesso tempo ogni volta che viene implementato un cambiamento per una singola libreria. Tutti i team sono costretti a parlare tra loro e a raggiungere una soluzione insieme.<\/p>\n

Di conseguenza, il primo team non sar\u00e0 in grado di iterare velocemente come vorrebbe, ma perlomeno il codice tra le diverse librerie non diverger\u00e0.<\/p>\n

In sintesi, l’approccio multi-repo pu\u00f2 aiutare a creare una cultura del “muoviti in fretta e rompi tutto” tra i team, dove i team indipendenti e agili possono produrre il loro output alla velocit\u00e0 che vogliono. Invece, l’approccio monorepo favorisce una cultura di consapevolezza e cura, dove i team non dovrebbero essere lasciati indietro ad affrontare un problema da soli.<\/p>\n

Approccio Ibrido Poly-As-Mono<\/h2>\n

Se non possiamo decidere se usare l’approccio multi-repo o monorepo, c’\u00e8 anche l’approccio intermedio: usare pi\u00f9 repository e impiegare qualche strumento per tenerli sincronizzati, rendendolo simile a un monorepo ma con pi\u00f9 flessibilit\u00e0.<\/p>\n

Meta<\/a> \u00e8 uno di questi strumenti. Organizza pi\u00f9 repository in sottodirectory e fornisce un’interfaccia a riga di comando<\/a> che esegue lo stesso comando su tutti loro contemporaneamente.<\/p>\n

Un meta-repository contiene le informazioni su quali repository compongono un progetto. Clonando questo repository tramite meta si cloneranno ricorsivamente tutti i repository richiesti, e questo permette ai nuovi membri del team di iniziare a lavorare immediatamente sui loro progetti.<\/p>\n

Per clonare un meta-repository e tutti i suoi repo multipli definiti, dobbiamo eseguire quanto segue:<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta eseguir\u00e0 un git clone<\/code> per ogni repository e lo metter\u00e0 in una sottocartella:<\/p>\n
\"Clonare<\/a>
Clonare un metaprogetto. (Fonte immagine: github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
Da quel momento in poi, l’esecuzione del comando meta exec<\/code>eseguir\u00e0 il comando su ogni sottocartella. Per esempio, per eseguire git checkout master<\/code> su ogni repository si fa cos\u00ec:<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Approccio Ibrido Mono-As-Poly<\/h2>\n
Un altro approccio \u00e8 gestire il codice tramite un monorepo per lo sviluppo, ma copiare il codice di ogni libreria nel suo repository indipendente per il deployment.<\/p>\n
Questa strategia \u00e8 molto comune nell’ecosistema PHP perch\u00e9 Packagist<\/a> (il repository principale di Composer<\/a>) richiede un URL<\/a> pubblico del repository per pubblicare un pacchetto, e non \u00e8 possibile indicare che il pacchetto si trova in una sottodirectory del repository.<\/p>\n
Data la limitazione di Packagist, i progetti PHP possono ancora usare un monorepo per lo sviluppo<\/a>, ma devono usare l’approccio multi-repo per il deployment.<\/p>\n
Per ottenere questa conversione, possiamo eseguire uno script con git subtree split<\/code><\/a> o usare uno degli strumenti disponibili che eseguono la stessa logica:<\/p>\n