Purtate una nova versione di prughjettu in a produzzione richiede un equilibru attentu trà a velocità di implementazione è l'affidabilità di a suluzione. Slack valuta iterazioni veloci, cicli brevi di feedback, è risposta pronta à e dumande di l'utilizatori. Inoltre, a cumpagnia hà centinaie di programatori chì si sforzanu di esse u più pruduttivu pussibule.
L'autori di u materiale, a traduzzione di quale avemu publicatu oghje, dicenu chì una sucità chì s'impegna à aderisce à tali valori è à u stessu tempu cresce deve migliurà constantemente u so sistema di implementazione di u prugettu. A cumpagnia deve invistisce in a trasparenza è l'affidabilità di i prucessi di travagliu, fendu questu per assicurà chì questi prucessi currispondenu à a scala di u prugettu. Quì parlemu di i flussi di travagliu chì anu sviluppatu in Slack, è di alcune di e decisioni chì anu purtatu a cumpagnia à utilizà u sistema di implementazione di u prugettu chì esiste oghje.
Cume i prucessi di implementazione di u prugettu funzionanu oghje
Ogni PR (pull request) in Slack deve esse sottumessu à a revisione di codice è deve passà bè tutte e teste. Solu dopu chì sti cundizioni sò scontri, u programatore pò unisce u so codice in u ramu maestru di u prugettu. Tuttavia, stu codice hè implementatu solu durante l'ora di l'affari, u tempu di l'America di u Nordu. In u risultatu, per via di u fattu chì i nostri impiegati sò in i so posti di travagliu, simu cumplettamente preparati per risolve ogni prublema inespettatu.
Ogni ghjornu realicemu circa 12 implementazioni pianificate. Durante ogni implementazione, u programatore designatu cum'è u capu di implementazione hè rispunsevule per mette a nova custruzzione in a produzzione. Questu hè un prucessu multi-passu chì assicura chì l'assemblea hè purtata in a pruduzzione in modu fluidu. Grazie à questu approcciu, pudemu detectà errori prima ch'elli affettanu tutti i nostri utilizatori. Se ci sò troppu errori, a implementazione di l'assemblea pò esse ritruvata. Se un prublema specificu hè scupertu dopu a liberazione, una correzione pò esse facilmente liberata per questu.
Interfaccia di u sistema Checkpoint, chì hè utilizatu in Slack per implementà i prughjetti
U prucessu di implementà una nova versione à a produzzione pò esse pensatu cum'è custituitu di quattru passi.
▍1. Crià un ramu di liberazione
Ogni liberazione principia cù un novu ramu di liberazione, un puntu in a nostra storia Git. Questu permette di assignà tag à a liberazione è furnisce un locu induve pudete fà correzioni in diretta per i bug trovati in u prucessu di preparazione di a liberazione per a liberazione à a produzzione.
▍2. Implementazione in un ambiente di staging
U prossimu passu hè di implementà l'assemblea nantu à i servitori di staging è eseguisce una prova automatica per a prestazione generale di u prugettu (test di fumu). L'ambiente di staging hè un ambiente di produzzione chì ùn riceve micca trafficu esternu. In questu ambiente, realicemu testi manuali supplementari. Questu ci duna cunfidenza supplementu chì u prughjettu mudificatu funziona bè. I testi automatizati solu ùn sò micca abbastanza per furnisce stu livellu di cunfidenza.
▍3. Impiegazione in ambienti canarini è canarini
L'implementazione à a produzzione principia cù un ambiente di dogfood, rapprisintatu da un inseme di ospiti chì servenu i nostri spazii di travagliu interni Slack. Siccomu simu utilizatori di Slack assai attivi, piglià stu approcciu ci hà aiutatu à catturà assai bug prima di a implementazione. Dopu avemu assicuratu chì a funziunalità di basa di u sistema ùn hè micca rottu, l'assemblea hè implementata in l'ambienti canarini. Rapprisenta sistemi chì cuntenenu circa 2% di u trafficu di produzzione.
▍4. Liberazione graduale à a produzzione
Se l'indicatori di monitoraghju per a nova liberazione risultanu stabile, è se dopu avè implementatu u prughjettu in l'ambienti canari ùn avemu micca ricevutu alcuna lagnanza, cuntinuemu à trasfirì gradualmente i servitori di produzzione à a nova versione. U prucessu di implementazione hè divisu in i seguenti tappe: 10%, 25%, 50%, 75% è 100%. In u risultatu, pudemu trasfiriri lentamente u trafficu di produzzione à a nova versione di u sistema. À u listessu tempu, avemu u tempu di investigà a situazione se ogni anomalia hè rilevata.
▍E se qualcosa va male durante l'implementazione?
Fà mudificazioni à u codice hè sempre un risicu. Ma facemu cun questu grazia à a presenza di "dirigenti di implementazione" ben furmati chì gestiscenu u prucessu di portà una nova versione in produzzione, monitoranu l'indicatori di monitoraghju è coordinanu u travagliu di i programatori chì liberanu codice.
In l'eventu chì qualcosa va veramente male, pruvemu di detectà u prublema u più prestu pussibule. Investighemu u prublema, truvamu u PR chì hè causatu l'errori, u rollu, analizà bè è creanu una nova custruzione. True, qualchì volta u prublema passa inosservatu finu à chì u prugettu entra in produzzione. In una tale situazione, u più impurtante hè di restaurà u serviziu. Dunque, prima di principià à investigà u prublema, avemu subitu torna à a custruzione di travagliu precedente.
Blocchi di costruzione di un sistema di implementazione
Fighjemu e tecnulugia chì sottumettenu u nostru sistema di implementazione di u prughjettu.
▍Spiegazioni veloci
U flussu di travagliu descrittu sopra pò sembrà, in retrospettiva, un pocu evidenti. Ma u nostru sistema di implementazione ùn hè micca diventatu cusì subitu.
Quandu a cumpagnia era assai più chjuca, tutta a nostra applicazione puderia eseguisce nantu à 10 istanze Amazon EC2. Implementà u prugettu in questa situazione significava aduprà rsync per sincronizà rapidamente tutti i servitori. Nanzu, u novu codice era solu un passu da a produzzione, rapprisintatu da un ambiente di staging. L'assemblei sò stati creati è pruvati in un tali ambiente, è poi andonu direttamente à a produzzione. Era assai faciule di capisce un tali sistema; permette à qualsiasi programatore di implementà u codice chì avia scrittu in ogni mumentu.
Ma cum'è u numeru di i nostri clienti cresce, cusì hà fattu a scala di l'infrastruttura necessaria per sustene u prugettu. Prestu, datu a crescita constante di u sistema, u nostru mudellu di implementazione, basatu annantu à spinghje novu codice à i servitori, ùn facia più u so travagliu. Vale à dì, aghjunghje ogni novu servitore significava aumentà u tempu necessariu per compie a implementazione. Ancu e strategie basate nantu à l'usu parallelu di rsync anu certe limitazioni.
Avemu finitu per risolve stu prublema passendu à un sistema di implementazione completamente parallelu, chì hè statu cuncepitu di manera diversa da u vechju sistema. Vale à dì, avà ùn avemu micca mandatu codice à i servitori cù un script di sincronizazione. Avà ogni servitore indipindente scaricatu u novu assemblea, sapendu chì ci vole à fà cusì da monitoring u cambiamentu chjave Consul. I servitori caricanu u codice in parallelu. Questu ci hà permessu di mantene una alta velocità di implementazione ancu in un ambiente di crescita constante di u sistema.
1. I servitori di pruduzzione monitoranu a chjave Consul. 2. I cambiamenti chjave, questu dici à i servitori chì anu bisognu di cumincià à scaricà u novu codice. 3. I servitori scaricanu i schedari tarball cù u codice di l'applicazione
▍Spiegamenti atomichi
Un'altra suluzione chì ci hà aiutatu à ghjunghje à un sistema di implementazione multi-livellu hè stata l'implementazione atomica.
Prima di utilizà implementazioni atomiche, ogni implementazione puderia risultatu in un gran numaru di messagi d'errore. U fattu hè chì u prucessu di cupià novi schedari à i servitori di produzzione ùn era micca atomicu. Questu hà risultatu in una curta finestra di tempu induve u codice chì chjamava e funzioni novi era dispunibule prima chì e funzioni stessi eranu dispunibili. Quandu un tali codice hè statu chjamatu, hà risultatu in l'errori internu chì sò tornati. Questu si manifesta in richieste API falluti è pagine web rotte.
A squadra chì hà travagliatu annantu à questu prublema hà risoltu intruducendu u cuncettu di repertorii "caldi" è "friddi". U codice in u hot directory hè rispunsevuli di trasfurmà u trafficu di produzzione. È in i repertorii "friddi", u codice, mentre chì u sistema hè in esecuzione, hè solu preparatu per l'usu. Durante a implementazione, u novu codice hè copiatu in un repertoriu friddu inutilizatu. Allora, quandu ùn ci sò micca prucessi attivi nantu à u servitore, un cambiamentu di repertoriu istantaneu hè realizatu.
1. Unpacking u codice dumanda in un cartulare "frid". 2. Cambia u sistema à un repertoriu "frid", chì diventa "caldo" (operazione atomica)
Risultati: cambiamentu di enfasi à affidabilità
In u 2018, u prughjettu hà crisciutu à una tale scala chì una implementazione assai rapida hà cuminciatu à dannà a stabilità di u pruduttu. Avemu avutu un sistema di implementazione assai avanzatu in quale avemu investitu assai tempu è sforzu. Tuttu ciò chì avemu bisognu di fà era ricustruisce è migliurà i nostri prucessi di implementazione. Avemu crisciutu in una cumpagnia abbastanza grande, chì i so sviluppi sò stati utilizati in tuttu u mondu per urganizà cumunicazioni ininterrotte è per risolve prublemi impurtanti. Dunque, a fiducia hè diventata u focu di a nostra attenzione.
Avemu bisognu di rende più sicura u prucessu di implementà e novi versioni di Slack. Questa necessità ci hà purtatu à migliurà u nostru sistema di implementazione. In fatti, avemu discututu stu sistema migliuratu sopra. In a prufundità di u sistema, cuntinuemu à aduprà tecnulugia di implementazione rapida è atomica. U modu di implementazione hè cambiatu. U nostru novu sistema hè pensatu per implementà gradualmente u novu codice à diversi livelli, in diversi ambienti. Avemu avà aduprà strumenti di supportu più avanzati è strumenti di monitoraghju di u sistema chè prima. Questu ci dà a capacità di catturà è corregge l'errori assai prima ch'elli anu a pussibilità di ghjunghje à l'utilizatore finale.
Ma ùn avemu da fermà quì. Migliuremu constantemente stu sistema, utilizendu strumenti ausiliarii più avanzati è arnesi d'automatizazione di u travagliu.
Beni, lettori! Cumu funziona u prucessu di implementazione di novi versioni di prughjettu induve travagliate?
Source: www.habr.com