Jan Mikoláš
Slovník pojmů
Build
Build připraví konkrétní verzi aplikace pro testování nebo vydání. Není vždy kompilace a není to automaticky deployment do produkce.
Stručná definice
Ze zdrojů vznikne dohledatelný artefakt, ne jen soubor „někde u vývojáře“.
U některých jazyků build zahrnuje kompilaci do binárního souboru. U PHP se často spíš nainstalují přesné závislosti podle composer.lock, vytvoří autoloader a ověří kód. Frontendový TypeScript se při běžném buildu často převede na JavaScript a sestaví se i CSS. Výsledkem může být adresář připravený k nasazení nebo kontejnerový image. I bez klasické kompilace je to build, pokud proces připravuje opakovatelný výstup.
Build není deployment. Build vytváří artefakt; deployment jej přenese nebo aktivuje v konkrétním prostředí. Není ani běžný runtime: runtime artefakt vykonává. Oddělení těchto kroků umožní otestovat jednu konkrétní verzi a stejný ověřený artefakt potom propagovat do stagingu či produkce bez nového sestavení v CI/CD.
Jaký problém řeší
Stejný výstup pro vývoj, CI a vydání
Build má odstranit ruční kroky a nejasnost, co přesně bylo ověřeno a vydáno.
- instalace PHP závislostí podle verze zachycené v composer.lock
- vytvoření optimalizovaných frontendových assetů nebo jiných distribuovaných souborů
- sestavení Docker image s jasným tagem nebo digestem
- spuštění kontrol nad čistým prostředím před vznikem artefaktu
- předání jednoho ověřeného artefaktu mezi CI, stagingem a produkcí
Praktický příklad
PHP aplikace jako kontejnerový artefakt
CI vezme konkrétní commit, instaluje produkční Composer závislosti podle lock souboru, spustí kontroly a sestaví image s označením verze. Základní image, Composer soubory a zdrojový kód jsou explicitní vstupy. Výsledný image je artefakt, který lze před nasazením zkontrolovat a uložit do registry.
Tajemství do build contextu ani image nepatří. Heslo databáze, API token nebo produkční certifikát se předávají až při běhu přes mechanismus daného prostředí. Pokud build závisí na tajném klíči pro stažení privátní závislosti, musí být předán dočasně bezpečným mechanismem buildu, ne zapsán do Dockerfile nebo vrstvy image.
Dockerfile
FROM composer:2 AS dependencies
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --prefer-dist --no-interaction
FROM php:8.4-cli
WORKDIR /app
COPY --from=dependencies /app/vendor ./vendor
COPY . .Diagram buildu
Zdrojový kód → ověření → artefakt → nasazení
Build diagram: commit a lock soubory → čisté build prostředí → kontroly a sestavení → verziovaný artefakt → samostatný deployment. Poslední krok už není build.
- Určené vstupy Konkrétní commit, lock soubory, build skripty a verzované konfigurace určují, co se má vytvořit. Neznámé lokální soubory nemají výstup potichu měnit.
- Čisté prostředí CI nebo kontejner začne bez pozůstatků ruční práce. Použité verze PHP, Composeru a dalších nástrojů jsou součástí reprodukovatelnosti.
- Ověření a sestavení Proces nainstaluje uzamčené závislosti, spustí příslušné kontroly a vytvoří distributelné soubory či image.
- Artefakt Výstup dostane verzi nebo digest, je uložen na určeném místě a lze jej spojit s commitem a výsledkem kontrol.
- Deployment Teprve samostatný krok artefakt nasadí s konfigurací a secrets cílového prostředí. Úspěšný build není důkazem úspěšného provozu.
Praktické hranice
Build skládá nástroje, ale nemá skrývat jejich vstupy.
Příkaz build může vypadat jednoduše, pod ním však musí být čitelné verze, závislosti a odpovědnost za výsledek.
Composer
Instaluje přesně uzamčené PHP závislosti a vytváří autoloader. Obecný composer update není standardní krok reprodukovatelného produkčního buildu.
Docker
Build vytváří image z Dockerfile a contextu. Context je potřeba omezit pomocí .dockerignore, aby neobsahoval secrets, lokální cache nebo zbytečně velké soubory.
CI/CD
CI často staví a testuje artefakt. CD jej může propagovat a nasadit; zelený job ovšem nenahrazuje monitoring cílového prostředí.
IDE a CLI
IDE nebo lokální CLI může build vyvolat. Pravidla buildu musí zůstat verzovaná a fungovat i na čistém runneru.
Důležité rozlišení
Build, kompilace, artefakt a deployment mají jinou odpovědnost.
Když tým tyto hranice pojmenuje, snáz dohledá rozdíl mezi změnou kódu, přípravou výstupu a problémem po nasazení.
Build
Celý opakovatelný proces přípravy výstupu. Může zahrnout stažení závislostí, generování kódu, assety, testy nebo sestavení image.
Kompilace a TypeScript
Kompilace je překlad zdrojového kódu do jiné podoby, často binárního programu. Je jen jedním z možných kroků buildu; běžný PHP build ji nemusí obsahovat. TypeScriptový build často převádí .ts do JavaScriptu a může generovat assety či deklarace.
Artefakt
Konkrétní výstup buildu: archiv, balíček, binární soubor, asset bundle nebo Docker image. Má být dohledatelný a neměnný.
Deployment
Předání artefaktu do cílového prostředí a jeho aktivace. Pracuje s konfigurací, migracemi, health checkem a runtime secrets, proto je samostatný krok.
Reprodukovatelnost
Znamená, že se stejnými deklarovanými vstupy vznikne stejný nebo ekvivalentní výstup. Pomáhá při opravě incidentu i při bezpečném review aktualizací.
Výhody a omezení
Opakovatelnost vyžaduje přesné vstupy a disciplínu kolem výstupů.
Přínosy
- dohledatelný vztah mezi commitem, kontrolami a vydaným artefaktem
- menší rozdíl mezi lokálním ověřením, CI a nasazením
- možnost propagovat stejný artefakt bez nového sestavení
- rychlejší diagnostika, co se skutečně dostalo do provozu
Rizika a chyby
- build závislý na necommitnutém lokálním souboru nelze spolehlivě zopakovat
- tajemství v image, artefaktu nebo cache se mohou dostat do registry či logu
- tag latest bez jednoznačné verze ztěžuje návrat a dohledání
- znovusestavení pro produkci může přinést jinou závislost než testovaný artefakt
- úspěšný build neověří migrace, síť, runtime konfiguraci ani chování v produkci
Kdy dává smysl
Každá nasazovaná aplikace potřebuje alespoň malý opakovatelný build.
Jednoduchý PHP projekt může mít build tvořený instalací závislostí podle composer.lock a spuštěním testů. Aplikace s frontendem, kontejnery či více službami bude potřebovat více kroků. Rozsah má odpovídat riziku, ale postup nemá záviset na tom, co má zrovna nainstalované jedno vývojářské zařízení.
Build sám neřeší obchodní pravidla, zálohu databáze, přístupová práva ani rollout. U změn objednávek a plateb je potřeba vedle artefaktu promyslet kompatibilní migrace, konfiguraci prostředí, monitoring a bezpečný návrat.
Na co myslet
Artefakt má být malý, dohledatelný a bez tajemství.
Dobrá build pipeline ukazuje, z čeho výstup vznikl, jak prošel kontrolami a kam může bezpečně pokračovat.
- vázat build na konkrétní commit a lock soubory, ne na plovoucí „nejnovější“ závislosti
- použít čisté nebo izolované build prostředí s určenými verzemi nástrojů
- vytvořený artefakt označit verzí či digestem a uchovat jeho původ
- nepřenášet do build contextu, image, cache ani logu secrets, privátní klíče a produkční konfiguraci
- omezit obsah Docker contextu pomocí .dockerignore a kontrolovat vícefázový build
- propagovat stejný ověřený artefakt do dalších prostředí místo nového buildu pro každý deploy
Časté otázky
Build bez častých záměn
Je build vždy kompilace?
Ne. Kompilace je jeden možný krok. PHP build často instaluje závislosti, vytvoří autoloader a assety nebo sestaví image, aniž by překládal PHP do binárního programu. TypeScriptový frontend se při buildu naopak často převádí z .ts do JavaScriptu.
Je build totéž co deployment?
Ne. Build vytvoří artefakt. Deployment jej aktivuje v konkrétním prostředí s jeho konfigurací, runtime secrets, migracemi a ověřením provozu.
Proč nestačí vytvořit build znovu na produkčním serveru?
Může vzniknout jiný výstup kvůli verzi nástroje, síti nebo plovoucí závislosti. Bezpečnější je propagovat jeden ověřený a označený artefakt.
Patří secrets do Docker image, když je registry soukromá?
Ne. Image se může kopírovat, cachovat nebo analyzovat a secret může zůstat ve vrstvě či logu. Tajemství patří do zabezpečeného runtime mechanismu cílového prostředí.
Jak držím kvalitu změn
Build, testy a vydaný artefakt chci mít dohledatelné jako jeden celek.
U PHP aplikací propojuji Composer, kontejnery a quality gates tak, aby byla každá verze sestavitelná, ověřitelná a bezpečně připravená pro další krok.