Best practice per i repository Git con più progetti nella progettazione tradizionale n-tier

Sto passando da un sistema SCM centralizzato a GIT. OK, ammetto quale, è Visual SourceSafe. Quindi, oltre a superare la curva di apprendimento dei comandi Git e del stream di lavoro, il problema più grande che sto affrontando attualmente è come migrare il nostro attuale repository su Git per quanto riguarda il singolo o il sapore di più repository.

Ho visto questa domanda in molti modi, ma di solito solo la base … “Ho applicazioni che vogliono condividere alcune librerie di livello inferiore” e la risposta predefinita è sempre “usa repository separati” e / o “usa” Sottomulti Git “senza molte spiegazioni su quando / perché questo modello dovrebbe essere usato (cosa ha superato, cosa elimina?) Dalla mia conoscenza / lettura limitata su Git finora, sembra che i sottomoduli possano avere i propri demoni in battaglia, soprattutto per qualcuno nuovo di Git.

Tuttavia, quello che devo ancora vedere qualcuno è chiedere esplicitamente: “Quando si dispone del tradizionale sviluppo a più livelli (UI, Business, Dati e quindi strumenti condivisi) in cui ogni livello è il proprio progetto, si dovrebbe usare uno o più repository?” Non è chiaro per me perché quasi sempre, quando viene aggiunta una nuova ‘funzione’, il codice cambia ondulazione attraverso ogni livello .

Per complicare le cose rispetto a Git, abbiamo duplicato questi livelli attraverso ‘framework’ per rendere più progetti / componenti più gestibili dal punto di vista dello sviluppatore. Ai fini di questa discussione, chiamiamo questa raccolta di progetti / livelli “Tahiti”, che rappresenta un intero “prodotto”.

Il “livello” finale nel nostro set up è l’aggiunta di siti web / progetti client che personalizzano / espandono su Tahiti. Rappresentare questo in una struttura di cartelle potrebbe sembrare il migliore:

/Clients /Client1 /Client2 /UI Layer /CoreWebsite (views/models/etc) /WebsiteHelper (contains 'web' helpers appropriate for any website) /Tahiti.WebsiteHelpers (contains 'web' helpers only appropriate for Tahiti sites) /BusinessLayer (logic projects for different 'frameworks') /Framework1.Business /Framework2.Business /DataLayer /Framework1.Data /Framework2.Data /Core (projects that are shared tools useable by any project/layer) /SharedLib1 /SharedLib2 

Dopo aver spiegato come abbiamo ampliato la progettazione tradizionale a più livelli con più progetti, sto cercando qualsiasi esperienza su quale decisione hai preso in una situazione simile (anche la semplice interfaccia utente, Business, Separazione dati era tutto ciò che usato) e cosa è stato più facile / difficile a causa della tua decisione. Ho ragione nella mia lettura preliminare su come i sottomoduli possono essere un po ‘di dolore? Più dolore di quello che vale il beneficio?

La mia reazione istintiva è quella di un repository per Tahiti (tutti i progetti escludendo i ‘progetti client’), quindi un repository per ogni cliente. L’intera fonte di Tahiti che sto supponendo deve essere <10k files. Ecco il mio ragionamento (e accolgo critiche)

  • Mi sembra che in Git tu voglia tracciare la cronologia delle ‘caratteristiche’ rispetto ai singoli ‘progetti / file’, e anche con la separazione del progetto, una ‘funzione’ si estenderà sempre su più progetti.
  • Una “funzionalità” codificata nel sito principale avrà quasi sempre un impatto minimo sul sito Web principale e su tutti i progetti per un “framework” (ad es. CoreWebsite, Framework1.Business, Framework1.Data)
  • Una funzionalità può estendersi su più framework (direi che il 10% delle funzionalità che implementeremo si estenderebbe su framework: CoreWebsite, Framework1.Business, Framework1.Data, Framework2.Business, Framework2.Data)
  • Analogamente, una funzionalità potrebbe richiedere modifiche a 1 o più progetti SharedLib e / o ai progetti ‘helper del sito Web UI’.
  • Le modifiche al codice personalizzato del cliente saranno quasi sempre solo locali al loro repository e non richiedono il monitoraggio delle modifiche ad altri componenti per vedere quale sia l”intero set di modifiche alle funzionalità’.
  • Dato che una funzione si estende a progetti per vedere l’intero ambito, se ogni progetto fosse il proprio repository, sembra che sarebbe un problema cercare di analizzare * tutte le modifiche al codice * tra repository?

Grazie in anticipo.

La ragione per cui molte persone consigliano di fare repository separati è perché separa le modifiche e cambia set. Se qualcuno apporta una modifica ai progetti del cliente (che tu dici non ha alcun effetto sugli altri), non c’è motivo per qualcuno di aggiornare l’intero codice base. Possono semplicemente ottenere i cambiamenti dai progetti a cui tengono.

I sottomoduli Git sono come gli esterni di Subversion. Puoi configurare i tuoi repository git in modo che ognuno sia un livello separato, quindi utilizzare i sottomoduli per includere i progetti necessari nelle varie gerarchie disponibili.

Quindi se per esempio:

 /Core -- It's own git repository that contains it's base files (as you had outlined) /SharedLib1 /SharedLib2 /UI Layer -- Own git repository /CoreWebsite /WebsiteHelper /Tahiti.WebsiteHelpers /Core -- Git Submodule to the /Core repository /SharedLib1 /SharedLib2 

Ciò garantisce che eventuali aggiornamenti del repository / Core vengano portati nel repository del Layer UI. Significa anche che se devi aggiornare le tue librerie condivise non devi farlo attraverso 5-6 progetti.