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

Ci sono alcuni argomenti ovvi contro questo.

1. Cosa succede se te ne vai. Tutte queste informazioni sono accuratamente documentate, o sono per lo più nella tua testa. Gli script automatici sono un posto molto migliore da cui qualcun altro subentrerà.

2. Ognuno fa errori. Arriverà un momento in cui la persona che fa il dispiegamento è stanca, senza prestare attenzione. Sì, gli schieramenti ideali sono fatti solo in un posto calmo e felice con molto tempo. In pratica possono essere affrettati e stressati quando si tenta di implementare correzioni urgenti. Questo è il momento più probabile per commettere un errore, e anche il più costoso. Se la distribuzione è un singolo script, il potenziale di errori è limitato.

3. Ora. Man mano che le distribuzioni diventano più complicate, aumenta la quantità che deve essere aumentata. Gli script richiedono solo il kick-off, un controllo manuale e poi un passaggio manuale (puoi automatizzare anche questo, ma condivido parte della paranoia:).

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

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

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

I miei script di distribuzione non si limitano a spingere gli archivi e riavviare i servizi. Stampano molte informazioni codificate a colori durante ogni fase della distribuzione e mi forniscono un riepilogo degli eventi alla fine. Mi fa sapere che i processi sono attivi e in esecuzione, che la home page sta servendo un codice di stato di 200 e che tutte le macchine e i servizi possono vedersi bene. Poi ho un servizio separato che non fa parte dello script che monitora i file di registro, gli errori 4xx e 5xx e le metriche del sito chiave. Quindi procede a urlarmi attraverso ogni mezzo possibile (e-mail, msg txt e allarmi) se ci sono drastici picchi con effetti negativi.

Tra questi e i server CI che eseguono i test, ho letteralmente distribuito e dimenticato a questo livello di automazione. Non sfoglio nemmeno una singola pagina sul sito dopo una spinta a causa di quanto sia affidabile ora il processo, che non solo consente di distribuire tutte le volte che voglio, ma consente a un nuovo sviluppatore del progetto di effettuare un aggiornamento sul live sito entro pochi minuti dal salire a bordo. In passato ho persino reso i server CI auto-distribuiti in produzione dopo un commit a un ramo master / trunk che passa tutto. È così sicuro di me nei miei strumenti.

Dovresti esserlo anche tu.

Esegui anche le macchine di produzione con il debug remoto e le passi manualmente? Costruire uno script corretto è identico alla scrittura di un programma. Tutti i problemi che hai indicano cose che dovranno essere controllate e controllate.

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

Ma se stai eseguendo manualmente i comandi, non hai nessuno di questi vantaggi. Hai invece una lista di svantaggi.

• Non hai un buon registro, la cronologia della shell non conta
• Nessun altro sa come farlo
• I passaggi vengono persi
• I controlli vengono talvolta eseguiti solo
• Alcuni elementi da distribuire potrebbero essere persi, 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 scritto tutto sulla shell. Questo è uno dei motivi per cui abbiamo script di bash. Se ti fidi delle cose che fai, perché non puoi registrare tutto e rafforzarlo? Controllo migliore, controllo più rapido, più controllo può accadere perché il computer lo fa.

Riesco a capire di essere un po 'nervoso a provare qualcosa di nuovo sull'ambiente prod. Diffidare del potenziale disastro è una buona cosa ^TM .

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

• Prepara (e fai pratica sull'inv di integrazione) una checklist / un set di test in modo da poter scoprire rapidamente se ha funzionato e se qualcosa è andato storto. La registrazione dettagliata può aiutare con questo.
• Esegui il backup di tutto. Prepara e pratica un rollback manuale in modo che tu possa recuperare se va male.
• Provalo il più possibile prima di farlo sul serio. Sembra che tu sia un buon modo insieme a questo con il tuo ambiente di integrazione
• La prima volta che lo provi, fallo su un profilo basso, a basso impatto. Qualcosa come un aggiornamento o una patch minori. L'idea è di minimizzare il fallout se va male. Non scegliere un aggiornamento principale di alto profilo (dove il CEO e tutti i tuoi concorrenti stanno guardando) per la tua prima esecuzione.

Una volta che hai avuto a portata di mano qualche corsa di successo, la tua fiducia aumenterà e presto ti chiedi come hai mai gestito le distribuzioni manuali.

Ecco il più grande argomento contro la distribuzione manuale alla produzione: sei un umano e commetti errori. Ci saranno indubbiamente dei momenti in cui ti dimenticherai di fare qualcosa che ti causerà dolore. Una distribuzione automatizzata ben scritta non ha la stessa tendenza. È vero che puoi ancora avere distribuzioni di produzione incasinate, ma è perché la tua distribuzione automatizzata ha dei bug che devono essere risolti.

In base alla mia esperienza, i vantaggi dei deployment automatizzati sulla produzione sono enormi. Il più grande è che ti divertirai nei fine settimana invece di provare a sfilare attraverso un processo di distribuzione manuale che non collaborerà.

Detto questo, ecco alcuni indicatori chiave per l'automazione delle distribuzioni di produzione:

• Non eseguire tutto in una volta! Inizia a scrivere lentamente le distribuzioni automatizzate. Impostare innanzitutto un ambiente di non produzione separato e provare ad automatizzare le distribuzioni. Una volta che hai acquisito fiducia nelle distribuzioni automatizzate, puoi iniziare a pensare di eseguire i deployment di produzione
• Inizia a rilasciare e distribuire molto spesso! È molto più semplice eseguire distribuzioni automatizzate quando non hai 4 mesi di codice in attesa di essere rilasciato. Rilasciare piccole funzionalità e correzioni di errori più volte alla settimana. I vantaggi di questo stile di rilascio non possono essere sottovalutati!
• Affidati a test automatizzati per darti sicurezza del funzionamento del tuo ambiente di produzione. Anche in questo caso è necessario molto tempo per essere sviluppati, ma è molto importante. I test automatici sono sempre migliori dei test di accettazione manuali. Certo, i test di accettazione manuali vanno bene, ma i test automatici possono aiutarti a sapere se dovresti distribuire in produzione o meno. Sono la chiave che consente l'intero processo di consegna automatica e continua. Se i tuoi test non passano, sai di non distribuirli in produzione.

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

Seriamente, è più probabile che tu commetta degli errori rispetto allo script di implementazione.

I computer non commettono errori, le persone lo fanno.

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

Fallo a mano e sei destinato a commettere errori. Forse hai scritto, tutto ciò che devi fare, ma è facile commettere un errore. Devi copiare tutti i file tranne il file web.config? Puoi scommettere che un giorno lo sovrascriveresti. Uno script non farà mai questo errore.

How can I automate production deployments without experiencing extreme anxiety?

L'estrema ansietà che si prova quando si automatizzano le distribuzioni di produzione è, molto probabilmente, basata su due convinzioni:

1. Un giorno o l'altro, alcuni passi della distribuzione falliranno e tu o un altro umano potrai recuperare rapidamente dall'errore mentre uno script automatico potrebbe ignorarlo.

2. Un errore trascurato nella produzione ha conseguenze drammatiche.

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

Una soluzione economica leggermente migliorativa sull'esistente sarebbe quella di utilizzare una procedura di distribuzione semiautomatica, in attesa di convalida alla fine di ogni fase dell'installazione. Con una soluzione semiautomatica beneficerai di una soluzione completamente automatica, come la coerenza e la riproducibilità, mentre avrai ancora la possibilità di monitorare i progressi e di recuperare dagli errori a cui sei abituato.

Lo script semi-automatico e il suo biotopo (test di regressione, ecc.) potrebbero anche servire da veicolo per le conoscenze che stai raccogliendo sui guasti che si verificano nella procedura di installazione e sui modi per recuperare da essi.

Quello che mi piace è che puoi testare la distribuzione su staging o QA e sapere che quando lo esegui su prod si succederà esattamente lo stesso.

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

...due to hardware and resource constraints our integration environment is not a 2 server load balanced environment like our production environment. While everything else is equal that would be the only difference between our integration and production environments (although a big one!)

Dato sopra, probabilmente sarei tanto ansioso quanto te.

Una volta ho esaminato e testato lo script automatizzato che viene distribuito a SLB e ritengo che senza pre-test con l'installazione bilanciata del carico preferirei fare manualmente le cose.

Oltre alla configurazione dei test di tipo prod-like, un'altra cosa che ha avuto un impatto significativo sulla mia tranquillità è che la distribuzione dei prod è stata eseguita da altri team che sviluppatori - da ragazzi il cui unico compito era mantenere l'ambiente di produzione .

• In uno dei progetti li stavo assistendo nella distribuzione come rappresentante della squadra di sviluppo. Prima della distribuzione, stavano rivedendo le mie istruzioni e durante la distribuzione ero appena seduto online pronto a consultarmi se le cose dovessero andare male. Allora, ho imparato ad apprezzare la separazione .
  
  Non che fossero più veloci (perché dovrebbero? Ho fatto test di distribuzione 5x-10x più frequentemente di loro). La grande differenza era a fuoco. Voglio dire, la mia testa è sempre caricata da cose "principali" - codifica, debugging, nuove funzionalità - ci sono troppe distrazioni per concentrarsi correttamente sulla distribuzione. Al contrario di ciò, la loro roba principale era solo la manutenzione della produzione e loro erano concentrati su quello.
  
  È incredibile quanto funzioni meglio il cervello quando è concentrato. Questi ragazzi, erano molto più attenti, hanno fatto meno errori di me. Sapevano solo quella roba meglio di me. Mi hanno anche insegnato una cosa o due che ha reso più facili le mie implementazioni di test.

Crea uno script di distribuzione che usi per spostare il tuo codice in qualsiasi ambiente. Usiamo lo stesso identico processo di distribuzione per spostare il codice su dev, qa, staging e, infine, produzione. Dal momento che stiamo distribuendo più volte al giorno per lo sviluppo e giornalmente per il controllo qualità, abbiamo acquisito la certezza che gli script di distribuzione sono corretti. Fondamentalmente, prova a provarci da usarlo spesso.

1. Semplifica. Il tuo processo di modifica dovrebbe essere file rsync, eseguire script SQL, nient'altro.
2. Automatizzare.
3. Prova.

Il motivo per automatizzare è ottenere qualcosa che è testabile, ripetibile e che ti puoi fidare di lavorare correttamente in ogni situazione prevista.

Devi ancora avere un piano di back-up, come per qualsiasi cambiamento in qualsiasi contesto, e dovrebbe essere anche automatizzato.

Continuerete a osservare il processo come accade se l'ambiente è veramente sensibile, ma non lo fate mai manualmente poiché non può essere riprodotto.

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

1. Ripristina in modo affidabile la versione precedente.
2. Ottieni conferma positiva che la distribuzione è stata applicata correttamente e risponde a traffico valido.
3. Avere ambienti comparabili per lo sviluppo e QA che utilizzano anche gli stessi script.

Ci sono alcuni vantaggi per gli script, in quanto non mancheranno mai un comando perché sono le 2 e sono stanco.

Tuttavia, gli script possono e continueranno a fallire. A volte l'errore è nella progettazione dello script, ma potrebbe anche essere causato da un'interruzione di rete o di alimentazione, file system corrotto, esaurimento della memoria .....

Ecco perché è importante che dopo che lo script è stato eseguito, venga seguita anche una fase di test definita che verifica che la nuova distribuzione sia attiva, in esecuzione e gestita 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. Deployment (automatizzato)

una volta che puoi schierare con sicurezza per la prima volta. puoi anche automatizzare il processo di backup.