Uvedení nového vydání projektu do produkce vyžaduje pečlivou rovnováhu mezi rychlostí nasazení a spolehlivostí řešení. Slack hodnoty rychlé iterace, krátké cykly zpětné vazby a rychlé reakce na požadavky uživatelů. Kromě toho má společnost stovky programátorů, kteří se snaží být co nejproduktivnější.
Autoři materiálu, jehož překlad dnes zveřejňujeme, říkají, že společnost, která se snaží takové hodnoty dodržovat a zároveň roste, musí neustále zlepšovat systém nasazení projektů. Společnost musí investovat do transparentnosti a spolehlivosti pracovních procesů, aby zajistila, že tyto procesy budou odpovídat rozsahu projektu. Zde budeme hovořit o pracovních postupech, které se vyvinuly ve Slacku, a o některých rozhodnutích, která vedla společnost k použití systému zavádění projektů, který dnes existuje.
Jak dnes fungují procesy nasazení projektu
Každý PR (pull request) ve Slacku musí projít kontrolou kódu a musí úspěšně projít všemi testy. Teprve po splnění těchto podmínek může programátor začlenit svůj kód do hlavní větve projektu. Tento kód je však nasazen pouze během pracovní doby, severoamerického času. Díky tomu, že naši zaměstnanci jsou na svých pracovištích, jsme plně připraveni řešit případné nečekané problémy.
Každý den provádíme cca 12 plánovaných nasazení. Během každého nasazení je programátor určený jako vedoucí nasazení zodpovědný za uvedení nového sestavení do produkce. Jedná se o vícestupňový proces, který zajišťuje hladké uvedení sestavy do výroby. Díky tomuto přístupu dokážeme odhalit chyby dříve, než postihnou všechny naše uživatele. Pokud je chyb příliš mnoho, lze nasazení sestavy vrátit zpět. Pokud je po vydání objeven konkrétní problém, lze pro něj snadno vydat opravu.
Rozhraní systému Checkpoint, které se ve Slacku používá k nasazování projektů
Proces nasazení nového vydání do produkce lze považovat za sestávající ze čtyř kroků.
▍1. Vytvoření větve vydání
Každé vydání začíná novou větví vydání, bodem v naší historii Git. To vám umožňuje přiřadit štítky k vydání a poskytuje místo, kde můžete provádět živé opravy chyb nalezených v procesu přípravy vydání pro vydání do produkce.
▍2. Nasazení ve stagingovém prostředí
Dalším krokem je nasazení sestavení na pracovní servery a spuštění automatického testu celkového výkonu projektu (kouřový test). Pracovní prostředí je produkční prostředí, které nepřijímá externí provoz. V tomto prostředí provádíme dodatečné ruční testování. To nám dává další jistotu, že upravený projekt funguje správně. Samotné automatické testy k zajištění této úrovně spolehlivosti nestačí.
▍3. Nasazení v testovacích a kanárských prostředích
Nasazení do produkce začíná testovacím prostředím, které představuje sada hostitelů, kteří obsluhují naše interní pracovní prostory Slack. Vzhledem k tomu, že jsme velmi aktivní uživatelé Slacku, tento přístup nám pomohl zachytit spoustu chyb v rané fázi nasazení. Poté, co jsme se ujistili, že základní funkcionalita systému není narušena, je sestava nasazena v kanárském prostředí. Představuje systémy, které tvoří přibližně 2 % produkčního provozu.
▍4. Postupné uvolňování do výroby
Pokud se ukazatele monitorování pro novou verzi ukážou jako stabilní a pokud po nasazení projektu v prostředí Kanárských ostrovů neobdržíme žádné stížnosti, pokračujeme v postupném převodu produkčních serverů na novou verzi. Proces nasazení je rozdělen do následujících fází: 10 %, 25 %, 50 %, 75 % a 100 %. Díky tomu můžeme pomalu přenášet produkční provoz do nového vydání systému. Zároveň máme čas na prošetření situace, pokud by byly zjištěny nějaké anomálie.
▍Co když se během nasazení něco pokazí?
Provádění úprav kódu je vždy riziko. S tím se ale vyrovnáváme díky přítomnosti dobře vyškolených „deployment leaderů“, kteří řídí proces uvedení nového vydání do výroby, monitorují monitorovací indikátory a koordinují práci programátorů uvolňujících kód.
V případě, že se opravdu něco pokazí, snažíme se problém odhalit co nejdříve. Prozkoumáme problém, najdeme PR, který způsobuje chyby, vrátíme jej zpět, důkladně analyzujeme a vytvoříme nové sestavení. Pravda, někdy problém zůstane nepovšimnut, dokud se projekt nedostane do výroby. V takové situaci je nejdůležitější službu obnovit. Než tedy začneme problém zkoumat, okamžitě se vrátíme k předchozímu funkčnímu sestavení.
Stavební bloky systému nasazení
Podívejme se na technologie, které jsou základem našeho systému nasazení projektu.
▍Rychlé nasazení
Výše popsaný pracovní postup se může při zpětném pohledu zdát poněkud samozřejmý. Ale náš systém nasazení se nestal tímto způsobem hned.
Když byla společnost mnohem menší, celá naše aplikace mohla běžet na 10 instancích Amazon EC2. Nasazení projektu v této situaci znamenalo použití rsync k rychlé synchronizaci všech serverů. Dříve byl nový kód jen jeden krok od výroby, reprezentovaný pracovním prostředím. V takovém prostředí byly vytvořeny a testovány sestavy a poté šly rovnou do výroby. Bylo velmi snadné takovému systému porozumět, umožňoval každému programátorovi kdykoli nasadit kód, který napsal.
Ale jak rostl počet našich klientů, rostl i rozsah infrastruktury potřebné k podpoře projektu. Vzhledem k neustálému růstu systému náš model nasazení, založený na vkládání nového kódu na servery, brzy přestal plnit svou funkci. Konkrétně přidání každého nového serveru znamenalo prodloužení doby potřebné k dokončení nasazení. I strategie založené na paralelním použití rsync mají určitá omezení.
Nakonec jsme tento problém vyřešili přechodem na zcela paralelní systém nasazení, který byl navržen jinak než starý systém. Konkrétně jsme nyní neposílali kód na servery pomocí synchronizačního skriptu. Nyní si každý server nezávisle stáhl novou sestavu, protože věděl, že to musí udělat sledováním změny klíče konzula. Servery načetly kód paralelně. To nám umožnilo udržet vysokou rychlost nasazení i v prostředí neustálého růstu systému.
1. Produkční servery monitorují klíč Consul. 2. Klíč se změní, to říká serverům, že musí začít stahovat nový kód. 3. Servery stahují soubory tarball s kódem aplikace
▍Rozmístění atomů
Dalším řešením, které nám pomohlo dosáhnout vícevrstvého systému nasazení, bylo atomové nasazení.
Před použitím atomických nasazení může každé nasazení vést k velkému počtu chybových zpráv. Faktem je, že proces kopírování nových souborů na produkční servery nebyl atomický. To mělo za následek krátké časové okno, kdy byl kód, který volal nové funkce, k dispozici dříve, než byly dostupné funkce samotné. Když byl takový kód zavolán, vedlo to k vrácení vnitřních chyb. To se projevilo neúspěšnými požadavky API a nefunkčními webovými stránkami.
Tým, který na tomto problému pracoval, jej vyřešil zavedením konceptu „horkých“ a „studených“ adresářů. Kód v horkém adresáři je zodpovědný za zpracování produkčního provozu. A v „studených“ adresářích se kód, zatímco systém běží, teprve připravuje k použití. Během nasazení je nový kód zkopírován do nepoužívaného studeného adresáře. Poté, když na serveru nejsou žádné aktivní procesy, dojde k okamžitému přepnutí adresáře.
1. Rozbalení kódu aplikace do „studeného“ adresáře. 2. Přepnutí systému do „studeného“ adresáře, který se stane „horkým“ (atomový provoz)
Výsledky: posun důrazu na spolehlivost
V roce 2018 se projekt rozrostl do takového rozsahu, že velmi rychlé nasazení začalo škodit stabilitě produktu. Měli jsme velmi pokročilý systém nasazení, do kterého jsme investovali spoustu času a úsilí. Vše, co jsme museli udělat, bylo přebudovat a zlepšit naše procesy nasazení. Vyrostli jsme v poměrně velkou společnost, jejíž vývoj se používá po celém světě k organizaci nepřetržité komunikace a řešení důležitých problémů. Spolehlivost se proto stala středem naší pozornosti.
Potřebovali jsme, aby byl proces nasazení nových verzí Slack bezpečnější. Tato potřeba nás vedla ke zlepšení našeho systému nasazení. Ve skutečnosti jsme tento vylepšený systém diskutovali výše. V hloubi systému nadále používáme technologie rychlého a atomového nasazení. Způsob nasazení se změnil. Náš nový systém je navržen tak, aby postupně nasazoval nový kód na různých úrovních, v různých prostředích. Nyní používáme pokročilejší nástroje podpory a nástroje pro monitorování systému než dříve. To nám dává možnost zachytit a opravit chyby dlouho předtím, než se dostanou ke koncovému uživateli.
Ale nezůstaneme u toho. Tento systém neustále vylepšujeme, využíváme pokročilejší pomocné nástroje a nástroje pro automatizaci práce.
Vážení čtenáři! Jak funguje proces nasazování nových verzí projektu tam, kde pracujete?
Zdroj: www.habr.com