Uvedenie nového vydania projektu do produkcie si vyžaduje starostlivú rovnováhu medzi rýchlosťou nasadenia a spoľahlivosťou riešenia. Slack hodnoty rýchle iterácie, krátke cykly spätnej väzby a rýchle reakcie na požiadavky používateľov. Okrem toho má spoločnosť stovky programátorov, ktorí sa snažia byť čo najproduktívnejší.
Autori materiálu, ktorého preklad dnes uverejňujeme, hovoria, že spoločnosť, ktorá sa snaží dodržiavať takéto hodnoty a zároveň rastie, musí neustále zlepšovať svoj systém nasadzovania projektov. Spoločnosť musí investovať do transparentnosti a spoľahlivosti pracovných procesov, aby zabezpečila, že tieto procesy budú zodpovedať rozsahu projektu. Tu budeme hovoriť o pracovných postupoch, ktoré sa vyvinuli v Slacku, a o niektorých rozhodnutiach, ktoré viedli spoločnosť k použitiu systému nasadzovania projektov, ktorý dnes existuje.
Ako dnes fungujú procesy nasadzovania projektov
Každý PR (pull request) v Slacku musí prejsť kontrolou kódu a musí úspešne prejsť všetkými testami. Až po splnení týchto podmienok môže programátor zlúčiť svoj kód do hlavnej vetvy projektu. Tento kód je však nasadený iba počas pracovných hodín, severoamerického času. Vďaka tomu, že naši zamestnanci sú na svojich pracoviskách, sme plne pripravení riešiť akékoľvek neočakávané problémy.
Každý deň realizujeme približne 12 plánovaných nasadení. Počas každého nasadenia je programátor určený ako vedúci nasadenia zodpovedný za uvedenie novej zostavy do produkcie. Ide o viackrokový proces, ktorý zaisťuje hladké uvedenie montáže do výroby. Vďaka tomuto prístupu dokážeme odhaliť chyby skôr, ako zasiahnu všetkých našich používateľov. Ak je príliš veľa chýb, nasadenie zostavy možno vrátiť späť. Ak sa po vydaní objaví konkrétny problém, možno preň jednoducho vydať opravu.
Rozhranie systému Checkpoint, ktoré sa v Slacku používa na nasadenie projektov
Proces nasadenia nového vydania do produkcie si možno predstaviť ako pozostávajúci zo štyroch krokov.
▍1. Vytvorenie vetvy uvoľnenia
Každé vydanie začína novou vetvou vydania, bodom v našej histórii Git. To vám umožňuje priradiť štítky k vydaniu a poskytuje miesto, kde môžete robiť živé opravy chýb nájdených v procese prípravy vydania na vydanie do produkcie.
▍2. Nasadenie v inscenačnom prostredí
Ďalším krokom je nasadenie zostavy na staging serveroch a spustenie automatického testu celkového výkonu projektu (dymový test). Pracovné prostredie je produkčné prostredie, ktoré neprijíma externú prevádzku. V tomto prostredí vykonávame dodatočné manuálne testovanie. To nám dáva dodatočnú istotu, že upravený projekt funguje správne. Samotné automatizované testy nestačia na zabezpečenie tejto úrovne istoty.
▍3. Nasadenie v testovacom a kanárikovom prostredí
Nasadenie do produkcie začína interným testovacím prostredím, ktoré predstavuje súbor hostiteľov, ktorí obsluhujú naše interné pracovné priestory Slack. Keďže sme veľmi aktívni používatelia Slacku, tento prístup nám pomohol zachytiť veľa chýb na začiatku nasadenia. Potom, čo sme sa uistili, že základná funkcionalita systému nie je narušená, je zostava nasadená v prostredí kanárikov. Predstavuje systémy, ktoré tvoria približne 2 % produkčnej prevádzky.
▍4. Postupné uvoľňovanie do výroby
Ak sa ukazovatele monitorovania pre nové vydanie ukážu ako stabilné a ak po nasadení projektu v prostredí kanárikov nedostaneme žiadne sťažnosti, pokračujeme v postupnom presune produkčných serverov na nové vydanie. Proces nasadenia je rozdelený do nasledujúcich etáp: 10 %, 25 %, 50 %, 75 % a 100 %. Výsledkom je, že môžeme pomaly preniesť produkčnú prevádzku do nového vydania systému. Zároveň máme čas na prešetrenie situácie, ak sa zistia nejaké anomálie.
▍Čo ak sa počas nasadenia niečo pokazí?
Vykonávanie úprav kódu je vždy riziko. Ale zvládame to vďaka prítomnosti dobre vyškolených „deployment lídrov“, ktorí riadia proces uvedenia nového vydania do produkcie, monitorujú monitorovacie indikátory a koordinujú prácu programátorov uvoľňujúcich kód.
V prípade, že sa niečo naozaj pokazí, snažíme sa problém odhaliť čo najskôr. Vyšetríme problém, nájdeme PR, ktoré spôsobuje chyby, vrátime ho späť, dôkladne analyzujeme a vytvoríme novú zostavu. Je pravda, že niekedy problém zostane nepovšimnutý, kým sa projekt nedostane do výroby. V takejto situácii je najdôležitejšie obnoviť službu. Preto skôr, ako začneme problém skúmať, okamžite sa vrátime späť k predchádzajúcej funkčnej zostave.
Stavebné bloky systému nasadenia
Pozrime sa na technológie, ktoré sú základom nášho systému nasadzovania projektov.
▍Rýchle nasadenie
Vyššie opísaný pracovný postup sa môže pri spätnom pohľade zdať akosi samozrejmý. Ale náš systém nasadenia sa tak nestal hneď.
Keď bola spoločnosť oveľa menšia, celá naša aplikácia mohla bežať na 10 inštanciách Amazon EC2. Nasadenie projektu v tejto situácii znamenalo použitie rsync na rýchlu synchronizáciu všetkých serverov. Predtým bol nový kód len jeden krok od výroby, reprezentovanej prípravným prostredím. Zostavy boli vytvorené a testované v takomto prostredí a potom išli priamo do výroby. Porozumieť takémuto systému bolo veľmi jednoduché, umožnilo to každému programátorovi kedykoľvek nasadiť kód, ktorý napísal.
Ako však rástol počet našich klientov, rástol aj rozsah infraštruktúry potrebnej na podporu projektu. Čoskoro, vzhľadom na neustály rast systému, náš model nasadenia, založený na posúvaní nového kódu na servery, už neplnil svoju úlohu. Konkrétne pridanie každého nového servera znamenalo zvýšenie času potrebného na dokončenie nasadenia. Aj stratégie založené na paralelnom používaní rsync majú určité obmedzenia.
Nakoniec sme tento problém vyriešili prechodom na úplne paralelný systém nasadenia, ktorý bol navrhnutý inak ako starý systém. Totiž, teraz sme neposielali kód na servery pomocou synchronizačného skriptu. Teraz každý server nezávisle stiahol novú zostavu s vedomím, že to musí urobiť monitorovaním zmeny kľúča konzula. Servery načítali kód paralelne. To nám umožnilo udržať vysokú rýchlosť nasadenia aj v prostredí neustáleho rastu systému.
1. Produkčné servery monitorujú kľúč Consul. 2. Kľúčové zmeny, to povie serverom, že musia začať sťahovať nový kód. 3. Servery sťahujú súbory tarball s kódom aplikácie
▍Nasadenie atómov
Ďalším riešením, ktoré nám pomohlo dosiahnuť viacvrstvový systém nasadenia, bolo atómové nasadenie.
Pred použitím atómových nasadení môže každé nasadenie viesť k veľkému počtu chybových hlásení. Faktom je, že proces kopírovania nových súborov na produkčné servery nebol atómový. To malo za následok krátke časové okno, v ktorom bol kód, ktorý volal nové funkcie, dostupný skôr, ako boli dostupné funkcie samotné. Keď bol takýto kód zavolaný, viedlo to k vráteniu interných chýb. To sa prejavilo neúspešnými požiadavkami API a nefunkčnými webovými stránkami.
Tím, ktorý na tomto probléme pracoval, ho vyriešil zavedením konceptu „horúcich“ a „studených“ adresárov. Kód v horúcom adresári je zodpovedný za spracovanie produkčnej prevádzky. A v „studených“ adresároch sa kód, kým je systém spustený, iba pripravuje na použitie. Počas nasadenia sa nový kód skopíruje do nepoužívaného studeného adresára. Potom, keď na serveri nie sú žiadne aktívne procesy, vykoná sa okamžité prepnutie adresára.
1. Rozbaľte aplikačný kód do „studeného“ adresára. 2. Prepnutie systému do „studeného“ adresára, ktorý sa stáva „horúcim“ (atómová operácia)
Výsledky: posun dôrazu na spoľahlivosť
V roku 2018 sa projekt rozrástol do takej miery, že veľmi rýchle nasadenie začalo škodiť stabilite produktu. Mali sme veľmi pokročilý systém nasadenia, do ktorého sme investovali veľa času a úsilia. Všetko, čo sme potrebovali, bolo prebudovať a zlepšiť naše procesy nasadenia. Vyrástli sme na pomerne veľkú spoločnosť, ktorej vývoj sa využíva na celom svete na organizovanie neprerušovanej komunikácie a riešenie dôležitých problémov. Spoľahlivosť sa preto stala stredobodom našej pozornosti.
Potrebovali sme, aby bol proces nasadzovania nových verzií Slack bezpečnejší. Táto potreba nás viedla k zlepšeniu nášho systému nasadenia. V skutočnosti sme o tomto vylepšenom systéme diskutovali vyššie. V hĺbke systému naďalej používame technológie rýchleho a atómového nasadenia. Spôsob nasadenia sa zmenil. Náš nový systém je navrhnutý tak, aby postupne nasadzoval nový kód na rôznych úrovniach, v rôznych prostrediach. Teraz používame pokročilejšie nástroje podpory a nástroje na monitorovanie systému ako predtým. To nám dáva možnosť zachytiť a opraviť chyby dlho predtým, ako sa dostanú ku koncovému používateľovi.
Ale nezastavíme sa pri tom. Tento systém neustále vylepšujeme, využívame pokročilejšie pomocné nástroje a nástroje na automatizáciu práce.
Vážení čitatelia! Ako funguje proces nasadzovania nových vydaní projektu tam, kde pracujete?
Zdroj: hab.com