Predstav si dva programátorské tímy.
Prvý pripravuje novú verziu aplikácie.
Programátor dokončí úlohu. Niečo skontroluje kód. Potom treba spustiť testy. Niekto pripraví balík. Niekto iný sa prihlási na server. Následne treba vykonať niekoľko ručných úkonov, skontrolovať konfiguráciu a po nasadení sledovať systém. Ak všetko prebehne dobre, nová verzia je dostupná.
Druhý tím pracuje inak.
Kód putuje do repozitára. Automaticky sa spúšťajú testy, analýza kvality a bezpečnostné kontroly. Systém zostaví verziu aplikácie, nasadí ju na testovacie prostredie, vykoná ďalšie kontroly a po splnení určených podmienok ju môže nasadiť do produkcie. Ak sa niečo pokazí, nasadenie sa zastaví alebo sa systém môže vrátiť k predchádzajúcej verzii.
Oba tímy vytvárajú softvér.
Ale iba jeden z nich vybudoval opakovaný proces dodávania softvéru.
A práve o to ide v CI/CD.
"Funguje v produkcii" ešte nie je zrelý proces
Mnohé firmy merajú úspech veľmi jednoduchou metrikou: aplikácia funguje.
To je samozrejme základná podmienka.
Ale s rastom systému sa objavujú ďalšie otázky:
- Ako rýchlo vieme nasadiť opravu?
- Ako často môžeme zverejňovať nové funkcie?
- Koľko ručných úkonov robíme pri každom nasadení?
- Môže každý programátor spustiť proces nasadenia podľa tých istých pravidiel?
- Vieme, ktorá verzia práve beží?
- Vieme sa vrátiť k predchádzajúcej verzii?
- Kontrolujeme po nasadení automaticky, či systém funguje správne?
- Máme monitoring?
- Vieme, že nasadenie spôsobilo problém, skôr než ho nahlási zákazník?
Toto sú otázky týkajúce sa software delivery, a nie len samotného programovania.
CI a CD - dve časti jedného procesu
CI, teda Continuous Integration, znamená nepretržitú integráciu zmien.
V praxi ide o to, aby zmeny často smerovali do spoločného repozitára a boli automaticky kontrolované.
Typický pipeline môže spustiť okrem iného:
-
kompiláciu alebo zostavenie aplikácie,
-
jednotkové testy,
-
integračné testy,
-
linting,
-
statickú analýzu kódu,
-
skenovanie závislostí,
-
bezpečnostné kontroly,
-
vytváranie nasadzovacích artefaktov.
Vďaka tomu sa problém môže odhaliť ešte predtým, než sa kód dostane do produkcie.
CD, teda Continuous Delivery alebo Continuous Deployment, sa týka ďalšej fázy - doručovania zmien.
V závislosti od zvoleného modelu systém môže pripraviť hotovú verziu na nasadenie alebo ju automaticky nasadiť po prechode určenými kontrolami.
Ide o dôležité rozlíšenie.
Continuous Delivery nemusí znamenať automatické nasadenie každej zmeny do produkcie.
Môže jednoducho znamenať, že každá verzia je opakovateľne pripravená na nasadenie.
Prečo sa ručné nasadenia stávajú problémom?
Ručné nasadenie nemusí byť zlé.
V malom projekte môže byť úplne postačujúce.
Problém začína vtedy, keď proces rastie spolu s aplikáciou.
Najprv máme jednu osobu, ktorá vie, ako nasadiť systém. Potom pribudne druhý server. Neskôr testovacie prostredie. Následne databáza, cache, fronty, storage, niekoľko služieb a externé API. K tomu sa pridávajú rôzne konfigurácie pre development, testovanie a produkciu.
Po niekoľkých rokoch môže proces vyzerať približne takto:
"Najprv spusti X, potom zmeň parameter Y, neskôr reštartuj službu Z, ale predtým sprav zálohu databázy. A ak sa objaví chyba, zavolaj osobe, ktorá to nasadzovala naposledy."
To už nie je proces. To je vedomosť skrytá v hlave človeka. A práve vtedy riziko rastie.
Automatizácia neslúži len pohodliu programátorov
CI/CD sa často predstavuje ako nástroj zvyšujúci komfort developerov. Je to pravda, ale je to len časť obrazu.
Automatizácia delivery predovšetkým zvyšuje opakovateľnosť procesu.
Ak nasadenie vykonáva človek, existuje možnosť, že zakaždým urobí niečo trochu inak.
Ak to robí pipeline, dá sa definovať presná postupnosť krokov.
Tá istá verzia.
Tie isté testy.
Tie isté kontroly.
Tie isté pravidlá.
Je to mimoriadne dôležité v projektoch, ktoré vyvíja niekoľko ľudí alebo niekoľko tímov.
Testy pred nasadením sú dôležitejšie ako rýchlosť nasadenia
Automatizácia bez testov môže len spôsobiť, že chyby sa budú objavovať rýchlejšie.
Preto dobre navrhnutý pipeline nemá byť len mechanizmom: "kód → produkcia".
Mal by byť systémom kontroly kvality.
V závislosti od projektu môžu byť jeho súčasťou:
- Jednotkové testy - overujú jednotlivé prvky logiky.
- Integračné testy - overujú spoluprácu komponentov.
- End-to-end testy - simulujú reálne používateľské scenáre.
- Bezpečnostné testy - kontrolujú okrem iného závislosti a známe zraniteľnosti.
- Výkonnostné testy - potrebné tam, kde je dôležité zvládnutie určitej záťaže.
Nie každá aplikácia potrebuje všetky tieto vrstvy v rovnakom rozsahu.
A to je dôležité.
CI/CD nie je o nahádzaní čo najväčšieho počtu nástrojov do pipeline'u.
Ide o prispôsobenie kontrol riziku konkrétneho systému.
Čo sa stane, keď test neprejde?
To je jedna z najdôležitejších otázok v celom procese.
Zrelý pipeline by mal mať jasne definované pravidlá.
Ak kritický test neprejde, verzia by nemala byť považovaná za pripravenú na nasadenie.
Ak bezpečnostný sken odhalí určitú úroveň rizika, pipeline môže proces zastaviť.
Ak sa build nevykoná, nie je čo nasadzovať.
Znie to banálne. Ale práve takéto automatické "brány" spôsobujú, že kvalita nezávisí iba od pamäti a presnosti človeka.
A ak sa nasadenie aj tak nepodarí?
Ani ten najlepší proces neeliminuje všetky chyby. Preto je druhým prvkom zrelého delivery možnosť kontrolovaného vrátenia zmeny.
Rollback môže znamenať návrat k predchádzajúcemu artefaktu, obrazu kontajnera alebo verzii aplikácie. Ale tu sa objavuje dôležitý problém. Rollback kódu nie vždy znamená rollback dát.
Ak nová verzia zmenila štruktúru databázy, situácia sa stáva zložitejšou.
Preto by sa databázové migrácie mali navrhovať tak, aby celý proces bol čo najbezpečnejší a vratný, alebo aspoň kompatibilný s predchádzajúcou verziou aplikácie.
Toto je jeden z príkladov ukazujúcich, že profesionálne CI/CD je architektonický problém, a nie len konfigurácia nástroja.
Blue-green, canary a ďalšie stratégie nasadzovania
V náročnejších systémoch nie je potrebné hneď prepínať všetkých používateľov na novú verziu. Možno použiť rôzne stratégie nasadzovania.
Blue-green deployment
Bežia dve verzie prostredia.
Jedna obsluhuje prevádzku, druhá sa pripravuje na prevzatie prevádzky.
Po pozitívnom overení nasleduje prepnutie.
Výhodou je možnosť rýchleho návratu k predchádzajúcemu prostrediu.
Nevýhodou môže byť vyššia spotreba infraštruktúry.
Canary deployment
Nová verzia sa najprv dostane k malej časti používateľov alebo prevádzky.
Ak monitoring neodhalí problémy, rozsah nasadenia sa môže postupne zvyšovať.
Tým sa obmedzuje potenciálny rozsah chyby.
Vyžaduje si to však vhodnú infraštruktúru, monitoring a spôsob riadenia prevádzky.
Feature flags
Funkcia môže byť nasadená do systému, ale zostať pre používateľov vypnutá.
Vďaka tomu sa nasadenie kódu a spustenie funkcionality stávajú dvoma samostatnými procesmi.
To prináša väčšiu kontrolu, najmä pri veľkých zmenách.
To však neznamená, že feature flags sú riešením pre každý projekt. Ich nadbytok môže tiež zvýšiť zložitosť systému.
Monitoring po nasadení
Možno vykonať všetky testy. Možno mať skvelý pipeline. Možno nasadiť novú verziu bez akejkoľvek chyby. A o pár minút neskôr sa aplikácia môže začať správať inak pod skutočnou záťažou.
Preto by sa proces nemal končiť pri nasadení. Potrebná je observability, teda možnosť porozumieť tomu, čo sa deje vo vnútri bežiaceho systému.
V závislosti od architektúry zahŕňa okrem iného:
-
logy,
-
metriky,
-
tracing,
-
monitoring infraštruktúry,
-
monitoring aplikácie,
-
alerty,
-
informácie o chybách,
-
biznisové ukazovatele.
Nejde o to zbierať všetko. Ide o to, aby sa na dôležité otázky dalo odpovedať na základe dát.
Beží aplikácia?
Beží pomalšie ako predtým?
Zvýšil sa počet chýb?
Ktorá služba generuje problém?
Týka sa problém všetkých používateľov alebo len časti?
100 nasadení denne nie je vždy cieľ
Názov tohto článku hovorí o 100 nasadeniach denne, ale nejde o stanovenie takéhoto čísla ako cieľa.
Vo vnútornom systéme aktualizovanom raz za mesiac nemá zmysel umelo sa snažiť o stovky deploymentov. V systéme vyvíjanom veľmi intenzívne môže byť táto frekvencia technicky možná.
Kľúčová je schopnosť bezpečne dodávať zmeny, a nie samotný počet nasadení. To je zásadný rozdiel.
Zrelosť procesu sa nemeria tým, ako často nasadzujeme, ale tým, ako predvídateľne a bezpečne to dokážeme robiť.
Kedy môže byť CI/CD prehnaním formy nad obsahom?
Nie každá aplikácia potrebuje zložitú infraštruktúru nasadzovania.
Ak máme malú aplikáciu, malý tím a niekoľko nasadení ročne, rozšírený pipeline môže stáť viac než problémy, ktoré rieši.
Podobne je to pri veľmi špecifických systémoch, kde nasadenie vyžaduje manuálnu kontrolu z dôvodov bezpečnosti, regulácií alebo povahy infraštruktúry.
Preto by architektúra delivery mala vychádzať z potrieb systému. Nie z módy.
Kedy dáva automatizácia nasadzovania obzvlášť veľký zmysel?
Oplatí sa ju zvážiť najmä vtedy, keď:
-
systém sa vyvíja pravidelne,
-
na kóde pracuje viacero ľudí,
-
existuje viac než jedno prostredie,
-
nasadenia sú časté,
-
manuálne nasadzovania generujú chyby,
-
systém má kritický biznisový význam,
-
potrebujeme rýchly rollback,
-
aplikácia má viacero komponentov,
-
sú potrebné audity alebo stopa zmien,
-
čas dodania funkcionality má biznisový význam.
V takýchto prípadoch môže dobre navrhnutý pipeline patriť medzi najdôležitejšie prvky procesu vývoja softvéru.
CI/CD neopraví zlú architektúru
Aj to treba zdôrazniť.
Možno vytvoriť skvelý pipeline pre zlú aplikáciu.
Automaticky testovať zlý kód.
Automaticky nasadzovať zlú architektúru.
Automaticky škálovať zle navrhnutý systém.
Automatizácia teda nenahrádza architektúru, testy ani kompetencie tímu.
Posilňuje existujúci proces.
Ak je proces dobrý, pomáha ho škálovať.
Ak je proces zlý, môže jednoducho rýchlejšie vykonávať zlé veci.
Ako vyzerá zrelý proces?
Neexistuje jeden univerzálny pipeline.
Ale zrelý proces by mal mať niekoľko základných vlastností.
Opakovateľnosť - nasadenie sa vykonáva podľa definovaných krokov.
Automatizáciu - stroje vykonávajú čo najväčšiu časť opakovateľnej práce.
Testovateľnosť - zmeny sa automaticky overujú.
Bezpečnosť - proces zahŕňa primerané bezpečnostné kontroly.
Pozorovateľnosť - po nasadení vieme, čo sa deje so systémom.
Vratnosť - existuje plánovaný spôsob reakcie na nepodarenú zmenu.
Sledovanie zmien - vieme, aká verzia bola nasadená a z čoho vznikla.
Kontrolu prístupu - nie každý môže ľubovoľne nasadiť čokoľvek do produkcie.
Práve z takýchto prvkov vzniká profesionálny proces software delivery.
Najdôležitejšia zmena sa začína inou otázkou
Firmy sa často pýtajú: "Ako rýchlo môžeme vytvoriť túto funkcionalitu?"
Je dobré pridať druhú otázku: "Ako rýchlo a bezpečne budeme môcť doručovať ďalších 50 funkcionalít?"
Jedno nasadenie sa dá vykonať manuálne. Aplikáciu možno dokonca manuálne nasadzovať aj niekoľko rokov. Ale so zvyšovaním produktu, tímu, počtu používateľov a počtu zmien rastie aj cena takéhoto prístupu.
Preto CI/CD, automatické testy, monitoring a kontrolované deploymenty nie sú len riešenia pre veľké korporácie.
Sú to prvky infraštruktúry procesu, ktorý umožňuje rozvíjať softvér bez pridávania zbytočného rizika do každej ďalšej zmeny.
A v konečnom dôsledku práve o to ide.
Nie o 100 nasadení denne.
Nie o módne nástroje.
Nie o najzložitejší pipeline.
Len o možnosť povedať:
"Máme zmenu. Skontrolovali sme ju. Vieme, čo nasadzujeme. Vieme, ako ju sledovať. A vieme, čo urobíme, ak sa niečo pokazí."
