Continuous Delivery (CD): ce este, cum diferă de Continuous Deployment

Ce este Continuous Delivery

Continuous Delivery (CD) — este o extensie a Continuous Integration, care adaugă automatizarea tuturor etapelor de pregătire a versiunii: construirea versiunii de lansare, semnarea cu certificate, ofuscarea, verificarea metadatelor magazinului de aplicații și implementarea pe staging. Termenul a fost introdus de Jez Humble și David Farley în cartea „Continuous Delivery” (2010), în care au formalizat practica ce permite echipelor să facă lansări previzibile și cu risc scăzut.

Evoluția livrării de software

Înainte de CD, lansările erau un eveniment: echipa se aduna într-o cameră, parcurgea o listă de verificare cu 20 de puncte, rula scripturi manual și spera că nimic nu se va strica. Continuous Delivery transformă lansarea dintr-un eveniment într-un proces: o mică modificare de cod poate fi livrată utilizatorilor în minute, nu săptămâni. Amazon, Netflix și Etsy au fost primii care au implementat CD în anii 2010 — astăzi este un standard pentru echipele de produs.

Valoarea de afaceri a CD

Livrarea rapidă a funcționalităților este un avantaj competitiv. Dacă concurentul lansează o nouă funcționalitate în zile, iar tu în luni, piața alege concurentul. Metricile DORA arată: echipele elite (cu CD) au un timp de implementare sub 1 oră, echipele low (fără CD) — de la 1 săptămână la 1 lună. CD reduce, de asemenea, radical riscul: modificările mici sunt mai greu de stricat decât o lansare mare o dată pe trimestru.

CD vs CI vs Continuous Deployment

Termenii CI, CD și Continuous Deployment sunt adesea confundați, dar există o graniță clară între ei. Înțelegerea diferențelor ajută la proiectarea corectă a pipeline-ului și alegerea nivelului de automatizare potrivit maturității echipei și cerințelor de afaceri.

Continuous Integration

CI este fundația pe care se construiește CD. CI garantează că fiecare commit trece de construire și teste. Fără CI, CD este imposibil: dacă codul nu este verificat, nu poate fi lansat. CI verifică corectitudinea, CD verifică pregătirea pentru utilizarea de business.

Continuous Delivery

CD adaugă la CI etapele de pregătire a versiunii de lansare, verificare a metadatelor, semnare și implementare pe staging sau în magazinul de aplicații pentru testare beta. Diferența cheie — decizia de lansare în producție o ia o persoană (manager, product owner). CD face lansarea „un singur clic” — simplă și sigură.

Continuous Deployment

Continuous Deployment este automatizarea completă: fiecare modificare care trece de toate etapele pipeline-ului CD este trimisă automat în producție fără confirmare manuală. Continuous Deployment este aplicabil pentru produse SaaS și servicii web, dar este rar folosit în dezvoltarea mobilă din cauza politicilor magazinelor de aplicații (App Store Review, Google Play Review necesită trimitere manuală).

Continuous Delivery pentru aplicații mobile

CD pentru aplicații mobile are caracteristici care îl diferențiază de pipeline-urile web și backend. Lansările mobile trec prin magazinele de aplicații (App Store Review, Google Play Review), ceea ce adaugă o barieră de timp și procedurală. CD automatizează tot ce poate fi automatizat înainte de trimiterea pentru review, pentru a maximiza șansa de a trece de verificare din prima încercare.

Pregătirea pentru publicare în Google Play

Pipeline-ul Android CD include: construirea AAB (Android App Bundle), semnarea cu cheia de release, ofuscarea prin R8/ProGuard, verificarea dimensiunii APK și claselor multidex, generarea notelor de lansare. Utilizarea Gradle product flavors (free/paid, dev/staging/prod) permite gestionarea mai multor configurații dintr-un singur pipeline.

Pregătirea pentru publicare în App Store

iOS CD necesită semnarea cu certificate prin Fastlane match, verificarea conformității pictogramelor (cerința App Store — 1024×1024 px), validarea metadatelor (nume, descriere, cuvinte cheie), verificarea absenței API-urilor private. Technical validation se efectuează prin altool --validate-app fără încărcare în App Store Connect, ceea ce oferă feedback rapid.

# Fastfile — pipeline CD complet pentru iOS și Android
platform :ios do
  desc "iOS CD — pregătirea versiunii și încărcarea în 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 — construirea AAB și încărcarea în 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 colectează capturile de ecran, obține certificatele prin match, construiește IPA-\ul și încarcă în TestFlight. Pentru Android, lane-ul deliver_to_internal construiește Release AAB prin Gradle și încarcă pe circuitul intern Google Play Console. Ambele pipeline-uri sunt lansate din CI după trecerea testelor.

Componentele pipeline-ului CD

Pipeline-ul CD constă într-o succesiune de etape, fiecare adăugând încrederea că versiunea este gata pentru utilizatori. Etapele se împart în tehnice (construire, semnare) și de produs (verificarea metadatelor, capturilor de ecran, descrierii). Omiterea oricărei etape crește riscul de respingere a versiunii de către magazin.

Gestionarea versiunilor

O componentă critică a CD — gestionarea automată a versiunilor. Version bump (versionCode și versionName pentru Android, CFBundleVersion și CFBundleShortVersionString pentru iOS) se efectuează pe baza tag-urilor Git sau a versiunii anterioare din magazin. Fastlane increment_version_number și comenzile Gradle (versionCode auto-increment) automatizează acest pas.

Metadatele magazinului

Google Play Console și App Store Connect necesită: descrierea aplicației, cuvinte cheie, categorie, rating, linkuri către politica de confidențialitate. CD include verificarea prezenței și corectitudinii metadatelor. Fastlane deliver și supply automatizează încărcarea descrierii, capturilor de ecran și pictogramelor împreună cu build-ul.

Verificări de tip gate

Înainte de trimiterea pentru review, pipeline-ul efectuează verificări de tip gate: verificarea dimensiunii build-ului (APK > 200 MB este respins de Google Play), prezența tuturor localizărilor, absența simbolurilor debug în build-ul de release, verificarea fișierului ProGuard mapping pentru decodarea logurilor de crash. Dacă cel puțin o verificare eșuează — pipeline-ul blochează lansarea.

Testare automatizată pentru CD

Nivelul de încredere în CD este direct proporțional cu calitatea testelor automate. Dacă testele nu detectează regresiunile — lansarea poate strica producția, iar echipa pierde încrederea în CD. CD mobil necesită o piramidă de testare pe trei niveluri, adaptată specificului platformei.

Teste unitare

Testele unitare verifică logica de business în izolare. Acoperirea codului trebuie să fie de cel puțin 70% pentru modulele critice (autentificare, plăți, lucrul cu rețeaua). CI rulează testele unitare la fiecare push, iar dacă eșuează — pipeline-ul CD este blocat până la remediere.

Teste de integrare

Verifică interacțiunile componentelor: stratul de rețea cu API real (sau server mock), baza de date, sistemul de fișiere. Testele Room DAO pentru Android, testele Core Data pentru iOS — exemple de teste de integrare. Sunt mai lente decât testele unitare (1–5 minute) și se execută în etapa CD, nu la fiecare commit.

Teste UI și de capturi de ecran

Testele de capturi de ecran (snapshot testing) compară ecranele aplicației cu imagini de referință. Dacă o modificare de cod a schimbat UI-ul — testul eșuează, iar dezvoltatorul verifică dacă schimbarea este așteptată. Android suportă Roborazzi și Paparazzi, iOS — SnapshotTesting de la Point-Free. Testele de capturi de ecran se execută înainte de lansare ca parte a pipeline-ului CD.

Cele mai bune practici Continuous Delivery

Implementarea Continuous Delivery necesită nu doar instrumente, ci și schimbarea culturii echipei. Practicile de mai jos se bazează pe experiența pe termen lung a echipelor mobile de la Google, Spotify și Uber și sunt adaptate pentru proiecte de orice dimensiune.

Feature flags

Codul noii funcționalități este livrat în producție, dar ascuns în spatele unui flag. Feature flags permit livrarea codului mai devreme decât funcționalitatea este gata pentru utilizatori și dezactivarea imediată în caz de probleme. Biblioteci: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags sunt o condiție obligatorie pentru CD în proiecte mobile.

Mediul de staging

Înainte de trimiterea în producție, build-ul este publicat pe staging — un mediu identic cu producția, dar cu date de test. Inginerii QA verifică funcționalitatea pe build-ul de staging instalat prin TestFlight sau Internal Testing track. Dacă staging trece — build-ul primește aprobarea pentru trimiterea la review în magazin.

Notele de lansare și changelog

CD generează automat notele de lansare pe baza mesajelor de commit. Conventional Commits (feat:, fix:, chore:) și tag-urile Git în format semantic versioning permit parsarea istoricului modificărilor. Fastlane changelog_from_git_commits colectează modificările dintre ultimele două tag-uri și le formatează pentru magazinul de aplicații.

Monitorizarea după lansare

CD nu se termină cu publicarea — după lansare se activează monitorizarea: crash rate, ANR rate pentru Android, timpul de pornire, frecvența eșecurilor de plată. Dacă metricile depășesc limitele — pipeline-ul CD trebuie să retragă automat versiunea sau să notifice echipa. Instrumente: Firebase Crashlytics, Sentry, New Relic.

// Exemplu Feature Flag cu Firebase Remote Config pentru 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")
    }
}

// Utilizare în cod
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}