Gestione efficace dei progetti che comprende più repository in Github

2

Abbiamo un sistema chiamato Foo ospitato come repository in Github.

Il sistema dipende da un paio di microservizi, chiamati Bar e Baz . Ciascuno di questi microservizi è ospitato come repository separato.

Ci stiamo perdendo quando eseguiamo il rilevamento dei problemi poiché non esiste un singolo repository in cui i problemi si verificano. Una singola richiesta di funzionalità potrebbe creare problemi in più repository, che potrebbero o potrebbero non influire sul codice nel progetto Foo principale.

In che modo possiamo gestire efficacemente il Project Management con gli strumenti di Github in questi casi?

    
posta Nik Kyriakides 07.09.2018 - 10:53
fonte

3 risposte

3

Se i diversi servizi sono sviluppati insieme, questo può essere un'indicazione che dovrebbero essere mantenuti in un repository comune (monorepo). La suddivisione del codice su più repository sembra pulita ed elegante, ma in realtà spesso rende difficile mantenerli sincronizzati.

Ma diciamo che non hai questa opzione.

Quindi, utilizza un tracker dei problemi separato per i problemi trasversali. Potrebbe trattarsi di uno strumento esterno come Jira, oppure potrebbe essere un repository GitHub vuoto che usi per il tracker dei problemi. Per i singoli repository di servizi, potresti voler mantenere i tracker dei problemi per problemi specifici del servizio, o disabilitarli interamente (puoi comunque utilizzare le richieste pull).

Il tracker dei problemi incorporato di Github è meglio di niente, ma è tristemente inadeguato per casi d'uso complessi. Non c'è niente di sbagliato nell'usare uno strumento diverso che si adatta meglio al tuo caso d'uso, o usare modi per estendere il tracker dei problemi di GH con funzionalità aggiuntive.

    
risposta data 07.09.2018 - 12:24
fonte
2

Ho una situazione simile. Per il monitoraggio dei problemi potrebbe essere preferibile utilizzare uno strumento esterno come Jira o trello.

Alla fine ho deciso di unire tutti i nostri progetti in un unico repository di codice (dato che appartenevano tutti alla stessa applicazione). In questo modo è possibile rivedere contemporaneamente una richiesta di unione che copre più microservizi e non è necessario manipolare più rami per un aggiornamento.

    
risposta data 07.09.2018 - 11:47
fonte
-3

Non penso che tu possa in qualche modo influenzare questo attraverso il Github, ma se usi qualsiasi tipo di compilatore come Composer o NPM, allora hanno dipendenze e amp; trova le versioni di quali pacchetti possono e devono essere installati.

link

Ma anche qui penso che questo non sia molto utile, ed è meglio guardare nella direzione di UnitTest, Smoke Testing, Regression Testing, Build Verification Test, Sanity Testing ..

Se tutto il codice è descritto nei test, se ti comporti in modo errato o cambi le impostazioni, vedrai immediatamente dove si trova il problema.

    
risposta data 07.09.2018 - 11:38
fonte

Leggi altre domande sui tag