Questa domanda potrebbe essere un po 'vaga, ma la risposta dipende da cosa è stato costruito il tuo software, cosa fa e chi è il tuo pubblico o la base di clienti.
Supponendo che l'applicazione abbia un focus sul lato client (oltre al lato server), con test di automazione che utilizzano framework di test come Capybara che coprono la maggior parte dei tuoi clienti, i casi d'uso comuni faranno molta strada per impedire la funzionalità di regressione.
Per il side-code del server, assicurando di aver scritto i test unitari appropriati per (quasi) ogni riga di codice e scrivendo test di integrazione più estesi per coprire (ancora) casi d'uso comuni eviteranno il verificarsi di futuri bug. Il TDD è il re dell'era moderna, ma praticare TDD-lite (come lo chiamo io) può aiutarti ad andare in pista abbastanza rapidamente (scrivendo i casi di test prima, e poi inserisci i dettagli mentre il codice può funzionare, ma è preferibile il TDD completo ).
In entrambi i casi, quando i bug emergono è bene aggiungere test per questi bug direttamente nelle suite di test di automazione e unità in modo da impedire loro di regredire in futuro.
Queste pratiche richiedono sicuramente qualcosa come Jenkins o altri strumenti simili (Semaphore) per fornire statue di build appropriate.
Per rispondere alla tua domanda "Che cosa riesce a trasmettere con successo il codice ..." - la risposta è che dovrebbe trasmettere un senso generale che i tuoi casi d'uso più comuni e bug precedenti non siano stati interrotti o regrediti. Per aiutare con questo, fornire passaggi per post-distribuzione per garantire che tutto funzioni aiuterà.
Raddoppiare le risorse di revisione del codice può essere d'aiuto, ma dipende dagli individui / team che hai. Ma qui dovrebbe esserci il rigore (e ci sono molte risorse intorno a opinioni su come dovrebbero funzionare le recensioni del codice, questo è uno dei miei preferiti: link )
I seguenti passi saranno rivolti a QA, ha detto la filiale PR in un ambiente identico alla produzione che non può influenzare i clienti (un QA o un ambiente di staging funziona meglio, spendono decisamente risorse ottenendo questo 1: 1 nel tuo ambiente di produzione, vale doppiamente i tuoi sforzi per usare software contenitore come Docker per non aumentare i costi del server). Tieni questo ramo isolato dal tuo ramo di sviluppo / master e unisci solo dopo aver passato CR, Build e QA.
Per altre domande sui passaggi, ti consiglio di creare una solida base su come scrivere e gestire sia le funzionalità che i bug. Ciò comporta che il tuo team segua una buona impostazione per i ticket JIRA quando sono stati identificati problemi / nuove funzionalità (fornendo riepiloghi accurati del problema o nuova funzionalità, Procedura da riprodurre e dettagli specifici dell'azienda e passaggi Demo per lo sviluppatore Prodotto, il revisore del codice e l'ingegnere del controllo qualità), quindi fornisce buoni progetti o soluzioni nel ticket prima che uno sviluppatore risolva il problema (toelettatura). Il grooming dovrebbe aiutare a identificare i casi di test.
Non sono sicuro di come misurare questo diverso dal tracciare i biglietti, legare i nuovi biglietti ai biglietti in cui potrebbero essere generati e mappare il numero di problemi che si presentano dopo il rilascio.
Un'altra nota: le metriche di cottura nel codice in anticipo ti aiuteranno anche a mantenere l'applicazione in uno stato desiderato e ti avviseranno dei problemi che potrebbero sorgere laddove l'automazione e i precedenti passaggi non sono riusciti, consentendo di reagire più rapidamente a problemi e fornire un tempo di risoluzione più breve.