Continuous Delivery (CD): co to je a čím se liší od Continuous Deployment

Co je Continuous Delivery

Continuous Delivery (CD) — to je rozšíření Continuous Integration, které přidává automatizaci všech fází přípravy verze: sestavení release buildu, podepsání certifikáty, obfuskaci, kontrolu metadat obchodu s aplikacemi a nasazení na staging. Termín zavedli Jez Humble a David Farley v knize „Continuous Delivery“ (2010), kde formalizovali praxi umožňující týmům učinit verze předvídatelnými a nízce rizikovými.

Evoluce doručování softwaru

Před zavedením CD byly verze událostí: tým se sešel v místnosti, prošel kontrolní seznam o 20 bodech, ručně spouštěl skripty a doufal, že se nic nerozbije. Continuous Delivery přeměňuje verzi z události na proces: malá změna kódu může být uživatelům doručena za minuty, ne za týdny. Amazon, Netflix a Etsy zavedly CD jako první v 2010. letech — dnes je to standard pro produktové týmy.

Obchodní hodnota CD

Rychlé doručování funkcí je konkurenční výhodou. Pokud konkurent spouští novou funkcionalitu za dny a vy za měsíce, trh si vybere konkurenta. DORA metriky ukazují: elite týmy (s CD) mají dobu vydání méně než 1 hodinu, low týmy (bez CD) — od 1 týdne do 1 měsíce. CD také radikálně snižuje riziko: malé změny se rozbíjejí obtížněji než velká verze jednou za čtvrtletí.

CD vs CI vs Continuous Deployment

Termíny CI, CD a Continuous Deployment se často zaměňují, ale mezi nimi je jasná hranice. Pochopení rozdílů pomáhá správně navrhnout pipeline a zvolit úroveň automatizace odpovídající vyspělosti týmu a obchodním požadavkům.

Continuous Integration

CI je základ, na kterém se CD staví. CI zaručuje, že každý commit projde sestavením a testy. Bez CI je CD nemožné: pokud kód není ověřen, nelze jej vydat. CI kontroluje správnost, CD kontroluje připravenost k obchodnímu použití.

Continuous Delivery

CD přidává k CI fáze přípravy release buildu, kontroly metadat, podepisování a nasazení na staging nebo do obchodu s aplikacemi pro beta testování. Klíčový rozdíl — rozhodnutí o vydání do produkce dělá člověk (manažer, vlastník produktu). CD dělá verzi „jedním kliknutím“ — jednoduchou a bezpečnou.

Continuous Deployment

Continuous Deployment je plná automatizace: každá změna, která projde všemi fázemi CD pipeline, je automaticky odeslána do produkce bez ručního potvrzení. Continuous Deployment je použitelný pro SaaS produkty a webové služby, ale v mobilním vývoji se používá zřídka kvůli politikám obchodů s aplikacemi (App Store Review, Google Play Review vyžaduje ruční odeslání).

Continuous Delivery pro mobilní aplikace

CD pro mobilní aplikace má zvláštnosti, které jej odlišují od webových a backend pipeline. Mobilní verze procházejí obchody s aplikacemi (App Store Review, Google Play Review), což přidává časovou a procesní bariéru. CD automatizuje vše, co lze automatizovat před odesláním na review, aby se maximalizovala šance na projití kontroly napoprvé.

Příprava na publikaci v Google Play

Android CD pipeline zahrnuje: sestavení AAB (Android App Bundle), podepsání release klíčem, obfuskaci přes R8/ProGuard, kontrolu velikosti APK a multidex tříd, generování poznámek k verzi. Použití Gradle product flavors (free/paid, dev/staging/prod) umožňuje spravovat více konfigurací z jednoho pipeline.

Příprava na publikaci v App Store

iOS CD vyžaduje podepsání certifikáty přes Fastlane match, kontrolu souladu ikon (požadavek App Store — 1024×1024 px), validaci metadat (název, popis, klíčová slova), kontrolu nepřítomnosti privátních API. Technická validace se provádí přes altool --validate-app bez nahrávání do App Store Connect, což poskytuje rychlou zpětnou vazbu.

# Fastfile — kompletní CD pipeline pro iOS a Android
platform :ios do
  desc "iOS CD — příprava verze a nahrání do TestFlight"
  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 — sestavení AAB a nahrání do Google Play Console"
  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

Fastlane deliver_to_testflight shromažďuje snímky obrazovky, získává certifikáty přes match, sestavuje IPA a nahrává do TestFlight. Lane deliver_to_internal pro Android sestavuje Release AAB přes Gradle a nahrává jej na interní track Google Play Console. Oba pipeline se spouštějí z CI po projití testů.

Komponenty CD pipeline

CD pipeline se skládá z postupných fází, z nichž každá přidává důvěru v to, že verze je připravena pro uživatele. Fáze se dělí na technické (sestavení, podepisování) a produktové (kontrola metadat, snímků obrazovky, popisu). Přeskočení jakékoli fáze zvyšuje riziko odmítnutí verze obchodem s aplikacemi.

Správa verzí

Kritickou komponentou CD je automatická správa verzí. Version bump (versionCode a versionName pro Android, CFBundleVersion a CFBundleShortVersionString pro iOS) se provádí na základě Git tagů nebo předchozí verze v obchodě. Fastlane increment_version_number a příkazy Gradle (versionCode auto-increment) tento krok automatizují.

Metadata obchodu

Google Play Console a App Store Connect vyžadují: popis aplikace, klíčová slova, kategorii, hodnocení, odkazy na zásady ochrany soukromí. CD zahrnuje kontrolu existence a správnosti metadat. Fastlane deliver a supply automatizují nahrávání popisu, snímků obrazovky a ikon společně s buildem.

Gate kontroly

Před odesláním na review pipeline provádí gate kontroly: kontrolu velikosti buildu (APK větší než 200 MB Google Play odmítá), přítomnost všech lokalizací, nepřítomnost debug symbolů v release buildu, kontrolu ProGuard mapping souboru pro dekódování crash logů. Pokud jakákoli kontrola neprojde, pipeline blokuje vydání.

Automatizované testování pro CD

Úroveň důvěry v CD je přímo úměrná kvalitě automatických testů. Pokud testy nezachycují regrese, verze může rozbít produkci a tým ztrácí důvěru v CD. Mobilní CD vyžaduje tříúrovňovou pyramidu testování přizpůsobenou specifikům platformy.

Unit testy

Unit testy kontrolují obchodní logiku izolovaně. Pokrytí kódu by mělo být alespoň 70% u kritických modulů (autentizace, platby, práce se sítí). CI spouští unit testy při každém push a pokud padají, CD pipeline je blokován do opravy.

Integrační testy

Kontrolují interakci komponent: síťovou vrstvu se skutečným API (nebo mock serverem), databázi, souborový systém. Room DAO testy pro Android, Core Data testy pro iOS — příklady integračních testů. Jsou pomalejší než unit testy (1–5 minut) a provádějí se ve fázi CD, ne v CI při každém commitu.

UI a screenshot testy

Screenshot testy (snapshot testing) porovnávají obrazovky aplikace s referenčními snímky. Pokud změna kódu změnila UI, test padá a vývojář kontroluje, zda je změna očekávaná. Android podporuje Roborazzi a Paparazzi, iOS — SnapshotTesting od Point-Free. Screenshot testy se provádějí před vydáním jako součást CD pipeline.

Nejlepší postupy Continuous Delivery

Zavedení Continuous Delivery vyžaduje nejen nástroje, ale i změnu kultury týmu. Níže uvedené postupy vycházejí z mnohaletých zkušeností mobilních týmů z Googlu, Spotify a Uberu a jsou přizpůsobeny projektům jakékoli velikosti.

Feature flagy

Kód nové funkce se dodává do produkce, ale je skryt za flagem. Feature flagy umožňují vydat kód dříve, než je funkce připravena k zobrazení uživatelům, a okamžitě ji vypnout při problémech. Knihovny: LaunchDarkly, Firebase Remote Config, Unleash. Feature flagy jsou povinnou podmínkou pro CD v mobilních projektech.

Staging prostředí

Před odesláním do produkce se build nasazuje na staging — prostředí identické s produkcí, ale s testovacími daty. QA inženýři kontrolují funkci na staging buildu nainstalovaném přes TestFlight nebo Internal Testing track. Pokud staging projde, build dostane schválení k odeslání na review do obchodu.

Poznámky k verzi a changelog

CD automaticky generuje poznámky k verzi na základě commit messages. Conventional Commits (feat:, fix:, chore:) a Git tagy ve formátu semantic versioning umožňují analyzovat historii změn. Fastlane changelog_from_git_commits shromažďuje změny mezi posledními dvěma tagy a formátuje je pro obchod s aplikacemi.

Monitoring po vydání

CD nekončí publikováním — po vydání se spouští monitoring: crash rate, ANR rate pro Android, doba spuštění, četnost selhání plateb. Pokud metriky překročí normální hranici, CD pipeline by měl verzi automaticky vrátit nebo informovat tým. Nástroje: Firebase Crashlytics, Sentry, New Relic.

// Příklad Feature Flagu s Firebase Remote Config pro CD
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

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

// Použití v kódu
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}