Continuous Delivery (CD): vad är det och vad skiljer det från Continuous Deployment

Vad är Continuous Delivery

Continuous Delivery (CD) — detta är en utvidgning av Continuous Integration som lägger till automatisering för alla faser av releaseförberedelse: bygga releasebuilden, signera med certifikat, obfuskering, kontroll av appbutikens metadata och deploy till staging. Termen introducerades av Jez Humble och David Farley i boken „Continuous Delivery“ (2010), där de formaliserade en praxis som gör att team kan göra releaser förutsägbara och lågriskmässiga.

Mjukvaruleveransens utveckling

Innan CD infördes var releaser en händelse: teamet samlades i ett rum, gick igenom en checklista med 20 punkter, körde skript manuellt och hoppades att ingenting skulle gå sönder. Continuous Delivery förvandlar releasen från en händelse till en process: en liten kodändring kan levereras till användarna inom minuter, inte veckor. Amazon, Netflix och Etsy införde CD först under 2010-talet — idag är det standard för produktteam.

CD:s affärsvärde

Snabb leverans av funktioner är en konkurrensfördel. Om en konkurrent lanserar ny funktionalitet inom dagar och du inom månader, väljer marknaden konkurrenten. DORA-metriker visar: elite-team (med CD) har en lanseringstid på mindre än 1 timme, low-team (utan CD) från 1 vecka till 1 månad. CD minskar också radikalt risken: små ändringar är svårare att förstöra än en stor release en gång per kvartal.

CD vs CI vs Continuous Deployment

Termerna CI, CD och Continuous Deployment blandas ofta ihop, men det finns en tydlig gräns mellan dem. Att förstå skillnaderna hjälper till att utforma pipelinen korrekt och välja en automatiseringsnivå som matchar teamets mognad och affärskraven.

Continuous Integration

CI är grunden som CD byggs på. CI garanterar att varje commit genomgår bygge och tester. Utan CI är CD omöjligt: om koden inte är verifierad kan den inte släppas. CI kontrollerar korrektheten, CD kontrollerar beredskapen för affärsmässig användning.

Continuous Delivery

CD lägger till CI faser för att förbereda releasebuilden, kontrollera metadata, signera och distribuera till staging eller till appbutiken för betatestning. Den viktigaste skillnaden — beslutet om release till produktion fattas av en människa (chef, produktägare). CD gör releasen „med ett klick“ — enkel och säker.

Continuous Deployment

Continuous Deployment är fullständig automatisering: varje ändring som genomgår alla faser av CD-pipelinen skickas automatiskt till produktion utan manuell bekräftelse. Continuous Deployment är tillämpligt för SaaS-produkter och webbtjänster, men används sällan inom mobilutveckling på grund av appbutikernas policyer (App Store Review, Google Play Review kräver manuell inlämning).

Continuous Delivery för mobilapplikationer

CD för mobilapplikationer har särdrag som skiljer det från webb- och backend-pipelines. Mobila releaser går genom appbutiker (App Store Review, Google Play Review), vilket lägger till en tids- och processbarriär. CD automatiserar allt som kan automatiseras före inlämning till review, för att maximera chansen att klara granskningen vid första försöket.

Förberedelse för publicering i Google Play

Android CD-pipelinen inkluderar: bygga AAB (Android App Bundle), signera med release-nyckel, obfuskering via R8/ProGuard, kontroll av APK-storlek och multidex-klasser, generering av releaseanteckningar. Att använda Gradle product flavors (free/paid, dev/staging/prod) gör det möjligt att hantera flera konfigurationer från en pipeline.

Förberedelse för publicering i App Store

iOS CD kräver signering med certifikat via Fastlane match, kontroll av ikonernas överensstämmelse (App Store-krav — 1024×1024 px), validering av metadata (namn, beskrivning, nyckelord), kontroll att inga privata API:er finns. Teknisk validering utförs via altool --validate-app utan uppladdning till App Store Connect, vilket ger snabb feedback.

# Fastfile — komplett CD-pipeline för iOS och Android
platform :ios do
  desc "iOS CD — förbered release och ladda upp till 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 — bygg AAB och ladda upp till 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 samlar in skärmbilder, hämtar certifikat via match, bygger IPA och laddar upp till TestFlight. Länen deliver_to_internal för Android bygger Release AAB via Gradle och laddar upp den till den interna spåret i Google Play Console. Båda pipelinerna startas från CI efter att testerna godkänts.

Komponenter i CD-pipelinen

En CD-pipeline består av successiva faser, där varje fas ökar förtroendet för att releasen är redo för användarna. Faserna delas in i tekniska (bygge, signering) och produktmässiga (kontroll av metadata, skärmbilder, beskrivning). Att hoppa över någon fas ökar risken att appbutiken avvisar releasen.

Versionshantering

En kritisk komponent i CD är automatisk versionshantering. Version bump (versionCode och versionName för Android, CFBundleVersion och CFBundleShortVersionString för iOS) utförs baserat på Git-taggar eller den tidigare versionen i butiken. Fastlane increment_version_number och Gradle-kommandon (versionCode auto-increment) automatiserar detta steg.

Butikens metadata

Google Play Console och App Store Connect kräver: appbeskrivning, nyckelord, kategori, betyg, länkar till integritetspolicyn. CD inkluderar kontroll av att metadata finns och är korrekt. Fastlane deliver och supply automatiserar uppladdning av beskrivning, skärmbilder och ikoner tillsammans med builden.

Gate-kontroller

Före inlämning till review utför pipelinen gate-kontroller: kontroll av build-storleken (APK större än 200 MB avvisas av Google Play), att alla lokaliseringar finns, frånvaro av debug-symboler i releasebuilden, kontroll av ProGuard mapping-filen för att avkoda crash-loggar. Om någon kontroll misslyckas blockerar pipelinen releasen.

Automatiserad testning för CD

Förtroendenivån för CD är direkt proportionell mot kvaliteten på de automatiska testerna. Om testerna inte fångar regressioner kan releasen förstöra produktionen och teamet förlorar förtroendet för CD. Mobil CD kräver en trelagrad testpyramid, anpassad till plattformens särdrag.

Enhetstester

Enhetstester kontrollerar affärslogiken isolerat. Kodtäckningen bör vara minst 70% för kritiska moduler (autentisering, betalningar, nätverksarbete). CI kör enhetstester vid varje push, och om de misslyckas blockeras CD-pipelinen tills det åtgärdats.

Integrationstester

De kontrollerar interaktionen mellan komponenter: nätverkslagret med ett verkligt API (eller mock-server), databasen, filsystemet. Room DAO-tester för Android, Core Data-tester för iOS — exempel på integrationstester. De är långsammare än enhetstester (1–5 minuter) och utförs i CD-fasen, inte i CI vid varje commit.

UI- och skärmbildstester

Skärmbildstester (snapshot testing) jämför appens skärmar med referensbilder. Om en kodändring ändrade UI:n misslyckas testet, och utvecklaren kontrollerar om ändringen är förväntad. Android stöder Roborazzi och Paparazzi, iOS — SnapshotTesting från Point-Free. Skärmbildstester körs före releasen som en del av CD-pipelinen.

Bästa praxis för Continuous Delivery

Att införa Continuous Delivery kräver inte bara verktyg utan också en förändring av teamkulturen. Praxisen nedan bygger på mångårig erfarenhet av mobila team från Google, Spotify och Uber och är anpassad för projekt av alla storlekar.

Feature flags

Koden för en ny funktion levereras till produktion men är dold bakom en flagga. Feature flags gör det möjligt att släppa koden innan funktionen är redo att visas för användarna och att omedelbart stänga av den vid problem. Bibliotek: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags är ett obligatoriskt villkor för CD i mobilprojekt.

Staging-miljö

Före leverans till produktion placeras builden på staging — en miljö som är identisk med produktionen men med testdata. QA-ingenjörer kontrollerar funktionen på staging-builden, installerad via TestFlight eller Internal Testing-spåret. Om staging klarar sig får builden godkännande för inlämning till review i butiken.

Releaseanteckningar och changelog

CD genererar automatiskt releaseanteckningar baserat på commit-meddelanden. Conventional Commits (feat:, fix:, chore:) och Git-taggar i semantic versioning-format gör det möjligt att parsa ändringshistoriken. Fastlane changelog_from_git_commits samlar in ändringar mellan de två senaste taggarna och formaterar dem för appbutiken.

Övervakning efter releasen

CD slutar inte vid publicering — efter releasen startas övervakning: crash rate, ANR rate för Android, starttid, frekvens av betalningsfel. Om mätvärdena överskrider normalgränsen bör CD-pipelinen automatiskt rulla tillbaka releasen eller meddela teamet. Verktyg: Firebase Crashlytics, Sentry, New Relic.

// Exempel på Feature Flag med Firebase Remote Config för 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")
    }
}

// Användning i koden
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}