V mnohých firmách je nasadenie novej verzie softvéru udalosť. Naplánuje sa termín, napíše sa zoznam krokov, večer sa niekto pripojí, spustí to a potom sa hodinu pozerá, či niečo nespadlo. Ak spadne, nastáva improvizácia, lebo cesta späť nie je pripravená.
Continuous integration a continuous delivery (CI/CD) tento stav nemenia tým, že by nasadenie zrýchlili. Menia ho tým, že z neho spravia bežnú, nudnú operáciu, ktorá sa deje niekoľkokrát denne a nikto si ju nevšimne. Rozdiel nie je v technológii, ale v tom, koľko strachu je v tíme naviazaného na jedno tlačidlo.
Čo znamená CI a čo CD
Oba pojmy sa používajú spolu, ale riešia inú vec.
Continuous integration (CI) je automatická kontrola pri každej zmene kódu. Keď vývojár odošle zmenu, systém ju sám zostaví, spustí testy, skontroluje typy a štýl kódu a povie, či je zmena v poriadku. Cieľom je zistiť problém v momente, keď ho autor ešte má v hlave — nie o dva týždne pri nasadení.
Continuous delivery (CD) je automatizované doručenie overenej zmeny do prostredia. Nasadenie prestane byť ručnou sekvenciou príkazov a stane sa opakovateľným procesom, ktorý prebehne rovnako zakaždým. Práve opakovateľnosť je to podstatné — ručný postup je zakaždým trochu iný, a rozdiel sa prejaví v ten najnevhodnejší večer.
Prostredia: čo má a nemá zmysel
Väčšina projektov si vystačí s tromi prostrediami, každé s inou úlohou.
| Prostredie | Na čo slúži | Kto ho používa |
|---|---|---|
| Vývojové | práca na zmene, rýchla spätná väzba | vývojári |
| Staging | overenie pred nasadením, testovanie klientom | tím a zadávateľ |
| Produkcia | reálna prevádzka | používatelia |
Staging je z nich najčastejšie nepochopený. Jeho zmysel nie je v tom, že existuje, ale v tom, ako veľmi sa podobá produkcii. Prostredie s inou verziou databázy, inou konfiguráciou a desiatimi testovacími záznamami namiesto reálneho objemu dát nedokáže odhaliť práve tie problémy, kvôli ktorým vzniklo. Falošná istota je horšia než žiadny staging, lebo vedie k tomu, že sa nasadzuje s pocitom, že „to bolo predsa otestované".
Súčasťou tejto úvahy je aj to, s akými dátami sa na stagingu pracuje. Kópia produkčnej databázy dá realistické správanie, ale znamená to, že osobné údaje zákazníkov sú zrazu v prostredí s voľnejším prístupom — čo je vec, ktorú treba vedome vyriešiť anonymizáciou, nie prehliadnuť.
Testy: koľko ich stačí
Automatické testy sú predpoklad, bez ktorého je CI/CD len rýchlejší spôsob, ako nasadiť chybu. Nemusí ich však byť veľa — dôležitejšie je, ktoré to sú.
Minimum, ktoré dáva zmysel takmer v každom projekte:
- Zostavenie a kontrola typov. Zachytí najlacnejšiu kategóriu chýb okamžite.
- Testy kritických tokov. Prihlásenie, objednávka, platba, uloženie hlavného záznamu — to, čo nesmie prestať fungovať nikdy.
- Testy vecí, ktoré sa už raz pokazili. Každá oprava chyby by mala pribudnúť ako test, aby sa tá istá chyba nemohla vrátiť.
Snaha pokryť testami všetko je typický spôsob, ako sa téma odloží na neurčito. Praktickejšie je začať kritickými tokmi a dopĺňať podľa toho, čo sa reálne rozbíja. Širšie sa téme venujeme v článku o QA procese pred spustením.
Rollback je dôležitejší než rýchlosť
Najpodceňovanejšia časť celého nasadzovania nie je cesta dopredu, ale cesta späť. Tím, ktorý vie za dve minúty vrátiť predchádzajúcu verziu, nasadzuje pokojne. Tím, ktorý to nevie, nasadzuje opatrne, zriedka a vo veľkých dávkach — čo paradoxne zvyšuje riziko, lebo pri probléme je ťažšie zistiť, ktorá z tridsiatich zmien ho spôsobila.
Aby bol návrat spoľahlivý, musia platiť tri veci:
- Predchádzajúca verzia je stále k dispozícii a dá sa spustiť bez opätovného zostavovania.
- Zmeny v databáze sú spätne kompatibilné. Toto je tá časť, ktorá rollback najčastejšie znemožní — kód sa vrátiť dá, zmazaný stĺpec nie. Preto sa štrukturálne zmeny nasadzujú v krokoch: najprv pridať, potom prepnúť, až v ďalšej verzii odstrániť staré.
- Vie sa, že nastal problém. Bez monitoringu sa o chybe firma dozvie od zákazníka, a vtedy už rýchly rollback nepomôže reputácii.
Prečo sa nereleasuje v piatok
Pravidlo „v piatok poobede sa nenasadzuje" pôsobí ako povera, ale je to racionálna reakcia na konkrétny stav: tím neverí, že problém dokáže vyriešiť rýchlo. Ak by rollback trval dve minúty a monitoring by upozornil do minúty, piatok by nebol iný než utorok.
Je to teda užitočný ukazovateľ. Ak vo firme toto pravidlo platí, otázka nie je „ako presvedčiť tím, aby nasadzoval v piatok", ale „čo chýba k tomu, aby to bolo bezpečné". Odpoveď býva vždy jedna z troch vecí: chýbajúce testy, nespoľahlivý rollback alebo žiadny monitoring.
Súvisiaca téma je stav samotného kódu — projekt s vysokým technickým dlhom sa nasadzuje ťažko bez ohľadu na to, aký dobrý je pipeline. Tomu, ako dlh rozpoznať a splácať, sa venujeme v samostatnom článku.
Zhrnutie
CI/CD nie je o tom, ako často sa nasadzuje, ale o tom, či je nasadenie bežná operácia alebo udalosť. Automatické kontroly pri každej zmene, staging, ktorý sa naozaj podobá produkcii, testy kritických tokov a hlavne spoľahlivý rollback — to sú štyri veci, ktoré rozhodujú.
Rozsah nastavenia sa medzi projektmi líši podľa toho, kde aplikácia beží, ako vyzerá databáza a aké sú požiadavky na dostupnosť. Ak riešite, ako u vás nasadzovanie postaviť alebo prečo súčasné bolí, prejdeme si to na nezáväznej konzultácii — alebo si pozrite naše prístupy k vývoju na mieru.