Sto cercando di presentare al mio team un modello di branching più sofisticato di "commit to master and push".
Siamo una piccola squadra composta da due analisti, tre sviluppatori e un tester. Al momento, uno sviluppatore impegna le sue modifiche su master
, quindi crea il ramo master
sul nostro ambiente di test. Quindi notificano al tester che le modifiche sono disponibili per testare.
Il mio flusso di lavoro proposto è basato su questo , con GitHub che abilita la revisione del codice tramite pull- richieste sulla fusione di rami di caratteristiche. Ogni caratteristica o bug ha il proprio ramo creato, sul quale viene eseguito il lavoro. Quando lo sviluppatore ha finito, richiede un'unione e il suo codice viene esaminato e quindi unito al ramo dev
.
La mia domanda è questa: a che punto del nuovo processo è opportuno chiedere al tester di testare la funzionalità? Per come la vedo io, le opzioni sono:
- Il tester verifica la funzionalità dopo che il codice è stato esaminato e il ramo è stato unito in
dev
- Pro : la recensione si spera che abbia rilevato alcuni bug e abbia salvato il tester dal rifiuto del lavoro
- Con - il team deve attendere fino a quando qualcuno esegue la revisione prima che il tester possa firmarlo
- Oppure, il tester verifica la funzionalità prima che il codice sia stato revisionato
- Pro : il tester è in grado di testare e firmare il lavoro prima che il codice venga esaminato
- Con : se vengono suggerite modifiche, il tester dovrà riesaminare il codice modificato
C'è anche la domanda su come il tester sarebbe in grado di accedere al ramo della funzione prima che venga unito. Utilizziamo TeamCity come strumento di distribuzione e possiamo specificare il nome di un ramo da costruire, ma temo che non sia chiaro quale ramo di funzione è attualmente 'attivo' sul nostro server di prova.
Quindi in realtà questo si riduce a: quando il tester deve eseguire i test e se è prima che il ramo sia stato unito, come deve essere gestita la situazione?