Git, preview prostředí a CI/CD

1. srpna 2012 nasadila Knight Capital nový kód na svoje obchodní servery. Na sedm z osmi. Na osmém zůstala stará verze a v ní osm let mrtvý kód jménem Power Peg, který nový deploy omylem probudil přes recyklovaný feature flag. V 9:30 se otevřela burza. Za 45 minut systém poslal 4 026 087 obchodů, které neměl poslat, a Knight prodělal 440 milionů dolarů. Víc, než kolik měla firma vlastního kapitálu. Za pár dní ji koupil konkurent.

Celá ta katastrofa stojí na jednom slově: částečně. Sedm serverů z osmi. Nasazení, které neproběhlo celé, nechalo systém běžet napůl ve staré a napůl v nové verzi. Z toho plyne první a nejdůležitější pravidlo nasazování, ať jde o burzovní systém, nebo o blog: nasazení musí být atomické. Všechno, nebo nic. Nikdy „skoro hotovo".

Dobrá zpráva pro obsahový web je, že tohle pravidlo nemusíš vymýšlet. Atomický deploy, preview pro každou větev i okamžitý rollback ti dává spravovaný hosting zadarmo. Smysl téhle kapitoly není „postav si CI/CD pipeline". Je „nezahazuj to, co už máš, ručním FTP do produkce".

Editace v produkci je špatný vzorec

Nejčastější zdroj nehod u „jednoduchých" webů není složitá architektura. Je to opak: někdo se přihlásí na FTP, přepíše soubor přímo na živém serveru a doufá. Žádná historie, žádný náhled, žádná cesta zpět. Když to rozbije, rozbije to návštěvníkům, ne jemu na obrazovce.

Celá pipeline je v jádru jedna věc: vsunout mezi „chci změnu" a „je to živé" řetěz kroků, který tuhle ruletu nahradí. Zdroj webu žije ve verzovaném repozitáři. Změna nejde rovnou do main, ale na vlastní větev a přes pull request. PR postaví preview. Preview projde kontrolami a okem člověka. Teprve schválená změna se sloučí a nasadí atomicky. A když přesto něco proklouzne, je tu rollback. Repo, PR, preview, kontrolní brána, atomický deploy, rollback. Zbytek kapitoly je těch šest slov rozepsaných.

Preview: živá URL pro každou větev

Tohle je funkce, kvůli které stojí za to mít hosting napojený na Git. Pošleš větev a hosting postaví preview deploy, kompletní živou kopii webu se změnou, na vlastní URL. Otevřeš ji na mobilu, pošleš klientovi, ukážeš redaktorovi, jak bude článek reálně vypadat. Všechno ještě předtím, než se cokoli dotkne produkce.

Poskytovatelé to dělají skoro stejně. Vercel staví preview pro každé odeslání změny a do PR vloží komentář s odkazem a metrikami výkonu. Netlify jim říká „deploy previews", přidá GitHub status check a umí i branch-based split testing, tedy A/B test celé větve. Cloudflare Pages dá každému PR unikátní preview URL, která se aktualizuje s každým commitem. Chce trochu víc konfigurace, zato je levný a rychlý.

Mechanika je vždycky stejná: push do feature větve vyrobí preview s unikátní adresou, otevření PR přidá odkaz na preview a status check přímo na GitHub. Recenzent nečte diff a nepředstavuje si výsledek. Klikne a vidí ho.

Brány kvality: ať to za tebe zkontroluje stroj

Preview ukáže změnu člověku. Kontrolní brána ji nechá zkontrolovat strojem, dřív než se sloučí. Tady se do pipeline zapojuje kvalita, kterou jinak nikdo nehlídá průběžně.

Lighthouse CI spustí audit výkonu v CI a umí build zastavit, když metriky spadnou pod práh nebo když stránka přeleze rozpočet zapsaný v budget.json. Pravidla mají tři úrovně ve stylu ESLintu. off nic neřeší, warn jen varuje, error build zastaví a zablokuje merge. Stejně se dají zapojit automatické kontroly přístupnosti i kontrola rozbitých odkazů. Výsledek se objeví jako check run s pass/fail ve záložce Checks u PR.

To, co se jinak dělá ručně a nárazově (nebo se nedělá vůbec), tím běží u každé změny automaticky. Pipeline je nástroj, kterým správa a údržba vynucuje kvalitu pořád, ne jednou za rok při auditu.

Rollback: vrátí se jen to, co bylo v artefaktu

Tady přichází ta nejhezčí část a zároveň nejčastější nedorozumění. Spravovaný hosting nasazuje neměnné deploye: nový build se nahraje celý vedle starého a teprve hotový se atomicky přepne naživo. Starý deploy se nikdy nepřepíše. Pořád leží na svém místě.

Z toho plyne okamžitý rollback. Vrátit se ke staršímu deployi nespouští nový build. Jen přepne, kam ukazuje doména, na verzi, která už hotová leží. Proto je rollback otázka sekund, ne minut. Netlify se chlubí „rollbackem za 2 vteřiny". Je to přesně tahle mechanika.

Ale pozor, kde rollback končí. Vrátí se jen to, co bylo součástí toho deploye, toho artefaktu. Když máš obsah v Gitu, je v artefaktu, takže rollback vrátí i obsah. Čistě. Když ale obsah žije v externí databázi nebo headless CMS, do artefaktu se nevejde a rollback deploye ho nevrátí. Vrátíš kód a šablony, ale data zůstanou taková, jaká byla. To je hranice, o kterou se lidi nejčastěji říznou: rollback není stroj času na všechno, je to přepnutí na starší stav. Co bylo mimo artefakt, mimo zůstane.

Tenhle neměnný artefakt je zároveň materiál pro spuštění a migraci: jednorázové spuštění je jen vyústění průběžné pipeline, okno zmrazení a „starý web dostupný" stojí na tom, že staré deploye nikdy nezmizí.

Není to zbytečné pro malý web?

Pro pětistránkovou vizitku editovanou jednou za rok zní celý tenhle aparát zbytečně těžce. Napůl je to pravda. Schvalovací brány, split testing a výkonové rozpočty na takovém webu nepotřebuješ.

Jenže to nejcennější z pipeline tam dostaneš tak jako tak a zadarmo. Napoj repo na spravovaný hosting a máš atomický deploy, preview pro každou změnu a okamžitý rollback, aniž bys cokoli stavěl. Aparát kolem se škáluje s velikostí projektu. Otázka „mít pipeline, nebo ne" se neškáluje. Odpověď je vždycky ano, jen v různě bohaté podobě.

A jestli ti to pořád zní jako zbytečná byrokracie, jsou tu tvrdá data. DORA report 2024: elitní týmy nasazují 182× častěji než ti nejpomalejší, mají osmkrát nižší podíl chybných nasazení (kolem 5 %) a z výpadku se zotaví za méně než hodinu. Kontrolní brány a automatizace vydání nezpomalují. Korelují s tím, že je rychlejší i bezpečnější.

Tři typické záměny

• Stačí přepsat soubor na produkci. Editace v produkci je špatný vzorec, ne zkratka. Bez větve, preview a rollbacku rozbíjíš naživo a nemáš cestu zpět.
• Rollback vrátí všechno. Vrátí jen obsah artefaktu. Kód a obsah v Gitu ano, data v externí DB nebo headless CMS ne. Ta žijí mimo deploy.
• Smazaný secret je v bezpečí. Co se jednou dostalo do Git historie, tam zůstane, a 70 % uniklých klíčů je dál aktivních. Klíč se musí zneplatnit a zrotovat, ne jen smazat v dalším commitu.

Praktický checklist

• Zdroj webu i obsah jsou ve verzovaném repu; změny jdou přes větev a PR, ne přímo do main ani na produkci.
• Každá větev / PR staví preview deploy na vlastní URL a review probíhá nad ním.
• V CI běží automatické kontroly: build, kontrola odkazů, Lighthouse CI a přístupnost, s úrovní error tam, kde mají blokovat merge.
• Žádný secret není v repu; klíče se čtou z chráněného úložiště a vstřikují za běhu.
• Jsou definovaná prostředí (preview / případně stage / prod) a u citlivých deployů schvalovací brána (pozor na omezení free plánu pro privátní repo).
• Existuje neměnný artefakt a je jasné, co rollback vrátí a co ne (externí data nevrátí).