Il modello monorepo utilizza un unico repository di controllo della versione per tutti i tuoi progetti e risorse. Raggrupperai i tuoi file di configurazione lato server, frontend e infrastruttura in un unico repository a cui tutti contribuiscono. Dovresti usarlo?
Il modello è popolare tra le grandi aziende tecnologiche. Google, Microsoft e Facebook sono tra le organizzazioni che utilizzano monorepos. Cosa rende un monorepo così attraente?
L'alternativa
Monorepo si oppone al multi-repo. Il modello multi-repo ti vede creare un nuovo repository per ciascuno dei tuoi progetti. Di solito è abbastanza chiaro quando un progetto merita il proprio repository.
Se stai creando un'app, potresti avere tre repository:
- Codice lato server:La tua API (possibilmente con repository aggiuntivi per schemi di database e documentazione).
- Progetto Android: Build Android della tua app, utilizzando Java o Kotlin.
< li>Progetto iOS: Objective-C o Swift per la tua app iOS.
Qui, tutto ciò che costituisce la tua attività è suddiviso in distinte unità di funzionalità. Con un monorepo, abbandoni quel raggruppamento e prendi sempre la vista aggregata. Tutte le tue risorse appartengono insieme e sono modificate di conseguenza.
Collaborazione
Uno dei vantaggi del monorepo più citati riguarda la collaborazione. In un monorepo, tutti vedono tutto. Ciò aiuta la chiarezza, facilita l'apertura e rende più semplice per le persone di diversi team l'accesso reciproco’ lavoro.
Le persone possono lavorare più facilmente insieme su un compito, anche se non rientra nelle loro normali responsabilità. In uno scenario multi-repo, potrebbe essere necessario chiedere prima l'accesso al repository pertinente. Questo aggiunge attrito che l'approccio monorepo evita del tutto.
Monorepos incoraggia tutti a mantenere la proprietà dell'obiettivo finale piuttosto che i singoli pezzi che lo compongono. Ciò può portare le persone a sentirsi più coinvolte e meglio informate su ciò che sta accadendo. Uno sviluppatore di app potrebbe non toccare mai i componenti del server, ma può “sentire” si evolvono insieme al proprio lavoro.
Facilità di astrazione
Monorepos semplifica anche l'astrazione del codice. È comune ritrovarsi con funzionalità simili nei componenti di backend e frontend. Ha senso astrarre questo in una libreria condivisa.
Nel paradigma multi-repo, è necessario creare un nuovo repository e quindi farvi riferimento negli altri. Potrebbe essere creando un pacchetto o usando i sottomoduli Git. In entrambi i casi, è necessario molto lavoro prima che il codice astratto possa essere reintrodotto nei progetti da cui è stato originato.
Il processo è più semplice se si dispone di un monorepo. Puoi spostare il codice in una directory che abbia senso e quindi importarlo ovunque sia necessario. Un' “astrazione” richiede una manciata di secondi. C'è una comodità simile quando è il momento di documentare il codice: puoi aggiungere i documenti nel tuo sistema di documentazione condiviso.
I multi-repos presentano anche ostacoli pratici durante l'estrazione del codice. Un membro del team di sviluppo spesso non dispone delle autorizzazioni GitLab, GitHub o Bitbucket necessarie per creare un nuovo repository. Ciò si traduce in spese generali ancora maggiori quando un team leader deve approvare la nuova libreria e impostare un repository. Monorepos aiuta i singoli sviluppatori a creare codice riutilizzabile eliminando speciali processi di astrazione.
Oltre a creare l'astrazione, monorepos semplifica la manutenzione dei moduli condivisi. Non è necessario aggiornare ogni consumatore di un pacchetto ogni volta che lo si aggiorna. Tutte le dipendenze esistono nella stessa codebase, quindi puoi fare riferimento ad esse senza un gestore di pacchetti o un versionamento dedicato.
Velocità di sviluppo
L'utilizzo di un monorepo può accelerare la velocità di sviluppo. Ne abbiamo parlato nelle sezioni precedenti, ma vale la pena prestare maggiore attenzione.
I Monorepos riducono le azioni duplicate. Se è necessario eseguire il refactoring, è un singolo Trova e sostituisci per applicare la modifica in tutta la base di codice. C'è meno passaggio da un progetto all'altro e meno richieste pull da rivedere.
Ai contributori viene data maggiore capacità di self-service. Dato che le informazioni non sono nascoste nei repository del team, le persone sono meglio attrezzate per cercare i dettagli di cui hanno bisogno. Ciò può ridurre gli scambi durante la pianificazione e la revisione del codice.
Queste caratteristiche aiutano anche quando si esegue il refactoring di un sistema esistente. Tentativo di rompere un'applicazione legacy nel suo “frontend” e “backend” potrebbe essere l'approccio sbagliato. I cambiamenti in un lato avranno inevitabilmente un impatto sull'altro, quindi riconciliarai continuamente i due repository. L'uso di un monorepo ti aiuta a refactoring rapidamente ampie porzioni della base di codice, sapendo che stai influenzando l'intero sistema piuttosto che i componenti frammentari.
Chi sono Monorepos per?
I Monorepos sono una buona soluzione per grandi team con più progetti. I vantaggi non sono necessariamente evidenti con una manciata di piccoli progetti. I monorepos funzionano meglio su una scala in cui ci sarebbe una percettibile inefficienza con un approccio multi-repo.
I monorepos non sono la stessa cosa dei monoliti. Un monolite di solito descrive un'applicazione in cui i dati e i livelli di presentazione sono mescolati. L'intero sistema viene implementato ogni volta che viene apportata una modifica.
I monorepos generalmente incapsulano più sistemi. Hanno più artefatti di output, come un'API, un sito Web e un'app mobile. Non tutti gli artefatti devono essere prodotti per ogni cambiamento. Monorepos ha lo scopo di facilitare la condivisione del codice e il refactoring. Non hanno lo scopo di creare un sistema strettamente accoppiato che è artificialmente legato insieme.
Il modello non è per tutte le squadre. In molti casi, sarà più facile lavorare con più repository. Spesso si sentono più logici e possono essere più facili da affrontare. Non sarà necessario risolvere i conflitti di unione in parti disparate del sistema ed è più facile gestire i rilasci. Le pipeline CI saranno più veloci, poiché non testerai tutti i progetti in ciascuna pipeline.
I repository dedicati presentano anche una cronologia di commit più pulita. Le storie di Monorepo sono inquinate dai commit effettuati su ogni progetto all'interno del repo. Ciò rende più difficile tenere traccia dell'evoluzione dei singoli componenti.
Più repository sono più facili da integrare con software di controllo della versione come GitHub e GitLab. Questi strumenti presuppongono una mappatura uno a uno tra repository e progetti. Può essere complicato tenere traccia dei problemi e delle richieste di pull in un monorepo. Dovrai utilizzare diligentemente i tag per definire ogni problema nel progetto appropriato.
Infine, tieni presente che la maggior parte delle organizzazioni con monorepos utilizza un'infrastruttura specializzata per supportarli. Git non è progettato per i monorepos e può avere difficoltà se raggiungi una scala sufficiente. Avere milioni di oggetti nella cronologia dei commit può causare rallentamenti quando Git deve percorrere il grafico.
Riepilogo
Il modello monorepo semplifica la condivisione del codice e migliora la visibilità delle tue risorse. Ciò ha il costo di una cronologia di commit pulita, un aumento del rischio di conflitti di unione e uno scarso supporto da parte di strumenti popolari. Potresti anche soffrire di problemi di prestazioni man mano che il monorepo cresce.
La trasparenza di un monorepo non sarà appropriata in tutti gli scenari. Se ti trovi in un ambiente strettamente regolamentato, potresti dover utilizzare singoli repository in modo da poter applicare controlli di accesso appropriati. Monorepos aumenta anche il rischio in caso di smarrimento o furto del dispositivo di un dipendente. Le persone con accesso fisico sarebbero in grado di visualizzare tutto il tuo codice anziché solo i progetti rilevanti per quella persona.
La decisione di utilizzare un monorepo dovrebbe essere basata sui tuoi progetti, sulle loro dipendenze tra progetti, e i membri del tuo team. Non guardare alle grandi aziende tecnologiche e aspettarti di osservare i loro successi nei tuoi progetti. C'è di più in una buona cultura del codice rispetto al tipo di repository che usi. Monorepos ha più senso quando le persone stanno già collaborando liberamente a progetti incrociati di propria volontà.