Continuous Delivery (CD): mi ez, és miben különbözik a Continuous Deploymenttől

Mi az a Continuous Delivery

Continuous Delivery (CD) — a Continuous Integration kiterjesztése, amely automatizálást ad hozzá a release-előkészítés összes szakaszához: a release build elkészítése, tanúsítványokkal való aláírás, obfuszkáció, az alkalmazásbolt metaadatainak ellenőrzése és a stagingre történő deploy. A kifejezést Jez Humble és David Farley vezette be a „Continuous Delivery“ (2010) című könyvben, ahol formalizálták azt a gyakorlatot, amely lehetővé teszi a csapatok számára, hogy a release-eket kiszámíthatóvá és alacsony kockázatúvá tegyék.

A szoftverszállítás evolúciója

A CD bevezetése előtt a release-ek eseménynek számítottak: a csapat összegyűlt egy teremben, végigment egy 20 pontos ellenőrzőlistán, manuálisan futtatta a szkripteket, és remélte, hogy semmi nem romlik el. A Continuous Delivery a release-t eseményből folyamattá alakítja: egy kis kódváltoztatás percek alatt eljuttatható a felhasználókhoz, nem hetek alatt. Az Amazon, a Netflix és az Etsy vezette be először a CD-t a 2010-es években — ma ez a termékcsapatok szabványa.

A CD üzleti értéke

A funkciók gyors szállítása versenyelőnyt jelent. Ha a versenytárs napok alatt indítja el az új funkcionalitást, Ön pedig hónapok alatt, a piac a versenytársat választja. A DORA metrikák azt mutatják: az elite csapatok (CD-vel) kiadási ideje kevesebb mint 1 óra, a low csapatoké (CD nélkül) 1 héttől 1 hónapig tart. A CD radikálisan csökkenti a kockázatot is: a kis változtatásokat nehezebb elrontani, mint egy nagy, negyedévenkénti release-t.

CD vs CI vs Continuous Deployment

A CI, CD és Continuous Deployment kifejezéseket gyakran összekeverik, de közöttük egyértelmű határ van. A különbségek megértése segít helyesen megtervezni a pipeline-t és kiválasztani a csapat érettségének és üzleti követelményeknek megfelelő automatizálási szintet.

Continuous Integration

A CI az az alap, amelyre a CD épül. A CI garantálja, hogy minden commit átmegy a builden és a teszteken. CI nélkül a CD lehetetlen: ha a kód nincs ellenőrizve, nem adható ki. A CI a helyességet ellenőrzi, a CD az üzleti használatra való készséget.

Continuous Delivery

A CD a CI-hez hozzáadja a release build elkészítésének, a metaadatok ellenőrzésének, az aláírásnak és a stagingre vagy az alkalmazásboltba történő, béta tesztelésre szánt telepítésnek a szakaszait. A fő különbség — a produkcióba való kiadásról ember dönt (menedzser, terméktulajdonos). A CD „egy kattintásossá“ teszi a release-t — egyszerűvé és biztonságossá.

Continuous Deployment

A Continuous Deployment teljes automatizálás: minden, a CD pipeline minden szakaszán átment változtatás manuális megerősítés nélkül automatikusan kerül produkcióba. A Continuous Deployment SaaS-termékekre és webszolgáltatásokra alkalmazható, de a mobilfejlesztésben ritkán használják az alkalmazásboltok szabályzatai miatt (az App Store Review, Google Play Review manuális beküldést igényel).

Continuous Delivery mobilalkalmazásokhoz

A mobilalkalmazások CD-je olyan sajátosságokkal rendelkezik, amelyek megkülönböztetik a webes és backend pipeline-októl. A mobil release-ek az alkalmazásboltokon (App Store Review, Google Play Review) mennek keresztül, ami időbeli és folyamatbeli akadályt jelent. A CD mindent automatizál, amit a review-ba küldés előtt lehet, hogy maximalizálja az ellenőrzés első próbálkozásra történő átmenésének esélyét.

Felkészülés a Google Play-en való közzétételre

Az Android CD pipeline magában foglalja: az AAB (Android App Bundle) elkészítését, release kulccsal történő aláírást, obfuszkációt az R8/ProGuard segítségével, az APK méretének és a multidex osztályok ellenőrzését, a release-jegyzetek generálását. A Gradle product flavors (free/paid, dev/staging/prod) használata lehetővé teszi több konfiguráció kezelését egyetlen pipeline-ból.

Felkészülés az App Store-ban való közzétételre

Az iOS CD megköveteli a Fastlane match segítségével történő tanúsítvánnyal való aláírást, az ikonok megfelelőségének ellenőrzését (az App Store követelménye — 1024×1024 px), a metaadatok (név, leírás, kulcsszavak) validálását, a privát API-k hiányának ellenőrzését. A technikai validálás az altool --validate-app segítségével történik, App Store Connect feltöltése nélkül, ami gyors visszajelzést ad.

# Fastfile — teljes CD pipeline iOS-hez és Androidhoz
platform :ios do
  desc "iOS CD — release előkészítése és feltöltés a TestFlightba"
  lane :deliver_to_testflight do
    capture_screenshots
    match(type: "appstore")
    build_app(
      scheme: "MyApp",
      export_method: "app-store",
      workspace: "MyApp.xcworkspace"
    )
    pilot(skip_waiting_for_build: true)
  end
end

platform :android do
  desc "Android CD — AAB építése és feltöltés a Google Play Console-ba"
  lane :deliver_to_internal do
    gradle(
      task: "bundleRelease",
      build_type: "Release",
      print_command: true
    )
    upload_to_play_store(
      track: "internal",
      skip_upload_metadata: true
    )
  end
end

A Fastlane deliver_to_testflight összegyűjti a képernyőképeket, a match-en keresztül megszerzi a tanúsítványokat, elkészíti az IPA-t, és feltölti a TestFlightba. Az Androidhoz tartozó deliver_to_internal lane a Gradle-en keresztül Release AAB-t épít, és feltölti a Google Play Console belső sávjába. Mindkét pipeline a tesztek átmenése után indul el a CI-ből.

A CD pipeline összetevői

A CD pipeline egymást követő szakaszokból áll, amelyek mindegyike növeli a bizalmat abban, hogy a release készen áll a felhasználók számára. A szakaszok technikai (build, aláírás) és termékbeli (metaadatok, képernyőképek, leírás ellenőrzése) csoportokra oszlanak. Bármely szakasz kihagyása növeli annak kockázatát, hogy az alkalmazásbolt elutasítja a release-t.

Verziókezelés

A CD kritikus összetevője az automatikus verziókezelés. A Version bump (versionCode és versionName Androidnál, CFBundleVersion és CFBundleShortVersionString iOS-nél) Git címkék vagy a boltban lévő korábbi verzió alapján történik. A Fastlane increment_version_number és a Gradle parancsok (versionCode auto-increment) automatizálják ezt a lépést.

A bolt metaadatai

A Google Play Console és az App Store Connect megköveteli: az alkalmazás leírását, kulcsszavakat, kategóriát, minősítést, az adatvédelmi szabályzatra mutató linkeket. A CD magában foglalja a metaadatok meglétének és helyességének ellenőrzését. A Fastlane deliver és supply automatizálja a leírás, a képernyőképek és az ikonok feltöltését a builddel együtt.

Gate-ellenőrzések

A review-ba küldés előtt a pipeline gate-ellenőrzéseket végez: a build méretének ellenőrzését (a 200 MB-nál nagyobb APK-t a Google Play elutasítja), az összes lokalizáció meglétét, a debug szimbólumok hiányát a release buildben, a ProGuard mapping fájl ellenőrzését a crash-logok dekódolásához. Ha bármelyik ellenőrzés nem sikerül, a pipeline blokkolja a release-t.

Automatizált tesztelés a CD-hez

A CD-be vetett bizalom szintje egyenesen arányos az automatikus tesztek minőségével. Ha a tesztek nem kapják el a regressziókat, a release tönkreteheti a produkciót, és a csapat elveszíti a bizalmát a CD-ben. A mobil CD háromszintű tesztelési piramist igényel, amely a platform sajátosságaihoz igazított.

Egységtesztek

Az egységtesztek elszigetelten ellenőrzik az üzleti logikát. A kódlefedettség kritikus modulok esetén (hitelesítés, fizetések, hálózati munka) legalább 70% kell, hogy legyen. A CI minden push-nál futtatja az egységteszteket, és ha azok elhasalnak, a CD pipeline a javításig blokkolva van.

Integrációs tesztek

A komponensek kölcsönhatását ellenőrzik: a hálózati réteget valós API-val (vagy mock szerverrel), az adatbázist, a fájlrendszert. A Room DAO tesztek Androidnál, a Core Data tesztek iOS-nél — az integrációs tesztek példái. Ezek lassabbak, mint az egységtesztek (1–5 perc), és a CD szakaszban futnak, nem a CI-ben minden commitnál.

UI és képernyőkép-tesztek

A képernyőkép-tesztek (snapshot testing) az alkalmazás képernyőit hasonlítják össze referencia képekkel. Ha a kódváltoztatás megváltoztatta a UI-t, a teszt elhasal, és a fejlesztő ellenőrzi, hogy a változás várt-e. Az Android támogatja a Roborazzi és Paparazzi megoldásokat, az iOS — a Point-Free SnapshotTestingjét. A képernyőkép-tesztek a release előtt futnak a CD pipeline részeként.

A Continuous Delivery legjobb gyakorlatai

A Continuous Delivery bevezetése nemcsak eszközöket, hanem a csapat kultúrájának megváltoztatását is igényli. Az alábbi gyakorlatok a Google, Spotify és Uber mobilcsapatainak többéves tapasztalatán alapulnak, és bármilyen méretű projekthez igazítottak.

Feature flag-ek

Az új funkció kódja produkcióba kerül, de egy flag mögé van rejtve. A Feature flag-ek lehetővé teszik, hogy a kódot korábban kiadják, mint ahogy a funkció kész lenne a felhasználóknak való megmutatásra, és problémák esetén azonnal kikapcsolják. Könyvtárak: LaunchDarkly, Firebase Remote Config, Unleash. A Feature flag-ek kötelező feltétel a CD-hez a mobilprojektekben.

Staging környezet

A produkcióba küldés előtt a build a stagingre kerül — a produkcióval azonos, de tesztadatokkal rendelkező környezetbe. A QA-mérnökök a TestFlighton vagy az Internal Testing sávon keresztül telepített staging builden ellenőrzik a funkciót. Ha a staging átmegy, a build jóváhagyást kap a boltba való review-ba küldéshez.

Release-jegyzetek és changelog

A CD automatikusan generál release-jegyzeteket a commit-üzenetek alapján. A Conventional Commits (feat:, fix:, chore:) és a semantic versioning formátumú Git címkék lehetővé teszik a változási előzmények elemzését. A Fastlane changelog_from_git_commits összegyűjti az utolsó két címke közötti változásokat, és formázza őket az alkalmazásbolt számára.

Monitoring a release után

A CD nem ér véget a publikálással — a release után monitoring indul: crash rate, ANR rate Androidnál, indítási idő, fizetési hibák gyakorisága. Ha a metrikák túllépik a normál határt, a CD pipeline-nak automatikusan vissza kell vonnia a release-t, vagy értesítenie kell a csapatot. Eszközök: Firebase Crashlytics, Sentry, New Relic.

// Feature Flag példa Firebase Remote Config-kal a CD-hez
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// Használat a kódban
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}