<\/a><\/noindex><\/p>\nCome funzionano oggi i processi di distribuzione dei progetti<\/h2>\n \nOgni 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\u00f2 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.<\/p>\n
Ogni giorno eseguiamo circa 12 distribuzioni programmate. Durante ogni distribuzione, il programmatore designato come responsabile della distribuzione \u00e8 responsabile dell'implementazione della nuova build in produzione. Si tratta di un processo multi-fase che garantisce un'implementazione fluida della build in modalit\u00e0 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\u00f2 essere annullata. Se, invece, un singolo problema viene rilevato dopo la pubblicazione, \u00e8 facile rilasciare una correzione per esso.<\/p>\n
L'interfaccia del sistema Checkpoint, utilizzata in Slack per la distribuzione dei progetti<\/i><\/p>\n
Il processo di distribuzione di una nuova versione in produzione pu\u00f2 essere rappresentato come costituito da quattro passaggi.<\/p>\n
\u258d1. Creazione del ramo di rilascio<\/h3>\n \nOgni 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.<\/p>\n
\u258d2. Distribuzione nell'ambiente di staging<\/h3>\n \nIl passo successivo consiste nella distribuzione della build sui server di staging e nell'esecuzione di un test automatico per verificare la funzionalit\u00e0 generale del progetto (smoke test). L'ambiente di staging \u00e8 un ambiente di produzione che non riceve traffico esterno. In questo ambiente effettuamo ulteriori prove manuali. Questo ci d\u00e0 maggiore sicurezza che il progetto modificato funzioni correttamente. Non sono sufficienti solo i test automatizzati per poter avere tale certezza.<\/p>\n
\u258d3. Distribuzione negli ambienti dogfood e canary<\/h3>\n \nLa 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\u00e0 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.<\/p>\n
\u258d4. Rilascio graduale in produzione<\/h3>\n \nSe 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 \u00e8 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\u00ec tempo per analizzare la situazione in caso emergano anomalie.<\/p>\n
\u258dCosa fare se qualcosa va storto durante la distribuzione?<\/h3>\n \nApportare 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.<\/p>\n
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\u00f2, il problema passa inosservato fino al rilascio del progetto in produzione. In una tale situazione, la cosa pi\u00f9 importante \u00e8 ripristinare il funzionamento del servizio. Per questo motivo, prima di iniziare a esplorare il problema, torniamo immediatamente all'ultima build funzionante.<\/p>\n
Strutture di base del sistema di deployment<\/h2>\n \nConsideriamo le tecnologie che stanno alla base del nostro sistema di deployment dei progetti.<\/p>\n
\u258dDeployment rapidi<\/h3>\n \nIl processo di lavoro descritto sopra potrebbe sembrare, a posteriori, del tutto ovvio. Ma il nostro sistema di deployment non \u00e8 diventato tale da un giorno all'altro.<\/p>\n
Quando l'azienda era significativamente pi\u00f9 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.<\/p>\n
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.<\/p>\n
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\u00e0 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\u00e0 di distribuzione anche in un contesto di crescita costante del sistema.<\/p>\n
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.<\/i><\/p>\n\u258dDistribuzioni atomiche<\/h3>\n
\nUn'altra soluzione che ci ha aiutato a raggiungere un sistema di distribuzione multilivello \u00e8 stata la distribuzione atomica.<\/p>\n
Prima di utilizzare le distribuzioni atomiche, ogni distribuzione poteva portare alla generazione di un numero significativo di messaggi di errore. Questo perch\u00e9 il processo di copia di nuovi file sui server di produzione non era atomico. Ci\u00f2 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\".<\/p>\n
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\" \u00e8 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.<\/p>\n
1. Decompressione del codice dell'applicazione nella directory \"fredda\". 2. Cambio del sistema sulla directory \"fredda\", che diventa \"calda\" (operazione atomica).<\/i><\/p>\nConclusioni: spostamento dell'accento sulla robustezza<\/h2>\n
\nNel 2018, il progetto \u00e8 cresciuto a tal punto che il rapido deployment ha iniziato a danneggiare la stabilit\u00e0 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\u00e0 \u00e8 diventata il nostro obiettivo principale.<\/p>\n
Era necessario rendere il processo di deployment delle nuove versioni di Slack pi\u00f9 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. \u00c8 cambiato il modo in cui viene effettuato il deployment. Il nostro nuovo sistema \u00e8 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\u00f9 sofisticati rispetto a prima. Questo ci consente di rilevare e correggere errori molto prima che possano raggiungere l'utente finale.<\/p>\n
Ma non intendiamo fermarci qui. Miglioriamo costantemente questo sistema, utilizzando strumenti ausiliari e mezzi di automazione pi\u00f9 avanzati.<\/p>\n
Gentili lettori!<\/b> Come \u00e8 organizzato il processo di deployment delle nuove versioni nei progetti dove lavori tu?<\/p>\n
habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77784,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t