V mnoha firmách je nasazení nové verze softwaru událost. Naplánuje se termín, sepíše se seznam kroků, večer se někdo připojí, spustí to a pak se hodinu dívá, jestli něco nespadlo. Pokud spadne, nastává improvizace, protože cesta zpět není připravená.
Continuous integration a continuous delivery (CI/CD) tento stav nemění tím, že by nasazení zrychlily. Mění ho tím, že z něj udělají běžnou, nudnou operaci, která se děje několikrát denně a nikdo si jí nevšimne. Rozdíl není v technologii, ale v tom, kolik strachu je v týmu navázáno na jedno tlačítko.
Co znamená CI a co CD
Oba pojmy se používají spolu, ale řeší jinou věc.
Continuous integration (CI) je automatická kontrola při každé změně kódu. Když vývojář odešle změnu, systém ji sám sestaví, spustí testy, zkontroluje typy a styl kódu a řekne, jestli je změna v pořádku. Cílem je zjistit problém ve chvíli, kdy ho autor ještě má v hlavě — ne za dva týdny při nasazení.
Continuous delivery (CD) je automatizované doručení ověřené změny do prostředí. Nasazení přestane být ruční sekvencí příkazů a stane se opakovatelným procesem, který proběhne pokaždé stejně. Právě opakovatelnost je to podstatné — ruční postup je pokaždé trochu jiný, a rozdíl se projeví ten nejnevhodnější večer.
Prostředí: co má a nemá smysl
Většině projektů stačí tři prostředí, každé s jinou úlohou.
| Prostředí | K čemu slouží | Kdo ho používá |
|---|---|---|
| Vývojové | práce na změně, rychlá zpětná vazba | vývojáři |
| Staging | ověření před nasazením, testování klientem | tým a zadavatel |
| Produkce | reálný provoz | uživatelé |
Staging je z nich nejčastěji nepochopený. Jeho smysl není v tom, že existuje, ale v tom, jak moc se podobá produkci. Prostředí s jinou verzí databáze, jinou konfigurací a deseti testovacími záznamy místo reálného objemu dat nedokáže odhalit právě ty problémy, kvůli kterým vzniklo. Falešná jistota je horší než žádný staging, protože vede k tomu, že se nasazuje s pocitem, že „to přece bylo otestované".
Součástí této úvahy je i to, s jakými daty se na stagingu pracuje. Kopie produkční databáze dá realistické chování, ale znamená to, že osobní údaje zákazníků jsou najednou v prostředí s volnějším přístupem — což je věc, kterou je třeba vědomě vyřešit anonymizací, ne přehlédnout.
Testy: kolik jich stačí
Automatické testy jsou předpoklad, bez kterého je CI/CD jen rychlejší způsob, jak nasadit chybu. Nemusí jich však být hodně — důležitější je, které to jsou.
Minimum, které dává smysl téměř v každém projektu:
- Sestavení a kontrola typů. Zachytí nejlevnější kategorii chyb okamžitě.
- Testy kritických toků. Přihlášení, objednávka, platba, uložení hlavního záznamu — to, co nesmí přestat fungovat nikdy.
- Testy věcí, které se už jednou pokazily. Každá oprava chyby by měla přibýt jako test, aby se tatáž chyba nemohla vrátit.
Snaha pokrýt testy všechno je typický způsob, jak se téma odloží na neurčito. Praktičtější je začít kritickými toky a doplňovat podle toho, co se reálně rozbíjí. Šířeji se tématu věnujeme v článku o QA procesu před spuštěním.
Rollback je důležitější než rychlost
Nejpodceňovanější část celého nasazování není cesta dopředu, ale cesta zpět. Tým, který umí za dvě minuty vrátit předchozí verzi, nasazuje klidně. Tým, který to neumí, nasazuje opatrně, zřídka a ve velkých dávkách — což paradoxně zvyšuje riziko, protože při problému je těžší zjistit, která ze třiceti změn ho způsobila.
Aby byl návrat spolehlivý, musí platit tři věci:
- Předchozí verze je stále k dispozici a dá se spustit bez opětovného sestavování.
- Změny v databázi jsou zpětně kompatibilní. To je ta část, která rollback nejčastěji znemožní — kód se vrátit dá, smazaný sloupec ne. Proto se strukturální změny nasazují v krocích: nejprve přidat, pak přepnout, až v další verzi odstranit staré.
- Ví se, že nastal problém. Bez monitoringu se o chybě firma dozví od zákazníka, a to už rychlý rollback reputaci nepomůže.
Proč se nereleasuje v pátek
Pravidlo „v pátek odpoledne se nenasazuje" působí jako pověra, ale je to racionální reakce na konkrétní stav: tým nevěří, že problém dokáže vyřešit rychle. Kdyby rollback trval dvě minuty a monitoring upozornil do minuty, pátek by nebyl jiný než úterý.
Je to tedy užitečný ukazatel. Pokud ve firmě toto pravidlo platí, otázka není „jak přesvědčit tým, aby nasazoval v pátek", ale „co chybí k tomu, aby to bylo bezpečné". Odpověď bývá vždy jedna ze tří věcí: chybějící testy, nespolehlivý rollback nebo žádný monitoring.
Související téma je stav samotného kódu — projekt s vysokým technickým dluhem se nasazuje těžko bez ohledu na to, jak dobrý je pipeline. Tomu, jak dluh rozpoznat a splácet, se věnujeme v samostatném článku.
Shrnutí
CI/CD není o tom, jak často se nasazuje, ale o tom, jestli je nasazení běžná operace nebo událost. Automatické kontroly při každé změně, staging, který se opravdu podobá produkci, testy kritických toků a hlavně spolehlivý rollback — to jsou čtyři věci, které rozhodují.
Rozsah nastavení se mezi projekty liší podle toho, kde aplikace běží, jak vypadá databáze a jaké jsou požadavky na dostupnost. Pokud řešíte, jak u vás nasazování postavit nebo proč současné bolí, projdeme si to na nezávazné konzultaci — nebo si prohlédněte naše přístupy k vývoji na míru.