Nella produzione si riscontrano bug "sottili" che non sono stati identificati nell'ambiente di gestione temporanea - in uno dei progetti con problemi del genere ho visto che questo problema è stato risolto con successo dalla tattica che definirei problemi doppi. Intendo per bug del genere, i ragazzi hanno creato due ticket nel tracker dei problemi: uno è stato assegnato agli sviluppatori per correggere il codice, un altro ai tester per progettare e stabilire test di regressione o cambiamenti nell'ambiente di gestione temporanea che avrebbero impedito di ripeterlo in futuro. Ciò ha contribuito a mantenere la messa in scena abbastanza vicino da prod.
i problemi nell'ambiente di produzione richiedono rollback - se questi sono frequenti, le tue uscite settimanali sono in realtà false - considera di adattare la frequenza al livello che funziona davvero. Per falso intendo che se si dice che una delle due versioni settimanali viene ripristinata, gli utenti devono affrontare una nuova versione (funzionante) una volta ogni due settimane, il che è tutto ciò che conta, non il numero di volte che si distribuisce.
rami delle funzioni applicati con entusiasmo - significa che qualche tempo prima, hai anche provato a lavorare su un singolo ramo e l'hai trovato inferiore? Se sì, salta il resto. Altrimenti, prova a lavorare su un singolo ramo (se necessario, google per la strategia di ramificazione "ramo di sviluppo" o strategia di ramificazione "tronco instabile" per i dettagli). Oppure, se si utilizza Perforce, cercare nel Web le linee guida di Microsoft su diramazione e unione. Prova l' ho detto? scusate la parola appropriata dovrebbe essere test : voglio dire, 1) pianificare per quando e come misurare se un singolo ramo è migliore o meno di quello che avete ora e 2) pianificare per quando e come tornerete ai rami delle caratteristiche nel caso in cui questo il test fallisce .
PS.
Probabilmente puoi trovare altri trucchi come quello cercando sul web qualcosa come la gestione del rischio di progetti software
aggiornare
<copia dai commenti>
Percepisco le hot-fix frequenti come sintomo di una pipeline di test interrotta - non è così? Ad ogni modo, richiedono rilasci ripetuti per ottenere le soluzioni rapide per far lavorare di più il team operativo. Inoltre, le hotfix sono generalmente codificate in condizioni di estrema pressione temporale, il che significa che probabilmente saranno di qualità inferiore rispetto al normale lavoro.
</ copia dai commenti>
- hot-fix dell'ultimo minuto - le preoccupazioni di cui sopra mi sembrano ragionevoli, così come il tuo riferimento a una pipeline di test interrotta. Con questo aggiornamento, la tua nota precedente che lunedì l'integrazione del nuovo codice è bloccata suona come un altro sintomo della pipeline spezzata (penso che si contenderebbero parole più precise ). Per contesa intendo quanto segue: si utilizza il singolo ramo per servire contemporaneamente due scopi: integrazione e rilascio. Quando si avvicina il rilascio, questi due scopi iniziano a scontrarsi tra loro, spingendo per requisiti contrastanti: lo scopo dell'integrazione è meglio servito con un ramo sempre aperto ( Unisci presto e spesso ) mentre i benefici di stabilità del rilascio sono sigillati dal ramo(isolato) il più a lungo possibile. A-ha sembra che le parti del puzzle inizino ad essere abbinate ...
... Guarda, quel congelamento del lunedì ora sembra un compromesso fatto per servire a scopi contrastanti: gli sviluppatori soffrono di un blocco di nuova integrazione di codice mentre i tester soffrono di questo blocco essendo troppo breve, tutti sono un po 'infelici ma entrambi gli scopi sono più o meno serviti.
Sai, dato sopra penso che la tua scommessa migliore sarebbe provare a rilasciare da un ramo dedicato (diverso dall'integrazione) . Che questo ramo sia longevo come l'integrazione o di breve durata come i tuoi rami di funzionalità (con "feature" che è, beh, rilascio) - dipende da te, deve solo essere separato.
Basta pensarci. Attualmente trovi che un giorno non è abbastanza per stabilizzare comodamente il rilascio, giusto? con la nuova strategia di branching, puoi semplicemente fork 2 giorni prima del rilascio invece di uno, nessun problema. Se ritieni che anche due giorni non siano sufficienti, prova a fare il fork 3 giorni prima, ecc. Il fatto è che puoi isolare il ramo di rilascio appena vuoi perché ciò non bloccherà più l'unione del nuovo codice con il ramo di integrazione. Nota in questo modello, non è necessario congelare affatto il ramo di integrazione: i tuoi sviluppatori possono utilizzarlo continuamente , lunedì, martedì, venerdì, qualunque cosa.
Il prezzo che paghi per questa felicità è una complicazione degli hotfix. Dovrebbero essere fusioni in due rami anziché in uno (rilascio + integrazione). Questo è ciò su cui dovresti concentrarti quando collaudi un nuovo modello. Tieni traccia di tutto ciò che è correlato - sforzi extra che dedichi alla fusione con il secondo ramo, sforzi legati al rischio che si possa dimenticare di fondersi con il secondo ramo - tutto ciò che riguarda.
Alla fine del test, basta aggregare ciò che è stato tracciato e scoprire se la quantità di questo sforzo extra è accettabile o meno. Se è accettabile, il gioco è fatto. Altrimenti, torna al tuo modello attuale, analizza ciò che è andato storto e inizia a pensare a come altrimenti puoi migliorare.
Update2
<copia dai commenti>
Il mio obiettivo è quello di ottenere storie testate e realizzabili (dietro o davanti a un muro di configurazione) all'interno di un'iterazione, questo può essere raggiunto solo se i tester stanno testando il lavoro eseguito in iterazione (e non stabilizzando il codice dall'iterazione precedente).
</ copia dai commenti>
Vedo. Beh, non ho esperienza diretta in quel modo, ma ho visto test di tipo in iterazione eseguiti con successo in un progetto correlato al nostro. Dato che il nostro progetto stava seguendo la strada opposta, ho avuto anche un lusso di confronto faccia a faccia per questi approcci opposti .
Dal mio punto di vista, l' approccio di test fuori iterazione sembrava superiore in quella razza. Sì, il loro progetto è andato bene e i loro tester hanno rilevato bug più velocemente dei nostri, ma in qualche modo questo non ha aiutato. Anche il nostro progetto è andato bene e, in qualche modo, potevamo permetterci iterazioni più brevi di loro, e avevamo meno (molto meno) rilasci di loro e c'era meno tensione tra dev e tester al nostro fianco.
A proposito, nonostante il rilevamento più veloce al loro fianco, siamo riusciti ad avere la stessa durata media dei bug (la durata è il tempo tra introduzione e correzione , non tra introduzione e rilevazione). Probabilmente abbiamo anche avuto un leggero vantaggio qui poiché con iterazioni più brevi e versioni meno slittate potremmo affermare che in media le nostre correzioni raggiungono gli utenti più velocemente delle loro.
Riassumendo, credo ancora che l'isolamento del codice di rilascio abbia maggiori possibilità di migliorare la produttività del team.
su un ulteriore pensiero ...
- l'isolamento del codice di rilascio presenta maggiori possibilità : rileggendolo, ritengo che ciò possa farti credere di scoraggiarti dal provare i test in iterazione . Vorrei chiarire perfettamente di no.
Nel tuo caso l'approccio del test in iterazione sembra sicuro da provare (ehm ... test ) perché sembra che tu abbia una chiara comprensione di come raggiungerlo ( pipeline di test regolare ) e quali sono i principali ostacoli. Dopotutto, hai sempre la possibilità di tornare a un approccio alternativo se trovi troppo difficile ottenere quella pipeline giusta.
A proposito di ostacoli, altri che vale la pena tenere traccia in quel caso saranno problemi come la mancata riproduzione del bug sul lato sviluppo e in ritardo per trovare / in ritardo per verificare la correzione sul lato tester. Anche questi potrebbero bloccare la pipeline , come accade ora con gli aggiornamenti rapidi.