Postupy DevOps fungujú. Sami sme sa o tom presvedčili, keď sme 10-krát skrátili čas inštalácie vydania. V systéme FIS Profile, ktorý používame vo VTB, teraz inštalácia trvá 90 minút namiesto 10. Čas zostavenia vydania sa skrátil z dvoch týždňov na dva dni. Počet pretrvávajúcich chýb implementácie klesol takmer na minimum. Aby sme sa vyhli „ručnej práci“ a odstránili závislosť od dodávateľa, museli sme pracovať s barlami a nájsť neočakávané riešenia. Pod zostrihom je podrobný príbeh o tom, ako sme vybudovali plnohodnotný interný vývoj.
Prológ: DevOps je filozofia
Za posledný rok sme urobili veľa práce na organizácii interného vývoja a implementácie postupov DevOps vo VTB:
- Vybudovali sme interné vývojové procesy pre 12 systémov;
- Spustili sme 15 potrubí, z ktorých štyri boli uvedené do výroby;
- Automatizované 1445 testovacích scenárov;
- Úspešne sme implementovali množstvo vydaní pripravených internými tímami.
Jedným z najnáročnejších na organizáciu vnútropodnikového vývoja a implementácie postupov DevSecOps sa ukázal byť systém FIS Profile – maloobchodný produktový procesor na nerelačnej DBMS. Napriek tomu sme boli schopní vybudovať vývoj, spustiť pipeline, nainštalovať jednotlivé nevydané balíčky na produkt a naučiť sa zostavovať vydania. Úloha nebola jednoduchá, ale zaujímavá a bez zjavných obmedzení pri implementácii: tu je systém - musíte vybudovať vlastný vývoj. Jedinou podmienkou je použitie CD pred produktívnym prostredím.
Spočiatku sa implementačný algoritmus zdal jednoduchý a jasný:
- Rozvíjame počiatočnú odbornosť vývoja a dosahujeme prijateľnú úroveň kvality od kódového tímu bez hrubých chýb;
- Čo najviac sa integrujeme do existujúcich procesov;
- Na prenos kódu medzi zrejmými fázami prerežeme potrubie a jeden z jeho koncov zatlačíme do pokračovania.
Počas tejto doby musí vývojový tím požadovanej veľkosti rozvíjať zručnosti a zvýšiť podiel svojho príspevku na vydaniach na prijateľnú úroveň. A to je všetko, môžeme považovať úlohu za splnenú.
Zdalo by sa, že toto je úplne energeticky efektívna cesta k požadovanému výsledku: tu je DevOps, tu sú metriky výkonnosti tímu, tu sú nahromadené odborné znalosti... V praxi sme však dostali ďalšie potvrdenie, že DevOps je stále o filozofii a nie „pripojené k procesu gitlab, ansible, nexus a ďalej v zozname“.
Po opätovnom zanalyzovaní akčného plánu sme si uvedomili, že v sebe budujeme akýsi outsourcingový predajca. Preto bol do algoritmu opísaného vyššie pridaný proces reengineeringu, ako aj rozvoj odborných znalostí pozdĺž celej cesty vývoja, aby sa dosiahla vedúca úloha v tomto procese. Nie je to najjednoduchšia možnosť, ale toto je cesta ideologicky správneho vývoja.
Kde začína vlastný vývoj?
Nebol to práve najpriateľskejší systém na prácu. Architektonicky to bol jeden veľký nerelačný DBMS, pozostával z mnohých samostatných spustiteľných objektov (skriptov, procedúr, dávok atď.), ktoré sa volali podľa potreby a fungoval na princípe čiernej skrinky: prijíma požiadavku a vydáva odozva. Medzi ďalšie ťažkosti, ktoré stojí za zmienku, patria:
- exotický jazyk (MUMPS);
- Rozhranie konzoly;
- Nedostatok integrácie s populárnymi automatizačnými nástrojmi a rámcami;
- Objem dát v desiatkach terabajtov;
- Zaťaženie viac ako 2 milióny operácií za hodinu;
- Význam - Obchodný kritický.
Zároveň na našej strane neexistovalo žiadne úložisko zdrojového kódu. Vôbec. Dokumentácia existovala, ale všetky kľúčové znalosti a kompetencie boli na strane externej organizácie.
Vývoj systému sme začali zvládať takmer od nuly, berúc do úvahy jeho vlastnosti a nízku distribúciu. Začiatok v októbri 2018:
- Študoval dokumentáciu a základy generovania kódu;
- Študovali sme krátky kurz o vývoji, ktorý sme dostali od predajcu;
- Zvládnuté počiatočné rozvojové zručnosti;
- Zostavili sme tréningový manuál pre nových členov tímu;
- Súhlasili sme so zapojením tímu do „bojového“ režimu;
- Vyriešený problém s kontrolou kvality kódu;
- Zorganizovali sme stánok pre rozvoj.
Strávili sme tri mesiace rozvíjaním odborných znalostí a ponorením sa do systému a od začiatku roka 2019 začal interný vývoj smerovať k svetlej budúcnosti, niekedy s ťažkosťami, ale sebavedomo a cieľavedome.
Migrácia úložiska a automatické testy
Prvou úlohou DevOps je úložisko. Rýchlo sme sa dohodli na poskytnutí prístupu, no bolo potrebné migrovať zo súčasného SVN s jednou kmeňovou vetvou na náš cieľový Git s prechodom na model viacerých vetiev a vývojom Git Flow. Máme tiež 2 tímy s vlastnou infraštruktúrou a časť tímu dodávateľa v zahraničí. Musel som žiť s dvoma Gitmi a zabezpečiť synchronizáciu. V takejto situácii to bolo menšie z dvoch ziel.
Migrácia úložiska bola opakovane odkladaná, dokončená bola až v apríli za pomoci kolegov z prvej línie. S Git Flow sme sa rozhodli urobiť veci na začiatok jednoduchými a rozhodli sme sa pre klasickú schému s rýchlou opravou, vývojom a vydaním. Rozhodli sa opustiť majstra (aka prod-like). Nižšie si vysvetlíme, prečo sa nám táto možnosť ukázala ako optimálna. Ako pracovník bol použitý externý repozitár patriaci predajcovi, spoločný pre dva tímy. Synchronizovalo sa s interným úložiskom podľa plánu. Teraz s Git a Gitlab bolo možné automatizovať procesy.
Otázka autotestov bola vyriešená prekvapivo jednoducho - dostali sme hotový framework. S prihliadnutím na osobitosti systému bolo volanie samostatnej operácie pochopiteľnou súčasťou obchodného procesu a zároveň slúžilo ako unit test. Ostávalo už len pripraviť testovacie dáta a nastaviť požadované poradie volania skriptov a vyhodnocovania výsledkov. Keď sa naplnil zoznam scenárov vytvorený na základe prevádzkových štatistík, kritickosti procesov a existujúcej regresnej metodológie, začali sa objavovať automatické testy. Teraz by sme mohli začať stavať plynovod.
Ako to bolo: model pred automatizáciou
Existujúci model procesu implementácie je samostatný príbeh. Každá modifikácia bola manuálne prenesená ako samostatný prírastkový inštalačný balík. Nasledovala manuálna registrácia v Jira a manuálna inštalácia na prostrediach. Pri jednotlivých balíkoch vyzeralo všetko prehľadne, no s prípravou vydania to bolo komplikovanejšie.
Montáž prebiehala na úrovni jednotlivých dodávok, ktoré boli samostatnými objektmi. Akákoľvek zmena je nová dodávka. Okrem iného bolo k 60 – 70 balíkom hlavného zloženia vydania pridaných 10 – 15 technických verzií – verzie získané pri pridávaní alebo vylúčení niečoho z vydania a odrážajúcich zmeny v predaji mimo vydaní.
Objekty v rámci dodávok sa navzájom prekrývali, najmä v spustiteľnom kóde, ktorý bol unikátny menej ako z polovice. Existovalo veľa závislostí na už nainštalovanom kóde aj na tom, ktorého inštalácia bola práve plánovaná.
Pre získanie potrebnej verzie kódu bolo nutné striktne dodržať inštalačný poriadok, počas ktorého sa objekty mnohokrát fyzicky prepisovali, asi 10-12-krát.
Po inštalácii dávky balíkov som musel manuálne postupovať podľa pokynov na inicializáciu nastavení. Vydanie zostavil a nainštaloval predajca. Zloženie vydania bolo objasnené takmer pred momentom implementácie, čo znamenalo vytvorenie „oddeľovacích“ balíkov. V dôsledku toho sa značná časť dodávok presunula z vydania na vydanie s vlastným chvostom „odpojení“.
Teraz je jasné, že s týmto prístupom - zostavením puzzle vydania na úrovni balíka - jediná hlavná vetva nemala žiadny praktický význam. Inštalácia do výroby trvala jeden a pol až dve hodiny ručnej práce. Je dobré, že aspoň na úrovni inštalátora bolo špecifikované poradie spracovania objektu: polia a štruktúry boli zadané pred údajmi pre ne a procedúrami. To však fungovalo len v rámci samostatného balíka.
Logickým výsledkom tohto prístupu boli povinné inštalačné chyby v podobe pokrivených verzií objektov, zbytočného kódu, chýbajúcich inštrukcií a nezohľadnených vzájomných vplyvov objektov, ktoré boli po vydaní horúčkovito odstraňované.
Prvé aktualizácie: odovzdajte montáž a dodávku
Automatizácia začala prenosom kódu cez potrubie pozdĺž tejto trasy:
- Vyzdvihnutie hotovej dodávky zo skladu;
- Nainštalujte ho do vyhradeného prostredia;
- spustiť autotesty;
- Vyhodnoťte výsledok inštalácie;
- Zavolajte nasledujúci kanál na strane testovacieho príkazu.
Ďalší kanál by mal zaregistrovať úlohu v Jira a čakať na distribúciu príkazov do vybraných testovacích cyklov, ktoré závisia od načasovania implementácie úlohy. Trigger - list o pripravenosti na doručenie na danú adresu. To bola, samozrejme, jasná barlička, ale niekde som začať musel. V máji 2019 sa prenos kódu začal kontrolami našich prostredí. Proces sa začal, zostáva len uviesť ho do slušného stavu:
- Každá modifikácia sa vykonáva v samostatnej vetve, ktorá zodpovedá inštalačnému balíku a zlúči sa do cieľovej hlavnej vetvy;
- Spúšťač spustenia potrubia je objavenie sa nového odovzdania v hlavnej vetve prostredníctvom žiadosti o zlúčenie, ktorú zatvoria správcovia z interného tímu;
- Repozitáre sa synchronizujú raz za päť minút;
- Spustí sa montáž inštalačného balíka – pomocou assembleru, ktorý dostanete od predajcu.
Potom už existovali kroky na kontrolu a prenos kódu, spustenie potrubia a montáž na našej strane.
Táto možnosť bola spustená v júli. Ťažkosti s prechodom vyústili do určitej nespokojnosti medzi predajcom a prednou líniou, ale v priebehu nasledujúceho mesiaca sa nám podarilo odstrániť všetky drsné hrany a zaviesť postup medzi tímami. Teraz máme montáž na objednávku a dodávku.
V auguste sa nám podarilo dokončiť prvú inštaláciu samostatného balíka na produkcii pomocou nášho pipeline a od septembra sa bez výnimky všetky inštalácie jednotlivých nevydaných balíkov vykonávali cez náš CD nástroj. Okrem toho sa nám podarilo dosiahnuť podiel interných úloh na 40% zloženia vydania s menším tímom ako dodávateľ – to je jednoznačný úspech. Zostala najvážnejšia úloha - zostaviť a nainštalovať vydanie.
Konečné riešenie: kumulatívne inštalačné balíky
Dobre sme pochopili, že skriptovanie pokynov dodávateľa je taká automatizácia; museli sme prehodnotiť samotný proces. Riešenie bolo zrejmé - zhromaždiť kumulatívnu zásobu z release vetvy so všetkými objektmi požadovaných verzií.
Začali sme s proof of concept: ručne sme zostavili balík vydania podľa obsahu minulej implementácie a nainštalovali sme ho do našich prostredí. Všetko vyšlo, koncept sa ukázal ako životaschopný. Ďalej sme vyriešili problém so skriptovaním inicializačných nastavení a ich zahrnutím do odovzdania. V rámci aktualizácie kontúry sme pripravili nový balík a otestovali ho v testovacích prostrediach. Inštalácia sa podarila, aj keď so širokým spektrom pripomienok realizačného tímu. Ale hlavná vec je, že sme dostali povolenie spustiť výrobu v novembrovom vydaní s našou zostavou.
Zostávalo niečo vyše mesiaca a ručne vyberané zásoby jasne naznačovali, že čas sa kráti. Rozhodli sa vytvoriť zostavu z vetvy vydania, ale prečo by mala byť oddelená? Nemáme Prod-like a existujúce pobočky nie sú dobré – je tu veľa zbytočného kódu. Naliehavo potrebujeme znížiť prod-likes, a to je viac ako tri tisíce záväzkov. Ručná montáž nie je vôbec možná. Načrtli sme skript, ktorý prechádza protokolom inštalácie produktu a zhromažďuje odovzdania do pobočky. Tretíkrát to fungovalo správne a po „dokončení so súborom“ bola vetva pripravená.
Pre inštalačný balík sme napísali vlastný builder a dokončili ho za týždeň. Potom sme museli upraviť inštalačný program zo základnej funkcionality systému, keďže ide o open-source. Po sérii kontrol a úprav bol výsledok považovaný za úspešný. Medzitým sa formovalo zloženie vydania, pre správnu inštaláciu bolo potrebné zosúladiť testovací okruh s produkčným a bol na to napísaný samostatný scenár.
Prirodzene, k prvej inštalácii bolo veľa pripomienok, ale celkovo kód fungoval. A asi po tretej inštalácii všetko začalo vyzerať dobre. Kontrola zloženia a kontrola verzií objektov boli monitorované oddelene v manuálnom režime, čo bolo v tejto fáze celkom opodstatnené.
Ďalšou výzvou bol veľký počet neuverejnených, ktoré bolo potrebné vziať do úvahy. Ale s vetvou podobnou Prod a Rebase sa úloha stala transparentnou.
Prvýkrát, rýchlo a bez chýb
K vydaniu sme pristúpili s optimistickým prístupom a viac ako tuctom úspešných inštalácií na rôznych okruhoch. Ale doslova deň pred termínom sa ukázalo, že predajca nedokončil prácu na príprave vydania na inštaláciu akceptovaným spôsobom. Ak z nejakého dôvodu naša zostava nefunguje, vydanie sa preruší. Navyše našou snahou, čo je obzvlášť nepríjemné. Nemali sme ako ustúpiť. Preto sme premysleli alternatívne možnosti, pripravili akčné plány a začali s montážou.
Prekvapivo, celé vydanie, pozostávajúce z viac ako 800 objektov, začalo správne, na prvýkrát a len za 10 minút. Strávili sme hodinu kontrolou denníkov hľadaním chýb, ale žiadne sme nenašli.
Celý nasledujúci deň bolo v diskusnom rozhovore ticho: žiadne problémy s implementáciou, skreslené verzie alebo „nevhodný“ kód. Dokonca to bolo akosi nepríjemné. Neskôr sa objavili nejaké pripomienky, no v porovnaní s inými systémami a predchádzajúcimi skúsenosťami bol ich počet a priorita citeľne nižšia.
Dodatočným efektom kumulatívneho efektu bolo zvýšenie kvality montáže a testovania. Kvôli viacerým inštaláciám úplného vydania boli chyby zostavenia a chyby nasadenia identifikované včas. Testovanie v konfiguráciách s úplným vydaním umožnilo dodatočne identifikovať chyby vo vzájomnom ovplyvňovaní objektov, ktoré sa neobjavili pri postupných inštaláciách. Bol to určite úspech, najmä vzhľadom na náš 57% podiel na vydaní.
Výsledky a závery
Za necelý rok sa nám podarilo:
- Vybudujte si plnohodnotný vnútorný rozvoj pomocou exotického systému;
- Odstráňte kritickú závislosť od dodávateľa;
- Spustite CI/CD pre veľmi nepriateľské dedičstvo;
- Pozdvihnúť implementačné procesy na novú technickú úroveň;
- Výrazne skrátiť čas nasadenia;
- Výrazne znížiť počet chýb pri implementácii;
- S dôverou sa vyhlasujte za popredného odborníka na vývoj.
Samozrejme, veľa z toho, čo je opísané, vyzerá ako úplná kravina, ale toto sú vlastnosti systému a obmedzenia procesov, ktoré v ňom existujú. Zmeny sa v súčasnosti dotkli produktov a služieb Profil IS (hlavné účty, plastové karty, sporiace účty, escrow, hotovostné úvery), ale potenciálne je možné tento prístup aplikovať na akýkoľvek IS, pre ktorý je stanovená úloha implementácie postupov DevOps. Kumulatívny model možno bezpečne replikovať pre následné implementácie (vrátane tých, ktoré nie sú vydané) z mnohých dodávok.
Zdroj: hab.com