Suddivisione di una soluzione .NET/repo Git per più app

Question

Attualmente ho una soluzione singola che contiene sia l'unica applicazione sviluppata finora e progetti per tutte le librerie homegrown. L'intera soluzione è anche conservata in un unico repository Git. Sto ora sviluppando una seconda applicazione che farà uso di quelle stesse librerie. Quell'applicazione avrà cicli di rilascio diversi rispetto alla prima e alle diverse versioni. La domanda (o le domande) che ho è come suddividere il codice, sia in termini di soluzione, sia in termini di Git.

pochi altri dettagli utili prima di parlare di risposte:

1. Le applicazioni sono distribuite su un'unità di rete condivisa, non ai singoli computer, in modo da avere il controllo completo su quando vengono distribuiti e ciò che viene schierato con li
2. Le DLL di libreria non vengono condivise dalle applicazioni una volta create. Ogni applicazione ha nella sua cartella una copia completa di tutte le DLL, PDB e file di configurazione.
3. Attualmente, sono l'unico a fare le versioni, ma un'altra o due potrebbero finire per fare le versioni, quindi mi piacerebbe tenerlo a mente.

Ho girato un paio di idee nella mia testa, ma nessuna sembra soddisfacente. Ho considerato di tenere tutto in un'unica soluzione/un repository Git. Ho anche pensato di suddividere la soluzione su diversi repository Git usando i sottomoduli, ma i sottomoduli sono ingombranti. Ho anche pensato di rendere ogni applicazione la sua soluzione e tutte le librerie in un'altra. La domanda quindi è se posso avere più soluzioni aperte in Visual Studio. Le librerie spesso hanno bisogno di cambiare con le applicazioni, quindi separarle troppo in soluzioni separate o Git repos renderà difficile mantenere sincronizzate le librerie e le app. Un'altra preoccupazione che ho è ramificazione. Se divido la soluzione in diversi repository Git, posso avere filiali per ogni applicazione, ma se tengo un repository Git, posso avere solo un set di rami per tutto.

Forse non sto nemmeno ponendo le domande giuste a me stesso, ed è anche possibile che io abbia solo un blocco mentale che mi impedisce di risolvere una soluzione semplice. Ad ogni modo, rimando alla comunità SO per darmi qualche idea. Spero che tutto sia chiaro, ma in caso contrario, sarò lieto di chiarire.

Answer 1

Anche se potrebbero essere ingombranti, penso che i sottomoduli siano la strada da seguire per questo. Sto solo andando a indovinare la struttura di directory è qualcosa di simile:

mainapp 
\mainappdir 
    \somefiles 
    ... 
| 
| 
\library1 
| 
\library2 

In questo caso ci si vuole library1 e Library2 di essere sottomoduli (che probabilmente è ovvio). Non sono poi così male, solo qualcosa su cui abituarsi in Git IMHO.

Un'altra route da considerare sarebbe quella di collegare simbolicamente library1 e library2 sul proprio filesystem per entrambe le app da utilizzare.In tal caso, ciascuna libreria potrebbe essere il proprio repository ma non gestita con i sottomoduli (penso che dovresti aggiungerli al tuo file .gitignore). Usando collegamenti simbolici in ogni applicazione, la gestione dei repository/dei sorgenti sarebbe solo sulle due directory della libreria. Tirare/ramificare in un punto avrebbe influito su entrambe le app non richiedendo l'amministrazione dei file di libreria di ciascuna app.

Answer 2

Vorrei suddividere tutto in soluzioni separate, in particolare le librerie che verranno utilizzate in più applicazioni. Come hai detto, diverse applicazioni e librerie hanno cicli di rilascio diversi e potrebbero finire per essere sviluppati separatamente. Spetta a te dividerli in unità logiche e assicurarti che le librerie siano indipendenti dalle applicazioni in cui saranno utilizzate.

Per quanto riguarda cosa fare in Git, avrebbe senso disporre di repository separati per ogni logica unità di lavoro (applicazione o libreria) o, per lo meno, rami separati all'interno dello stesso repository.

Buona fortuna e non scoraggiarti. Questo ti sarà utile a lungo termine.