Continuous Delivery (CD): co to jest, czym różni się od Continuous Deployment

Co to jest Continuous Delivery

Continuous Delivery (CD) — to rozszerzenie Continuous Integration, dodające automatyzację wszystkich etapów przygotowania wydania: kompilację wersji wydaniowej, podpisywanie certyfikatami, zaciemnianie kodu, sprawdzanie metadanych sklepu z aplikacjami i wdrażanie na staging. Termin został wprowadzony przez Jeza Humble'a i Davida Farleya w książce „Continuous Delivery” (2010), w której sformalizowali praktykę umożliwiającą zespołom przewidywalne i niskoryzykowe wydania.

Ewolucja dostarczania oprogramowania

Przed wdrożeniem CD wydania były wydarzeniem: zespół spotykał się w sali, realizował listę kontrolną 20 punktów, uruchamiał skrypty ręcznie i miał nadzieję, że nic się nie zepsuje. Continuous Delivery przekształca wydanie z wydarzenia w proces: niewielka zmiana kodu może być dostarczona użytkownikom w ciągu minut, a nie tygodni. Amazon, Netflix i Etsy jako pierwsze wdrożyły CD w latach 2010. — dziś jest to standard dla zespołów produktowych.

Wartość biznesowa CD

Szybkie dostarczanie funkcji to przewaga konkurencyjna. Jeśli konkurent wdraża nową funkcjonalność w ciągu dni, a Ty w ciągu miesięcy, rynek wybiera konkurenta. Metryki DORA pokazują: elite-zespoły (z CD) mają czas wdrożenia poniżej 1 godziny, low-zespoły (bez CD) — od 1 tygodnia do 1 miesiąca. CD również radykalnie zmniejsza ryzyko: małe zmiany są trudniejsze do zepsucia niż duże wydanie raz na kwartał.

CD vs CI vs Continuous Deployment

Terminy CI, CD i Continuous Deployment są często mylone, ale istnieje między nimi wyraźna granica. Zrozumienie różnic pomaga prawidłowo zaprojektować potok i wybrać poziom automatyzacji odpowiadający dojrzałości zespołu i wymaganiom biznesowym.

Continuous Integration

CI to fundament, na którym buduje się CD. CI gwarantuje, że każdy commit przechodzi kompilację i testy. Bez CI niemożliwy jest CD: jeśli kod nie jest zweryfikowany, nie można go wydać. CI sprawdza poprawność, CD sprawdza gotowość do użytku biznesowego.

Continuous Delivery

CD dodaje do CI etapy przygotowania kompilacji wydaniowej, sprawdzania metadanych, podpisywania i wdrażania na staging lub do sklepu z aplikacjami w celu testów beta. Kluczowa różnica — decyzję o wydaniu produkcyjnym podejmuje człowiek (menedżer, właściciel produktu). CD sprawia, że wydanie jest „jednym kliknięciem” — proste i bezpieczne.

Continuous Deployment

Continuous Deployment to pełna automatyzacja: każda zmiana, która przeszła wszystkie etapy potoku CD, jest automatycznie wysyłana do produkcji bez ręcznego potwierdzenia. Continuous Deployment ma zastosowanie w produktach SaaS i usługach internetowych, ale rzadko jest używany w rozwoju aplikacji mobilnych ze względu na polityki sklepów z aplikacjami (App Store Review, Google Play Review wymagają ręcznego wysyłania).

Continuous Delivery dla aplikacji mobilnych

CD dla aplikacji mobilnych ma cechy odróżniające go od potoków internetowych i backendowych. Wydania mobilne przechodzą przez sklepy z aplikacjami (App Store Review, Google Play Review), co dodaje barierę czasową i proceduralną. CD automatyzuje wszystko, co można zautomatyzować przed wysłaniem do recenzji, aby zmaksymalizować szansę przejścia kontroli za pierwszym razem.

Przygotowanie do publikacji w Google Play

Android CD potok obejmuje: kompilację AAB (Android App Bundle), podpisanie kluczem wydaniowym, zaciemnianie przez R8/ProGuard, sprawdzenie rozmiaru APK i klas multidex, generowanie notatek wydania. Użycie Gradle product flavors (free/paid, dev/staging/prod) pozwala zarządzać wieloma konfiguracjami z jednego potoku.

Przygotowanie do publikacji w App Store

iOS CD wymaga podpisywania certyfikatami przez Fastlane match, sprawdzenia zgodności ikon (wymóg App Store — 1024×1024 px), walidacji metadanych (nazwa, opis, słowa kluczowe), sprawdzenia braku prywatnych API. Technical validation jest wykonywane przez altool --validate-app bez przesyłania do App Store Connect, co zapewnia szybką informację zwrotną.

# Fastfile — pełny potok CD dla iOS i Androida
platform :ios do
  desc "iOS CD — przygotowanie wydania i przesyłanie 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 — kompilacja AAB i przesyłanie 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 zbiera zrzuty ekranu, pobiera certyfikaty przez match, kompiluje IPA i przesyła do TestFlight. Lane deliver_to_internal dla Androida kompiluje Release AAB przez Gradle i przesyła go na wewnętrzny tor Google Play Console. Oba potoki są uruchamiane z CI po przejściu testów.

Komponenty potoku CD

Potok CD składa się z następujących po sobie etapów, z których każdy dodaje pewności, że wydanie jest gotowe dla użytkowników. Etapy dzielą się na techniczne (kompilacja, podpisywanie) i produktowe (sprawdzanie metadanych, zrzutów ekranu, opisu). Pominięcie dowolnego etapu zwiększa ryzyko odrzucenia wydania przez sklep z aplikacjami.

Zarządzanie wersjami

Krytyczny komponent CD — automatyczne zarządzanie wersjami. Version bump (versionCode i versionName dla Androida, CFBundleVersion i CFBundleShortVersionString dla iOS) jest wykonywany na podstawie tagów Git lub poprzedniej wersji w sklepie. Fastlane increment_version_number i komendy Gradle (versionCode auto-increment) automatyzują ten krok.

Metadane sklepu

Google Play Console i App Store Connect wymagają: opisu aplikacji, słów kluczowych, kategorii, oceny, linków do polityki prywatności. CD obejmuje sprawdzenie obecności i poprawności metadanych. Fastlane deliver i supply automatyzują przesyłanie opisu, zrzutów ekranu i ikon wraz z kompilacją.

Kontrole bramkowe (gate)

Przed wysłaniem do recenzji potok wykonuje kontrole bramkowe: sprawdzenie rozmiaru kompilacji (APK > 200 MB jest odrzucane przez Google Play), obecność wszystkich lokalizacji, brak symboli debug w kompilacji wydaniowej, sprawdzenie pliku mapowania ProGuard do dekodowania logów crashy. Jeśli choć jedna kontrola nie przejdzie — potok blokuje wydanie.

Testy zautomatyzowane dla CD

Poziom zaufania do CD jest wprost proporcjonalny do jakości testów automatycznych. Jeśli testy nie łapią regresji — wydanie może zepsuć produkcję, a zespół traci zaufanie do CD. Mobilne CD wymaga trzypoziomowej piramidy testowania dostosowanej do specyfiki platformy.

Testy jednostkowe

Testy jednostkowe sprawdzają logikę biznesową w izolacji. Pokrycie kodu powinno wynosić co najmniej 70% dla krytycznych modułów (uwierzytelnianie, płatności, komunikacja sieciowa). CI uruchamia testy jednostkowe przy każdym pushu, a jeśli nie przejdą — potok CD jest blokowany do czasu naprawy.

Testy integracyjne

Sprawdzają interakcje komponentów: warstwę sieciową z rzeczywistym API (lub serwerem mock), bazę danych, system plików. Testy Room DAO dla Androida, testy Core Data dla iOS — przykłady testów integracyjnych. Są wolniejsze niż testy jednostkowe (1–5 minut) i wykonywane na etapie CD, a nie CI przy każdym commicie.

Testy UI i zrzutów ekranu

Testy zrzutów ekranu (snapshot testing) porównują ekrany aplikacji z wzorcowymi obrazami. Jeśli zmiana kodu zmieniła UI — test nie przechodzi, a programista sprawdza, czy zmiana jest oczekiwana. Android obsługuje Roborazzi i Paparazzi, iOS — SnapshotTesting od Point-Free. Testy zrzutów ekranu są wykonywane przed wydaniem jako część potoku CD.

Najlepsze praktyki Continuous Delivery

Wdrożenie Continuous Delivery wymaga nie tylko narzędzi, ale także zmiany kultury zespołu. Poniższe praktyki opierają się na wieloletnim doświadczeniu zespołów mobilnych z Google, Spotify i Uber i są dostosowane do projektów dowolnej wielkości.

Feature flags

Kod nowej funkcji jest dostarczany do produkcji, ale ukryty za flagą. Feature flags pozwalają wdrożyć kod wcześniej, niż funkcja będzie gotowa do pokazania użytkownikom, i natychmiast ją wyłączyć w razie problemów. Biblioteki: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags to obowiązkowy warunek dla CD w projektach mobilnych.

Staging

Przed wysłaniem do produkcji kompilacja jest publikowana na stagingu — środowisku identycznym z produkcyjnym, ale z danymi testowymi. Inżynierowie QA sprawdzają funkcję na kompilacji stagingowej zainstalowanej przez TestFlight lub Internal Testing track. Jeśli staging przechodzi — kompilacja otrzymuje zgodę na wysłanie do recenzji w sklepie.

Notatki wydania i changelog

CD automatycznie generuje notatki wydania na podstawie commit messages. Conventional Commits (feat:, fix:, chore:) i tagi Git w formacie semantic versioning pozwalają parsować historię zmian. Fastlane changelog_from_git_commits zbiera zmiany między ostatnimi dwoma tagami i formatuje je dla sklepu z aplikacjami.

Monitorowanie po wydaniu

CD nie kończy się na publikacji — po wydaniu uruchamiane jest monitorowanie: crash rate, ANR rate dla Androida, czas uruchamiania, częstotliwość błędów płatności. Jeśli metryki wykraczają poza normę — potok CD powinien automatycznie wycofać wydanie lub powiadomić zespół. Narzędzia: Firebase Crashlytics, Sentry, New Relic.

// Przykład Feature Flag z Firebase Remote Config dla 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")
    }
}

// Użycie w kodzie
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}