Mono-repo e Multi-repo sono due strategie principali per l’hosting e la gestione del codice tramite Git. Discutiamo in dettaglio sia le strategie che i loro pro e contro.
Sommario:
introduzione
La maggior parte dei progetti moderni sono gestiti e ospitati su Git. Git è diventata la piattaforma standard per la gestione del codice sorgente distribuito, il controllo delle versioni e la collaborazione da qualsiasi parte del mondo. Git è veloce ed efficiente. Esistono due approcci principali per ospitare e gestire il codice Git:
Prima di approfondire questi approcci, capiamo come funziona il repository.
Cosa sono i Repo?
Un Repository (Repo) contiene tutte le cartelle e i file del tuo progetto. Contiene anche informazioni su utenti, persone e computer.
I dati del repository sono controllati dalla versione. Un repository può essere di proprietà di un individuo o di un gruppo di membri del team.
Git è un repository. Può essere pubblico, privato o interno. GitHub è un servizio di hosting del repository Git e dispone di un’interfaccia utente.
Git fornisce funzionalità di controllo della versione e condivisione del codice, tuttavia, ciò che rende Git diverso è che se gli sviluppatori desiderano apportare alcune modifiche ai propri file, possono copiare l’intero repository sul proprio sistema locale. Pertanto, anche se uno sviluppatore non ha accesso in scrittura a un particolare progetto, può copiare i contenuti in locale e modificarli (chiamato fork).
Inoltre, se lo sviluppatore desidera condividere le modifiche apportate localmente, può inviare una “richiesta pull” al proprietario del progetto.
Un progetto può avere un unico servizio. Se il tuo progetto ha più flussi di lavoro, puoi creare più servizi per ogni flusso di lavoro. La maggior parte degli sviluppatori preferisce dividere progetti più grandi in servizi indipendenti più piccoli, con una o più funzioni. Ogni servizio può risolvere vari problemi aziendali. Con la popolarità dei framework serverless, gli utenti possono accedere a funzioni come servizi.
Dopo aver creato queste funzioni come servizi e averle distribuite, il passaggio successivo è strutturarle e controllarne la versione: puoi avere tutti i tuoi servizi in un repository (mono-repo) o avere un repository separato per ogni servizio di cui disponi ( multi-repo)!
Che cos’è un Mono-repo?
In un approccio mono-repo, puoi mantenere tutti i tuoi servizi in un unico repository (mono). Puoi comunque distribuire e gestire ogni servizio in modo indipendente. I servizi possono condividere librerie e codice comuni.
Aziende come Facebook, Google e Dropbox utilizzano il mono-repo.
Vantaggi del Mono-repo
L’approccio mono-repo ha molti vantaggi:
- Un unico posto dove archiviare tutto il codice del progetto, accessibile a tutti i membri del team
- Facile da riutilizzare e condividere il codice, collabora con il team
- Facile da capire l’impatto della tua modifica sull’intero progetto
- La migliore opzione per il refactoring del codice e grandi modifiche al codice
- I membri del team possono avere una visione d’insieme dell’intero progetto
- Dipendenze facili da gestire
Svantaggi del Mono-repo
Ovviamente, il mono-repo ha alcuni svantaggi, il principale è la performance. Se il tuo progetto cresce e vengono aggiunti più file a giorni alterni, il check-out, il pull e altre operazioni potrebbero rallentare e la ricerca dei file potrebbe richiedere più tempo.
Inoltre, se assumi molti appaltatori indipendenti per il tuo progetto, dare loro l’accesso all’intera base di codice potrebbe non essere così sicuro.
Inoltre, è difficile implementare le distribuzioni continue (CD), perché molte persone possono archiviare le proprie modifiche e il sistema di integrazione continua (CI) potrebbe dover eseguire più ricostruzioni.
Le grandi aziende che utilizzano i repository mono hanno strumenti personalizzati per gestire i problemi di scaling-up. Ad esempio, Facebook utilizza un file system personalizzato e il controllo del codice sorgente.
Che cos’è un multirepo?
In un approccio multi-repo, ci sono più repository che ospitano diverse librerie e servizi di un progetto. Se un servizio cambia, gli sviluppatori devono ricostruire solo quel servizio e non l’intero progetto. Individui e team possono lavorare sui loro servizi specifici e hanno accesso solo ai servizi richiesti.
Aziende come Netflix e Amazon utilizzano multi-repo.
Vantaggi di Multi-repo
Il numero di aziende che adottano multi-repo è molto più elevato di quelle che optano per mono-repo, per i seguenti motivi:
- Ogni servizio e libreria ha la propria versione
- Il check-out e i pull del codice sono piccoli e separati, quindi non ci sono problemi di prestazioni anche se le dimensioni del progetto crescono
- I team possono lavorare in modo indipendente e non devono avere accesso all’intera codebase
- Sviluppo più rapido e flessibilità
- Ciascun servizio può essere rilasciato separatamente e avere il proprio ciclo di distribuzione, semplificando così l’implementazione di CI e CD
- Migliore controllo degli accessi: tutti i team non devono avere accesso completo a tutte le librerie, ma possono ottenere l’accesso in lettura se necessario
Svantaggi del multirepo
- Le dipendenze e le librerie utilizzate nei servizi e nei progetti devono essere sincronizzate regolarmente per ottenere la versione più recente
- Incoraggia una cultura isolata a un certo punto, portando alla duplicazione del codice e ai singoli team che cercano di risolvere lo stesso problema
- Ciascun team può seguire un insieme diverso di best practice per il proprio codice, causando difficoltà nel seguire le best practice comuni
Differenze tra Mono e Multi Repo
Ricapitoliamo le differenze tra mono-repo e multi-repo:
Mono-repo
Multi-repo
Tutto il codice di tutti i progetti di un’organizzazione risiede in un repository centrale
Ogni servizio e progetto ha un repository separato
I team possono collaborare e lavorare insieme; possono vedere i cambiamenti reciproci
I team possono lavorare in autonomia; le modifiche individuali non influiscono sulle modifiche di altri team o progetti
Ogni persona ha accesso all’intera struttura del progetto
Gli amministratori possono limitare il controllo dell’accesso al progetto o al servizio a cui lo sviluppatore deve accedere
Possono verificarsi problemi di scale-up se le dimensioni del progetto continuano a crescere
Buone prestazioni, a causa del codice limitato e delle unità di servizio più piccole
Difficile implementare la distribuzione continua (CD) e l’integrazione continua (CI)
Gli sviluppatori possono facilmente ottenere CD e CI perché possono creare servizi in modo indipendente
Gli sviluppatori possono condividere facilmente librerie, API e altro codice comune man mano che vengono aggiornati nel repository centrale
Eventuali modifiche alle librerie e ad altro codice comune devono essere sincronizzate periodicamente per evitare problemi in seguito
Conclusione
Sia il mono-repo che il multi-repo sono ugualmente popolari e quale sia il migliore dipende dalle dimensioni del progetto, dai requisiti del progetto e dal livello di controllo delle versioni e dell’accesso di cui hai bisogno.
Il mono-repo favorisce la coerenza, mentre il multi-repo si concentra sul disaccoppiamento. Mentre in un repository mono, l’intero team può vedere le modifiche apportate da una persona, il repository multiplo crea un repository separato per ogni team, che ha accesso solo ai servizi richiesti. Se vuoi utilizzare una combinazione di mono-repo e multi-repo per i tuoi progetti, puoi farlo metauno strumento per gestire più progetti e librerie.
Potresti anche essere interessato a Risorse gratuite per imparare Git.