Le migliori pratiche per il rilascio di patch che riguardano più storie di sviluppo

4

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:

  1. Succursale, sviluppa la storia
  2. Demo di accettazione utente della storia dal ramo
  3. Reintegrazione nel trunk, build del pacchetto TeamCity che viene rilasciato per testare
  4. 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:

  1. 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.
  2. 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?
posta Ben 09.02.2016 - 09:36
fonte

1 risposta

2

Puoi rilasciare un "tronco" QA prima di andare al tronco di rilascio. Questo ti consente di ottenere più test e ti consente di promuovere una buona build integrata per un rilascio. La difficoltà arriva se trovi un bug, devi decidere se aggiustarlo e integrarlo, o selezionare i rami che sono passati sul tronco di rilascio, saltando la funzionalità con il bug.

Questo significa che il tuo trunk QA può andare lentamente fuori sincrono con il rilascio se hai un sacco di buggy branch che sono integrati (cioè, poiché alcune funzionalità saranno unite al QA che non arriva alla Release). Puoi risolvere questo problema risolvendo sempre il bug e poi unendo l'aggiornamento a QA che verrà promosso a Release nel ciclo successivo o ripristinando tutte le modifiche dal ramo di funzionalità da QA se non è riuscito e non sarà parte del soluzione in qualsiasi momento presto.

Dovresti testare anche sui rami, ma questi non mostreranno necessariamente bug causati dalla scarsa integrazione con altre funzionalità. Dovrebbe mostrare che sono abbastanza buoni per essere promossi allo stadio successivo, cioè il tronco del QA.

Naturalmente, potresti rilasciare il bug con una nota spiegandone gli effetti come un problema noto. Senza dubbio hai già bug nel prodotto distribuito che vengono trovati dall'utente finale. Puoi gestire i nuovi bug nello stesso modo in cui gestisci quelli trovati nell'ambiente live.

    
risposta data 09.02.2016 - 09:48
fonte

Leggi altre domande sui tag