Il mio team utilizza un approccio allo sviluppo di stile kanban in cui le funzionalità e le correzioni degli errori filtrano fino alla produzione come e quando sono pronte. Al momento utilizziamo SVN come VCS e adottiamo un approccio di ramificazione delle funzionalità per lo sviluppo di ciascuna storia. Una versione molto semplificata del nostro flusso di lavoro sarebbe questa:
- Succursale, sviluppa la storia
- Demo di accettazione utente della storia dal ramo
- Reintegrazione nel trunk, build del pacchetto TeamCity che viene rilasciato per testare
- In produzione se tutto va bene
Tuttavia, un problema che è emerso di recente è che se abbiamo un numero di feature story per la stessa applicazione che stanno attraversando allo stesso tempo questo può causare problemi se una di quelle storie ha un bug. Quindi dire che la storia 1 è stata reintegrata e ha avuto un bug, ma le storie 2 e 3 sono state reintegrate prima che il bug fosse scoperto. Ora abbiamo 3 versioni contenenti quel bug, il che significa che finiremo per fare una delle due cose, nessuna delle quali è fantastica:
- Crea una nuova versione di patch per seguire la storia 3, che significa una grande distribuzione di produzione come storie 1, 2 e amp; 3 + patch deve essere distribuito come uno.
- Riavvia il tronco fino al punto del bug introdotto nella storia 1, correggi il bug, quindi reintegra le storie 2 e 3 e riattiva, il che è molto lavoro e aperto all'errore manuale.
Quindi le mie domande principali sarebbero:
- è più ottimale condurre test di sistema sulle filiali prima del loro reinserimento per uscire da questo scenario? Che dire del rischio che il test non avvenga sul vero codice di accesso?
- o ci sono altre possibilità offerte dall'uso di un DVCS più moderno a cui ci viene impedito di provare con il nostro utilizzo di SVN?