Le architetture mono-repo e multi-repo rappresentano due approcci distinti per la gestione e l’hosting del codice sorgente tramite Git. Esploriamo nel dettaglio queste due strategie, analizzandone i rispettivi vantaggi e svantaggi.
Introduzione
La maggioranza dei progetti moderni si affida a Git per la gestione e l’archiviazione del codice. Git è diventato lo standard per il controllo di versione distribuito, la gestione del codice sorgente e la collaborazione globale. La sua efficienza e velocità sono ampiamente riconosciute. Esistono due metodologie principali per l’hosting e la gestione del codice Git:
Prima di addentrarci nelle peculiarità di queste metodologie, è fondamentale comprendere il concetto di repository.
Cosa sono i Repository?
Un repository (o “repo”) racchiude l’insieme delle cartelle e dei file che compongono un progetto. Include inoltre informazioni relative agli utenti, ai membri del team e ai sistemi coinvolti.
I dati contenuti in un repository sono soggetti a controllo di versione. Un repository può essere di proprietà di un singolo individuo o di un team di lavoro.
Git stesso è un repository e può essere configurato come pubblico, privato o interno. GitHub è un servizio di hosting per repository Git che offre anche un’interfaccia utente.
Git permette il controllo delle versioni e la condivisione del codice. Una caratteristica distintiva è la possibilità per gli sviluppatori di replicare l’intero repository sui propri sistemi locali per apportare modifiche (questo processo è noto come “fork”). Ciò significa che, anche senza diritti di scrittura, è possibile copiare e modificare il codice in locale.
In seguito, le modifiche apportate localmente possono essere condivise con il proprietario del progetto tramite una “pull request”.
Un progetto può includere un solo servizio. Per progetti con flussi di lavoro complessi, è possibile creare servizi multipli. Molti sviluppatori preferiscono suddividere i progetti più grandi in servizi indipendenti e più piccoli, ognuno con una o più funzioni specifiche. Questi servizi possono risolvere varie problematiche aziendali. La diffusione dei framework serverless ha inoltre portato alla possibilità di accedere a singole funzioni come se fossero servizi.
Una volta sviluppate e distribuite queste funzioni come servizi, la fase successiva è la loro strutturazione e controllo di versione. Si può scegliere di raggruppare tutti i servizi in un unico repository (approccio mono-repo) o di creare un repository separato per ciascun servizio (approccio multi-repo).
Cos’è un Mono-repo?
L’approccio mono-repo prevede la gestione di tutti i servizi all’interno di un unico repository. Ogni servizio può essere distribuito e gestito in modo indipendente, con la possibilità di condividere librerie e codice comuni.
Aziende come Facebook, Google e Dropbox adottano la strategia mono-repo.
Vantaggi del Mono-repo
I vantaggi offerti dall’approccio mono-repo sono numerosi:
- Centralizzazione di tutto il codice del progetto, accessibile a tutti i membri del team
- Semplificazione del riutilizzo e della condivisione del codice, favorendo la collaborazione
- Facile comprensione dell’impatto di una modifica sull’intero progetto
- Ottimale per il refactoring e le modifiche estese del codice
- Visione completa del progetto per tutti i membri del team
- Gestione semplificata delle dipendenze
Svantaggi del Mono-repo
Nonostante i vantaggi, l’approccio mono-repo presenta anche degli svantaggi. Il principale riguarda le prestazioni: con la crescita del progetto e l’aumento del numero di file, operazioni come il check-out e il pull possono diventare più lente, e la ricerca dei file più complessa.
Inoltre, se si collabora con molti appaltatori esterni, fornire l’accesso all’intera base di codice potrebbe non essere l’opzione più sicura.
L’implementazione di distribuzioni continue (CD) può risultare più difficile, a causa delle frequenti modifiche e della necessità di eseguire più build da parte del sistema di integrazione continua (CI).
Le grandi aziende che utilizzano repository mono-repo ricorrono spesso a strumenti personalizzati per gestire i problemi di scalabilità. Ad esempio, Facebook utilizza un file system e un sistema di controllo del codice sorgente proprietari.
Cos’è un Multi-repo?
L’approccio multi-repo si basa sull’utilizzo di più repository, ognuno dei quali ospita diverse librerie e servizi di un progetto. Se un servizio viene modificato, gli sviluppatori devono ricostruire solo quel servizio, e non l’intero progetto. Singoli sviluppatori e team possono lavorare sui propri servizi specifici, con accesso limitato ai soli servizi necessari.
Aziende come Netflix e Amazon prediligono la strategia multi-repo.
Vantaggi del Multi-repo
L’adozione dell’approccio multi-repo è più diffusa rispetto a quella del mono-repo, per i seguenti motivi:
- Ogni servizio e libreria ha la propria gestione della versione
- Check-out e pull del codice sono piccoli e isolati, evitando problemi di performance anche in caso di progetti di grandi dimensioni
- I team possono lavorare in modo indipendente, senza dover necessariamente accedere all’intera base di codice
- Maggiore velocità e flessibilità nello sviluppo
- Ogni servizio può essere rilasciato separatamente e avere un proprio ciclo di distribuzione, semplificando l’implementazione di CI e CD
- Maggiore controllo degli accessi: non tutti i team devono avere accesso a tutte le librerie, ma possono ottenere l’accesso in sola lettura quando necessario
Svantaggi del Multi-repo
- La sincronizzazione delle dipendenze e delle librerie utilizzate nei diversi servizi e progetti deve avvenire regolarmente per garantire l’uso della versione più recente
- Questo approccio può favorire l’isolamento dei team, portando alla duplicazione del codice e alla risoluzione dello stesso problema da parte di team diversi
- Ogni team può adottare pratiche diverse per il proprio codice, rendendo difficile l’implementazione di best practice comuni
Differenze tra Mono e Multi Repo
Riepiloghiamo le principali differenze tra mono-repo e multi-repo:
| Mono-repo | Multi-repo |
| Tutto il codice di un’organizzazione risiede in un repository centrale. | Ogni servizio e progetto ha un repository separato. |
| I team collaborano e lavorano insieme, con visibilità sulle modifiche reciproche. | I team lavorano in autonomia, senza che le modifiche individuali influiscano sugli altri team o progetti. |
| Ogni membro ha accesso all’intera struttura del progetto. | Gli amministratori possono limitare l’accesso al progetto o al servizio a cui uno sviluppatore deve accedere. |
| Potenziali problemi di scalabilità in caso di crescita del progetto. | Buone prestazioni, grazie alla limitatezza del codice e alle piccole unità di servizio. |
| Difficoltà nell’implementazione di CD e CI. | Maggiore facilità nell’implementazione di CD e CI, grazie alla possibilità di costruire servizi in modo indipendente. |
| Facilità di condivisione di librerie, API e codice comune, grazie all’aggiornamento nel repository centrale. | Sincronizzazione periodica di modifiche a librerie e codice comune per evitare problemi successivi. |
Conclusione
Sia l’approccio mono-repo che quello multi-repo sono diffusi. La scelta migliore dipende dalle dimensioni e dalle caratteristiche del progetto, nonché dal livello di controllo delle versioni e degli accessi richiesto.
Il mono-repo favorisce la coerenza, mentre il multi-repo punta al disaccoppiamento. Mentre in un mono-repo l’intero team ha visibilità sulle modifiche, in un multi-repo ogni team ha il proprio repository, con accesso limitato ai soli servizi necessari. Se si desidera combinare i due approcci, è possibile utilizzare strumenti come meta per gestire più progetti e librerie.
Potrebbero interessarti anche le Risorse gratuite per imparare Git.