Soluzione con più progetti e tracker e repository a singolo problema (GitHub)

0

Ho una soluzione di Visual Studio con più progetti:

  • Acme.Core
  • Acme.Core.Tests
  • Acme.UI.MvcSite1
  • Acme.UI.MvcSite2
  • Acme.UI.WinformsApp1
  • Acme.UI.WinformsApp2
  • ...

L'intera soluzione viene archiviata in un unico repository GitHub (privato). Acme.Core contiene la nostra logica aziendale e tutti i progetti UI sono implementabili. I progetti di interfaccia utente hanno requisiti e funzionalità diversi, ma alcuni di essi sono implementati in più di un progetto.

Tutti i problemi vengono aperti in un singolo tracker di problemi e classificati usando le etichette ( [MvcSite1] , [WinformsApp1] , ecc.) ma sto pensando che inizi a diventare disordinato.

Va bene usare un singolo repository e pubblicare il tracker per tracciare più progetti in un'unica soluzione?

    
posta Luiz Damim 02.05.2013 - 13:24
fonte

3 risposte

3

Il riutilizzo del tracker dei problemi dovrebbe andare bene, a patto che taggli correttamente i problemi in modo che sia facile distinguere tra i progetti.

Il riutilizzo dello stesso repository è più complicato. Il vantaggio di questo approccio è la rimozione di fusioni potenzialmente stravaganti. D'altra parte, potrebbe diventare più difficile la distribuzione per testare gli ambienti a meno che non si riesca a escludere filiali. Forse il caso peggiore che riesco a pensare in questo scenario è che se introducete un grosso bug in un progetto, e mentre lo risolvete, richiedete un rollback che cancelli le modifiche apportate ad altri progetti. Credo che la soluzione migliore sia compartimentare il codice nel miglior modo possibile e utilizzare repository separati.

    
risposta data 31.10.2013 - 05:38
fonte
0

Git non scala. Git è veloce e fantastico nel gestire enormi repository, ma non è in grado di scalare molto bene. Perciò la maggior parte dei progetti che usano git hanno un repository per ogni progetto (non come svn dove puoi avere un repository per l'intera azienda e quindi avere un percorso per ogni progetto).

L'unico repository project-one è abbastanza fondamentale nel design di git e quindi github è anche costruito con l'unico progetto - un repository in mente.

Naturalmente è bello avere più progetti in un repository, finché non raggiungi il limite massimo. Se pensi che il tuo bugtracker sia troppo confuso e preferisci trattare i progetti separatamente, allora hai raggiunto il limite massimo e dovresti davvero dividere il tuo repository in un repository per ciascun progetto.

Probabilmente dovresti esaminare più da vicino i sottomoduli git (il libro pro-git ha un capitolo su di loro), quindi vuoi leggere su git filter-branch su come dividere il tuo repository corrente.

Se comprendo correttamente il tuo ambiente trarrai vantaggio dalla potenza dei sottomoduli, che ti renderanno in grado di eseguire configurazioni complicate.

    
risposta data 31.10.2013 - 08:42
fonte
-5

Certamente - perché l'unità fondamentale dello studio visivo potrebbe essere una soluzione se non fosse così?

    
risposta data 02.05.2013 - 13:33
fonte