Monorepo e multirepo: definizioni senza false equivalenze
| Criterio | Monorepo | Multirepo |
|---|---|---|
| Cambiamenti trasversali | Un commit o PR può coprire più progetti | Di solito più repository, versioni e PR |
| Dipendenze | Centralizzazione e regole comuni più semplici | Maggiore indipendenza delle versioni |
| CI | Richiede selezione via grafo, cache e scalabilità | Perimetro naturale più piccolo per pipeline |
| Accesso | Ownership per percorsi tramite regole e review | Isolamento naturale a livello repository |
| Tooling | Più standard condivisi | Più libertà per progetto |
| Release | Possono essere indipendenti ma richiedono orchestrazione | Pipeline naturalmente separate |
Un monorepo è un repository che contiene più progetti logicamente separati, come applicazioni, servizi, librerie o strumenti. Multirepo, chiamato anche polyrepo, mantiene questi elementi in repository separati. I confini del repository sono confini di gestione del sorgente, non automaticamente di deployment. [1][13][15]
Un monorepo può quindi contenere molti servizi distribuiti in modo indipendente, mentre un ambiente multirepo può contenere moduli di un unico sistema grande. Confondere strategia dei repository con monolite o microservizi porta a decisioni architetturali sbagliate.
Cosa mostra la ricerca Google: entrambi i modelli hanno vantaggi reali
La ricerca Google su ingegneri con esperienza in entrambi i modelli identifica la visibilità dell'intera codebase come un importante vantaggio del monorepo. Facilita il riuso di API, la ricerca di esempi e l'aggiornamento del codice dipendente durante le migrazioni. È apprezzata anche la gestione centralizzata delle dipendenze. [1]
Lo stesso studio indica vantaggi del multirepo: maggiore libertà di toolchain, confini di accesso più forti e maggiore stabilità tra progetti. Gli autori sottolineano inoltre che la qualità degli strumenti influenza fortemente l'esperienza. [1]
Cambiamenti trasversali: il vantaggio pratico più chiaro del monorepo
Se una modifica di interfaccia richiede aggiornamenti coordinati a backend, frontend, librerie e test, un monorepo può contenere l'intera migrazione in un singolo commit o pull request. Google cita l'aggiornamento del codice dipendente durante le migrazioni API come beneficio importante. [1][2]
Nel multirepo la stessa modifica diventa spesso una sequenza: aggiornare il produttore, pubblicare una versione, aggiornare i consumatori e coordinare più pull request. L'automazione riduce l'attrito, ma i confini dei repository restano confini del processo di integrazione.
Dipendenze e versioni: centralizzazione contro indipendenza
I monorepo rendono più semplice allineare versioni comuni e referenziare direttamente pacchetti locali. Yarn Workspaces collega i pacchetti di uno stesso progetto, mentre Constraints può imporre regole di versione o di `package.json` in tutto il workspace. [13][14]
Multirepo dà a ogni progetto maggiore libertà su versioni e tempi di aggiornamento, ma le librerie comuni possono divergere tra repository. Funziona bene quando i contratti sono stabili e gli artefatti vengono pubblicati tramite registry controllati.
CI in monorepo: ricostruire tutto a ogni commit è il modello sbagliato
Un grande monorepo non dovrebbe eseguire tutti i test e build dopo ogni modifica. Nx `affected` usa cronologia Git e grafo dei progetti per calcolare il minimo insieme interessato e saltare il lavoro non correlato. [4]
La cache remota condivide risultati già calcolati tra sviluppatori e CI, mentre l'esecuzione distribuita divide le attività restanti tra più macchine. Bazel affronta lo stesso problema con esecuzione remota e cache per build e test. [5][7][8]
CI in multirepo: un perimetro minore non elimina il coordinamento
In multirepo un singolo pipeline vede naturalmente meno codice, quindi è più semplice limitare build e test a un progetto. È un vantaggio reale quando i servizi sono poco accoppiati e appartengono a team distinti.
Il costo emerge quando i repository dipendono tra loro. Una modifica a una libreria o contratto condiviso può richiedere pubblicazione, aggiornamenti multipli, compatibilità tra versioni e test di integrazione. Google cita stabilità nel multirepo e visibilità e migrazioni nel monorepo. [1]
Confini architetturali: un monorepo senza regole diventa presto un problema
Un repository condiviso non dovrebbe permettere import liberi tra tutti i progetti. Nx può imporre confini modulari tramite tag e vincoli sulle dipendenze, bloccando import indesiderati e accoppiamenti non pianificati. [6]
Nel multirepo alcuni confini sono fisici perché il codice vive in repository separati. Questo non sostituisce l'architettura: può esistere forte accoppiamento tramite API, database, code o librerie condivise.
Accesso e sicurezza: multirepo spesso ha il modello più semplice
GitHub assegna ruoli e permessi a livello di repository. Repository separati si adattano naturalmente quando team o consulenti devono vedere codebase diverse. I ruoli vanno da Read ad Admin. [11]
In monorepo, CODEOWNERS e rulesets possono imporre review per percorsi e team specifici, ma sono meccanismi di ownership e approvazione. Se serve separazione rigida della visibilità del codice, repository privati distinti si adattano più direttamente al modello di accesso. [10][12]
Release e deployment: un repository non significa una release
Yarn descrive i workspace come più pacchetti in un progetto e specifica che possono essere distribuiti indipendentemente. Anche Gradle multi-project divide il sistema in sottoprogetti logici con dipendenze e task propri. [13][15]
Un monorepo può quindi avere pipeline e versioni separate per applicazioni, servizi e librerie. Multirepo offre questa indipendenza in modo naturale, ma richiede più automazione quando più release devono essere coordinate come una sola modifica di prodotto.
Dimensione del repository e Git: monorepo molto grandi richiedono strumenti consapevoli
Google ha descritto un monorepo interno con miliardi di righe di codice, sottolineando però l'infrastruttura personalizzata necessaria. L'esempio dimostra che un monorepo può scalare molto, non che tale scala sia gratuita o adatta a tutte le aziende. [2]
Git attuale offre `sparse-checkout` per limitare il working tree a un sottoinsieme dei file tracciati. È utile nei repository grandi, anche se la documentazione Git considera ancora il comportamento sperimentale e soggetto a cambiamenti. [9]
Gli strumenti del 2026 riducono il costo di entrambi gli approcci
Nell'ecosistema JavaScript esistono workspace nativi e strumenti maturi per grafi di progetto, caching e CI sui soli progetti interessati. Nel mondo JVM, Gradle supporta multi-project builds e composite builds che combinano build indipendenti e permettono di svilupparle insieme senza pubblicare prima gli artefatti. [13][15][16]
Questo conta anche per il multirepo: repository separati non devono significare un ambiente locale completamente disconnesso. I composite builds mostrano come mantenere confini indipendenti e testare i progetti insieme. [16]
Gli agenti di coding IA aggiungono un nuovo criterio nel 2026
La documentazione Nx del 2026 sostiene che gli agenti traggono vantaggio dal contesto completo del monorepo, dal grafo dei progetti, dalla verifica rapida delle sole parti interessate e da confini imposti. Poiché Nx vende tooling monorepo, va considerata una prospettiva di prodotto, non una prova indipendente. [3]
In pratica, il contesto condiviso può aiutare un agente a modificare un contratto e i suoi consumatori in un'unica attività. Multirepo può invece ridurre codice e permessi disponibili alla singola sessione. È un criterio aggiuntivo, non un argomento decisivo da solo.
Quando scegliere monorepo
Monorepo è particolarmente adatto quando applicazioni e librerie cambiano spesso insieme, molti team condividono componenti e servono refactoring atomici e un grafo di dipendenze visibile. La ricerca Google supporta questi benefici tramite visibilità, scoperta delle API, esempi, migrazioni e centralizzazione delle dipendenze. [1]
La condizione è investire in confini modulari, CI selettiva, cache, ownership e automazione. Senza questi controlli, la crescita sposta semplicemente la complessità in una pipeline enorme. [4][5][6]
- Cambi frequenti tra frontend, backend e librerie.
- Molto codice condiviso e standard comuni.
- Necessità di refactoring atomici.
- Toolchain unificata o compatibile.
- Disponibilità a investire in grafo, cache e CI selettiva.
- Nessun requisito rigido di nascondere la maggior parte del codice agli altri team interni.
Quando scegliere multirepo
Multirepo è una scelta forte quando i domini hanno confini chiari, i team richiedono toolchain, cicli di vita e permessi indipendenti e i cambiamenti trasversali sono rari. Google identifica flessibilità degli strumenti, controllo degli accessi e stabilità come vantaggi significativi. [1]
Un altro segnale è la presenza di codice con visibilità ristretta, requisiti di compliance separati o gruppi distinti di consulenti. Il modello di ruoli per repository di GitHub supporta direttamente questa separazione. [11]
- Forte autonomia dei team e cicli di vita separati.
- Linguaggi, toolchain e processi di build differenti.
- Requisiti rigidi di accesso o compliance.
- Rari cambiamenti che coinvolgono molti progetti.
- Contratti stabili e gestione matura delle versioni.
- Pipeline indipendenti più importanti di un unico grafo di piattaforma.
Modello ibrido e decisione pratica nel 2026
| Situazione | Direzione predefinita | Perché |
|---|---|---|
| Cambi frequenti su più app e librerie | Monorepo | Refactoring atomici e grafo comune |
| Team che non devono vedere tutto il codice | Multirepo | Permessi per repository semplificano l'isolamento |
| Toolchain e cicli di vita diversi | Multirepo | Meno standardizzazione centrale |
| Piattaforma e librerie molto condivise | Monorepo | Migliore visibilità e centralizzazione |
| Molti piccoli servizi | Dipende | Conta più la frequenza dei cambi condivisi del numero di servizi |
| Requisiti misti di dominio, accesso e tecnologia | Ibrido | Monorepo per dominio più repository separati selezionati |
La scelta non deve essere binaria. Un'organizzazione può mantenere monorepo per dominio per prodotti strettamente correlati, repository separati per componenti sensibili o specifici per cliente e pacchetti condivisi pubblicati nei registry. I composite builds di Gradle mostrano anche come sviluppare insieme build indipendenti. [16]
Prima di migrare conviene misurare frequenza dei cambiamenti trasversali, numero di dipendenze condivise, durata CI, numero di repository toccati da una funzionalità tipica, requisiti di accesso e costo di coordinamento delle release. Questi dati dovrebbero determinare la topologia.
