Un modo semplice per migliorare la qualità di rilascio in ambiente RAD

Un po 'di background qui - siamo un piccolo team (di 5) di sviluppatori RAD responsabili dello sviluppo di software interno in una grande azienda non software. Il "software interno" varia da un'applicazione desktop .NET che utilizza il server MSSQL come backend agli script Python in esecuzione in background su documenti e modelli MS Word, uno zoo di tecnologie.

L'intero team è composto da tuttofare in grado di ottenere i requisiti dagli utenti, codificarlo, testarlo e distribuirlo in produzione. Una volta che il software in produzione è stato curato da un altro team, ma di solito è facile per noi intervenire se qualcosa va storto.

Tutto suona bene finora, ma c'è un problema: essendo un team RAD dobbiamo rilasciare spesso, e non c'è giorno che passa senza che rilasciamo nuove versioni di una o due applicazioni (o potrebbe essere uno script, un documento Word aggiornato , App console C ++, ecc.) Nella produzione. Effettuiamo un test di sviluppo e coinvolgiamo anche gli utenti finali consentendo loro di eseguire il software in ambiente UAT ...

... ma gli insetti si stanno insinuando nella produzione comunque. Gli utenti comprendono che questi bug e l'instabilità occasionale sono il prezzo che stanno pagando per ottenere ciò che vogliono davvero in fretta, ma allo stesso tempo ci ha fatto pensare - forse potremmo migliorare il nostro sviluppo o pratiche di rilascio per migliorare la stabilità del software e ridurre il numero di bug che introduciamo quando si aggiunge una nuova funzionalità.

La cosa buona - non abbiamo davvero molti dei processi in primo luogo, quindi dovrebbe essere facile iniziare a migliorare, la cosa cattiva - essendo un piccolo team RAD non abbiamo davvero molto tempo e risorse da implementare qualcosa di grande, ma abbiamo pensato alle seguenti iniziative e saremmo lieti di ricevere feedback, suggerimenti, consigli e suggerimenti.

1. Attualmente alcune applicazioni vengono rilasciate nella produzione subito dopo il test dello sviluppatore, aggirando il test di accettazione dell'utente. Tale pratica dovrebbe essere interrotta e anche una piccola modifica deve essere testata da un utente finale. Ogni applicazione avrà un beta tester dedicato selezionato dagli utenti finali. Solo dopo che un beta-tester ha approvato la nuova versione, viene promosso dall'ambiente di test a quello di produzione.

2. Non effettuiamo revisioni del codice, ma inizieremo a fare revisioni del codice prima che uno di noi effettui il check-in del changeset. Stavo anche pensando a una "revisione dell'implementazione" - fondamentalmente uno degli sviluppatori deve sedersi accanto all'altro, guardandolo mentre esegue l'implementazione del software (copia dei file binari, aggiornamento delle configurazioni, aggiunta di una nuova tabella al database, ecc.) Di solito solo richiede 5-10 minuti, quindi non ci vorrà molto tempo per la "revisione dell'implementazione".

3. Come ridurre il tempo di rollback quando una nuova versione ha dimostrato di essere buggy abbastanza per essere ritirata dalla produzione e per essere sostituita da una buona versione precedente. Memorizziamo una cronologia di tutte le versioni (come file binari) per semplificare il riavvio di una versione, e sebbene sia rapido "sovrascrivere i file binari appena rilasciati con i file binari delle versioni precedenti", è ancora un processo manuale soggetto a errori ed esigente a volte "che cosa succede se il rollback fallirà e renderà il sistema inutilizzabile anziché difettoso".

È qui che abbiamo esaurito le nostre idee e vorremmo ricevere il tuo feedback su queste e se tu potessi condividere alcuni semplici consigli sul miglioramento dei processi di rilascio / sviluppo, sarebbe fantastico.

+1 per toccare un ottimo argomento. Quando facciamo la linea di sviluppo "Rilasciare la versione anticipata spesso", le cose prendono un ritmo reale e quando si sviluppa lo slancio sorgono molti problemi di questo tipo (come hai descritto) che altrimenti non siamo molto preparati ad affrontare. La peggiore paura è quando le persone vedono la velocità come un nemico del buon lavoro.

Ho visto una letteratura molto limitata su questo, tuttavia, questo è ciò che pratichiamo che aiuta sicuramente:

1. Tracciamento efficace dei
bug Rendi il tracciamento dei bug più efficace - ciò che facciamo non è solo tenere un elenco di bug e segni di spunta, ma una volta chiusi, dobbiamo definire alcune cose come "erano i problemi riproducibili?", "È questa una soluzione permanente o correzione di lavoro? "," qual è la causa principale "del problema? Ciò consente la conoscenza di ciò che è accaduto, quando questo bug era visibile l'ultima volta. Questa è la chiave per garantire che i bug non si ripetano spesso.

2. Definire i punti chiave di fallback
Sappiamo tutti che i bug arriveranno, quindi dovremo fornire un fallback efficace che funzioni più spesso. Di volta in volta finalizziamo (con un rapporto di circa 1 su 10 nel nostro caso) una versione più comune che funziona ovunque nel modo più affidabile. Il numero totale di rilasci può essere molti, ma se qualcosa va storto, i fallback sono pochi e non è necessario ricorrere ulteriormente. Uno dei modi più semplici per conoscere il miglior fallback è quello di vedere quale prima versione ha funzionato più a lungo in produzione senza molti problemi.

3. Distinguere rilasci di correzioni di bug rischiose, stabili o di piccole dimensioni
Quando sappiamo che abbiamo un cambiamento sostanziale dell'algoritmo, è più probabile che i bug possano insinuarsi in scenari che non sono tutti previsti. Dove ci sono momenti in cui i problemi sono molto piccoli (o ben compresi) e con pochi rischi. Fare NON club di tale funzionalità e semplici bug nella release stessi. Prima devi sempre correggere un bug più piccolo, che deve andare dove richiesto. Effettuare versioni dedicate per set di funzionalità speciali nella migliore delle ipotesi è possibile deprecare tale funzionalità, ma tutti gli altri bug importanti sono ancora disponibili risolti nella versione precedente.

4. Diramazione per lo sviluppo di funzionalità significative
Tutto ciò che associa modifiche che influiscono sulla progettazione deve essere eseguito separatamente su una diramazione. Lo sviluppo più grande non viene completato rapidamente rispetto ai bug più piccoli. Se introduciamo commit intermedi in cui il lavoro "parziale" relativo a funzionalità che non è ancora in uso - è una potenziale regione di introduzione di bug; i bug che non sarebbero sorti se il pieno lavoro per la funzione si fosse completato atomicamente - quindi questi sono bug che non dovremmo risolvere se ci fossero rami.

5. Pianifica sempre una release basata sul tema
Molte volte arrivano diversi bug di diverse versioni, ma è meglio organizzare bug (e funzionalità) che influenzano moduli simili, facilita il lavoro di ripetizione e minimizza il numero di bug originati da quel lavoro. Preparare sempre la road map di rilascio con largo anticipo; i bug continuano a riversarsi - e questo rientra in diverse versioni di destinazione per avere in modo ottimale un buon gruppo di bug da sparare insieme in una buona versione. Quando si combinano bug simili, si ottiene sempre una migliore comprensione degli scenari contraddittori.

6. Estendi qualsiasi nuova versione prima ad alcuni clienti
Nel nostro caso, vediamo prima testarla in un paio di siti e tutti gli altri siti vengono applicati una versione solo quando è richiesta. Molte volte alcuni (o molti) utenti passano solo da versioni stabili a altre versioni stabili.

7. Test di regressione
Lungo le linee di bug raccolti - costruisci un seme di regressione. Inoltre, se possibile, contrassegnare i bug critici e testare i più importanti che diventano criteri minimi di qualificazione da testare prima che un candidato al rilascio diventi effettivamente un rilascio.

8. Pausa e riflessione
Quando molte cose vanno a tutta velocità, dovrebbe esserci il tempo di mettere delle pause - fare una pausa e avere rilasci funzionalmente non migliori. In effetti hanno una vacanza di uscite da qualche tempo. (la durata è inversamente proporzionale alla frequenza). Ad esempio, molte volte abbiamo queste cosiddette versioni "clean-up" che non ottengono nulla di nuovo dal punto di vista della funzionalità, ma che aiutano a mantenere il codice mantenibile. La maggior parte di queste versioni sono ottimi punti di riferimento che non ricordi quasi mai la storia precedente.

9. Forse il più strano
lo trovo difficile da implementare spesso ma è sicuramente un buon trucco. Scambia il proprietario di determinati moduli. Quando alle persone viene chiesto di fare delle revisioni del codice, non viene molto da questa pratica. Ma quando devi affrontare seriamente quel nuovo codice, quando scambi gli autori, i potenziali disturbi "cattivi" vengono notati rapidamente molto prima che inizino a inquinare il codice. Ovviamente, questo riduce la velocità, ma se lo fai spesso, è probabile che le persone padroneggino varie parti del codice e imparino tutto il prodotto che è saggio molto difficile da insegnare.

10. Ultimo ma non meno importante
Impara a tornare spesso alla lavagna. Più ripensi come se questa funzionalità fosse parte del nostro progetto più iniziale, come avremmo pensato al design in quel momento? A volte, la più grande sfida con il lavoro incrementale è solo che siamo troppo vincolati dall'ordine di funzionalità che abbiamo costruito per primo e abbastanza spesso non possiamo tornare alle origini. Il trucco è continuare a vedere come generalizzeremmo piuttosto che accogliere questa nuova funzionalità o scenario. Ciò richiede che il design rimanga attuale, e ciò accade solo se torniamo indietro spesso al tavolo da disegno. Inoltre, quando i programmatori di nuova generazione si uniscono, entrano a far parte del think tank piuttosto che mettere semplicemente patch.

MODIFICA
11. Tenere traccia delle soluzioni alternative e progettare le lacune.
Abbastanza spesso siamo sotto pressione delle tempistiche per correggere il bug e rilasciarlo in produzione. Tuttavia, quando il bug è a livello di progettazione, alcune cose devono cambiare, ma spesso le persone risolveranno alcune scorciatoie per rispettare la scadenza. Questo è OK . Tuttavia, con l'aumentare di questo tipo di soluzioni, il codice diventa fragile. Tieni traccia speciale di quanti vuoti di progettazione sono già stati eliminati. In genere, quando negozia le scadenze con il project manager, è meglio impegnarsi a impegnarlo affinché lo consegneremo in scorciatoia per salvare la produzione, ma avremo anche cronologia e risorse per ottenere una soluzione permanente.

Lavoro anche in un piccolo team di sviluppatori (solo 2 di noi) e abbiamo riscontrato problemi simili che hai menzionato. Il problema principale per noi è che entrambi tendiamo a lavorare su attività separate e stava diventando troppo comune per noi per completare un'attività / funzionalità, testarla (testata solo dallo sviluppatore) e rilasciarla rapidamente. Ciò ha comportato molte piccole versioni con gli utenti che hanno segnalato piccoli bug che avrebbero dovuto essere facilmente rilevati durante i test.

Per migliorare il nostro processo ho iniziato introducendo una scheda Kanban . La scheda era molto semplice per iniziare e aveva solo poche colonne (impostazione utilizzando una lavagna, schede e magneti colorati):

Backlog | Fare | Fatto

Tuttavia, questo si è rapidamente evoluto per rispecchiare il nostro processo attuale:

Backlog | Sviluppo | Dev. Test | UAT | Fatto | Rilasciato

Insieme al consiglio di amministrazione abbiamo una regola secondo cui ogni compito / funzione deve essere testato da un altro sviluppatore (nonché dallo sviluppatore che ha implementato la funzione). Quindi, una volta che una scheda raggiunge la colonna "Fine", dovrebbe essere stata testata da almeno 2 sviluppatori e verificata anche l'accettazione da parte dell'utente.

Ci sono molti altri vantaggi nell'uso di Kanban. Per noi ha migliorato la comunicazione e ci ha aiutato a condividere le conoscenze in quanto entrambi siamo coinvolti in una certa misura in ogni compito. Ha anche migliorato il nostro processo di rilascio in quanto ora possiamo vedere esattamente quali attività / funzionalità sono pronte per essere rilasciate / completate e talvolta possono trattenerci dal rilascio se sappiamo che altri tak verranno eseguiti presto. Per le persone al di fuori del team, il consiglio di amministrazione funge anche da rapido riferimento per vedere quali attività sono state programmate, i lavori in corso e quelli rilasciati di recente.

Inoltre, utilizziamo i magneti colorati (uno per sviluppatore) per contrassegnare la carta su cui stiamo attualmente lavorando, ma un'altra opzione è quella di aggiungere corsie di nuoto (file), una per sviluppatore e posizionare le carte Kanban nelle corsie di nuoto pertinenti. Ancora una volta questo aiuta come riferimento rapido per vedere a cosa sta lavorando ogni sviluppatore.

Altri link che ho trovato utili:

Kanban applicato allo sviluppo software: da Agile a Lean

Un sistema Kanban per l'ingegneria del software - Video

Spero che Kanban affronti il ​​punto 1. della tua domanda. In relazione alle revisioni del codice, lo facciamo in fase di test di sviluppo in modo che eventuali modifiche richieste dopo la revisione vengano nuovamente testate prima di passare a UAT. Il rollback dipende dal tuo ambiente, ma distribuiamo i file delle applicazioni ai Terminal Server utilizzando i file batch che rinominano i file correnti e copiano i nuovi file da un server centrale e possiamo eseguire il rollback abbastanza facilmente posizionando il backup (file precedenti) nella posizione centrale e rieseguire gli script.

Hai già identificato che sai che ci sono problemi con i tuoi processi che incidono sulla qualità del tuo software, e mentre questa domanda provocherà una serie di risposte, il mio suggerimento sarebbe di esaminare l'argomento dell'ingegneria del software e provare e imparare cosa gli sviluppatori principali si stanno trovando a fare sempre di più in quella zona. Ti suggerisco di iniziare a leggere alcune buone risorse per farti dare il calcio d'inizio. Alcuni che mi vengono in mente:

• Lean Software Development di Mary e Tom Poppendeick è un'ottima lettura per le persone interessate a imparare come identificare gli "sprechi" e cosa fare per cambiare i processi per diventare più snelli ed efficienti.
• Head First Software Development di Dan Pilone e Russ Miles è un po 'come uno di quei libri "per manichini" a prima vista, ma guardando un po' oltre lo stile di presentazione caotico, contiene la maggior parte delle informazioni relative alle basi dell'ingegneria del software e ha una breve descrizione dello sviluppo guidato dai test.
• Presentazione di BDD è la pagina di Dan North su come entrare in Behavior Driven Development, o forse preferiresti un BDD Wiki . Questi sono riferimenti introduttivi per BDD e probabilmente vorrai cercare strumenti e framework per aiutarti. La cosa importante da capire è che il BDD è effettivamente il TDD portato a un livello concettuale più elevato. Ti consente di pensare ai test mentre stai pensando alle specifiche e di testare nella stessa lingua che usi quando scrivi le specifiche. I framework generalmente si integrano con altri framework di unit test, in modo da ottenere il meglio da entrambi i mondi se si decide che i test potrebbero non trarre necessariamente vantaggio dalla sintassi BDD.
• L'articolo di sviluppo software Agile di Wikipedia è un ottimo spunto per lo sviluppo di software agile e fornisce una serie di riferimenti utili e collegamenti ad articoli di alcune delle persone più rispettate della comunità di sviluppo.

Al fine di migliorare COME lavori, devi permetterti di essere completamente aperto e disposto a uscire ben al di fuori della tua zona di comfort per imparare a migliorare le cose che fai senza aggrapparti a certi concetti che potresti trovare sono più comodo a cui aggrapparsi. Parlando per esperienza personale, questa è probabilmente la cosa più difficile da fare o incoraggiare negli altri.

Il cambiamento è difficile nel migliore dei casi, anche se ritieni di essere attivamente alla ricerca del cambiamento, quindi il miglior consiglio che posso davvero darti è quello di esaminare le varie metodologie Agile che sono state sviluppate nel corso degli anni per familiarizzare con le pratiche che sono considerati i più importanti (ad esempio: unit test, integrazione continua, refactoring, ecc ...), quindi scegli la metodologia che sembra più vicina a ciò con cui tu e il tuo team vi sentirete più a vostro agio. Una volta che hai preso la tua decisione, ottimizza le pratiche e il processo di sviluppo in modo che si adatti al modo in cui il tuo team preferirebbe lavorare, tenendo a mente quei principi magri e come desideri lavorare in modo che il tuo team possa produrre il massimo valore con il meno spreco. Infine,

Se ritieni che i tuoi processi necessitino solo di modifiche, ma sei preoccupato che la tua catena di strumenti non sia abbastanza al passo con le tue esigenze, allora forse cerca miglioramenti lì. Come minimo, un prodotto di integrazione di integrazione continua (come Continuum, Cruise Control o Hudson) e un sistema di monitoraggio dei problemi (come Jira o Redmine) dovrebbero essere una priorità per aiutarti ad automatizzare alcuni dei tuoi processi di compilazione e rilascio, e per tenere sotto controllo i tuoi bug e le richieste di funzionalità.

La realtà è che non importa quanto RAD siano i tuoi processi, se non investi tempo per ottenere le cose "giuste" per il tuo team, i tuoi problemi continueranno a crescere solo con il tempo e la tua percezione del tempo disponibile sarà restringersi di conseguenza. I grandi cambiamenti di solito sono fuori discussione quando si è sottoposti a forti pressioni, ma provate a darvi un po 'di "spazio di manovra" al fine di mettere in atto i sistemi per aiutarvi a fare piccoli passi verso la visione del vostro team di una metodologia ideale.

Ogni volta che sento parlare di difetti, le mie prime domande riguardano l'origine dei difetti e dove vengono rilevati e rimossi. Rimozione dei difetti L'efficienza è un buon modo per misurare e tracciare questo. Conoscendo l'origine dei difetti e lavorando per migliorare i processi in quelle fasi, è possibile ridurre i tempi e i costi di un progetto. È risaputo che è più economico riparare i difetti più vicino al punto di iniezione, quindi una volta che sai da dove provengono i difetti, puoi quindi esaminare i cambiamenti delle attività per migliorare quelle fasi.

Una volta che hai informazioni su da dove provengono i difetti, puoi vedere esattamente quali tecniche e tecnologie vuoi applicare. Recensioni di requisiti, progettazione e codice, test automatizzati, analisi statiche, integrazione continua e test più estesi guidati dagli utenti potrebbero essere opzioni da considerare, a seconda delle fasi che generano difetti.

Per espandere il tuo desiderio di revisioni del codice, dovresti anche considerare diversi livelli di revisione del codice in base alla priorità e al rischio di un modulo. I moduli a basso rischio e bassa priorità potrebbero non necessitare affatto di una revisione del codice, o forse solo un semplice controllo da scrivania, in cui un altro sviluppatore legge il codice da solo e fornisce commenti, funzionerebbe. Altre tecniche di revisione del codice includono programmazione di coppie, procedure dettagliate, critiche e ispezioni con vari numeri di sviluppatori.

Ai fini del rollback, cercherei di automatizzare tale processo utilizzando una sorta di script per renderlo più veloce e meno soggetto a errori. In un mondo perfetto, vorrei aumentare la qualità dei prodotti spediti in modo tale che non sia necessario eseguire il rollback e puoi ottenere questo risultato. Avere la capacità, tuttavia, potrebbe essere una buona idea, ma renderla il più indolore possibile.

Come altri hanno sottolineato, l'aggiunta di test di regressione aiuterà a evitare che gli stessi difetti compaiano in futuro. Tuttavia, se riscontri nuovi difetti, potrebbe essere il momento di aggiungere asserzioni (ovvero contratti) al codice che specifichi le pre-condizioni, le post-condizioni e gli invarianti delle classi e dei metodi.

Ad esempio, se si dispone di una classe in cui un metodo può accettare solo numeri compresi tra 10 e 25 (questa è la pre-condizione), aggiungerebbe un'istruzione assert all'inizio del metodo. Quando questa affermazione fallisce, il programma si bloccherà immediatamente e sarai in grado di seguire la catena di metodi che ha portato a quell'errore.

Python, PHP e altri linguaggi di programmazione sono tipizzati in modo dinamico e non aggiungono molte condizioni ai metodi. Tutto ciò che serve affinché qualcosa funzioni è che implementa un metodo particolare. Ho il sospetto che tu abbia bisogno di più condizioni sui tuoi metodi. È necessario definire e testare per garantire che un metodo possa effettivamente funzionare nel suo ambiente.

Per i programmi C / C ++, ho scoperto che l'aggiunta di asserzioni per testare l'allocazione di memoria è stata molto utile nel ridurre il numero di perdite di memoria nel programma.