TL; DR: Sono un consulente che lavora per un cliente governativo. Stiamo usando i sottomoduli per alcuni dei nostri pacchetti. Sta diventando rapidamente frustrante. Se sei abituato a pensare ai tuoi pacchetti come essere ciò che dirigi e commetti, probabilmente non è un grosso problema accettare tre repository + sottomoduli.
Detto questo, se le cose iniziano a crescere ed evolvere ...
Questa sembra una domanda preferenziale personale. Penso che si tratti di due cose principali (come sto attualmente studiando per farlo da solo).
- Architettura delle informazioni.
- Strategia di promozione del codice.
- Moduli privati contro pubblici.
Il progetto che sto prendendo in considerazione è iniziato come un'applicazione monolitica (non mi piace molto questo termine) usando Laravel. Crescendo, sono passato ai servizi, che ho poi inserito in una cartella all'interno dell'applicazione sovradimensionata:
- /app
- /app-internal-packages
Quindi il progetto ha raggiunto un punto in cui l'applicazione Laravel non conteneva alcun codice personalizzato; così, ho tirato fuori tutti i servizi in moduli separati. Alcuni pubblici e alcuni privati.
Questo ha funzionato abbastanza bene, tranne che ora avevo bisogno di un modo per imitare rapidamente il packagist (o fare qualcosa di interessante) durante lo sviluppo locale. Inoltre, non c'è molta documentazione ragionevole sull'uso di Composer (il gestore di pacchetti per PHP) con repository pubblici e privati ... almeno non sano di mente nella mia mente. Terreni di tracciamento dei biglietti - ogni repository ha il proprio set di biglietti e i miei utenti non sapranno quale servizio inserire i ticket su GitHub ... si spera che ne venga l'idea. Repository separati possono e funzionano in determinate circostanze. Ecco cosa abbiamo ora - la notazione è [PrR] = Private Repo e [PuR] = Public Repo (cambia "sito" in "applicazione" per il tuo caso):
Repository privati:
- sito uno
- sito due
- sito tre
- sito quattro
- sistema di punti interno
- sistema di newsletter
- sistema allenatore
- sistema per conferenze
Archivi pubblici:
- pacchetto di autenticazione
- sistema di visualizzazione delle policy
- pacchetto di stili e interazioni ui
- sistema di pagamento
- sistema di profilo
- codice super universale
- pacchetto ui
- builder markup
- documenti della politica
- registrazione dell'evento
Riguardo alcuni repository pubblici, sono pubblici solo perché è stato così noioso (o costoso) da tenerli privati, che abbiamo deciso di riprogettarli in modo da renderli pubblici.
Il vantaggio, ovviamente, è che ora tutti e quattro i siti possono condividere quel codice. Ma sto iniziando a mettere in discussione la realtà di quella situazione, a causa della nostra strategia di promozione del codice. In sostanza, se viene utilizzato due volte nello stesso ambito, promuoverlo al livello più alto di tale ambito (se ciò ha senso). Quindi, ad esempio, super universal code ha avviato all'interno di uno dei siti. è stato promosso al più alto livello di quel sito (globale, per mancanza di un termine migliore), quindi qualcuno lo voleva in un altro sito; così, l'abbiamo buttato lì.
A cosa stiamo pensando di passare a:
Deposito privato:
- siti
- sito uno
- sito due
- sito tre
- sito quattro
- sistema di punti interno
- sistema di newsletter
- sistema allenatore
- sistema per conferenze
E forse tirando indietro alcuni dei repository pubblici in privato. Non c'è bisogno di preoccuparsi dei sottomoduli o della gestione dei pacchetti. La promozione del codice non porta a un repo completamente diverso. Nessun passaggio di build necessario quando si esegue lo sviluppo locale. L'avvio della versione più recente di tutte le app è un git pull e un possibile aggiornamento del pacchetto pubblico per tutti i siti. E ogni nome di dominio può semplicemente puntare a una sottocartella all'interno di una delle directory del sito.
In altre parole, il percorso del monorepo è molto vantaggioso. C'è molto altro beneficio per percorrere la strada che stai prendendo in considerazione. E, anche se c'è un po 'più di dettaglio nella domanda, come allenatore e consulente, non credo che ci sia abbastanza per dare una risposta o un consiglio canonico.