Cosa è possibile fare per ridurre il numero di bug di distribuzione di un sito Web live?

Sono sicuro che molti di voi hanno avuto questo problema. Un sito Web o un'applicazione Web è in esecuzione ed è in diretta. Vuoi caricare la versione successiva, ma non hai capito tutto, come impostare un valore su false nel file di configurazione, inserire un altro record nel database e fare molte cose minori che a volte possono contare su 20 o più parametri.

Non appena carichi la nuova versione, tutto si rompe. Ora, risolvere il problema può richiedere solo fino a 20 minuti, ma lo stress complessivo che tolleri e i danni finanziari e di avviamento alla società a volte non sono dimenticabili.

Quali sono i modi per ridurre questi tipi di bug derivanti dalla configurazione iniziale della distribuzione di una nuova versione?

PS: Per favore, non menzionare le liste di controllo, perché le abbiamo già. Il problema con le liste di controllo è che dovrebbero sempre essere aggiornate, ma non lo faranno.

Due cose:

• Ambiente di gestione temporanea, simile all'ambiente live in cui si eseguono test di distribuzioni.
• Test approfonditi di questo ambiente dopo la distribuzione. Automatizzato e non automatizzato.

Ci sono altre cose che possono essere fatte.

Suggerisco di leggere la serie di blog in 5 parti sulla distribuzione automatizzata di Troy Hunt. Gli strumenti che usa sono specifici dello stack MS, ma i concetti sono universali.

Mi chiedo perché nessuno abbia menzionato il controllo della versione , che è uno dei modi più importanti per salvarti dai problemi durante l'aggiornamento / l'aggiornamento.

Innanzitutto, la distribuzione dovrebbe essere solo un clone del ramo stabile sul repository. Tutto compreso i file di configurazione, i file SQL, gli script di installazione / aggiornamento DEVONO essere controllati dalla versione.

In secondo luogo, è necessario disporre di "una sorta di" area di gestione temporanea - potrebbe essere qualsiasi cosa - un server locale, un server cloud virtuale temporaneo appena generato, una configurazione dell'host virtuale molto semplice o un'applicazione personalizzata completa che mantenete insieme all'app principale. La differenza tra questa "area di gestione temporanea" e la tua "area di sviluppo" è che i primi modellano (o simulano) più da vicino l'ambiente di distribuzione effettivo. Ad esempio, è possibile sviluppare su PHP 5.3.x con il modulo Apache, ma poiché l'host è PHP 5.2.x con FCGI, l'area di gestione temporanea deve essere la stessa.

Quindi, prima scrivi e testa i tuoi aggiornamenti sul tuo ambiente di sviluppo. Unire le modifiche al repository dell'area di gestione temporanea e riprovare. A questo punto puoi apportare qualsiasi modifica alla tua configurazione per adattarla alla tua distribuzione - dal momento che è controllata dalla versione, nulla andrà perso e puoi sempre tornare indietro in caso di problemi.

Infine, unisci le modifiche dell'area di gestione temporanea sulla tua copia di distribuzione live.

La complessità dell'area di gestione temporanea dovrebbe riflettere la complessità e l'ambito dell'app. Ma in ogni caso il controllo della versione è indispensabile.

Ovviamente se non si utilizza il controllo versione - niente di tutto ciò si applica - ma è ingenuo come scrivere un database in Logo.

Come suggerito, utilizzare un sistema di stadiazione . Questo ti dà l'opportunità di testare le tue modifiche in un ambiente live.

Questo solleva un altro punto: avere tester . Testare le cose che ho scritto da solo non trova tanti bug come quando qualcun altro verifica la mia applicazione.

Un'altra cosa: automatizzare il processo di distribuzione . Esegui migrazioni db con ant migra, distribuisci automaticamente la versione più recente da svn via capistrano ecc. Quando distribuisci qualcosa, non dovresti fare altro che un clic e tutto è automatico. Soprattutto per i siti Web che richiedono alcune impostazioni di configurazione, i passaggi manuali necessari per la distribuzione sono un incubo e la possibilità che qualcosa vada storto è enorme.

Per qualcosa che assolutamente, positivamente non deve rompersi, considera di avere un sistema A e B e usa un bilanciamento del carico per indirizzare tutte le richieste ad A mentre aggiorni e testa B, quindi instrada tutto a B mentre aggiorni A.

Per i punti bonus, aggiungi C e assicurati che i tuoi sistemi siano separati geograficamente in modo che un terremoto non ne eliminerà 2 contemporaneamente.

Per molte applicazioni, ammetto che questo è eccessivo.

Inoltre complica qualsiasi gestione delle transazioni che devi fare, ma i problemi non sono insormontabili.

Sì, è necessario un ambiente di prova o di gestione temporanea in cui eseguire tutti i passaggi, ma è indispensabile mantenere file di configurazione separati per ambienti separati.

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

Fondamentalmente nei miei script di build e distribuzione prendo una proprietà di ambiente che recupererà i file di metadati specifici dell'ambiente come file XML e li sostituirà nella mia posizione di build prima del packaging. Inoltre nei miei script di distribuzione cercherò qualsiasi file SQL negli aggiornamenti del database ed eseguirò anche quelli sul database configurato per quell'ambiente.

Potrei farlo con un'attività di compilazione personalizzata, ma in realtà uso solo alcuni test JUnit per farlo per me. Se si verificano eccezioni SQL, il test ha esito negativo e pertanto la distribuzione non riesce. In generale, anche gli script SQL dispongono di intelligenza, se i dati necessari sono già presenti nell'ambiente, ignorano l'inserimento o l'aggiornamento.

Ho anche una directory simile per script batch o shell che devo eseguire per un ambiente specifico.

La risposta alla tua domanda è questa: dovrebbero sempre essere aggiornati, ma non lo faranno.

Queste configurazioni guidano le tue build e implementazioni automatizzate, quindi se NON le aggiorni, le tue build falliscono e il tuo manager riceve un'email al riguardo. È altrettanto importante che il team mantenga le configurazioni di compilazione e distribuzione per una versione specifica così come lo è per loro il check-in del codice che viene compilato. Entrambe le infrazioni interrompono la creazione.

In breve, una maggiore adozione dei principi di integrazione continua (CI) aiuterà a rimuovere il dolore delle versioni di produzione.

1) Distribuire prima sul sito di test e testare le modifiche

2) Avere tutta la configurazione in un file di configurazione (web config o simile). Questa configurazione dovrebbe quindi essere specifica per l'applicazione e mai sovrascritta. Eventuali modifiche vengono quindi delibrate anziché dimenticare di modificare qualcosa che dovrebbe differire dal test.

Oltre agli eccellenti suggerimenti di cui sopra per avere un ambiente di pre-produzione e utilizzare test automatizzati:

Ridurre la complessità della base di codice. Meno codice, in genere, significa meno bug e un tempo più facile per trovarli. Questa è la filosofia alla base del refactoring, della separazione delle preoccupazioni e così via.

Segmenta la base di codice . Un approccio comune è quello di separarlo in:

• alcune parti principali che cambiano lentamente e sono condivise sul sito
• molte parti fogliari che possono cambiare più rapidamente ma ognuna influisce solo su una parte più piccola del sito

Questa comprensione della tua base di codice ti consente di concentrare lo sviluppo e il test sulle parti principali, poiché i bug avranno l'effetto più drastico.

Una versione ben eseguita riguarda la pianificazione e la comunicazione. Quindi, prima di eseguire una versione, prendere in considerazione queste domande:

1. Quanto tempo richiederà il rilascio e ci sono dei rischi nel consentire alle persone di continuare a interfacciarsi con il mio prodotto mentre è in corso il rilascio? Se esiste un rischio per il sistema, prendere in considerazione la possibilità di disconnettere il sistema e di inserire un messaggio "Sistema in manutenzione attualmente in corso" al suo posto.

2. Ci sono clienti che potresti aver bisogno di comunicare in anticipo sul rilascio? Devo comunicare loro una possibile interruzione del servizio o un peggioramento delle prestazioni mentre è in corso il rilascio? Personalmente sbaglio sempre dal lato di comunicare eccessivamente e di dire a tutti i clienti di un'imminente finestra di rilascio o manutenzione su un blog pubblico o un luogo simile.

3. Quali sono i miei piani di emergenza se il rilascio dovesse andare storto? Ad esempio, se il rilascio non va a buon fine, dovremmo ripristinare e ripristinare il sistema in modo tale da ridurre al minimo ogni volta che siamo offline? E se è così, i passaggi per il rollback di una versione sono ben documentati? O dovrei avere le persone giuste a disposizione o a portata di mano per aiutare a risolvere i problemi che dovessero verificarsi. Personalmente, penso che il modo migliore per affrontare la pianificazione di qualsiasi versione sia quello di supporre che qualcosa andrà storto con la versione. In questo modo mi sono costretto a pensare in anticipo ad alcuni di questi problemi.

Successivamente, quando si tratta di eseguire una versione, uno dei modi migliori per assicurarsi che funzioni correttamente è esercitarsi, esercitarsi, esercitarsi e documentare tutto ciò che si incontra lungo la strada. Quindi, molto prima di distribuire il nuovo codice nella produzione, esercitarsi prima di distribuire il codice in un ambiente di gestione temporanea sicuro e correttamente sandbox. Avere la persona che sarà responsabile della distribuzione in produzione, eseguire la distribuzione di prova in stadiazione. Considera questa prova generale e comportati come faresti se fosse la cosa vera. Documenta tutto ciò che fai in ogni fase del processo; documenta ogni comando che esegui, qualsiasi codice SQL che esegui, qualsiasi file che modifichi e come li hai modificati e per ogni passaggio lungo la strada documenta ciò che ti aspetti di vedere se la procedura viene eseguita correttamente. Se e quando riscontri un problema di qualche tipo, documenta cosa hai fatto per risolverlo.

Quindi la distribuzione pratica è completa, controlla le tue note e vedi se riesci a perfezionare il processo per eliminare gli errori. Quindi ricominciare da capo . Continua ad esercitarti fino a quando l'esecuzione di una versione diventa ordinaria come seguendo un semplice foglio di istruzioni, come "accedi a questa macchina, esegui questo comando; quindi accedi al database ed esegui questo comando SQL; quindi ..."

Di seguito sono elencate le operazioni che un team di gestione delle operazioni o delle versioni può fare per facilitare l'esecuzione di una versione. Ma cosa può fare l'ingegneria per ridurre al minimo i rischi in una versione?

1. Mantenere i rilasci piccoli. In poche parole, più complesso è il set di modifiche al codice contenuto in una versione, più rischiosa sarà la versione. Favorisci il tuo team operativo pianificando di avere un numero maggiore di rilasci piccoli, anziché un numero inferiore di rilasci di grandi dimensioni nello stesso periodo di tempo.

2. Test, test, test. Non limitarti a testare il tuo codice nel tuo ambiente di QA, usa anche l'ambiente di staging per testare anche il tuo software. Spesso ci sono bug che hanno poco o nulla a che fare con il codice stesso, ma piuttosto hanno una causa principale che si trova nella configurazione dell'ambiente stesso (o in qualche mix dei due). Per trovare questi problemi è necessario testare il codice in un ambiente che rispecchi da vicino la produzione, ovvero la stadiazione.

Come ultima parola, a volte ciò che è più importante non è ciò che facciamo per evitare che le cose vadano male, ma è come ci comportiamo quando sbagliano. Pertanto, penso che sia importante costruire una cultura nella tua azienda attorno alla trasparenza operativa. Non cercare di nascondere problemi ai clienti, sii imminente. Usa Twitter attivamente per far sapere ai clienti se ci sono problemi di cui il tuo team operativo è attualmente a conoscenza e che sta lavorando per risolvere ( Lighthouse è fantastico in questo!). Prendi in considerazione la pubblicazione di una pagina "status" per il tuo servizio a cui i clienti possono fare riferimento per vedere se qualcosa non va ( TypePad ne offre un ottimo esempio). In conclusione, sempre errato sul lato della comunicazione eccessiva. I tuoi clienti ti ringrazieranno per questo.

Molte risposte qui già ti dicono come implementare la tua soluzione specifica al problema, ma, per quanto ne so, il vero problema non è quello di migrare / aggiornare correttamente un sito web. Può darsi che il design / l'architettura dietro di esso sia fragile.

Se questo è vero, dovrai regolare l'architettura del tuo sistema in modo tale che sia sufficientemente robusto per continuare a funzionare correttamente anche se le impostazioni di configurazione cambiano o non sono impostate correttamente e tale da degradarsi con grazia se si verificano. Idealmente, se hai aggiunto nuove funzionalità o modificato funzionalità precedenti in modi che richiedono una nuova colonna del database, il tuo sito funzionerà anche se manca la colonna (forse senza la nuova funzionalità o con una forma degradata della vecchia funzionalità) . Il tuo cliente non dovrebbe perdere denaro - nel peggiore dei casi, potrebbe non ricevere nuovi soldi dai miglioramenti che hai apportato.

Se il tuo sistema è abbastanza fragile che le impostazioni di configurazione possono causare problemi così gravi, gli aggiornamenti del programma non saranno le uniche fonti di problemi - e capire come fare gli aggiornamenti in modo sicuro aumenterà solo il danno che sperimenterai in caso di guasto una fonte diversa.