Kiadni, feltölteni, alkalmazni — a kifejezések lényege és különbségei

Mit jelent „kiadni”, „feltölteni”, „alkalmazni”

„Kiadni” — a legáltalánosabb kifejezés, amely egy szoftvertermék, funkció vagy változtatás új verziójának közzétételét jelenti. „Kiadta a frissítést”, „kiadta a javítást”, „kiadta a kiadást” — minden esetben arról van szó, hogy a változtatás elérhetővé vált a felhasználók számára. A kifejezés egy meglehetősen nagy akciót feltételez: általában a teljes verziót adják ki, nem egyetlen fájlt.

„Feltölteni” — egy konkrétabb kifejezés, amely fájlok, adatok vagy artefaktumok szerverre vagy tárhelyre történő feltöltését jelenti. „Töltsd fel a buildet a szerverre”, „töltsd fel a szkripteket az adatbázisba”, „töltsd fel az eszközöket a CDN-be”. Ellentétben a „kiadni” kifejezéssel, ez nem feltételezi, hogy a feltöltött tartalom elérhetővé vált a felhasználók számára — a fájlok lehetnek a szerveren, de még nem csatlakoztak az alkalmazáshoz. Árnyalat: a „feltölteni” a kód adattárba küldésére is használatos („feltöltöttem a GitHubra”).

„Alkalmazni” — egy kifejezés, amely egy változtatás meglévő verzióra történő alkalmazását jelenti. „Alkalmazd a migrációt”, „alkalmazd a javítást”, „alkalmazd a konfigurációt”. A kulcsfontosságú különbség — a változtatás a tetejére kerül teljes csere nélkül. Ha a „kiadni” az új verzió elindítása a régi helyett, akkor az „alkalmazni” egy változtatás hozzáadása ahhoz, ami már működik. A kifejezés elterjedt az adatbázisok (migrációk) és a javító kiadások kontextusában.

További kifejezések ugyanabból a szemantikai mezőből: „kiterjeszteni” (a változtatás elterjesztése a klaszter összes szerverére), „visszaállítani” (az előző verzió visszaállítása), „véletlenül telepíteni” (véletlenül rossz verziót telepíteni). Mindezek az igék a kóddal végzett műveleteket fizikai tárgyként írják le, amelyet „gurítani”, „önteni” és „visszagurítani” lehet.

A szlengkifejezések eredete

A „kiadni” kifejezés az autós metaforából származik: „kivinni az autót a garázsból”. Amikor a kód készen áll a kiadásra, „kiadják” — kibocsátják, elérhetővé teszik a felhasználók számára. A metafora a 2000-es évek elején terjedt el a continuous delivery gyakorlatok megjelenésével, amikor a kiadások rendszeressé váltak, nem évesek. „Ma van a kiadásunk” — a kiadás napját jelenti.

A „feltölteni” kifejezés a korai webben gyökerezik, amikor a weboldalakat FTP-n keresztül töltötték fel szerverekre. „Fájlok feltöltése a szerverre” — szó szerint fájlok átvitele a protokollon keresztül, amely az adatok „kiöntésével” volt kapcsolatos. A szó megmaradt, bár a modern telepítés CI/CD pipeline-okat használ, nem FTP klienseket. Érdekes tény: angolban az analóg „push” (push to server), nem „pour”. Az orosz nyelv más metaforát választott.

A „alkalmazni” kifejezés a termelési környezetből származik: „kereket feltenni”, „anyát felcsavarni”. A szoftver kontextusában — változtatást alkalmazni egy meglévő rendszerre, mint a menetet egy csavarra. Az adatbázisokban a kifejezés különösen organikus: a migrációkat pontosan „alkalmazzák” (apply) és „visszaállítják” (rollback). Rollback — azon kevés angol kifejezések egyike, amelynek pontos magyar megfelelője van: „visszaállítás”.

A kifejezések közötti különbség különböző kontextusokban

Az adatbázisok kontextusában: a migrációkat „alkalmazzák”, az adatokat „feltöltik”, a séma verzióját „kiadják”. Ha új oszlopot kell hozzáadni — migrációt alkalmaznak. Ha tesztadatokat kell beszúrni — dumpot töltenek fel. Ha az adatbázis szerkezete teljesen megváltozik — új sémát adnak ki. A különbség különböző műveleteket tükröz: apply, insert/load, deploy.

A DevOps kontextusában: „kiadni” — a pipeline elindítása, „feltölteni” — a Docker kép feltöltése a registry-be, „alkalmazni” — a konfiguráció alkalmazása a szerverre Ansible-en keresztül. Példa: „először töltsük fel a képet a registry-be, aztán alkalmazzuk a konfigot a szerverre, és csak azután adjuk ki a kiadást”. Minden kifejezés a CI/CD pipeline egy különálló szakaszának felel meg.

A mobilfejlesztés kontextusában: „feltölteni” — a build elküldése az App Store Connectbe vagy Google Play Console-ba, „kiadni” — közzététel az alkalmazásboltban, „alkalmazni” — a frissítés kézbesítése in-app updates mechanizmuson keresztül. iOS esetén a „kiadni” a Review-n való átesést jelenti, Android esetén — rolloute-ot a Play Console-on keresztül. Időskála: a „feltöltés” percekig tart, a „kiadás” — órákig vagy napokig (a review miatt).

A kiadási folyamat szakaszai: a committól a productionig

1. szakasz: Build (Build). A kód lefordításra kerül, létrejön az artefaktum (bináris, Docker kép, APK/IPA). A CI szerver minden commit után elindítja a buildet a fő ágban. A build eredménye — egy telepítésre kész artefaktum egyedi verziócímkével (semantic versioning vagy commit hash). Ha a build meghiúsul — a teljes pipeline leáll, a fejlesztő értesítést kap.

2. szakasz: Tesztelés (Test). Egységtesztek, integrációs tesztek, linterek, biztonsági ellenőrzés (SAST) futnak. Ez a szakasz nem tarthat tovább 10–15 percnél — ha tovább tart, a fejlesztők elveszítik a kontextust és más feladatokra váltanak. Gyors visszajelzés — a CI/CD kulcsfontosságú elve. A Puppet State of DevOps 2023 szerint a gyors tesztelésű csapatok (<10 perc) 3-szor több kiadást készítenek.

3. szakasz: Telepítés stagingre (Staging Deploy). Az artefaktum a productionnel azonos staging környezetbe kerül telepítésre. A stagingen E2E tesztek, smoke tesztek és szükség esetén kézi QA tesztelés futnak. Ha a stagingen regressziót észlelnek — a kiadás blokkolásra kerül, a változtatásokat javításra küldik.

4. szakasz: Rollout productionbe (Production Deploy). Az artefaktum a production szerverekre kerül telepítésre. A telepítési stratégiától függően (rolling, blue-green, canary) a rollout néhány másodperctől néhány óráig tarthat. A rollout után post-deploy tesztek és monitoring indulnak — ha a metrikák normálisak, a kiadás sikeresnek minősül. Automatikus visszaállítás a hibaküszöb túllépése esetén — szabványos gyakorlat.

Telepítési stratégiák: rolling, blue-green, canary

Rolling deploy — a szerverek egyenkénti frissítése. Amíg az egyik szerver frissül, a többiek tovább szolgálják a felhasználókat. Az első szerver sikeres frissítése után a második frissül, és így tovább. Hátrány: a telepítés során különböző verziók futnak a szervereken, ami inkompatibilitást okozhat. Előny: zero-downtime és nincs szükség kétszeres számú szerverre.

Blue-green deploy — két azonos környezet: Blue (aktuális verzió) és Green (új verzió). Miután a Green teljesen kész és tesztelt, a load balancer átkapcsolja a forgalmat Blue-ról Green-re. Ha a Green-en problémát észlelnek — visszakapcsolunk Blue-ra. Előny: azonnali rollback. Hátrány: kétszer annyi erőforrás (szerver) szükséges két környezet támogatásához. Átkapcsolás másodpercekig tart.

Canary deploy — az új verziót először a szerverek kis százalékára (5–10%) telepítik. A felhasználók egy része az új verzióra kerül, a többiek a régire. Ha a canary csoportban a metrikák normálisak (hibaarány nem nőtt, latency nem emelkedett), az új verziót fokozatosan kiterjesztik az összes szerverre. A Google, Netflix, Spotify a kockázat minimalizálása érdekében használ canary deploy-t. Hátrány: a monitoring és a metrikák elemzésének összetettsége.

Telepítés automatizálási eszközök

CI/CD szerverek — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (mobilhoz). A stack függvényében választják: Jenkins — univerzális, GitLab CI — ha a repó GitLabon van, Bitrise — iOS/Androidhoz. A CI/CD szerver fő feladata — a build, tesztelés és telepítés pipeline automatizált futtatása emberi beavatkozás nélkül.

Konténeresítés — Docker, Kubernetes. A Docker izolált konténereket hoz létre az alkalmazással és annak összes függőségével. A Kubernetes menedzseli a konténerek telepítését a szerverklaszteren: automatikus rolling update, skálázás, terheléselosztás. A CNCF Survey 2023 szerint a szervezetek 96%-a használ konténereket productionben, közülük 67% Kubernetes-t.

Infrastructure as Code — Terraform, Ansible, Pulumi. A Terraform kód formájában írja le az infrastruktúrát (szerverek, hálózatok, load balancerek) és kezeli annak állapotát. Az Ansible — szerverek konfigurálása: szoftver telepítése, paraméterek beállítása. A Terraform + Ansible kombináció teljesen automatizált infrastruktúrát biztosít: a Terraform felépíti a szervereket, az Ansible konfigurálja őket. Immutable infrastructure — a szerverek nem frissülnek, hanem új, frissített képpel rendelkező szerverekre cserélik őket.