Jan Mikoláš
Slovník pojmů
CI/CD: od změny v kódu k ověřenému nasazení
Cílem není zelená pipeline, ale rychlá a opakovatelná zpětná vazba o tom, zda změna porušila pravidla projektu.
Stručná definice
Automatizace kontroly a doručení změn.
CI, Continuous Integration, znamená časté spojování změn do sdíleného repozitáře s automatickým sestavením a kontrolami. Pull request tak dostává stejná ověření jako změna po merge a výsledek patří ke konkrétnímu commitu.
CD má dva významy. Continuous Delivery drží změnu ve stavu připraveném k vydání, ale produkční release může čekat na schválení. Continuous Deployment jde dál: po splnění určených automatických podmínek se změna do produkce nasadí sama.
Použití
Proč má pipeline hodnotu
Automatizace má nahradit opakovatelné ruční kroky, ne nahradit technické rozhodování týmu.
- stejná sada ověření pro pull request i merge
- dohledatelný artefakt navázaný na commit
- opakovatelný postup pro staging a produkci
- povinné kontroly a ochrana hlavní větve
- oddělené environmenty, secrets a oprávnění
- rychlé nalezení chyby blízko změny
Praktický příklad
Změna validace objednávky v PHP e-shopu
Po otevření pull requestu CI na čistém runneru ověří composer.json a lock, nainstaluje závislosti, spustí lint, PHPStan, PHPUnit a Deptrac. Selhání kterékoliv povinné kontroly znamená, že změna ještě není připravená k merge.
Po merge vznikne verziovaný artefakt. Staging ověří kompatibilní migraci a health endpoint. Produkční deploy může vyžadovat schválení environmentu; po nasazení smoke test kontroluje bezpečný tok bez vytváření testovací objednávky. Tým musí znát předchozí artefakt i slučitelnost návratu s databází.
Typická pipeline
Od commitu k provoznímu ověření
Konkrétní podoba se má řídit rizikem aplikace, ne počtem módních jobů.
- Závislosti Composer validate a instalace podle lock souboru na čistém runneru.
- Rychlé kontroly Lint a styl dají rychlou zpětnou vazbu k zápisu a konfiguraci.
- Kvalita PHPStan, PHPUnit a případně Deptrac ověří typy, chování i architektonické hranice.
- Artefakt a staging Stejný image či artefakt se nasadí, ověří migrace a bezpečný smoke test.
- Produkce a dohled Řízený deploy, monitoring, logy a známý postup rollbacku.
Důležité vlastnosti
Kontroly, nasazení a bezpečná změna
Přítomnost workflow souboru není sama o sobě kvalitní proces.
Merge gate
CI není jen běh testů. Pokud chráněná větev dovolí merge bez povinných kontrol, jejich výsledek nemá skutečnou váhu.
Stejný artefakt
Je bezpečnější propagovat stejný ověřený artefakt do stagingu i produkce než pro každé prostředí sestavovat něco nového.
Migrace a rollback
Migrace jsou součást změny. Návrat image neobnoví smazaná nebo nekompatibilně změněná data; pro rizikové změny pomáhá expand–migrate–contract postup.
Secrets a oprávnění
Produkční klíče nepatří do repozitáře ani logu. Environment může vyžadovat schválení a vydat secrets až po splnění ochranných pravidel.
Provozní kontrola
Staging, deploy a návrat změny
Nasazení má mít jasný stav, vlastníka a měřitelný výsledek.
- Staging
- Umožní ověřit artefakt a základní integrace mimo produkční data; sám nezaručuje přesně stejné chování v produkci.
- Concurrency
- Dva deploye do jednoho prostředí si mohou přepsat konfiguraci nebo migrace; řízená skupina jim brání závodit.
- Smoke test
- Malý bezpečný scénář po nasazení ověřuje více než jen domovskou stránku, například health endpoint a konfiguraci.
- Monitoring
- Green deploy neznamená, že vše funguje pro uživatele. Logy, metriky a alerty zůstávají nezbytné.
Výhody a omezení
Automatizace provádí proces, který tým nadefinoval
Přínosy
- opakovatelná kontrola každé změny
- chyby viditelné v pull requestu před vydáním
- release nezávislý na lokálním postupu jednoho člověka
- dohledatelnost commitu, artefaktu, kontrol a nasazení
Časté chyby
- zelená pipeline s malým nebo nevhodným pokrytím
- flaky testy, které se jen opakují místo opravují
- main bez branch protection
- únik secrets přes debug výpis nebo nedůvěryhodnou akci
- migrace, která znemožní bezpečný rollback
Hranice použití
Rozsah pipeline má odpovídat riziku změny.
Malý projekt nepotřebuje deset paralelních jobů. Minimum může být instalace závislostí, statická analýza, testy a opakovatelný deploy. U aplikace s objednávkami, platbami a integracemi je přiměřené přidat staging, architektonické kontroly, ochranu větve a vědomě navržené migrace.
Automatický production deployment není cíl sám o sobě. Bez observability, bezpečného návratu a kontroly secrets pouze zrychlí vydání chybné změny.
Na co myslet
Co má projít před vydáním
Kontroly mají být rychlé, reprodukovatelné a srozumitelné vývojáři.
- Composer validace a instalace podle locku
- lint, code style a statická analýza
- unit i důležité integrační testy
- architektonické kontroly tam, kde chrání skutečné hranice
- verziovaný artefakt, kompatibilní migrace a smoke test
- chráněná větev, omezená oprávnění a dohledatelný rollback
Časté otázky
Co CI/CD zaručuje
Jaký je rozdíl mezi continuous delivery a continuous deployment?
Delivery drží aplikaci ve stavu připraveném k vydání; produkční nasazení může čekat na schválení. Deployment nasadí změnu automaticky po úspěšných gatech.
Nahrazuje CI code review?
Ne. Automatizace hledá opakovatelné chyby, ale nezná obchodní záměr, srozumitelnost řešení ani nevhodný produktový kompromis.
Má smysl CI i pro malý PHP projekt?
Obvykle ano, alespoň pro instalaci závislostí, statickou analýzu a testy. U velmi krátkého jednorázového skriptu je ale potřeba posoudit přiměřenost investice.
Lze rollbackem vždy vyřešit chybnou migraci?
Ne. Pokud migrace odstranila či nevratně změnila data, návrat aplikace nestačí. Proto jsou důležité kompatibilní kroky, záloha a plán obnovy.
Jak CI a kontrolu kvality používám v praxi
Automatizované kontroly patří do běžného vývojového toku.
Veřejný projekt scheduling ukazuje workflow s testy a kontrolami kvality; je to ukázka CI pro zdrojový kód, ne tvrzení o konkrétním produkčním nasazení.