Come possiamo includere solo le funzionalità pronte per essere rilasciate nelle nostre versioni di produzione ogni due settimane?

Ci sono alcuni problemi che stanno causando problemi che stai riscontrando.

Il primo è il ramo QA di lunga durata. Avere un ramo a lungo termine parallelo alla linea di sviluppo può essere fonte di confusione perché ci sono diversi sforzi che devono essere replicati sia nel ramo QA che nella linea principale. Ciò significa che stai controllando le correzioni al ramo QA che devono essere unite alla linea principale (non è una cosa negativa), o stai effettuando il check-in sulla linea principale che viene unita al ramo QA (una fonte di possibili bug) .

L'altro problema con il ramo parallelo di lunga durata è che è possibile che i file diventino per sempre non sincronizzati. Una correzione del codice che non viene mai ripristinata o una configurazione necessaria per le build di produzione che non vengono mai testate e parte della linea di sviluppo.

Quindi, hai dei ruoli su cui tieni impacciato. Ciò significa che il ruolo della confezione (più su questo in seguito) non si sta sufficientemente isolando.

Nel modello git-flow , il ramo di rilascio è derivato dallo sviluppo (< em> non sviluppo unito al QA) e tutte le correzioni sono verificate nel ramo di rilascio e poi unite al ramo di sviluppo.

Alcune delle filosofie di ramificazione si possono trovare in Strategie di ramificazione avanzata di SCM (che considero essere una lettura eccellente). Questo si concentra sui ruoli che ogni ramo può assumere. Il ramo di rilascio assume il ruolo di imballaggio.

The packaging role is often confused with the accumulation or, more commonly, mainline roles. Once the intended development and maintenance have been performed and any accumulation has been done, it is time to prepare the code for release. Such an effort may not be trivial, requiring a team of release engineers and additional fixes beyond those already performed. The policy on a packaging branch is significantly different from that on a maintenance branch, as the packaging role suggests, only the changes necessary to make the product releasable should be addressed.

• Ramo dal punto di sviluppo al ramo di rilascio. Il ramo di rilascio da cui il QA viene generato ottiene un ramo e non si fonde dallo sviluppo.
  • Se vuoi percorrere questa strada, con nomi e hook coerenti, è possibile impedire che una fusione venga eseguita in un ramo di rilascio.
• Correggere tutto ciò che deve essere corretto nel ramo di rilascio e unire le modifiche alla linea principale.
• Alla fine dello sforzo di rilascio, unire il ramo di rilascio nel ramo "releases go here" e taggarlo come tale.
  • Alcuni siti non hanno un ramo "lascia andare qui" e lasciano pendere il ramo di rilascio con un tag.

Si dovrebbe prendere seriamente in considerazione la possibilità di applicare l'intero flusso git. Questo non è troppo lontano da ciò che viene fatto attualmente e pone una certa disciplina e coerenza in ciò che significa ogni ramo e in che modo ogni ramo interagisce con gli altri.

Il problema mi sembra che tu abbia un singolo ramo QA.

Per ogni versione, crea un ramo QA separato dal trunk / master di sviluppo primario. Quindi unire in solo correzioni per bug per le funzionalità su quel ramo - mai nuove funzionalità. Fai test del QA su questo ramo.

In questo modo, il "blocco" è abbastanza evidente, è nel nome del ramo. Potresti usare qualcosa del tipo, non so, release/26/10/2015 . Quindi è ovvio che nessuno dovrebbe fondersi in nuove funzionalità dopo questo.

È particolarmente utile se non si piega il ramo fino al congelamento. Le persone possono unirsi al master in qualsiasi momento, semplicemente non farà parte di questa versione se non viene eseguita in tempo per la verifica.

Non hai un solo ramo QA di lunga durata, questo è solo un accattonaggio. Fork dal ramo di sviluppo principale per ogni release e QA that branch.

Sei in qualche modo mappato al modello di diramazione Development-MAIN-Production visto sotto. L'area sopra MAIN si dice che sia l'area di sviluppo. L'area sotto MAIN è l'area di produzione.

Punti salienti di questo modello che considero pertinenti per te:

• I tuoi sviluppatori devono inoltrare Integrare (FI) (FI = unisci lontano da MAIN) frequentemente (2-3 volte a settimana) nelle loro filiali DEV per garantire che le loro ultime modifiche considerino sempre gli ultimi sviluppi generali.
• I tuoi sviluppatori devono Reverse Integrate (RI) (RI = unisci verso MAIN) nel ramo TEST solo quando hanno raggiunto una pietra miliare di completamento funzionalità che desiderano esporre a QA e per che sono pronti a fornire soluzioni rapide in risposta al feedback del QA. Le correzioni verranno eseguite sul ramo TEST e immediatamente su FI nel loro ramo DEV.
• Mai RI da qualsiasi ramo DEV in MAIN
• RI sempre dal ramo TEST in MAIN, esclusivamente quando il tuo QA considera la qualità del TEST OK. Mantieni una soglia di alta qualità per l'unione in MAIN. Per lo meno, il tuo Product Manager deve essere in grado di dimostrare sempre una versione funzionante del tuo prodotto dall'ultimo commit in MAIN.
• Crea filiali nell'area di produzione solo se necessario. Il tuo server di build dovrebbe sempre taggare tutti i rami, compresi quelli provenienti dall'area di sviluppo, e l'origine di qualsiasi build / rilascio dovrebbe essere sempre identificabile indipendentemente dal ramo da cui proviene.
• Prendi i rilasci per la produzione solo da MAIN o dall'area di produzione. Se in seguito è necessario fornire una correzione per una versione rilasciata esatta (ovvero non si può semplicemente fornire l'ultima versione da MAIN), creare un ramo nell'area di produzione dal tag MAIN della versione difettosa, quando è necessaria la correzione. Risolvete sempre il problema sul ramo HotFix e quindi immediatamente RI in MAIN e FI in TEST.

Ho il sospetto che tu abbia problemi perché:

• Il tuo indirizzo di ricerca in codice TEST che non è completo di caratteristiche fondamentali
• La tua devs RI in TEST senza ottenere la luce verde dal QA (cioè QA non ha il controllo di ciò che viene iniettato in TEST)
• Quando il QA segnala un errore su TEST, i tuoi sviluppatori lo correggono sul loro ramo DEV e poi su RI in TEST. Questa è una delle principali cattive pratiche perché l'unione porterà sempre altre merdate dev incomplete. Dovrebbero sempre sistemarlo su TEST e poi su FI nel loro ramo DEV. Se non è risolvibile su TEST, in primo luogo hanno consegnato una schifezza totale e hai problemi più grandi.
• I tuoi sviluppatori non fanno FI abbastanza spesso da TEST e quindi destabilizzano TEST ogni volta che li consegnano. È un'arte che bilancia la frequenza con FI in DEV. Rimandalo troppo e sarà estremamente costoso & rischioso prima della consegna, che non vorresti mai. Fatelo troppo spesso e non ottenete alcun lavoro di sviluppo effettivo se vi sovrapponete troppo con il lavoro fornito da altre persone in TEST nel frattempo.

Come ho capito la domanda hai due problemi. (a) le funzionalità interrotte vengono unite alle buone funzionalità che si desidera rilasciare; (b) vuoi essere in grado di rilasciare le buone caratteristiche mentre trattiene quelle rotte. Come limite alle possibili soluzioni, presumo che tu voglia che il tuo test QA finale / ufficiale avvenga su un ramo integrato che contenga tutte le funzionalità previste per la prossima versione.

Indipendentemente dal modello di ramificazione SCM, ti suggerisco di provare uno o entrambi i seguenti elementi:

1. Assegna una risorsa QA a ciascun team di funzioni. Fagli fare qualche funzione testare le build dal ramo delle funzionalità e dare loro l'autorità decidere quando una funzionalità è sufficiente per unire. Idealmente, avere loro lavorano in collaborazione con il resto del team di funzionalità, quindi roba viene testata poco dopo essere stata scritta. (Nota questo no significa che devono fare tutti i test stessi.)
2. Usa i cavicchi delle funzioni, al posto dei rami delle funzioni o in Oltre a loro. Fatto bene, i pulsanti funzione ti consentono di disattivare una funzionalità rotta senza provare a smontarla dal codice, quindi tu può testare e rilasciare le altre funzionalità. Il tipo di interruttore I'm parlare non è accessibile ai clienti; tu non vuoi un numero in aumento esponenziale di combinazioni da testare. Hai impostato il attiva / disattiva il ramo QA in modo che corrisponda alle funzioni che stai pianificando rilascio, e se il piano cambia perché una funzione non è pronta, tu cambia quella opzione.

Una soluzione molto semplice che ho visto lavorare su una squadra un po 'più grande della tua è far lavorare e distribuire tutti da una singola filiale.

Dici che il team è agile, ma non è chiaro se stai lavorando in sprint (es. Scrum) o in un flusso più continuo (cioè Kanban). Supponendo che tu stia facendo gli sprint, l'obiettivo per la squadra è di avere il codice sbloccabile alla fine di ogni sprint, per la tua uscita quindicinale. Non c'è confusione sul fatto che una caratteristica possa rompere un'altra in quanto sono state sviluppate insieme. I tester possono essere in grado di accedere alle funzionalità in blocchi più piccoli, in quanto il sovraccarico sugli sviluppatori da consegnare a loro è inferiore. E non hai davvero bisogno di un QA-Freeze, invece tutti sanno quando è la fine dello sprint e non dovrebbero intraprendere un lavoro che non possono finire, o lasciare in uno stato deployabile (cioè disabilitato).

Ovviamente ci sono pro e contro in ogni approccio, lo presento come un'opzione non necessariamente la "migliore".

Il motivo per cui stai riscontrando questi problemi è perché il tuo codice rilasciato al QA non è di qualità sufficiente (ed è anyones ?!), quindi devi iniziare a ottenere una versione migliore per il QA in modo che non debbano ricevere bigfix così spesso. il modo più semplice per farlo è quello di introdurre un ramo intermedio a cui rilasciate (chiamiamolo test). Questo è ancora sotto il mandato di sviluppo, ma consente agli sviluppatori di spingerlo a continuare a lavorare, pur avendo anche un ramo integrato che dovrebbe essere di qualità sufficiente per essere inviato al QA.

I test di integrazione possono svolgersi su questo ramo per trovare i bug che il QA sta attualmente trovando, i bug possono essere riparati sul ramo originale e poi uniti di nuovo, e di nuovo fino a che i bug o gli errori possono essere corretti direttamente su questo ramo ( Raccomando il primo). Una volta superato un carico di test di base, può essere inviato al QA per le "dita appiccicose dell'utente e il" cosa-fanno-cosa? " test.

Quindi questo approccio è progettato per proteggere la branca del controllo qualità da funzionalità di sviluppo non funzionanti, indipendentemente dal fatto che la funzione non sia stata codificata abbastanza bene o se ci siano stati problemi di integrazione imprevisti. Solo le filiali di sviluppo che superano il test di integrazione devono essere promosse a QA.