Come posso automatizzare le distribuzioni di produzione senza provare ansia estrema?

Nel nostro negozio utilizziamo SVN per il controllo del codice sorgente e CruiseControl per CI sulla gestione di build e implementazioni automatiche nei nostri ambienti di sviluppo, test e integrazione.

Tutto funziona senza problemi, tuttavia, a causa di vincoli hardware e di risorse, il nostro ambiente di integrazione non è un ambiente bilanciato con carico di 2 server come il nostro ambiente di produzione. Mentre tutto il resto è uguale, questa sarebbe l'unica differenza tra i nostri ambienti di integrazione e produzione (anche se grande!)

Teoricamente la differenza è una configurazione leggermente diversa dei nostri server di app e lo script di distribuzione dovrebbe semplicemente eliminare gli artefatti di build in due server anziché solo quello, ma perché sono così nervoso da automatizzare le nostre distribuzioni di produzione ?!

In genere non sono un maniaco del controllo ma sento sempre l'insaziabile necessità di distribuire manualmente la produzione in produzione. Ho sentito dai colleghi che in genere si tratta di Really BAD Thing ™, ma non sono riusciti a presentare un ricorso contro di essa.

So che quando lo faccio manualmente POSSO VEDERE che sto copiando fisicamente i file corretti, sto spegnendo fisicamente i server delle app e assicurandomi che siano chiusi correttamente, sto avviando fisicamente il backup dei server e quindi ispezionando fisicamente i log per fare sicuro che si è avviato correttamente e la distribuzione ha avuto successo. Mi dà tranquillità.

Quali sono gli argomenti contro questo argomento OR per la distribuzione automatica della produzione con script?

Ci sono alcuni ovvi argomenti contro questo.

1. Cosa succede se parti. Tutte queste informazioni sono accuratamente documentate o sono principalmente nella tua testa. Gli script automatizzati sono un posto molto migliore per qualcun altro da cui prendere il posto.

2. Tutti fanno degli errori. Arriverà un momento in cui la persona che esegue lo spiegamento è stanca, non prestando attenzione a nulla. Sì, idealmente le distribuzioni vengono eseguite solo in un luogo sereno e felice con molto tempo. In pratica possono essere affrettati e stressati quando si cerca di implementare correzioni urgenti. Questo è il momento più probabile per fare un errore, e anche il più costoso. Se la distribuzione è un singolo script, il rischio di errori è limitato.

3. Tempo. Man mano che le distribuzioni diventano più complicate, aumenta la quantità necessaria. Gli script richiedono solo il calcio d'inizio, un controllo manuale e quindi una commutazione manuale (potresti anche automatizzare questo, ma condivido un po 'della paranoia :).

Puoi ottenere il meglio dai migliori mondi: tranquillità con la verifica dei processi e l'affidabilità dell'automazione.

Script della distribuzione. Quindi, controlla e verifica manualmente che i processi vengano avviati, i file rimossi, ecc. In altre parole, scrivi il tuo script QA solo per verificare che i passaggi automatici 1 - X si siano effettivamente verificati.

Penso che la chiave qui sia: perché pensi di non poter scrivere il processo di verifica?

I miei script di distribuzione non limitano il push degli archivi e il riavvio dei servizi. Stampano molte informazioni con codice colore durante ogni fase della distribuzione e alla fine mi forniscono un riepilogo degli eventi. Mi fa sapere che i processi sono attivi e in esecuzione, che la homepage fornisce un codice di stato 200 e che tutte le macchine e i servizi possono vedersi bene. Ho quindi un servizio separato che non fa parte dello script che controlla i file di registro, gli errori di livello 4xx e 5xx e le metriche del sito chiave. Quindi procede a urlarmi contro ogni mezzo possibile (e-mail, SMS e allarmi) se ci sono picchi drastici di effetti negativi.

Tra quello e i server CI che eseguono i test, ho letteralmente distribuito e dimenticato a questo livello di automazione. Non sfoglio nemmeno una singola pagina del sito dopo una spinta a causa della affidabilità del processo, che non solo mi consente di implementare tutte le volte che voglio, ma consente a un nuovo sviluppatore del progetto di aggiornare il live sito a pochi minuti dall'imbarco. In passato ho persino effettuato la distribuzione automatica dei server CI in produzione dopo un commit in un ramo master / trunk che passa tutto. Ecco quanto sono fiducioso nei miei strumenti.

Dovresti esserlo anche tu.

Gestisci anche le tue macchine di produzione con il debug remoto e le passi manualmente? Costruire uno script adeguato è identico a scrivere un programma. Tutti i problemi riscontrati indicano elementi che dovranno essere cercati e verificati.

Se qualcosa va storto, dovrebbe passare attraverso adeguate procedure di rollback e inviarti un messaggio. Tutto ciò che accade può essere registrato per dopo. È possibile controllare la versione degli script e impostare casi di test.

Ma se esegui manualmente i comandi, non hai nessuno di questi vantaggi. Invece hai un elenco di svantaggi.

• Non hai un buon registro, la cronologia della shell non conta
• Nessun altro sa come farlo
• I passi mancano
• I controlli vengono effettuati solo a volte
• Alcuni elementi da distribuire potrebbero perdersi, l'ho già fatto prima
• Ci vuole molto più tempo
• Puoi essere interrotto durante il processo

Uno script corretto dovrebbe essere quasi identico a se hai digitato tutto sulla shell. Questo è uno dei motivi per cui abbiamo script bash. Se ti fidi delle cose che fai, perché non riesci a registrare tutto e stringere? Un controllo migliore, un controllo più rapido, un controllo maggiore può accadere perché il computer lo fa.

Posso capire di essere un po 'nervoso nel provare qualcosa di nuovo nell'ambiente prod. Diffidare di un potenziale disastro è una buona cosa ^TM .

Lo scripting automatico è anche una buona cosa ^TM e fintanto che ti avvicini con attenzione, dovresti essere in grado di ridurre al minimo il pericolo e ridurre la paura. Quindi il mio consiglio è questo;

• Preparare (ed esercitarsi sull'integration env) una checklist / serie di test in modo da poter scoprire rapidamente se ha funzionato e cosa se qualcosa è andato storto. La registrazione dettagliata può essere di aiuto.
• Eseguire il backup di tutto. Preparare ed esercitarsi in un rollback manuale in modo da poter recuperare se non funziona correttamente.
• Metti alla prova il più possibile prima di farlo sul serio. Sembra che tu sia un buon metodo insieme a questo ambiente di integrazione.
• La prima volta che lo provi, fallo su un profilo basso, modifica a basso impatto. Qualcosa come un aggiornamento o una patch minori. L'idea è di ridurre al minimo la ricaduta se va storto. Non scegliere un aggiornamento importante di alto profilo (dove il CEO e tutti i tuoi concorrenti stanno guardando) per la tua prima manche.

Dopo aver eseguito alcune corse di successo, la tua sicurezza aumenterà e presto ti chiederai come sei mai riuscito a fare distribuzioni manuali.

Ecco il più grande argomento contro il dispiegamento manuale nella produzione: sei un essere umano e commetterai errori. Ci saranno sicuramente momenti in cui ti dimenticherai di fare qualcosa che ti causerà dolore. Una distribuzione automatizzata ben scritta non ha la stessa tendenza. È vero che è ancora possibile disporre di distribuzioni di produzione incasinate, ma ciò è dovuto al fatto che la distribuzione automatizzata presenta bug che devono essere risolti.

Nella mia esperienza, i vantaggi delle distribuzioni automatizzate alla produzione sono enormi. Il più grande è che ti divertirai nei fine settimana invece di provare a marciare attraverso un processo di distribuzione manuale che non coopererà.

Detto questo, ecco alcuni suggerimenti chiave per automatizzare le distribuzioni di produzione:

• Non farlo tutto in una volta! Inizia a scrivere lentamente le tue distribuzioni automatizzate. Configurare innanzitutto un ambiente di non produzione separato e provare ad automatizzare le distribuzioni lì. Dopo aver acquisito sicurezza nelle tue distribuzioni automatizzate, puoi iniziare a pensare a fare distribuzioni di produzione
• Inizia a rilasciare e distribuire molto frequentemente! È molto più semplice eseguire distribuzioni automatizzate quando non si dispone di 4 mesi di codice in attesa di essere rilasciato. Rilascia piccole funzionalità e correzioni di bug più volte alla settimana. I vantaggi di questo stile di rilascio non possono essere sottovalutati!
• Affidati a test automatizzati per avere la certezza che il tuo ambiente di produzione funzionerà. Ancora una volta, questo richiede tempo per essere costruito, ma è molto importante. I test automatizzati sono sempre migliori dei test di accettazione manuale. Certo, i test di accettazione manuale vanno bene, ma i test automatizzati possono aiutarti a sapere se è necessario implementare in produzione o meno. Sono la chiave che consente l'intero processo di consegna automatizzata e continua. Se i test non passano, sai di non implementarli in produzione.

Esegui gli script sul server live. Funzionerà e dopo averlo visto funzionare bene alcune volte, ne sarai perfettamente sicuro.

Scherzi a parte, è più probabile che tu commetta errori rispetto allo script di distribuzione.

I computer non commettono errori, lo fanno le persone.

Scrivi una volta il tuo script e controllalo attentamente, esaminalo riga per riga. Da quel momento in poi puoi essere sicuro che ogni volta che eseguirai la distribuzione, funzionerà.

Fallo a mano e sei obbligato a fare errori. Forse hai scritto, tutto quello che devi fare, in fondo, ma è così facile fare un errore. Devi copiare tutti i file tranne il file web.config? Puoi scommettere che un giorno lo sovrascriverai. Una sceneggiatura non commetterà mai questo errore.

Come posso automatizzare le distribuzioni di produzione senza provare ansia estrema?

L'estrema ansia che proveresti quando automatizzi le distribuzioni di produzione è, molto probabilmente, basata su due convinzioni:

1. Un giorno o l'altro, alcuni passaggi della distribuzione falliranno e tu o un altro essere umano sarete in grado di recuperare rapidamente dal fallimento mentre uno script automatico potrebbe trascurarlo.

2. Un fallimento trascurato nella produzione ha conseguenze drammatiche.

C'è poco da fare su 2., oltre a evitare guasti, quindi concentriamoci su 1.

Una soluzione economica in lieve miglioramento rispetto all'esistente sarebbe quella di utilizzare una procedura di distribuzione semi-automatica, in attesa di convalida al termine di ogni passaggio dell'installazione. Con una soluzione semi-automatica godrai dei vantaggi di una soluzione completamente automatica, come coerenza e riproducibilità, mentre avrai comunque la possibilità di monitorare i progressi e recuperare dagli errori a cui sei abituato.

Lo script semi-automatizzato e il suo biotopo (test di regressione, ecc.) Potrebbero anche servire da veicolo per le conoscenze che si stanno raccogliendo sui guasti che si verificano nella procedura di installazione e sui modi per recuperarli.

Quello che mi piace è che è possibile testare la distribuzione in fase di gestione temporanea o QA e sapere che quando lo si esegue su prod, accadranno esattamente gli stessi passaggi.

Quando lo fai manualmente, è più facile dimenticare un passaggio o farlo fuori servizio.

... a causa di vincoli hardware e di risorse, il nostro ambiente di integrazione non è un ambiente bilanciato con carico di 2 server come il nostro ambiente di produzione. Mentre tutto il resto è uguale, questa sarebbe l'unica differenza tra i nostri ambienti di integrazione e produzione (anche se grande!)

Dato sopra, probabilmente sarei ansioso come te.

Una volta ho rivisto e testato lo script automatico che viene distribuito su SLB e la mia sensazione è che senza pre-test con una configurazione bilanciata del carico preferirei fare manualmente le cose.

Oltre all'impostazione di test simile a un prod, un'altra cosa che ha avuto un impatto significativo sulla mia tranquillità è che l'implementazione del prod è stata fatta da altri team che sviluppatori - da ragazzi il cui unico compito era mantenere l'ambiente di produzione.

• In uno dei progetti li stavo assistendo nello schieramento come rappresentante del team di sviluppo. Prima della distribuzione, stavano rivedendo le mie istruzioni e durante la distribuzione ero seduto online pronto a consultare se le cose andavano male. Allora, ho imparato ad apprezzare quella separazione .
   
  Non che fossero più veloci (perché avrebbero dovuto? Ho testato le distribuzioni 5x-10x più frequentemente di loro). La grande differenza era a fuoco. Voglio dire, la mia testa è sempre caricata da cose "principali" - codifica, debug, nuove funzionalità - ci sono troppe distrazioni per concentrarsi correttamente sulla distribuzione. Al contrario, le loro cose principali erano solo la manutenzione della produzione e si concentravano su questo.
   
  È incredibile quanto il cervello funzioni meglio quando è focalizzato. Questi ragazzi, erano solo molto più attenti, hanno fatto molti meno errori di me. Conoscevano quella roba meglio di me. Mi hanno persino insegnato una cosa o due che ha reso più semplici le mie implementazioni di test.

Crea uno script di distribuzione che utilizzi per spostare il codice in qualsiasi ambiente. Utilizziamo lo stesso identico processo di distribuzione per spostare il codice su dev, qa, staging e infine produzione. Poiché stiamo implementando più volte al giorno per lo sviluppo e ogni giorno per il QA, abbiamo acquisito la sicurezza che gli script di distribuzione sono corretti. Fondamentalmente, mettici alla prova, usandolo spesso.

1. Semplificare. Il processo di modifica dovrebbe essere file rsync, eseguire script SQL, niente di più.
2. Automatizzare.
3. Test.

Il motivo per automatizzare è ottenere qualcosa che sia testabile, ripetibile e che ci si possa fidare di lavorare correttamente in ogni situazione prevista.

È comunque necessario disporre di un piano di back-out, come per qualsiasi modifica in qualsiasi contesto, e dovrebbe anche essere automatizzato.

Vorrai comunque osservare il processo come accade se l'ambiente è molto sensibile, ma non farlo mai manualmente poiché non può essere riprodotto.

È del tutto possibile utilizzare script di automazione per distribuire in ambienti di produzione. Tuttavia, per farlo in modo affidabile devi essere in grado di fare diverse cose.

1. Ripristina in modo affidabile alla versione precedente.
2. Ottieni una conferma positiva che la distribuzione è stata applicata correttamente e risponde al traffico valido.
3. Hanno ambienti comparabili per lo sviluppo e il QA che usano anche gli stessi script.

Ci sono alcuni vantaggi negli script, in quanto non perderanno mai un comando perché sono le 2 del mattino ed è stanco.

Tuttavia, gli script possono e continuano a non riuscire. A volte l'errore è nella progettazione dello script, ma potrebbe anche essere causato da una rete o mancanza di corrente, file system corrotto, memoria insufficiente .....

Questo è il motivo per cui è importante che dopo l'esecuzione dello script venga seguita anche una fase di test definita che verifichi che la nuova distribuzione sia attiva, eseguendo e gestendo le richieste, prima che il traffico live sia abilitato.

1. prendere una finestra più grande per la distribuzione la prima volta se le cose vanno male

2. Dividere il processo di distribuzione in due parti. un. Backup (manuale): questo dovrebbe darti sicurezza se qualcosa va storto durante la distribuzione

   b. Distribuzione (automatizzato)

una volta che sarai in grado di eseguire la distribuzione in tutta sicurezza per la prima volta. puoi anche automatizzare il processo di backup.