Ako škálovať CI/CD pre stovky aplikácií bez straty autonómie

Tento článok vychádza z prednášky Ako škálovať CI/CD pre stovky aplikácií bez straty autonómie, ktorú na CODECON predstavil Tomáš Lauro z Multitude. Vo svojej prednáške ukazuje, ako sa ich CI/CD platforma počas približne šiestich rokov vyvíjala a aké rozhodnutia im pomohli dostať sa od množstva samostatných pipeline k riešeniu, ktoré dnes používajú stovky aplikácií.

CI/CD pipeline funguje pomerne jednoducho, keď ich máte niekoľko. Problém nastane, keď ich máte stovky a každý tím si ich udržiava po svojom.

V Multitude mali približne 30 tímov a 400 aplikácií, pričom väčšina z nich používala vlastnú copy-pasteovanú pipeline. Pipeline sa líšili štruktúrou, komplexitou aj výkonom. Ak bolo potrebné niečo zmeniť, vznikalo množstvo tiketov pre jednotlivé tímy a na implementáciu sa čakalo niekoľko sprintov.

Problém sa týkal aj bezpečnostných aktualizácií. Ak bolo potrebné zmeniť verziu knižnice používanej v pipeline, neexistovalo jedno miesto, kde by sa zmena dala urobiť. A rozdielne štruktúry pipeline zároveň komplikovali spoločný reporting nad aplikáciami.

Riešením preto nebolo vytvoriť ďalšiu pipeline. Potrebovali vytvoriť platformu, ktorá zjednotí spoločné časti CI/CD a zároveň ponechá tímom priestor na vlastné potreby.

Jedna štruktúra, rôzne technologické stacky

Pri stovkách aplikácií nie je problém len v tom, že každá potrebuje vlastnú pipeline. Problém nastane vo chvíli, keď sa spoločné časti začnú kopírovať medzi stovkami repozitárov. Každá zmena potom znamená upravovať množstvo pipeline, riešiť rozdiely medzi nimi a kontrolovať, či sa niekde nezabudlo na dôležitý krok.

Práve preto platforma v Multitude stojí na reusable workflows. Namiesto toho, aby si každý tím skladal celú CI/CD pipeline od začiatku, dostane spoločné stavebné bloky – napríklad pre lint, test, build, release či deployment. Tím ich môže použiť podľa svojich potrieb a zároveň si zachovať vlastnú konfiguráciu.

To je dôležitý rozdiel oproti jednej obrovskej pipeline, ktorá sa snaží pokryť každý možný prípad. Spoločná je štruktúra a opakovane použiteľná implementácia, nie každý detail konkrétnej aplikácie.

L1 a L2: čo má byť spoločné?

Tento princíp je postavený na dvoch vrstvách. L1 funguje ako orchestrátor – určuje, ktoré workflowy sa majú spustiť a v akom poradí. Neobsahuje samotnú implementáciu, skripty ani custom actions.

Tá je až v L2, kde sa jednotlivé workflowy prispôsobujú konkrétnemu technologickému stacku. Testovanie Java aplikácie totiž nebude vyzerať rovnako ako testovanie Pythonu alebo JavaScriptu. Základný proces však môže zostať rovnaký.

Výsledkom je oddelenie toho, čo sa má stať, od toho, ako sa to vykoná pre konkrétnu technológiu.

Tímy tak nemusia platformu používať iba ako jeden pevný balík. Ak potrebujú pre POC napríklad samostatné CI alebo CD, môžu použiť konkrétny reusable workflow, prispôsobiť ho svojim potrebám a prípadné zlepšenia neskôr vrátiť späť do spoločnej platformy.

Platforma poskytuje implementáciu, aplikácia konfiguráciu

Aby spoločný workflow neznamenal stratu autonómie, aplikácia doň neposiela vlastnú implementáciu, ale konfiguráciu. L2 workflowy majú definované vstupy a defaultné hodnoty, ktoré môže konkrétny repozitár podľa potreby prepísať.

Aplikačný repozitár tak obsahuje len minimum potrebné na spustenie pipeline a odkaz na spoločné workflowy. Samotná implementácia zostáva v centrálnej codebase.

To prináša praktický kompromis: platformový tím môže opraviť alebo rozšíriť spoločnú implementáciu bez toho, aby musel upravovať stovky repozitárov, zatiaľ čo jednotlivé tímy stále rozhodujú o konfigurácii svojej aplikácie.

Release a deployment bez zbytočného čakania

Pri stovkách aplikácií nestačí zjednotiť samotnú pipeline. Rovnaký prístup potrebujete aj pri release a deploymente.

Release proces preto využíva Conventional Commits a Release Please. Z typu zmeny v commit message sa automaticky určí verzia a zároveň sa pripravia release notes. Tímy tak nemusia pri každom release ručne riešiť verziu ani changelog.

Zaujímavejší problém bol deployment. Pôvodne pipeline spustila nasadenie a čakala na jeho výsledok. Po prechode do cloudu to znamenalo zbytočne obsadený a platený runner.

Riešením bol asynchrónny deployment cez GitOps. Jeden workflow aktualizuje deployment konfiguráciu a vytvorí GitHub Deployment v stave in progress. Samotné nasadenie potom prebehne v Kubernetes. Keď ho Flux dokončí, pošle notifikáciu a ďalší workflow nastaví výsledok deploymentu na success alebo failed.

Pipeline tak nemusí počas celého deployu čakať. A rovnaký callback sa dá využiť aj na ďalšie kroky, napríklad regresné alebo performance testy.

Ako udržať spoločné workflowy pod kontrolou

Keď viacero aplikácií používa rovnaké workflowy, každá zmena v spoločnej codebase môže ovplyvniť stovky repozitárov. Preto bolo dôležité vyriešiť aj verzovanie.

V L1 sa preto používa pinovanie verzie L2 workflowu. Aplikácia tak presne vie, ktorú implementáciu používa, a nová verzia platformy sa na ňu neprepíše automaticky.

Zároveň existuje mutable tag, ktorý ukazuje na najnovšiu verziu. Ten sa používa tam, kde chcete novú funkcionalitu dostať do aplikácie bez manuálnej zmeny každého repozitára.

Výsledkom je kompromis medzi stabilitou a jednoduchým rolloutom zmien. Tímy môžu zostať na konkrétnej verzii, keď potrebujú istotu, zatiaľ čo nové aplikácie alebo aktualizácie môžu používať aktuálnu verziu platformy.

Nie všetko, čo sa dá, treba skomplikovať

Pri budovaní platformy je ľahké skončiť pri riešení, ktoré je technicky flexibilné, ale v praxi príliš komplikované. Presne to sa im stalo pri jednej z prvých verzií platformy, kde podporovali viac branching modelov.

Na papieri to dávalo zmysel. V praxi však vznikla zbytočne komplikovaná codebase a tímy aj tak používali takmer vždy rovnaký flow.

Poučenie bolo jednoduché: nie každú možnosť, ktorú vieme používateľom ponúknuť, im aj poskytnúť musíme. Pri platforme pre stovky aplikácií je často dôležitejšia jednoduchosť a jasné pravidlá než maximálna konfigurovateľnosť.

Podobne sa osvedčilo otvoriť codebase platformy príspevkom od samotných tímov. Ľudia, ktorí pipeline používajú každý deň, často najlepšie vidia, čo im komplikuje prácu a čo by sa dalo zlepšiť.

Migrácie radšej automatizovať než dokumentovať

Pri platforme, ktorú používa stovky aplikácií, skôr či neskôr príde veľká zmena verzie. V Multitude ich zažili niekoľko a ukázalo sa, že najväčším problémom nie je samotná zmena, ale spôsob, akým ju dostať ku všetkým tímom.

Dokumentácia síce pomôže vysvetliť, čo treba urobiť, ale stále necháva jednotlivé kroky na človeka. Pri väčšom počte repozitárov tak rastie priestor na chyby.

Preto sa pri migráciách osvedčila automatizácia. Namiesto návodu, ktorý musí každý tím manuálne nasledovať, môže skript vykonať potrebné zmeny zaň. Nie je to bez chýb, ale väčšinu práce a rizika tým odstránite.

Pri platforme pre stovky aplikácií je to jednoduchý princíp: ak sa rovnakú zmenu chystáte robiť desiatky či stovky krát, oplatí sa automatizovať ju skôr, než ju dokumentovať.

CI/CD platforma nie je nikdy úplne hotová

Aj pri fungujúcej platforme zostávajú veci, ktoré sa dajú zlepšiť. Jednou z nich sú regresné testy pipeline, ktoré sú pri množstve rôznych kombinácií stackov náročnejšie na overovanie.

Ďalším krokom je usage reporting, aby mal tím lepší prehľad o využívaní a spendingu jednotlivých tímov. Do budúcnosti sa počíta aj s ďalším využitím feature flagov a on-demand environmentov.

Pointa však zostáva rovnaká: CI/CD platforma má vývojárom prácu zjednodušovať. A keď sa dostane na stovky aplikácií, jej vývoj tým nekončí.

Chcete vidieť celý návrh CI/CD platformy?

Tomáš Lauro v prednáške ukazuje konkrétnu architektúru platformy, L1 a L2 vrstvy, reusable workflows, konfiguráciu aj spôsob, akým vyriešili release a asynchrónny deployment.

FAQ

1. Ako škálovať CI/CD pre stovky aplikácií bez straty autonómie?
Pomocou reusable workflows, ktoré centralizujú spoločnú implementáciu, zatiaľ čo jednotlivé tímy si ponechávajú vlastnú konfiguráciu. L1 rieši orchestráciu a L2 konkrétnu implementáciu pre daný technologický stack.

2. Čo sú reusable workflows a prečo ich používať v CI/CD?
Ide o opakovane použiteľné časti pipeline, ktoré umožňujú zdieľať spoločnú implementáciu medzi aplikáciami bez kopírovania rovnakého kódu do každého repozitára.

3. Ako zabrániť tomu, aby zmena spoločnej CI/CD pipeline rozbila stovky aplikácií?
Pomocou verzovania reusable workflows a pinovania konkrétnej verzie. Tímy tak majú kontrolu nad tým, ktorú verziu spoločnej platformy používajú.