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.

Větve: krátké, ne strom

Vývojáři vedou roky spor mezi Git Flow a trunk-based developmentem. Git Flow drží víc dlouho žijících větví, integruje pozdě a dělá velké slučování. S velkým slučováním přicházejí dražší chyby. Trunk-based jede krátké větve a častá malá sloučení do main, opřená o automatické testy v CI. Kódová báze tak zůstává pořád připravená k vydání.

Pro obsah je ten spor naštěstí krátký. Jedna změna, jedna větev, jeden PR, rychle zpátky do main. Žádný develop, žádné release větve, žádný aparát Git Flow. Ten je pro software s víc podporovanými verzemi naráz, ne pro web, kde živá je vždycky jen jedna verze a vydáváš průběžně.

A obsah do téhle hry patří doopravdy. Git-based CMS jako Decap nebo Sveltia dovolí i netechnickému editorovi psát text v rozhraní, ale každou nepublikovanou změnu uloží jako commit, respektive PR. Editor projde stejným redakčním postupem draft → review → publish, jenže technicky je to větev a pull request. I oprava překlepu tak dostane náhled a kontrolu, místo aby šla naslepo do produkce. Není to plná náhrada psaní s živým náhledem (preview ukáže hotovou stránku, ne WYSIWYG během psaní), ale tu nejhorší díru zalepí.

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.

Secrets nepatří do repa. A je to měřitelný průšvih.

API klíče, tokeny, hesla k databázi. Nic z toho nesmí do Gitu. Jakmile to jednou je v historii, je to tam navždy, i když to příštím commitem smažeš.

Není to teoretické varování. GitGuardian napočítal jen v roce 2024 23,8 milionu secrets uniklých ve veřejných GitHub repozitářích, o čtvrtinu víc než rok předtím. A 70 % secrets, které unikly v roce 2022, je dodnes aktivních. Únik klíče není „smažu commit a je to". Je to klíč, který útočník nejspíš pořád může použít.

Secrets proto patří do prostředí, ne do kódu. CI je čte z chráněného úložiště (GitHub/GitLab secrets, environment variables hostingu) a do buildu je vloží za běhu. V repu zůstane jen jméno proměnné, hodnota nikdy.

Approval gates: kdo smí stisknout publish

Mezi „schváleno" a „živé" se občas hodí ještě jedna brzda, hlavně když změnu spouští automat. GitHub Environments k tomu mají deployment protection rules. Umí vyžádat ruční schválení (až 6 určených recenzentů, stačí jediné schválení), umí job zdržet časovačem na 1 minutu až 30 dní, umí ho omezit jen na vybrané větve. Dá se zakázat schvalování vlastní změny, takže kdo deploy spustil, nesmí ho sám odklepnout. Neschválený job po 30 dnech spadne sám.

Jeden háček, který se vyplatí znát dopředu: na plánech Free, Pro a Team fungují tyhle protection rules jen pro veřejné repozitáře. Privátní obsahový web na bezplatném plánu schvalovací brány prostě nemá. Není to nedopatření, je to placená funkce.

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í).

Zdroje

• Doug Seven, Henrico Dolfing — Knight Capital, 1. 8. 2012: deploy na 7 z 8 serverů, Power Peg, 4 026 087 obchodů / 45 minut / 440 mil. USD.
• Netlify blog — atomické a neměnné deploye, okamžitý rollback, „rollback za 2 vteřiny".
• vibecoder.me, Cloudflare Pages docs — preview / deploy previews pro větev a PR, unikátní URL, PR komentář a status check (Vercel, Netlify, Cloudflare Pages).
• GitGuardian, State of Secrets Sprawl 2024/2025 — 23,8 mil. secrets ve veřejných repech v 2024 (+25 % meziročně), 70 % secrets z 2022 dodnes aktivních.
• GitHub docs — Environments a deployment protection rules: approvals (max 6, stačí 1), wait timer 1–43 200 min, zákaz self-review, protection rules na Free/Pro/Team jen pro public repo.
• treosh/lighthouse-ci-action, web.dev — Lighthouse CI, budget.json, assertion levely off / warn / error, blokování merge, check run.
• Atlassian, Assembla — trunk-based development vs. Git Flow, krátké větve a „continuously releasable".
• Decap CMS docs, LogRocket — Git-based CMS, redakční postup draft → review → approve jako commit/PR.
• DORA report 2024 (getdx, Octopus) — elite 182× častější deploy, ~5 % change failure rate, recovery < 1 h.

Pipeline doručuje neměnné artefakty na hosting a CDN, kde atomický deploy, preview i rollback fyzicky žijí. U Cloudflare je Git-based deploy a preview pro každou větev přímo součástí Pages i Workers. Render bývá krokem buildu, takže navazuje na statický, dynamický, hybridní. Redakční postup se stavy patří do obsahového modelu, brány kvality zapojují výkon i přístupnost a celé to ústí v průběžné vynucování kvality přes správu a údržbu. Jednorázové spuštění a migrace je vyústění téhle pipeline. Pojmy repo, build, deploy a preview sjednocuje slovník.