CI/CD pro e-shop — jak nasazovat bez výpadků
Nasazení v pátek večer přes FTP a modlitba, ať to vydrží? Ukážeme, jak postavit pipeline, která změny testuje, nasazuje bez výpadku a umí se rychle vrátit, když se něco pokazí.
Mnoho e-shopů pořád nasazuje změny ručně. Vývojář nahraje soubory přes FTP nebo se přihlásí na server, stáhne novou verzi, spustí migraci a smaže cache. Když se něco pokazí, hledá se v noci, co přesně se změnilo. A protože je nasazení riskantní, dělá se zřídka. Změny se hromadí a každé další nasazení je ještě riskantnější.
CI/CD tenhle kruh přeruší. Každá změna projde automatickými testy, nasazuje se stejným postupem a dá se rychle vrátit. V článku ukážeme, jak takovou pipeline pro e-shop postavit, jaké strategie nasazení existují a jak řešit nejtěžší část: změny databáze.
Co je CI/CD a proč ho e-shop potřebuje
CI (continuous integration) znamená, že se každá změna v repozitáři automaticky sestaví a otestuje. CD (continuous delivery / deployment) znamená, že otestovaná změna se automaticky připraví k nasazení, nebo rovnou nasadí.
Pro e-shop to přináší tři věci:
- Menší změny. Nasazujete častěji a v menších dávkách, takže při chybě víte, kde hledat.
- Opakovatelnost. Nasazení je skript, ne ruční postup v hlavě jednoho vývojáře.
- Rychlý návrat. Předchozí verze je připravená a vrátit se k ní je otázka minut.
Na pronajímaných platformách typu Shoptet nasazuje samotnou platformu provozovatel. Pipeline ale dává smysl i tam: pro šablony, vlastní doplňky, integrace a middleware. U WooCommerce, Magenta nebo vlastního řešení je to základ provozu.
Jak vypadá pipeline krok za krokem
| Krok | Co se děje | Příklad |
|---|---|---|
| 1. Kontrola kódu | lint, statická analýza, kontrola závislostí | PHPStan, ESLint, audit balíčků |
| 2. Testy | jednotkové a integrační testy | PHPUnit, testy API |
| 3. Build | sestavení artefaktu: závislosti, zkompilovaný kód, statické soubory | Composer, npm, kompilace šablon |
| 4. Nasazení na staging | stejný artefakt na testovací prostředí | automaticky po sloučení do hlavní větve |
| 5. Ověření na stagingu | automatické testy průchodu nákupem, ruční kontrola | E2E test košíku a checkoutu |
| 6. Schválení | ruční potvrzení nasazení do produkce | schvalovatel v GitHub Actions nebo GitLab CI |
| 7. Nasazení do produkce | strategie bez výpadku (viz níže) | blue-green, rolling, canary |
| 8. Kontrola po nasazení | smoke testy, sledování chyb a objednávek | kontrola, že objednávky dál chodí |
Klíčový princip: build jednou, nasazuj všude. Na staging i do produkce jde stejný artefakt. Nikdy nesestavujte kód znovu na produkčním serveru.
Adobe to u Magenta popisuje jako pipeline deployment: statické soubory a zkompilovaný kód se připraví na samostatném build systému a výpadek produkce se tím omezí na dobu přenosu hotových souborů. Testovací prostředí rozebíráme v článku Testovací prostředí (staging): proč ho mít vždy.
GitHub Actions a GitLab CI v praxi
Oba nástroje umějí to, co e-shop potřebuje. Volba obvykle závisí na tom, kde máte repozitář.
GitHub Actions pracuje s prostředími (environments), například staging a production. Prostředí může mít ochranná pravidla: povinné schválení (job čeká, dokud ho někdo neschválí, a po 30 dnech bez schválení selže) nebo časovou prodlevu. Pozor na tarify: u GitHub Free, Pro a Team jsou povinní schvalovatelé a prodleva podle dokumentace dostupné jen pro veřejné repozitáře. Pro soukromé repozitáře potřebujete vyšší tarif. Souběžná nasazení do stejného prostředí omezí nastavení concurrency.
GitLab CI má podobný koncept prostředí. Ruční spuštění nasazení zajistí when: manual, klíčové slovo resource_group zaručí, že do prostředí běží vždy jen jedno nasazení. V přehledu prostředí jde jedním kliknutím znovu nasadit některou z předchozích úspěšných verzí.
Tajné údaje (hesla k databázi, API klíče platebních bran) patří do šifrovaných proměnných CI nástroje, ne do repozitáře.
Strategie nasazení bez výpadku
| Strategie | Jak funguje | Výhody | Nevýhody |
|---|---|---|---|
| Atomické přepnutí adresáře | nová verze se připraví vedle staré, pak se přepne symbolický odkaz | jednoduché, levné, rychlý návrat | běží na jednom serveru, migrace databáze řešíte zvlášť |
| Rolling | servery se aktualizují postupně jeden po druhém | není potřeba dvojitá kapacita | chvíli běží stará i nová verze současně |
| Blue-green | dvě kompletní prostředí, provoz se přepne najednou | okamžitý návrat přepnutím zpět | dvojnásobná infrastruktura, sdílená databáze |
| Canary | nová verze nejdřív pro malou část provozu | chyba zasáhne jen část zákazníků | složitější směrování a vyhodnocení metrik |
Pro většinu e-shopů na jednom serveru stačí atomické přepnutí adresáře. Na více serverech je běžný rolling. Blue-green a canary dávají smysl u větších e-shopů, kde každá minuta výpadku stojí hodně.
Všimněte si, že u rolling, blue-green i canary běží chvíli stará a nová verze současně nad stejnou databází. To je důvod, proč jsou migrace databáze nejtěžší část.
Migrace databáze: expand and contract
Přejmenování sloupce se na první pohled zdá jako drobnost. Jenže stará verze kódu, která ještě běží, hledá sloupec pod starým jménem a spadne. Řešením je vzor expand and contract (Martin Fowler ho popisuje jako parallel change). Nekompatibilní změnu rozdělíte na kroky, z nichž každý je zpětně kompatibilní:
- Expand. Přidáte nový sloupec vedle starého. Starý kód ho ignoruje.
- Nasazení kódu, který zapisuje do obou. Nová verze čte ze starého sloupce, zapisuje do obou.
- Převod dat. Dávkově zkopírujete historická data do nového sloupce.
- Přepnutí čtení. Další verze čte z nového sloupce.
- Contract. Až když starý sloupec nikdo nepoužívá, odstraníte ho.
Do posledního kroku se můžete kdykoli vrátit k předchozí verzi kódu. To je hlavní výhoda.
U velkých tabulek (produkty, objednávky) je problém i samotná změna schématu, která může tabulku na dlouho zamknout. MySQL 8 umí řadu úprav provést algoritmem INSTANT, který mění jen metadata. Od verze 8.0.29 to platí i pro přidání sloupce na libovolnou pozici a pro odebrání sloupce. Pro složitější změny se používají nástroje pro online migraci schématu, například gh-ost od GitHubu, který změny přenáší přes binární log.
Rollback: plán B musí být připravený předem
Rollback kódu je snadný: vrátíte předchozí artefakt. Rollback databáze snadný není. Data zapsaná novou verzí se zpátky nepřevedou sama. Proto:
- Migrace pište tak, aby s nimi fungovala i předchozí verze kódu (expand and contract).
- Před rizikovou migrací mějte čerstvou zálohu a ověřený postup obnovy.
- Riskantní funkce zapínejte přes feature flag, ne nasazením. Vypnout přepínač je rychlejší než rollback.
- Po nasazení sledujte chybovost, rychlost a hlavně počet objednávek. Když objednávky přestanou chodit, vracejte se hned a příčinu hledejte potom.
Checklist: je vaše nasazování bezpečné?
- Kód je v Gitu a na produkci se nic needituje ručně.
- Každá změna projde automatickými testy, včetně průchodu košíkem.
- Na staging i produkci jde stejný artefakt.
- Nasazení do produkce vyžaduje schválení a běží vždy jen jedno.
- Migrace databáze jsou zpětně kompatibilní.
- Předchozí verze je připravená k návratu a postup je vyzkoušený.
- Po nasazení se automaticky kontroluje, že web i objednávky fungují.
Pokud u vás nasazování pořád závisí na jednom člověku a ručním postupu, pomůžeme pipeline navrhnout a zavést. Vývoj na míru včetně CI/CD děláme v rámci programování, průběžnou péči o provoz a nasazování v programu Ecommerce Care. Cenu připravíme po konzultaci podle rozsahu.
Potřebujete s tím pomoct?