Portare in produzione la versione di un nuovo progetto richiede un attento equilibrio tra velocità di distribuzione e affidabilità della soluzione. Slack valorizza le iterazioni veloci, i cicli di feedback brevi e la risposta rapida alle richieste degli utenti. Inoltre, l'azienda ha centinaia di programmatori che si sforzano di essere il più produttivi possibile.
Gli autori del materiale, la cui traduzione pubblichiamo oggi, affermano che un'azienda che si sforza di aderire a tali valori e allo stesso tempo cresce deve migliorare costantemente il proprio sistema di implementazione dei progetti. L'azienda deve investire nella trasparenza e nell'affidabilità dei processi di lavoro, facendo ciò per garantire che questi processi corrispondano alla scala del progetto. Qui parleremo dei flussi di lavoro che si sono sviluppati in Slack e di alcune delle decisioni che hanno portato l'azienda a utilizzare il sistema di distribuzione dei progetti esistente oggi.
Come funzionano oggi i processi di distribuzione dei progetti
Ogni PR (richiesta pull) in Slack deve essere soggetta a revisione del codice e deve superare con successo tutti i test. Solo dopo che queste condizioni sono soddisfatte il programmatore può unire il suo codice nel ramo principale del progetto. Tuttavia, questo codice viene distribuito solo durante l'orario lavorativo, ora del Nord America. Di conseguenza, poiché i nostri dipendenti sono sul posto di lavoro, siamo pienamente preparati a risolvere eventuali problemi imprevisti.
Ogni giorno effettuiamo circa 12 implementazioni pianificate. Durante ogni distribuzione, il programmatore designato come responsabile della distribuzione è responsabile della messa in produzione della nuova build. Si tratta di un processo in più fasi che garantisce che l'assemblaggio venga portato in produzione senza problemi. Grazie a questo approccio, possiamo rilevare gli errori prima che colpiscano tutti i nostri utenti. Se sono presenti troppi errori, è possibile eseguire il rollback della distribuzione dell'assembly. Se un problema specifico viene scoperto dopo il rilascio, è possibile rilasciare facilmente una correzione.
Interfaccia del sistema Checkpoint, utilizzata in Slack per distribuire progetti
Il processo di distribuzione di una nuova versione in produzione può essere considerato composto da quattro passaggi.
▍1. Creazione di un ramo di rilascio
Ogni rilascio inizia con un nuovo ramo di rilascio, un punto nella nostra storia Git. Ciò consente di assegnare tag alla versione e fornisce un luogo in cui è possibile apportare correzioni in tempo reale per i bug rilevati nel processo di preparazione della versione per il rilascio in produzione.
▍2. Distribuzione in un ambiente di staging
Il passaggio successivo consiste nel distribuire l'assembly sui server di staging ed eseguire un test automatico per le prestazioni complessive del progetto (smoke test). L'ambiente di gestione temporanea è un ambiente di produzione che non riceve traffico esterno. In questo ambiente eseguiamo ulteriori test manuali. Questo ci dà ulteriore fiducia che il progetto modificato funzioni correttamente. I test automatizzati da soli non sono sufficienti per fornire questo livello di fiducia.
▍3. Distribuzione in ambienti dogfood e canarini
La distribuzione in produzione inizia con un ambiente sperimentale, rappresentato da un insieme di host che servono i nostri spazi di lavoro Slack interni. Dato che siamo utenti Slack molto attivi, adottare questo approccio ci ha aiutato a individuare molti bug nelle prime fasi della distribuzione. Dopo esserci assicurati che la funzionalità di base del sistema non venga interrotta, l'assembly viene distribuito nell'ambiente canary. Rappresenta sistemi che rappresentano circa il 2% del traffico di produzione.
▍4. Rilascio graduale in produzione
Se gli indicatori di monitoraggio per la nuova versione risultano stabili e se dopo l'implementazione del progetto in ambiente canary non abbiamo ricevuto alcun reclamo, continueremo a trasferire gradualmente i server di produzione alla nuova versione. Il processo di distribuzione è suddiviso nelle seguenti fasi: 10%, 25%, 50%, 75% e 100%. Di conseguenza, possiamo trasferire lentamente il traffico di produzione alla nuova versione del sistema. Allo stesso tempo, abbiamo tempo per indagare sulla situazione se vengono rilevate eventuali anomalie.
▍Che cosa succede se qualcosa va storto durante la distribuzione?
Apportare modifiche al codice è sempre un rischio. Ma ce la facciamo grazie alla presenza di "leader di distribuzione" ben addestrati che gestiscono il processo di messa in produzione di una nuova versione, monitorano gli indicatori di monitoraggio e coordinano il lavoro dei programmatori che rilasciano il codice.
Nel caso in cui qualcosa vada davvero storto, cerchiamo di individuare il problema il prima possibile. Esaminiamo il problema, troviamo il PR che causa gli errori, lo eseguiamo il rollback, lo analizziamo a fondo e creiamo una nuova build. È vero, a volte il problema passa inosservato finché il progetto non entra in produzione. In una situazione del genere, la cosa più importante è ripristinare il servizio. Pertanto, prima di iniziare a indagare sul problema, eseguiamo immediatamente il rollback alla build funzionante precedente.
Elementi costitutivi di un sistema di distribuzione
Diamo un'occhiata alle tecnologie che sono alla base del nostro sistema di implementazione del progetto.
▍Implementazioni rapide
Il flusso di lavoro sopra descritto può sembrare, in retrospettiva, alquanto ovvio. Ma il nostro sistema di distribuzione non è diventato subito così.
Quando l'azienda era molto più piccola, la nostra intera applicazione poteva essere eseguita su 10 istanze Amazon EC2. Distribuire il progetto in questa situazione significava utilizzare rsync per sincronizzare rapidamente tutti i server. In precedenza, il nuovo codice era solo a un passo dalla produzione, rappresentata da un ambiente di staging. Gli assemblaggi sono stati creati e testati in un ambiente di questo tipo, per poi passare direttamente alla produzione. Era molto facile comprendere un sistema del genere; consentiva a qualsiasi programmatore di utilizzare il codice che aveva scritto in qualsiasi momento.
Ma man mano che il numero dei nostri clienti cresceva, aumentava anche la portata dell’infrastruttura necessaria per supportare il progetto. Ben presto, data la costante crescita del sistema, il nostro modello di distribuzione, basato sull’invio di nuovo codice ai server, non riuscì più a svolgere il suo lavoro. In altre parole, aggiungere ogni nuovo server significava aumentare il tempo necessario per completare la distribuzione. Anche le strategie basate sull'uso parallelo di rsync presentano alcune limitazioni.
Alla fine abbiamo risolto questo problema passando a un sistema di distribuzione completamente parallelo, progettato in modo diverso dal vecchio sistema. Vale a dire, ora non abbiamo inviato codice ai server utilizzando uno script di sincronizzazione. Ora ogni server ha scaricato in modo indipendente il nuovo assembly, sapendo che doveva farlo monitorando la modifica della chiave Consul. I server hanno caricato il codice in parallelo. Ciò ci ha consentito di mantenere un'elevata velocità di implementazione anche in un ambiente di costante crescita del sistema.
1. I server di produzione monitorano la chiave Consul. 2. La chiave cambia, questo dice ai server che devono iniziare a scaricare il nuovo codice. 3. I server scaricano i file tarball con il codice dell'applicazione
▍Dispiegamenti atomici
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 potrebbe generare un numero elevato di messaggi di errore. Il fatto è che il processo di copia di nuovi file sui server di produzione non era atomico. Ciò ha comportato un breve lasso di tempo in cui il codice che chiamava nuove funzioni era disponibile prima che le funzioni stesse fossero disponibili. Quando veniva chiamato tale codice, venivano restituiti errori interni. Ciò si è manifestato in richieste API non riuscite e pagine Web danneggiate.
Il team che ha lavorato su questo problema lo ha risolto introducendo il concetto di directory “calde” e “fredde”. Il codice nella hot directory è responsabile dell'elaborazione del traffico di produzione. E nelle directory "fredde", il codice, mentre il sistema è in esecuzione, viene solo preparato per l'uso. Durante la distribuzione, il nuovo codice viene copiato in una directory fredda non utilizzata. Quindi, quando non sono presenti processi attivi sul server, viene eseguito un cambio di directory istantaneo.
1. Decomprimere il codice dell'applicazione in una directory “fredda”. 2. Passaggio del sistema ad una directory “fredda”, che diventa “calda” (operazione atomica)
Risultati: spostamento dell’accento sull’affidabilità
Nel 2018, il progetto è cresciuto a tal punto che un’implementazione molto rapida ha iniziato a danneggiare la stabilità del prodotto. Avevamo un sistema di distribuzione molto avanzato nel quale abbiamo investito molto tempo e impegno. Tutto quello che dovevamo fare era ricostruire e migliorare i nostri processi di distribuzione. Siamo cresciuti fino a diventare un'azienda abbastanza grande, i cui sviluppi sono stati utilizzati in tutto il mondo per organizzare comunicazioni ininterrotte e risolvere problemi importanti. Pertanto, l’affidabilità è diventata il centro della nostra attenzione.
Avevamo bisogno di rendere più sicuro il processo di distribuzione delle nuove versioni di Slack. Questa esigenza ci ha portato a migliorare il nostro sistema di distribuzione. È un dato di fatto, abbiamo discusso di questo sistema migliorato sopra. Nelle profondità del sistema, continuiamo a utilizzare tecnologie di distribuzione rapide e atomiche. Il modo in cui viene eseguita la distribuzione è cambiato. Il nostro nuovo sistema è progettato per implementare gradualmente nuovo codice a diversi livelli, in diversi ambienti. Ora utilizziamo strumenti di supporto e strumenti di monitoraggio del sistema più avanzati rispetto a prima. Questo ci dà la possibilità di individuare e correggere gli errori molto prima che abbiano la possibilità di raggiungere l'utente finale.
Ma non ci fermeremo qui. Miglioriamo costantemente questo sistema, utilizzando strumenti ausiliari e strumenti di automazione del lavoro più avanzati.
Cari lettori! Come funziona il processo di distribuzione delle nuove versioni del progetto dove lavori?
Fonte: habr.com