Come usare Subversion in combinazione con DTAP con diversi team Scrum?

In un precedente lavoro avevamo un setup simile (DTAP) anche se non usavamo SVN (usavamo Perforce) sarebbe stato facilmente trasferito dal momento che entrambi sono o la stessa famiglia VCS.

Avevamo un ramo di sviluppo in cui si è verificato tutto lo sviluppo. Poiché la ramificazione è piuttosto costosa in P4, lo stesso vale per SVN, non abbiamo usato i rami di sprint, ma solo quando una feature, o user story, o epic sarebbe stata abbastanza complessa e si allungherebbe nel tempo abbastanza a lungo useremmo un ramo di scopo da Development (tronco). Sarebbe quindi responsabilità degli sviluppatori in questo specifico ramo tenerlo sincronizzato con il trunk e unirlo di nuovo quando è fatto.

Abbiamo ricevuto consegne continue che periodicamente prendevano il bagagliaio e costruivano il prodotto, dico periodicamente da quando la costruzione ha richiesto un tempo considerevole, quindi non potevamo farlo su ogni commit che sarebbe stato l'ideale.

Una prima linea di QA (smoke test) è stata eseguita su una di queste versioni di tronco e, se soddisfacente, la build è stata "promossa" per testare dove sarebbe sottoposta a test più intensi (la fase T). Siamo faticosamente ramificati al ramo di testing se il test non ha rifiutato la build (come troppo instabile) ma ha comunque richiesto delle correzioni. Le correzioni sono state fatte nel ramo di test e unite al trunk e il sistema di build avrebbe rilasciato una nuova versione di test. Raramente abbiamo corretto i bug nei test, preferendo continuare a lavorare in trunk ans semplicemente promuovendo una build successiva. Abbiamo sistemato i bug lì quando il trunk era troppo instabile e / o le correzioni / le funzionalità non potevano più aspettare di essere spinte alla produzione.

Una volta superato il test, la build è stata nuovamente promossa all'accettazione (nel nostro caso si trattava di sessioni di test di gioco, laboratori di usabilità, ecc.). Lo stesso processo si è ripetuto come nella fase di test. Le correzioni dei bug apportate nel ramo di accettazione sono state unite al tronco (non test, a questo punto il ramo di testing probabilmente proverebbe già una nuova build testata affumicata). Una volta accettato nuovamente, è stato promosso alla produzione.

Nella produzione tuttavia abbiamo ramificato avidamente tutto dall'accettazione, promosso la build. Una volta promosso, la build è stata immediatamente distribuita. Dovrebbero essere trovati bug di blocco nella linea di produzione e lì sono state apportate le correzioni e (dopo l'unione al trunk) create e distribuite al più presto con test minimi. Sembra un po 'pazzo con il test minimo in prod perché solo una serie di correzioni molto piccole (quelle che non potevano assolutamente aspettare) sarebbero state fatte lì, altrimenti sono state fatte nel bagagliaio e hanno attraversato l'intero processo.

Ha funzionato abbastanza bene per noi.

Ora, per adattarlo a un processo agile iterativo (SCRUM) ci sono molti approcci che potrebbero essere adottati,

• Promuovi solo alla fine dell'iterazione. L'inconveniente è che la produzione sarebbe sempre 3-4 iterazioni complete dietro. Detto questo, spesso è il momento in cui il codice deve essere adeguatamente stabilizzato e testato.
• Promuovi continuamente (come abbiamo fatto) e mirare a un ciclo completo in un'unica iterazione. In linea di principio, è più rigorosa l'adesione alla mischia. Si ottiene un risultato inferiore in quanto è necessario consentire il test. Il problema qui è che mentre i test sono in corso, potresti finire con gli sviluppatori inattivi mentre hanno finito il loro lavoro e stanno solo aspettando che i bug vengano trovati.

Dall'esperienza vorrei provare un approccio ibrido. Promuovi continuamente i test e miri a promuovere l'accettazione alla fine dell'iterazione. Nella pianificazione dell'iterazione, vedere cosa deve essere risolto in fase di accettazione e definire le priorità di conseguenza, puntando alla produzione al termine di questa seconda iterazione. I tuoi sviluppatori dovrebbero suddividere il tempo tra due rami (tronco e accettazione) con l'occasionale incursione nei test. Questo massimizza la produttività riducendo al minimo il tempo di produzione.

• trunk è il limite principale del tuo sistema, il più instabile.
• testing è un'istantanea del trunk se sono stati trovati bug. Preferisci comunque fissarlo nel bagagliaio.
• l'accettazione era dove le cose si sono stabilizzate, più test sono stati fatti qui.
• la produzione era ciò che era attualmente distribuito. Raramente le riparazioni degli articoli fatte qui, ma è importante avere comunque.

Non avevamo più versioni in produzione, costringendo gli utenti ad aggiornare ogni volta che veniva creato un nuovo build di produzione.

Spero che questo aiuti, mi dispiace per il romanzo, non ho avuto il tempo di fare più breve.

Mantenere molti rami in sovversione è un trascinamento, prova git. Tratta ogni build come una release candidate e "ferma la linea" per i difetti. Crea binari una volta. Se si applicano i principi della consegna continua, come il lavoro con piccoli lotti, i rami di breve durata, l'integrazione sulla linea principale, l'intero tool CI diventa molto più semplice.