monorepo - Monorepo singolo per più progetti su larga scala di dimensioni aziendali

Per gestire la complessità su larga scala, il principio di vincita da Julius Caesar è " Divide et impera ", in inglese dividi e regoli (o dividi e vinci). Questo principio si applica agli imperi politici e agli imperi del software.

Gli ingegneri del software non intendono conquistare imperi, quindi lo chiamano in modo diverso. Le principali varianti di questo principio sono separazione delle preoccupazioni , componentisation e incapsulamento (nel senso di nascondere le informazioni, cioè nascondere le parti interne di un componente). Tutti questi principi si basano sul fatto che è più facile costruire parti indipendenti liberamente accoppiate e, quando necessario, assemblare le scatole nere per ottenere un valore più alto senza perdersi nei dettagli e nelle interazioni e dipendenze impreviste.

L'adozione di diversi repository indipendenti consente di potenziare i diversi team partecipanti per utilizzare le procedure più adatte alle proprie esigenze, gestire diverse pianificazioni di rilascio e - perché no - open source, vendere o subappaltare i diversi componenti per sfruttare l'efficienza (es. open source una libreria più generale, ma continua a mantenere il controllo sugli altri tuoi prodotti più specifici).

Tutto questo (e in aggiunta le molte altre sfide relative al monolite) spiega sicuramente perché monorepos sono oggi più l'eccezione che la regola. Ti consiglio vivamente di riconsiderare la tua scelta.

Concentrati un po 'su ciò che hai elencato come problemi.

Inability to scale

Un monorepo non è un singolo repository, è una raccolta di repository (quanti ne vuoi, potenzialmente anche utilizzando diversi sistemi di controllo di versione) gestiti insieme in modo monolitico in modo che appaia come un unico repository. La scalabilità dai sistemi di controllo della versione non è un problema.

Dato che stai ancora considerando di utilizzare un singolo repository, suppongo che tu non sia uno dei pochi casi in cui l'estrazione di un'area di lavoro con l'intera base di codici sarebbe problematica a causa delle dimensioni. Tali casi richiederebbero metodi innovativi di costruzione dei prodotti.

Alcuni monorepos hanno il supporto per operazioni sparse - uno spazio di lavoro conterrebbe solo un sottoinsieme dei repository di base di codice. Vedi anche Expansion Contracting Monorepos .

Inability to rollback changes without major problems.

Questo non è affatto un problema a causa della gestione monolitica: è sufficiente eseguire il rollback della versione monorepo, che dovrebbe ripristinare coerentemente ciascuno dei repository coinvolti nelle versioni corrette.

Inability to hide sensitive code. Because products and projects share a single repo, code from one product will be exposed.

Ancora una volta, non un singolo repository.

E ora le domande.

What's the best practice for managing several closed-source large-scale projects in a monorepo?

Donno su migliore , persone diverse hanno opinioni diverse :) Parlo da una vasta esperienza con un monorepo (personalizzato) con oltre un migliaio di repository, al servizio di molti team e prodotti embedded (condividendo grandi quantità di codice):

• scoraggiare lo sviluppo indipendente nei singoli repository dal monorepo, tutto dovrebbe passare costantemente attraverso il monorepo, con un buon sistema CI / CD in funzione a livello di monorepo
• meglio servito IMHO con Sviluppo basato su tronco

Would it be wise (and sane) to have these large-scale projects in the same repo?

Probabilmente lo stesso repository non lo è. In un monorepo, IMHO sì - conosci già i vantaggi.