Praktiky DevOps fungují. Sami jsme se o tom přesvědčili, když jsme zkrátili dobu instalace vydání 10krát. V systému FIS Profile, který používáme ve VTB, nyní instalace trvá 90 minut namísto 10. Doba sestavení vydání se zkrátila ze dvou týdnů na dva dny. Počet přetrvávajících implementačních defektů klesl téměř na minimum. Abychom se dostali od „ruční práce“ a odstranili závislost na prodejci, museli jsme pracovat s berličkami a nacházet neočekávaná řešení. Pod střihem je podrobný příběh o tom, jak jsme vybudovali plnohodnotný interní vývoj.
Prolog: DevOps je filozofie
Za poslední rok jsme udělali hodně práce na organizaci interního vývoje a implementace postupů DevOps ve VTB:
- Vybudovali jsme interní vývojové procesy pro 12 systémů;
- Spustili jsme 15 potrubí, z nichž čtyři byly uvedeny do výroby;
- Automatizovaných 1445 testovacích scénářů;
- Úspěšně jsme implementovali řadu verzí připravených interními týmy.
Jednou z nejobtížnějších na organizaci vlastního vývoje a implementace postupů DevSecOps se ukázal být systém FIS Profile - maloobchodní produktový procesor na nerelačním DBMS. Přesto jsme byli schopni vybudovat vývoj, spustit pipeline, nainstalovat jednotlivé nevydané balíčky na produkt a naučit se sestavovat vydání. Úkol to nebyl snadný, ale zajímavý a bez zjevných omezení při implementaci: zde je systém - potřebujete vybudovat vlastní vývoj. Jedinou podmínkou je použití CD před produktivním prostředím.
Zpočátku se implementační algoritmus zdál jednoduchý a jasný:
- Rozvíjíme počáteční odborné znalosti a dosahujeme přijatelné úrovně kvality od kódového týmu bez hrubých vad;
- Co nejvíce se integrujeme do stávajících procesů;
- Abychom přenesli kód mezi zřejmými fázemi, přeřízneme potrubí a jeden z jeho konců zatlačíme do pokračování.
Během této doby musí vývojový tým požadované velikosti rozvíjet dovednosti a zvýšit podíl svého příspěvku na vydání na přijatelnou úroveň. A to je vše, můžeme považovat úkol za splněný.
Zdálo by se, že jde o zcela energeticky efektivní cestu k požadovanému výsledku: zde je DevOps, zde výkonnostní metriky týmu, zde nashromážděné odborné znalosti... V praxi jsme ale získali další potvrzení, že DevOps je stále o filozofii a nikoli „připojený k procesu gitlab, ansible, nexus a dále v seznamu“.
Po opětovné analýze akčního plánu jsme si uvědomili, že v sobě budujeme jakýsi outsourcingový prodejce. Proto byl k výše popsanému algoritmu přidán procesní reengineering a také rozvoj odborných znalostí podél celé cesty vývoje, aby bylo dosaženo vedoucí role v tomto procesu. Není to nejjednodušší možnost, ale toto je cesta ideologicky správného vývoje.
Kde začíná vlastní vývoj?
Nebyl to zrovna nejpřívětivější systém pro práci. Architektonicky se jednalo o jeden velký nerelační DBMS, skládal se z mnoha samostatných spustitelných objektů (skriptů, procedur, dávek atd.), které byly volány podle potřeby, a fungoval na principu černé skříňky: přijímá požadavek a vydává odpověď. Mezi další obtíže, které stojí za zmínku, patří:
- exotický jazyk (MUMPS);
- Rozhraní konzoly;
- Nedostatek integrace s oblíbenými automatizačními nástroji a frameworky;
- Objem dat v desítkách terabajtů;
- zatížení přes 2 miliony operací za hodinu;
- Význam - Business-Critical.
Zároveň na naší straně neexistovalo žádné úložiště zdrojového kódu. Vůbec. Dokumentace existovala, ale všechny klíčové znalosti a kompetence byly na straně externí organizace.
Vývoj systému jsme začali zvládat téměř od nuly, s ohledem na jeho vlastnosti a nízkou distribuci. Zahájeno v říjnu 2018:
- Studoval dokumentaci a základy generování kódu;
- Prostudovali jsme krátký kurz o vývoji, který jsme dostali od dodavatele;
- Zvládnuté počáteční rozvojové dovednosti;
- Sestavili jsme tréninkový manuál pro nové členy týmu;
- Dohodli jsme se, že tým zahrneme do „bojového“ režimu;
- Vyřešen problém s kontrolou kvality kódu;
- Uspořádali jsme stánek pro rozvoj.
Strávili jsme tři měsíce rozvojem odborných znalostí a ponořením se do systému a od začátku roku 2019 zahájil interní vývoj svůj pohyb směrem ke světlé budoucnosti, někdy obtížně, ale sebevědomě a cíleně.
Migrace úložiště a autotesty
První úlohou DevOps je úložiště. Rychle jsme se dohodli na poskytnutí přístupu, ale bylo nutné provést migraci ze současného SVN s jednou kmenovou větví na náš cílový Git s přechodem na model několika větví a vývojem Git Flow. Máme také 2 týmy s vlastní infrastrukturou a část týmu dodavatele v zahraničí. Musel jsem žít se dvěma Gity a zajistit synchronizaci. V takové situaci to bylo menší ze dvou zel.
Migrace úložiště byla opakovaně odkládána, dokončena byla až v dubnu za pomoci kolegů z první linie. S Git Flow jsme se rozhodli pro začátek věci zjednodušit a rozhodli jsme se pro klasické schéma s opravou hotfix, vývojem a vydáním. Rozhodli se opustit mistra (aka prod-like). Níže si vysvětlíme, proč se pro nás tato možnost ukázala jako optimální. Jako pracovník byl použit externí repozitář patřící dodavateli, společný pro dva týmy. Synchronizoval se s interním úložištěm podle plánu. Nyní s Git a Gitlab bylo možné automatizovat procesy.
Problematika autotestů byla vyřešena překvapivě snadno – byl nám poskytnut již hotový framework. S přihlédnutím ke zvláštnostem systému bylo volání samostatné operace srozumitelnou součástí obchodního procesu a zároveň sloužilo jako unit test. Zbývalo jen připravit testovací data a nastavit požadované pořadí volání skriptů a vyhodnocování výsledků. S vyplňováním seznamu scénářů sestaveného na základě provozních statistik, kritičnosti procesů a stávající regresní metodiky se začaly objevovat automatické testy. Nyní bychom mohli začít stavět potrubí.
Jak to bylo: model před automatizací
Stávající model procesu implementace je samostatný příběh. Každá modifikace byla ručně přenesena jako samostatný přírůstkový instalační balíček. Dále přišla ruční registrace v Jira a ruční instalace na prostředí. U jednotlivých balíčků vše vypadalo jasně, ale s přípravou vydání to bylo složitější.
Montáž probíhala na úrovni jednotlivých dodávek, které byly samostatnými objekty. Jakákoli změna je nová dodávka. Mimo jiné bylo přidáno 60–70 technických verzí k 10–15 balíčkům složení hlavního vydání – verze získané přidáním nebo vyloučením něčeho z vydání a odrážející změny v prodeji mimo vydání.
Objekty v rámci dodávek se navzájem překrývaly, zejména ve spustitelném kódu, který byl z méně než poloviny unikátní. Existovalo mnoho závislostí jak na již nainstalovaném kódu, tak na tom, jehož instalace byla právě plánována.
Pro získání požadované verze kódu bylo nutné striktně dodržet instalační pořadí, při kterém byly objekty mnohokrát fyzicky přepisovány, zhruba 10–12krát.
Po instalaci dávky balíčků jsem musel ručně postupovat podle pokynů k inicializaci nastavení. Vydání bylo sestaveno a nainstalováno dodavatelem. Složení vydání bylo vyjasněno téměř před okamžikem implementace, což znamenalo vytvoření „oddělovacích“ balíčků. V důsledku toho se významná část dodávek přesunula z vydání do vydání s vlastním koncem „odpojení“.
Nyní je jasné, že s tímto přístupem – sestavením skládačky vydání na úrovni balíčku – neměla jediná hlavní větev žádný praktický význam. Instalace do výroby trvala od jedné a půl do dvou hodin ruční práce. Je dobré, že alespoň na úrovni instalátoru bylo specifikováno pořadí zpracování objektů: pole a struktury byly zadány před daty pro ně a procedurami. To však fungovalo pouze v rámci samostatného balíčku.
Logickým vyústěním tohoto přístupu byly obligátní instalační vady v podobě křivých verzí objektů, zbytečného kódu, chybějících instrukcí a nezapočítávaných vzájemných vlivů objektů, které byly po vydání horečně odstraňovány.
První aktualizace: potvrzení montáže a dodání
Automatizace začala přenosem kódu potrubím po této trase:
- Vyzvedněte si hotovou dodávku ze skladu;
- Nainstalujte jej do vyhrazeného prostředí;
- Spustit autotesty;
- Vyhodnoťte výsledek instalace;
- Zavolejte následující kanál na straně testovacího příkazu.
Další kanál by měl zaregistrovat úlohu v Jira a čekat na distribuci příkazů do vybraných testovacích smyček, které závisí na načasování implementace úlohy. Spoušť - dopis o připravenosti k doručení na danou adresu. To byla samozřejmě jasná berlička, ale někde jsem začít musel. V květnu 2019 začal přenos kódu kontrolami našich prostředí. Proces začal, zbývá jen uvést jej do slušného stavu:
- Každá modifikace se provádí v samostatné větvi, která odpovídá instalačnímu balíčku a sloučí se do cílové hlavní větve;
- Spouštěcím mechanismem pro spuštění kanálu je objevení se nového odevzdání v hlavní větvi prostřednictvím žádosti o sloučení, které je uzavřeno správci z interního týmu;
- Úložiště se synchronizují jednou za pět minut;
- Spustí se montáž instalačního balíčku – pomocí assembleru obdrženého od dodavatele.
Poté již existovaly kroky ke kontrole a přenosu kódu, spuštění potrubí a montáži na naší straně.
Tato možnost byla spuštěna v červenci. Obtíže přechodu vedly k určité nespokojenosti mezi dodavatelem a přední linií, ale během příštího měsíce se nám podařilo odstranit všechny hrubky a zavést mezi týmy proces. Nyní máme montáž formou odevzdání a dodání.
V srpnu se nám podařilo dokončit první instalaci samostatného balíčku na produkci pomocí našeho pipeline a od září byly bez výjimky všechny instalace jednotlivých nevydaných balíčků prováděny přes náš CD nástroj. Navíc se nám podařilo dosáhnout podílu vnitropodnikových úkolů ve 40 % složení release s menším týmem než je dodavatel – to je jednoznačný úspěch. Zůstal nejvážnější úkol - sestavit a nainstalovat vydání.
Konečné řešení: kumulativní instalační balíčky
Dokonale jsme pochopili, že skriptování pokynů dodavatele je tak velká automatizace; museli jsme přehodnotit samotný proces. Řešení bylo nasnadě – shromáždit kumulativní zásobu z release větve se všemi objekty požadovaných verzí.
Začali jsme s proof of concept: ručně jsme sestavili balíček vydání podle obsahu minulé implementace a nainstalovali jej do našich prostředí. Vše klaplo, koncept se ukázal jako životaschopný. Dále jsme vyřešili problém se skriptováním inicializačních nastavení a jejich zahrnutím do odevzdání. V rámci aktualizace kontur jsme připravili nový balíček a otestovali jej v testovacích prostředích. Instalace se povedla, i když s širokým spektrem připomínek realizačního týmu. Ale hlavní věc je, že jsme dostali povolení k uvedení do výroby v listopadovém vydání s naší montáží.
Zbývalo něco málo přes měsíc a ručně sbírané zásoby jasně napovídaly, že čas se krátí. Rozhodli se vytvořit sestavení z větve vydání, ale proč by mělo být odděleno? Nemáme podobný Prod a stávající pobočky nejsou dobré – je tam spousta zbytečného kódu. Naléhavě potřebujeme omezit prod-likes, a to je přes tři tisíce commitů. Ruční montáž není vůbec možná. Načrtli jsme skript, který prochází protokolem instalace produktu a shromažďuje potvrzení do větve. Napotřetí to fungovalo správně a po „dokončení se souborem“ byla větev připravena.
Napsali jsme vlastní builder pro instalační balíček a dokončili ho za týden. Poté jsme museli upravit instalační program ze základní funkce systému, protože je open-source. Po řadě kontrol a úprav byl výsledek považován za úspěšný. Mezitím se vyprofilovala skladba releasu, pro jejíž správnou instalaci bylo nutné sladit testovací okruh s produkčním a byl k tomu napsán samostatný scénář.
Přirozeně se objevilo mnoho připomínek k první instalaci, ale celkově kód fungoval. A asi po třetí instalaci začalo vše vypadat dobře. Kontrola kompozice a kontrola verzí objektů byla sledována samostatně v manuálním režimu, což bylo v této fázi zcela oprávněné.
Další výzvou byl velký počet nevydaných dokumentů, které bylo třeba vzít v úvahu. Ale s větví podobnou Prod a Rebase se úkol stal transparentním.
Poprvé, rychle a bez chyb
K vydání jsme přistoupili s optimistickým přístupem a více než tuctem úspěšných instalací na různých okruzích. Ale doslova den před termínem se ukázalo, že prodejce nedokončil práci na přípravě vydání k instalaci přijatým způsobem. Pokud z nějakého důvodu naše sestavení nefunguje, bude vydání přerušeno. Navíc naším úsilím, což je obzvlášť nepříjemné. Neměli jsme jak ustoupit. Proto jsme promysleli alternativní možnosti, připravili akční plány a zahájili instalaci.
Překvapivě celé vydání skládající se z více než 800 objektů začalo správně, napoprvé a za pouhých 10 minut. Strávili jsme hodinu kontrolou protokolů hledáním chyb, ale žádné jsme nenašli.
Celý další den bylo v chatu o vydání ticho: žádné problémy s implementací, křivé verze nebo „nevhodný“ kód. Bylo to dokonce tak nějak trapné. Později se nějaké připomínky objevily, ale ve srovnání s jinými systémy a předchozími zkušenostmi byl jejich počet a priorita znatelně nižší.
Dodatečným efektem kumulativního efektu bylo zvýšení kvality montáže a testování. Kvůli vícenásobným instalacím plné verze byly chyby sestavení a chyby při nasazení identifikovány včas. Testování v konfiguracích plné verze umožnilo dodatečně identifikovat závady ve vzájemném ovlivňování objektů, které se neobjevily při inkrementálních instalacích. Byl to rozhodně úspěch, zvláště s ohledem na náš 57% podíl na vydání.
Shrnutí a závěry
Za necelý rok se nám podařilo:
- Vybudujte si plnohodnotný vnitřní rozvoj pomocí exotického systému;
- Eliminujte kritickou závislost na dodavateli;
- Spusťte CI/CD pro velmi nepřátelské dědictví;
- Pozvednout implementační procesy na novou technickou úroveň;
- Výrazně zkrátit dobu nasazení;
- Výrazně snížit počet chyb při implementaci;
- S důvěrou se prohlašujte za předního odborníka na vývoj.
Samozřejmě, že mnoho z toho, co je popsáno, vypadá jako úplná kravina, ale toto jsou vlastnosti systému a omezení procesů, která v něm existují. V tuto chvíli se změny dotkly produktů a služeb IS Profile (master účty, plastové karty, spořicí účty, úschova, hotovostní úvěry), ale potenciálně lze tento přístup aplikovat na jakýkoli IS, pro který je stanoven úkol implementace postupů DevOps. Kumulativní model lze bezpečně replikovat pro následné implementace (včetně těch bez vydání) z mnoha dodávek.
Zdroj: www.habr.com