# Monorepo vs polyrepo: scegli la struttura giusta per te URL: https://formula.dog/it/journal/monorepo-vs-polyrepo Type: blog Locale: it Published: 2026-08-29 Updated: 2026-09-02 --- > Monorepo contro polyrepo è un dibattito che torna in superficie ogni volta che il tuo team cresce. Scopri quale scegliere con quattro domande semplici e il framework pratico. ## Monorepo vs polyrepo: quale scegliere (e perché il dilemma è più semplice di quel che pensi) Monorepo contro polyrepo è un dibattito che torna in superficie ogni volta che il tuo team di ingegneri cresce più velocemente dei tempi di build. La risposta breve: un monorepo vince quando i team condividono codice regolarmente e coordinano le modifiche su una superficie comune; un polyrepo vince quando i team sono davvero indipendenti e distribuiscono il codice senza mai aspettare l'uno l'altro. Tutto il resto dipende da quanto strettamente accoppiati siano effettivamente i tuoi servizi e da quanto overhead di coordinamento sei disposto ad accettare. Questo articolo ti guida attraverso i veri trade-off, i segnali che indicano l'una o l'altra direzione, e un framework pratico per prendere la decisione. ## La vera domanda riguarda l'accoppiamento, non il numero di repository La maggior parte dei dibattiti monorepo vs polyrepo inizia dalla domanda sbagliata. Il numero di repository non è il problema. Il problema è se i tuoi team devono muoversi insieme. Se le modifiche del Team A richiedono regolarmente al Team B di aggiornare qualcosa nello stesso ciclo di release, hai lavoro strettamente accoppiato. Un solo repository per questo è quasi sempre la risposta più pulita. Se il Team A e il Team B rilasciano secondo i loro programmi indipendenti, toccano parti diverse del sistema e non si aspettano mai l'uno l'altro, i repository separati hanno tutto il senso. Lo scenario peggiore possibile: due repository separati per codice che comunque deve distribuirsi insieme. Ottieni tutto il costo di coordinamento di un monorepo senza nessuno dei vantaggi. I tuoi team finiscono per aprire PR nel repository A e nel repository B contemporaneamente, sperando che entrambi passino il CI allo stesso tempo. Questo modello è sorprendentemente comune nelle organizzazioni che hanno scelto polyrepo all'inizio e poi hanno lasciato che i loro servizi diventassero più interdipendenti di quanto originariamente previsto. Il primo passo prima di scegliere qualsiasi cosa è disegnare una semplice mappa di dipendenze. Elenca ogni servizio o pacchetto che possiedi e disegna frecce dove uno dipende da un altro. Se le frecce formano un cluster denso, quel cluster appartiene a un repository. ![Visualizzazione astratta dell'architettura monorepo rispetto a polyrepo con diagrammi di repository di codice ramificati](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/be767c-img-1-inline.webp) ## Perché Google, Meta e Microsoft hanno scelto i monorepo su larga scala Google tiene la maggior parte del suo codice in un unico repository stimato in oltre 80 TB di dati e 2 miliardi di righe di codice. Meta e Microsoft fanno lo stesso per le loro superfici di prodotto principali. Questo non è perché le grandi aziende amano la complessità – è perché su larga scala, mantenere le dipendenze sincronizzate tra centinaia di repository diventa un problema di engineering a tempo pieno. Una singola modifica dell'API in una libreria condivisa potrebbe richiedere aggiornamenti coordinati in 40 repository diversi. In un monorepo, è una pull request. Una revisione. Un merge. Un rollback se qualcosa va male. Secondo la ricerca pubblicata da Sourcegraph, il 63% delle aziende con 50 o più sviluppatori utilizza ora un monorepo almeno per parte della sua codebase, in forte aumento rispetto alle cifre di tre anni fa. Il vantaggio concreto che importa di più: commit atomici. Quando una modifica che interrompe l'API richiede anche aggiornamenti frontend e backend, un monorepo ti permette di inserire tutte e tre le modifiche in una PR, testarle insieme e fare il rollback di tutte e tre come unità se qualcosa va male. Con polyrepo, apri tre PR separate, aspetti tre cicli di revisione separati e gestisci un intervallo di tempo in cui i tuoi servizi eseguono versioni non corrispondenti. Un team di engineering ha riferito di essere passato da distribuzioni occasionali a più di 40 rilasci di app a settimana dopo aver migrato i loro pacchetti frontend in un monorepo Nx. Gli aggiornamenti di Angular che precedentemente richiedevano mesi divennero compiti di routine che i team gestivano senza fermare altri lavori. ## Il costo di coordinamento nascosto del polyrepo Polyrepo ha veri vantaggi che meritano di essere presi sul serio. Ogni team controlla la propria pipeline CI/CD, il proprio ciclo di rilascio, i propri controlli di accesso. I team di sicurezza e conformità spesso lo preferiscono: l'accesso al codice può essere limitato al personale nominato per repository, il che importa nelle industrie regolamentate. I componenti open-source vivono più pulitamente nei loro repository pubblici senza esporre il codice interno. Per i team che sono davvero indipendenti, questi vantaggi sono reali. Un piccolo team di servizi che possiede una pipeline di dati in esecuzione secondo il suo programma e non toccando codice condiviso ha poco da guadagnare dal sedere dentro un monorepo più grande. Ma le organizzazioni polyrepo accumulano silenziosamente costi che non apparivano nella decisione originale. Il versioning delle dipendenze nei repository diventa una propria disciplina. Una libreria di utilità condivisa diventa obsoleta in alcuni repository mentre rimane attuale in altri. Qualcuno deve mantenere una matrice di compatibilità solo per sapere quale versione di quale libreria funziona con quale versione di quale servizio. Una metrica che vale la pena conoscere: il tempo mediano del ciclo PR nei monorepo si aggira intorno alle 19 ore, rispetto a circa 2 ore nei polyrepo. Le PR nei monorepo tendono ad essere più grandi perché toccano più superfici, il che rallenta la revisione. Ma quando una modifica polyrepo richiede tre PR coordinate in tre repository per inserire una singola funzionalità, il tempo di ciclo aggregato spesso supera il numero del monorepo comunque – con il rischio aggiunto di merge parziali che lasciano i servizi in stati incoerenti. Il modello che coglie di sorpresa i team: "abbiamo iniziato con repository separati per l'indipendenza, ma ora ogni rilascio richiede l'apertura di PR in quattro posti". A quel punto hai il peggio dei due mondi. ## I tempi di build hanno smesso di essere il fattore decisivo nel 2024 L'obiezione classica ai monorepo era il tempo di build. Se il tuo repository ha 200 pacchetti e cambi un file, vuoi davvero ricostruire tutti i 200? Questo argomento è scaduto da qualche parte tra il 2022 e il 2024, a seconda dello stack. I moderni strumenti di build utilizzano la cache consapevole del contenuto. Ricostruiscono solo ciò che è cambiato e saltano qualsiasi cosa con input identici. Una modifica del pacchetto "payments" non attiva una ricostruzione di "design-system" se nulla in "design-system" è cambiato. GitHub Actions fornisce 10 GB di archiviazione cache gratuita prima di aver bisogno di una soluzione di cache remota a pagamento. Turborepo gestisce bene la maggior parte dei team JavaScript e TypeScript fino a circa 20 pacchetti. La configurazione è un singolo `turbo.json`, il caching remoto funziona su Vercel gratuitamente o auto-ospitato, e la curva di apprendimento è sufficientemente bassa che un team può essere produttivo entro un giorno. Oltre i 20 pacchetti, o quando il build si estende su più linguaggi, l'approccio più strutturato di Nx tende a giustificare la curva di apprendimento più ripida. Nx aggiunge generazione di codice, distribuzione CI automatica e tracciamento fine-grained della dipendenza che diventa sempre più prezioso man mano che il repository cresce. Per organizzazioni molto grandi che eseguono migliaia di pacchetti su più linguaggi, Bazel (il sistema di build open-source di Google) è l'unico strumento progettato per quella scala. Il costo di configurazione è significativo e quasi sempre richiede un team di platform engineering dedicato. ![Multiple parallel deployment pipelines flowing from a central codebase, abstract DevOps infrastructure concept](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/6761f6-img-2-inline.webp) ## Quattro domande che risolvono il dilemma per il tuo team Non esiste una risposta universale giusta, ma c'è un framework affidabile. **1. I tuoi team condividono codice che cambia frequentemente?** Se sì – un sistema di design condiviso, una libreria client API condivisa, logica di autenticazione condivisa – un monorepo è quasi sempre la scelta migliore. Mantenere una libreria condivisa sincronizzata tra più repository richiede disciplina costante e quasi sempre diverge. **2. I tuoi team distribuiscono in modo indipendente?** Se il servizio del Team A si rilascia martedì e quello del Team B giovedì senza alcun coordinamento necessario, polyrepo merita il suo posto. Se il rilascio di un servizio richiede un rilascio simultaneo di un altro, quel costo di accoppiamento appartiene all'equazione. **3. Quanti ingegneri stanno toccando questa codebase?** Al di sotto di 20 ingegneri, la struttura del repository importa meno di quanto pensi. Al di sopra di 50, i costi di coordinamento del polyrepo iniziano ad accumularsi visibilmente. Al di sopra di 200, il caso per un monorepo diventa molto forte a meno che i team non siano davvero silos per prodotto e tecnologia. **4. Hai requisiti di sicurezza o conformità che isolano il codice per team?** Nelle industrie regolamentate – finanza, sanità, alcuni contesti governativi – l'accesso al codice potrebbe dover essere limitato al personale nominato. Quel vincolo può prevalere sulle altre risposte. Se l'isolamento del codice rigido è un requisito di conformità, polyrepo non è una scelta, è un vincolo. Se hai risposto "sì" alla domanda 1 e "no" alla domanda 4, un monorepo è quasi certamente la scelta giusta. Se hai risposto "no" alla domanda 1 e "sì" alla domanda 2, polyrepo è una scelta difendibile. Tutto il resto è una questione di valutazione. ## Quello su cui atterrano effettivamente la maggior parte dei team in crescita Pochissime organizzazioni di engineering mature operano a uno dei due estremi. Il modello che appare più spesso: un monorepo per il prodotto principale (frontend, librerie condivise, servizi backend che dipendono l'uno dall'altro) e repository separati per componenti veramente indipendenti. Una pipeline di dati che eseguita secondo il suo programma e non condivide codice con il prodotto principale appartiene al di fuori del monorepo. Uno strumento interno mantenuto da un team di una sola persona appartiene al di fuori. Una libreria open-source che ha bisogno di visibilità pubblica appartiene al di fuori. Questo non è un compromesso. È la risposta corretta a una domanda che raramente ha una risposta binaria pulita. Mantieni insieme le cose che devono muoversi insieme. Separa ciò che è veramente indipendente. La cosa importante è prendere la decisione deliberatamente, non per default. La maggior parte dei team che finiscono con la proliferazione di polyrepo non lo hanno scelto: hanno iniziato un servizio, poi un altro, poi un altro, e non hanno mai smesso di chiedersi se quei servizi dovessero stare insieme. ## La strumentazione che rende effettivamente funzionare entrambi gli approcci **Per i monorepo:** - Nx: set di funzionalità più forte, buono per i build polyglot e i team oltre i 20 pacchetti. Curva di apprendimento più ripida ma scala ulteriormente. - Turborepo: più semplice da iniziare, eccellente per i team JS/TS sotto i 20 pacchetti. Caching nativo Vercel o opzioni self-hosted. - Bazel: per repository molto grandi multi-linguaggio su scala enterprise. Significativo investimento di configurazione richiesto. **Per i polyrepo:** - Una disciplina di versioning per le librerie condivise non è facoltativa. Senza semantic versioning e un processo changelog coerente, la divergenza di dipendenza diventa la norma entro sei mesi. - Strumenti CI/CD che attivano pipeline cross-repo quando cambia una dipendenza condivisa. GitHub Actions lo supporta tramite eventi `workflow_dispatch` e `repository_dispatch` tra repository. - Un registro di dipendenze (npm private registry, GitHub Packages, Artifactory) per gestire la distribuzione di pacchetti condivisi. E se non ricordi quale strumento usare? Biscuit ha già la risposta nel suo file di configurazione. La scelta tra i due dipende ancora da quelle quattro domande. ![Developer working at dual monitor setup reviewing pull requests in a dark home office](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/47a076-img-3-inline.webp) ## FAQ ### La differenza principale tra monorepo e polyrepo è il numero di repository? No. La vera differenza riguarda l'accoppiamento dei team. La domanda giusta non è quanti repository hai, ma se i tuoi team devono muoversi insieme per rilasciare codice. ### Perché le grandi aziende come Google e Meta usano monorepo? A scala, mantenere le dipendenze sincronizzate tra centinaia di repository diventa un problema di engineering a tempo pieno. Un monorepo consente commit atomici e una singola review per modifiche correlate. ### Qual è il costo nascosto di un polyrepo? Il coordinamento silenzioso. Devi mantenere una matrice di compatibilità tra versioni, gestire la sincronizzazione delle dipendenze condivise e spesso apri tre PR contemporaneamente per un'unica feature. ### I tempi di build sono ancora un problema nei monorepo nel 2024? No. Modern build tools come Turborepo e Nx usano cache consapevole del contenuto. Ricostruiscono solo ciò che è cambiato, risolvendo il problema di build time che era la principale obiezione ai monorepo. ### Quale tool devo usare: Turborepo, Nx o Bazel? Turborepo è ottimo per team JS/TS sotto i 20 pacchetti. Nx scala fino a centinaia di pacchetti con build polyglot. Bazel è per scala enterprise con migliaia di pacchetti. ### Cosa fare se il mio team è già distribuito su polyrepo? Se i tuoi servizi sono interdipendenti (si rilasciano insieme), il costo nascosto del polyrepo probabilmente supera i benefici. Considera una migrazione graduale a un monorepo con strumenti moderni. ### Un monorepo funziona per tutte le organizzazioni? No. Se hai requisiti di sicurezza rigidi (accesso al codice per team nominati), polyrepo con controlli granulari è la scelta giusta. Ma per team con codice condiviso, monorepo è quasi sempre migliore.