La pubblicazione di una nuova versione del progetto in produzione richiede una attenta osservanza del bilanciamento tra la velocità di distribuzione e l'affidabilità della soluzione. In azienda, Slack apprezza le iterazioni rapide, i cicli di feedback brevi e la reazione tempestiva alle richieste degli utenti. Inoltre, l'azienda dispone di centinaia di programmatori che mirano alla massima produttività possibile.
Gli autori del materiale, la cui traduzione pubblichiamo oggi, affermano che un'azienda che cerca di attenersi a tali valori e allo stesso tempo cresce, deve costantemente migliorare il proprio sistema di distribuzione dei progetti. L'azienda deve investire risorse nella trasparenza e nell'affidabilità dei processi di lavoro, affinché questi rispettino la scala del progetto. Qui parleremo dei processi di lavoro che si sono sviluppati in Slack e di alcune soluzioni che hanno portato l'azienda a utilizzare l'attuale sistema di distribuzione dei progetti.
Come funzionano oggi i processi di distribuzione dei progetti
Ogni PR (pull request) in Slack deve essere necessariamente sottoposta a codice revisione e deve superare tutti i test con successo. Solo dopo che queste condizioni sono state soddisfatte, il programmatore può eseguire la fusione del proprio codice con il branch master del progetto. Tuttavia, la distribuzione di tale codice avviene solo durante l'orario lavorativo secondo il fuso orario nordamericano. Di conseguenza, grazie al fatto che i nostri dipendenti sono al lavoro, siamo completamente pronti a risolvere eventuali problemi imprevisti.
Ogni giorno eseguiamo circa 12 distribuzioni programmate. Durante ogni distribuzione, il programmatore designato come responsabile della distribuzione è responsabile dell'implementazione della nuova build in produzione. Si tratta di un processo multi-fase che garantisce un'implementazione fluida della build in modalità operativa. Grazie a questo approccio, possiamo individuare errori prima che colpiscano tutti i nostri utenti. Se ci sono troppi errori, la distribuzione della build può essere annullata. Se, invece, un singolo problema viene rilevato dopo la pubblicazione, è facile rilasciare una correzione per esso.
L'interfaccia del sistema Checkpoint, utilizzata in Slack per la distribuzione dei progetti
Il processo di distribuzione di una nuova versione in produzione può essere rappresentato come costituito da quattro passaggi.
▍1. Creazione del ramo di rilascio
Ogni rilascio inizia con un nuovo ramo di rilascio, a partire da un certo punto nella nostra storia Git. Questo consente di assegnare tag al rilascio e offre uno spazio dove apportare correzioni per errori trovati durante la preparazione del rilascio per la produzione.
▍2. Distribuzione nell'ambiente di staging
Il passo successivo consiste nella distribuzione della build sui server di staging e nell'esecuzione di un test automatico per verificare la funzionalità generale del progetto (smoke test). L'ambiente di staging è un ambiente di produzione che non riceve traffico esterno. In questo ambiente effettuamo ulteriori prove manuali. Questo ci dà maggiore sicurezza che il progetto modificato funzioni correttamente. Non sono sufficienti solo i test automatizzati per poter avere tale certezza.
▍3. Distribuzione negli ambienti dogfood e canary
La distribuzione in produzione inizia con l'ambiente dogfood, rappresentato da un insieme di host che servono i nostri ambienti di lavoro interni su Slack. Essendo utenti molto attivi di Slack, questo approccio ha aiutato a scoprire molti errori nelle fasi iniziali della distribuzione. Dopo averci assicurati che la funzionalità di base del sistema non sia compromessa, procediamo con la distribuzione della build nell'ambiente canary. Quest'ultimo rappresenta i sistemi che ricevono circa il 2% del traffico in produzione.
▍4. Rilascio graduale in produzione
Se i parametri di monitoraggio del nuovo rilascio risultano stabili, e dopo la distribuzione del progetto nell'ambiente canary non riceviamo lamentele, continuiamo a trasferire gradualmente i server di produzione al nuovo rilascio. Il processo di distribuzione è suddiviso nelle seguenti fasi: 10%, 25%, 50%, 75% e 100%. In questo modo possiamo lentamente reindirizzare il traffico di produzione al nuovo rilascio del sistema. Abbiamo così tempo per analizzare la situazione in caso emergano anomalie.
▍Cosa fare se qualcosa va storto durante la distribuzione?
Apportare modifiche al codice comporta sempre un rischio. Ma riusciamo a gestirlo grazie alla presenza di esperti ben preparati nei "deployment", che guidano il processo di rilascio della nuova versione in produzione, monitorano le metriche di controllo e coordinano il lavoro dei programmatori che rilasciano il codice.
Nel caso in cui qualcosa vada realmente storto, cerchiamo di identificare il problema il prima possibile. Analizziamo il problema, troviamo il PR che causa errori, lo annulliamo, lo analizziamo attentamente e creiamo una nuova build. A volte, però, il problema passa inosservato fino al rilascio del progetto in produzione. In una tale situazione, la cosa più importante è ripristinare il funzionamento del servizio. Per questo motivo, prima di iniziare a esplorare il problema, torniamo immediatamente all'ultima build funzionante.
Strutture di base del sistema di deployment
Consideriamo le tecnologie che stanno alla base del nostro sistema di deployment dei progetti.
▍Deployment rapidi
Il processo di lavoro descritto sopra potrebbe sembrare, a posteriori, del tutto ovvio. Ma il nostro sistema di deployment non è diventato tale da un giorno all'altro.
Quando l'azienda era significativamente più piccola, tutta la nostra applicazione poteva funzionare su 10 istanze Amazon EC2. In tale situazione, il deployment del progetto significava l'uso di rsync per una rapida sincronizzazione di tutti i server. In passato, un nuovo codice era separato dalla produzione da un solo passaggio rappresentato da un ambiente intermedio. Le build venivano create e verificate in tale ambiente, per poi andare direttamente in produzione. Capire un sistema del genere era molto semplice, permetteva a qualsiasi programmatore di distribuire il codice che aveva scritto in qualsiasi momento.
Ma con l'aumento del numero dei nostri clienti, anche le dimensioni dell'infrastruttura necessaria per il funzionamento del progetto sono aumentate. Presto, considerando la continua crescita del sistema, il nostro modello di deployment, basato sull'invio di nuovo codice ai server, ha smesso di funzionare. Aggiungere ogni nuovo server significava aumentare il tempo necessario per eseguire il deployment. Anche le strategie basate sull'applicazione parallela di rsync hanno delle limitazioni.
Alla fine abbiamo risolto questo problema passando a un sistema di distribuzione completamente parallelo, strutturato in modo diverso rispetto al vecchio sistema. In particolare, ora non inviavamo il codice ai server utilizzando uno script di sincronizzazione. Ora ogni server scaricava autonomamente la nuova build, venendo a conoscenza della necessità di farlo grazie all'osservazione della modifica della chiave Consul. I server scaricavano il codice in parallelo. Questo ci ha permesso di mantenere un'elevata velocità di distribuzione anche in un contesto di crescita costante del sistema.
1. I server di produzione monitorano la chiave Consul. 2. La chiave cambia, comunicando ai server di iniziare a scaricare il nuovo codice. 3. I server scaricano i file tarball con il codice dell'applicazione.
▍Distribuzioni atomiche
Un'altra soluzione che ci ha aiutato a raggiungere un sistema di distribuzione multilivello è stata la distribuzione atomica.
Prima di utilizzare le distribuzioni atomiche, ogni distribuzione poteva portare alla generazione di un numero significativo di messaggi di errore. Questo perché il processo di copia di nuovi file sui server di produzione non era atomico. Ciò portava all'esistenza di un breve intervallo di tempo in cui il codice che richiamava nuove funzioni era accessibile prima che queste funzioni fossero disponibili. Quando questo codice veniva eseguito, si traduceva in errori interni. Questo si manifestava in richieste API non riuscite e in pagine web "rotte".
Il team che si occupava di questo problema lo ha risolto introducendo il concetto di directory "calde" (hot) e "fredde" (cold). Il codice nella directory "calda" è responsabile dell'elaborazione del traffico di produzione. Nelle directory "fredde", il codice viene solo preparato per l'uso durante il funzionamento del sistema. Durante la distribuzione, il nuovo codice viene copiato in una directory "fredda" non utilizzata. Poi, quando sul server non ci sono processi attivi, viene eseguito un cambio istantaneo delle directory.
1. Decompressione del codice dell'applicazione nella directory "fredda". 2. Cambio del sistema sulla directory "fredda", che diventa "calda" (operazione atomica).
Conclusioni: spostamento dell'accento sulla robustezza
Nel 2018, il progetto è cresciuto a tal punto che il rapido deployment ha iniziato a danneggiare la stabilità del prodotto. Avevamo un sistema di deployment piuttosto avanzato, in cui abbiamo investito molte energie e tempo. Dovevamo solo ristrutturare e migliorare i processi di organizzazione del deployment. Siamo diventati un'azienda abbastanza grande, le cui soluzioni sono state utilizzate in tutto il mondo per garantire comunicazioni ininterrotte e per affrontare compiti importanti. Pertanto, l'affidabilità è diventata il nostro obiettivo principale.
Era necessario rendere il processo di deployment delle nuove versioni di Slack più sicuro. Questa esigenza ci ha portato a migliorare il nostro sistema di deployment. In effetti, abbiamo discusso proprio di questo sistema avanzato. All'interno del sistema continuiamo a utilizzare tecnologie di deployment rapide e atomiche. È cambiato il modo in cui viene effettuato il deployment. Il nostro nuovo sistema è progettato per eseguire il deployment del nuovo codice in modo graduale, su diversi livelli e in ambienti differenti. Ora utilizziamo strumenti ausiliari e sistemi di monitoraggio più sofisticati rispetto a prima. Questo ci consente di rilevare e correggere errori molto prima che possano raggiungere l'utente finale.
Ma non intendiamo fermarci qui. Miglioriamo costantemente questo sistema, utilizzando strumenti ausiliari e mezzi di automazione più avanzati.
Gentili lettori! Come è organizzato il processo di deployment delle nuove versioni nei progetti dove lavori tu?
Fonte: habr.com
