Vydat, nahrát, aplikovat — podstata termínů a rozdíly

Co znamená „vydat”, „nahrát”, „aplikovat”

„Vydat” — nejobecnější termín znamenající publikování nové verze softwarového produktu, funkce nebo změny. „Vydali jsme aktualizaci”, „vydali jsme opravu”, „vydali jsme verzi” — ve všech případech jde o to, že změna se stala dostupnou uživatelům. Termín předpokládá poměrně velkou akci: obvykle se vydává celá verze, ne jeden soubor.

„Nahrát” — konkrétnější termín znamenající nahrání souborů, dat nebo artefaktů na server nebo do úložiště. „Nahraj build na server”, „nahraj skripty do DB”, „nahraj assety do CDN”. Na rozdíl od „vydat” termín nepředpokládá, že nahrané se stalo dostupným uživatelům — soubory mohou být na serveru, ale ještě připojeny k aplikaci. Nuance: „nahrát” se také používá pro odeslání kódu do úložiště („nahrál jsem na GitHub”).

„Aplikovat” — termín znamenající aplikování změny na stávající verzi. „Aplikovat migraci”, „aplikovat patch”, „aplikovat konfiguraci”. Klíčový rozdíl — změna se aplikuje navrch bez úplného nahrazení. Pokud „vydat” znamená spustit novou verzi místo staré, pak „aplikovat” znamená přidat změnu k tomu, co již funguje. Termín je rozšířen v kontextu databází (migrace) a patch vydání.

Další termíny ze stejného sémantického pole: „rozšířit” (rozšířit změnu na všechny servery v clusteru), „vrátit” (obnovit předchozí verzi), „omylem nasadit” (omylem nasadit špatnou verzi). Všechna tato slovesa popisují akce s kódem jako s fyzickým objektem, který lze „válet”, „lít” a „vracet zpět”.

Původ slangových termínů

Termín „vydat” pochází z automobilové metafory: „vyjet s autem z garáže”. Když je kód připraven k vydání, je „vydán” — vypuštěn ven, zpřístupněn uživatelům. Metafora se rozšířila na počátku 21. století s nástupem continuous delivery praktik, kdy se vydání stala pravidelnými, nikoli ročními. „Dnes máme vydání” — znamená den vydání.

Termín „nahrát” má kořeny v raném webu, kdy byly weby nahrávány na servery přes FTP. „Nahrát soubory na server” — doslova přenést soubory protokolem, který byl spojován s „léváním” dat. Slovo zůstalo, i když moderní nasazení používá CI/CD pipeline, ne FTP klienty. Zajímavost: v angličtině je analogem „push” (push to server), nikoli „pour”. Ruština si vybrala jinou metaforu.

Termín „aplikovat” pochází z výrobního prostředí: „nasadit kolo”, „našroubovat matici”. V kontextu softwaru — aplikovat změnu na stávající systém, jako se nasazuje závit na šroub. V databázích je termín obzvláště organický: migrace se právě „aplikují” (apply) a „vracejí” (rollback). Rollback — jeden z mála anglických termínů, který má přesný český ekvivalent „vrácení”.

Rozdíl mezi termíny v různých kontextech

V kontextu databází: migrace se „aplikují”, data se „nahrávají”, verze schématu se „vydává”. Pokud je třeba přidat nový sloupec — aplikuje se migrace. Pokud je třeba vložit testovací data — nahraje se dump. Pokud se struktura databáze zcela změní — vydá se nové schéma. Rozdíl odráží různé operace: apply, insert/load, deploy.

V kontextu DevOps: „vydat” — spustit pipeline, „nahrát” — nahrát Docker image do registru, „aplikovat” — aplikovat konfiguraci na server přes Ansible. Příklad: „nejdřív nahrajeme image do registru, pak aplikujeme config na server, a teprve potom vydáme verzi”. Každý termín odpovídá samostatné fázi CI/CD pipeline.

V kontextu mobilního vývoje: „nahrát” — odeslat build do App Store Connect nebo Google Play Console, „vydat” — publikovat v obchodě s aplikacemi, „aplikovat” — doručit aktualizaci pomocí mechanismu in-app updates. Pro iOS „vydat” znamená projít Review, pro Android — rollout přes Play Console. Časová škála: „nahrání” trvá minuty, „vydání” — hodiny nebo dny (kvůli review).

Fáze procesu vydání: od commitu k produkci

Fáze 1: Sestavení (Build). Kód je zkompilován, vzniká artefakt (binárka, Docker image, APK/IPA). CI server spouští sestavení po každém commitu do hlavní větve. Výsledek sestavení — artefakt připravený k nasazení s unikátním tagem verze (semantic versioning nebo commit hash). Pokud sestavení selže — celý pipeline se zastaví, vývojář obdrží oznámení.

Fáze 2: Testování (Test). Spouští se unit testy, integrační testy, lintery, bezpečnostní kontrola (SAST). Tato fáze by neměla trvat déle než 10–15 minut — pokud déle, vývojáři ztrácejí kontext a přecházejí na jiné úkoly. Rychlá zpětná vazba — klíčový princip CI/CD. Podle Puppet State of DevOps 2023 dělají týmy s rychlým testováním (<10 min) 3krát více vydání.

Fáze 3: Nasazení na staging (Staging Deploy). Artefakt je nasazen na stagingové prostředí, identické s produkcí. Na stagingu se provádějí E2E testy, smoke testy a v případě potřeby ruční QA testování. Pokud je na stagingu zjištěna regrese — vydání je zablokováno, změny jsou odeslány k opravě.

Fáze 4: Rollout na produkci (Production Deploy). Artefakt je nasazen na produkční servery. V závislosti na strategii nasazení (rolling, blue-green, canary) může rollout trvat od několika sekund do několika hodin. Po rolloutu se spouští post-deploy testy a monitoring — pokud jsou metriky v normě, vydání je považováno za úspěšné. Automatické vrácení při překročení prahu chyb — standardní praxe.

Strategie nasazení: rolling, blue-green, canary

Rolling deploy — aktualizace serverů jeden po druhém. Zatímco jeden server je aktualizován, ostatní nadále obsluhují uživatele. Po úspěšné aktualizaci prvního serveru se aktualizuje druhý, a tak dále. Nevýhoda: během nasazení na serverech běží různé verze, což může způsobit nekompatibilitu. Výhoda: zero-downtime a absence potřeby dvojnásobného počtu serverů.

Blue-green deploy — dvě identická prostředí: Blue (aktuální verze) a Green (nová verze). Poté, co je Green plně připraven a otestován, load balancer přesměruje provoz z Blue na Green. Pokud je v Green zjištěn problém — přepneme se zpět na Blue. Výhoda: okamžitý rollback. Nevýhoda: je potřeba dvojnásobek zdrojů (serverů) pro podporu dvou prostředí. Přepnutí trvá sekundy.

Canary deploy — nová verze je nejprve nasazena na malé procento serverů (5–10%). Část uživatelů se dostane na novou verzi, zbytek na starou. Pokud jsou metriky v canary skupině v normě (error rate se nezvýšil, latency se nezvětšila), nová verze je postupně rozšířena na všechny servery. Google, Netflix, Spotify používají canary deploy k minimalizaci rizik. Nevýhoda: složitost monitoringu a analýzy metrik.

Nástroje pro automatizaci nasazení

CI/CD servery — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (pro mobil). Vybírají se podle stacku: Jenkins — univerzální, GitLab CI — pokud je repozitář na GitLabu, Bitrise — pro iOS/Android. Hlavním úkolem CI/CD serveru — automatické spuštění pipeline sestavení, testování a nasazení bez lidského zásahu.

Kontejnerizace — Docker, Kubernetes. Docker vytváří izolované kontejnery s aplikací a všemi závislostmi. Kubernetes řídí nasazení kontejnerů na clusteru serverů: automatický rolling update, škálování, load balancing. Podle CNCF Survey 2023 používá 96 % organizací kontejnery v produkci, z toho 67 % — Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform popisuje infrastrukturu (servery, sítě, load balancery) ve formě kódu a spravuje její stav. Ansible — konfigurace serverů: instalace softwaru, nastavení parametrů. Kombinace Terraform + Ansible poskytuje plně automatizovanou infrastrukturu: Terraform staví servery, Ansible je konfiguruje. Immutable infrastructure — servery se neaktualizují, ale nahrazují novými s aktualizovaným obrazem.