Cosa puoi fare per ridurre il numero di bug di distribuzione di un sito web dal vivo?

Due cose:

• Ambiente di gestione temporanea, simile a quello dell'ambiente in cui vengono eseguite le installazioni di test.
• Ampio test di questo ambiente dopo la distribuzione. Automatico 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. La strumentazione che usa è specifica per lo stack MS, ma i concetti sono universali.

Mi chiedo, perché nessuno ha menzionato Controllo versione - che è uno dei più importante modi per salvarti dai problemi durante l'aggiornamento / l'aggiornamento.

Innanzitutto, la tua distribuzione dovrebbe essere solo un clone del ramo stabile nel tuo repository. Tutto ciò che include i file di configurazione, i file SQL, gli script di installazione / aggiornamento DEVONO essere controllati dalla versione.

In secondo luogo, devi avere "una sorta di" area di staging - potrebbe essere qualsiasi cosa - un server locale, un temporaneo server virtuale di cloud che hai appena generato, una configurazione di host virtuale molto semplice o, a pieno titolo applicazione personalizzata che mantieni insieme all'app principale. La differenza tra questa "area di staging" e la "zona di sviluppo" è che i primi modellano più da vicino (o simulano) il tuo reale ambiente di distribuzione. Ad esempio, puoi sviluppare su PHP 5.3.x con il modulo Apache, ma dal momento che l'host è PHP 5.2.x con FCGI, l'area di staging deve essere uguale.

Quindi, prima scrivi e testa gli aggiornamenti sul tuo ambiente di sviluppo. Unisci queste modifiche al repository dell'area di staging e di nuovo test. A questo punto puoi apportare qualsiasi modifica alla tua configurazione per adattarla alla tua implementazione - 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 alla copia della distribuzione live.

La complessità della tua area di sosta dovrebbe riflettere la complessità e la portata della tua app. Ma in ogni caso il controllo della versione è indispensabile.

Ovviamente, se non si utilizza il controllo della versione - non si applica nulla di ciò - ma poi è ingenuo come scrivere un database in Logo.

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

Questo fa apparire un altro punto: ha tester . Testare le cose che ho scritto io non trova tanti bug come quando qualcun altro mette alla prova la mia applicazione.

Un'altra cosa: automatizza la tua implementazione processo. Le migrazioni di db con ant migrano, distribuiscono automaticamente la versione più recente da svn via capistrano ecc. Quando si distribuisce qualcosa, non si dovrebbe fare altro che un semplice clic e tutto è automatico. Soprattutto per i siti web che richiedono un po 'di configurazione, i passaggi manuali necessari per la distribuzione sono un incubo e la possibilità che qualcosa vada storto enormemente.

Per qualcosa che assolutamente, in modo positivo, non si deve rompere considera un sistema A e un sistema B e usa un bilanciamento del carico per instradare tutte le richieste ad A mentre aggiorni e collaudi 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 prenda 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 test o di staging in cui si eseguano tutti i passaggi, ma è essenziale conservare 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 compilazione e implementazione, prendo una proprietà di ambiente che recupera i file di metadati specifici dell'ambiente come i file XML e li sostituisce nella posizione di creazione prima del confezionamento. Inoltre negli script di distribuzione cercherò qualsiasi file SQL negli aggiornamenti del database ed eseguirò quelli sul database configurato anche per quell'ambiente.

Potrei farlo con un'attività di creazione personalizzata, ma in realtà uso solo alcuni test JUnit per fare questo per me . Se si verificano eccezioni SQL, il test fallisce e quindi la distribuzione fallisce. In generale anche gli script SQL hanno intelligenza, se i dati necessari già esistono nell'ambiente, allora saltano l'inserto o l'aggiornamento.

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

Il tell all nella tua domanda è questo: dovrebbero sempre essere aggiornati, ma non lo faranno.

Queste configurazioni guidano le build e le distribuzioni automatiche, quindi se NON le aggiorni, le tue build falliscono e il tuo manager viene informato via email. È altrettanto importante che il team mantenga le configurazioni di generazione e distribuzione per una versione specifica, poiché è compito loro di controllare il codice che compila. Qualsiasi infrazione interrompe la compilazione.

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

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

2) Avere tutte le configurazioni in un file di configurazione (web config o simile). Questa configurazione dovrebbe quindi essere specifica per l'applicazione e mai sovrascritta. Eventuali modifiche sono quindi delibrare piuttosto che dimenticare di modificare qualcosa che dovrebbe essere diverso dal test.

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

Riduci la complessità della base di codici. Meno codice, in genere, significa meno bug e più facile trovarli. Questa è la filosofia dietro il refactoring, la separazione delle preoccupazioni e così via.

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

• alcune parti principali che cambiano lentamente e sono condivise sul sito
• molte parti foglia che possono cambiare più rapidamente, ma ognuna ha un impatto solo su una parte più piccola del sito

Questa comprensione della tua base di codice ti consente di focalizzare lo sviluppo e i test sulle parti principali, dal momento che i bug avranno l'effetto più drastico.

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

1. Quanto è probabile che il rilascio sia lungo e ci sono dei rischi nel permettere alle persone di continuare a interfacciare con il mio prodotto mentre è in corso il rilascio? Se c'è un rischio per il sistema , considera di prendere il sistema offline e di inserire un messaggio "Sistema attualmente in fase di manutenzione" al suo posto.

2. Ci sono clienti che potrebbero essere tenuti a notificare in anticipo la versione? Devo comunicare loro una possibile interruzione del servizio o un peggioramento delle prestazioni durante il rilascio? Personalmente, sbaglio sempre dalla parte della comunicazione eccessiva e della comunicazione a tutti i clienti di una prossima versione o finestra di manutenzione su un blog pubblico o un luogo simile.

3. Quali sono i miei piani di emergenza nel caso in cui il rilascio non vada a buon fine? Ad esempio, se il rilascio non funziona correttamente dovremmo eseguire il rollback e ripristinare il sistema in modo da ridurre al minimo il tempo sono offline? E se sì, i passaggi per il rollback di una release sono ben documentati? O dovrei avere le persone giuste su chiamata o a portata di mano per assistere con i problemi di risoluzione dei problemi nel caso si presentassero. Personalmente, ritengo che il modo migliore per approcciare la pianificazione di qualsiasi release sia quello di presumere che qualcosa vada storto con il rilascio. In questo modo mi sono costretto a pensare prima su alcuni di questi problemi.

Inoltre, quando si tratta di eseguire una versione, uno dei modi migliori per assicurarti che funzioni senza intoppi è quello di esercitarsi, esercitarsi, esercitarsi e documentare tutto ciò che incontri lungo la strada . Quindi, con largo anticipo sull'implementazione del nuovo codice in produzione, esercitarsi a distribuire il codice in un ambiente di staging sicuro e correttamente sandboxed. Chiedere alla persona responsabile della distribuzione in produzione, eseguire la distribuzione del test alla messa in scena. Considera questa tua prova generale e comportati come faresti se fosse questa la cosa reale. Documenta tutto ciò che fai in ogni fase; documenta ogni comando che esegui, qualsiasi codice SQL che esegui, tutti i file che modifichi e come li hai modificati e per ogni passo lungo il percorso documenta ciò che ti aspetti di vedere se la procedura viene eseguita correttamente. Se e quando incontri un problema di qualche tipo, documenta cosa hai fatto per risolverlo.

Quindi la distribuzione pratica è completa, controlla le tue note e vedi se è possibile perfezionare il processo per eliminare gli errori. Quindi fai tutto da capo . Continuare a esercitarsi fino a quando l'esecuzione di un rilascio diventa di routine 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 del rilascio può fare per facilitare il corretto svolgimento del rilascio. Ma cosa può fare l'ingegneria per ridurre al minimo i rischi in una versione?

1. Mantiene le versioni piccole. In parole semplici, più complesso è il set di modifiche al codice contenuto da una release, più rischioso diventerà il rilascio. Le tue operazioni sono favorevoli, prevedendo di avere un maggior numero di piccole versioni, piuttosto che un numero minore di grandi versioni nello stesso periodo di tempo.

2. Test, test, test. non basta testare il codice nell'ambiente QA, utilizzare l'ambiente di staging per testare anche il software. Spesso ci sono bug che hanno poco o nulla a che fare con il codice stesso, ma hanno una causa alla radice che risiede nella configurazione dell'ambiente stesso (o in qualche mix dei due). Per trovare questi problemi è necessario testare il codice in un ambiente che rispecchia da vicino la produzione, ad esempio la gestione temporanea.

Come ultima parola, a volte ciò che è più importante non è ciò che facciamo per evitare che le cose vadano storte, ma è il modo in cui ci comportiamo quando sbagliano. Pertanto, penso che sia importante costruire una cultura nella tua azienda attorno alla trasparenza operativa. Non cercare di nascondere i problemi dei clienti, sii prossimo. Utilizza Twitter attivamente per far sapere ai clienti se ci sono problemi che il tuo team operativo è al corrente e che sta lavorando per risolvere ( Lighthouse è fantastico Questo!). Considera la pubblicazione di una pagina di "stato" per il tuo servizio che i clienti possono fare riferimento per vedere se qualcosa non va ( TypePad offre un ottimo esempio di questo) . Linea di fondo, errare sempre 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 posso dire, il vero problema non è quello di migrare / aggiornare correttamente un sito web. Può darsi che il design / architettura dietro di esso sia fragile.

Se ciò è vero, dovrai adattare l'architettura del tuo sistema in modo tale che sia abbastanza robusto per continuare a funzionare correttamente anche se le impostazioni di configurazione cambiano o non sono impostate correttamente e in modo tale che si degradino con garbo se si verificano. Idealmente, se hai aggiunto nuove funzionalità o hai cambiato le vecchie funzionalità in modi che richiedono una nuova colonna di database, il tuo sito funzionerà anche se manca la colonna (magari senza la nuova funzionalità o con una forma degradata della vecchia funzionalità) . Il tuo cliente non dovrebbe perdere soldi - nel peggiore dei casi, potrebbe non ottenere nuovi guadagni dai miglioramenti che hai inserito.

Se il tuo sistema è abbastanza fragile che le impostazioni di configurazione possono causare seri problemi, gli aggiornamenti del programma non saranno l'unica fonte di problemi - e capire come fare in modo sicuro gli aggiornamenti aumenterà solo il danno che avvertirai quando l'errore proviene da una fonte diversa.