Continuous Delivery (CD): wat is het en waarin verschilt het van Continuous Deployment

Wat is Continuous Delivery

Continuous Delivery (CD) — dit is een uitbreiding van Continuous Integration die automatisering toevoegt aan alle fasen van releasevoorbereiding: het bouwen van de releasebuild, ondertekening met certificaten, obfuscatie, controle van de metadata van de app-winkel en deploy naar staging. De term werd geïntroduceerd door Jez Humble en David Farley in het boek „Continuous Delivery“ (2010), waarin ze de praktijk formaliseerden die teams in staat stelt releases voorspelbaar en laagrisico te maken.

De evolutie van softwarelevering

Vóór de invoering van CD waren releases een gebeurtenis: het team verzamelde zich in een ruimte, doorliep een checklist van 20 punten, draaide scripts handmatig en hoopte dat er niets kapot zou gaan. Continuous Delivery verandert de release van een gebeurtenis in een proces: een kleine codewijziging kan binnen enkele minuten aan gebruikers worden geleverd in plaats van weken. Amazon, Netflix en Etsy voerden CD als eerste in in de jaren 2010 — vandaag is het de standaard voor productteams.

De zakelijke waarde van CD

Snelle levering van functies is een concurrentievoordeel. Als een concurrent nieuwe functionaliteit binnen dagen uitrolt en jij binnen maanden, kiest de markt voor de concurrent. DORA-metrieken tonen aan: elite-teams (met CD) hebben een uitroltijd van minder dan 1 uur, low-teams (zonder CD) van 1 week tot 1 maand. CD verlaagt bovendien radicaal het risico: kleine wijzigingen zijn moeilijker kapot te maken dan een grote release eens per kwartaal.

CD vs CI vs Continuous Deployment

De termen CI, CD en Continuous Deployment worden vaak door elkaar gehaald, maar er is een duidelijke grens tussen hen. Inzicht in de verschillen helpt om de pipeline correct te ontwerpen en het automatiseringsniveau te kiezen dat past bij de volwassenheid van het team en de zakelijke vereisten.

Continuous Integration

CI is het fundament waarop CD wordt gebouwd. CI garandeert dat elke commit door de build en tests komt. Zonder CI is CD onmogelijk: als code niet is geverifieerd, kan deze niet worden gereleased. CI controleert de correctheid, CD controleert de gereedheid voor zakelijk gebruik.

Continuous Delivery

CD voegt aan CI fasen toe voor het voorbereiden van de releasebuild, controle van metadata, ondertekening en implementatie op staging of in de app-winkel voor bètatesting. Het belangrijkste verschil — de beslissing over de release naar productie wordt genomen door een mens (manager, producteigenaar). CD maakt de release „met één klik“ — eenvoudig en veilig.

Continuous Deployment

Continuous Deployment is volledige automatisering: elke wijziging die alle fasen van de CD-pipeline doorloopt, wordt automatisch naar productie gestuurd zonder handmatige bevestiging. Continuous Deployment is toepasbaar voor SaaS-producten en webservices, maar wordt zelden gebruikt in mobiele ontwikkeling vanwege het beleid van app-winkels (App Store Review, Google Play Review vereist handmatige verzending).

Continuous Delivery voor mobiele applicaties

CD voor mobiele applicaties heeft kenmerken die het onderscheiden van web- en backend-pipelines. Mobiele releases doorlopen app-winkels (App Store Review, Google Play Review), wat een tijd- en procesbarrière toevoegt. CD automatiseert alles wat vóór de review kan worden geautomatiseerd, om de kans te maximaliseren dat de controle in één keer wordt doorstaan.

Voorbereiding voor publicatie in Google Play

De Android CD-pipeline omvat: het bouwen van AAB (Android App Bundle), ondertekening met de release-sleutel, obfuscatie via R8/ProGuard, controle van de APK-grootte en multidex-klassen, generatie van releasenotities. Het gebruik van Gradle product flavors (free/paid, dev/staging/prod) maakt het mogelijk meerdere configuraties vanuit één pipeline te beheren.

Voorbereiding voor publicatie in de App Store

iOS CD vereist ondertekening met certificaten via Fastlane match, controle van de conformiteit van iconen (vereiste van de App Store — 1024×1024 px), validatie van metadata (naam, beschrijving, trefwoorden), controle op afwezigheid van private API's. Technische validatie wordt uitgevoerd via altool --validate-app zonder upload naar App Store Connect, wat snelle feedback geeft.

# Fastfile — volledige CD-pipeline voor iOS en Android
platform :ios do
  desc "iOS CD — release voorbereiden en uploaden naar 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 — AAB bouwen en uploaden naar 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 verzamelt screenshots, verkrijgt certificaten via match, bouwt de IPA en uploadt naar TestFlight. De lane deliver_to_internal voor Android bouwt de Release AAB via Gradle en uploadt deze naar het interne spoor van Google Play Console. Beide pipelines worden vanuit CI gestart na het doorstaan van de tests.

Onderdelen van een CD-pipeline

Een CD-pipeline bestaat uit opeenvolgende fasen, waarvan elke fase vertrouwen toevoegt dat de release klaar is voor gebruikers. De fasen worden verdeeld in technisch (build, ondertekening) en product (controle van metadata, screenshots, beschrijving). Het overslaan van een fase verhoogt het risico dat de app-winkel de release afkeurt.

Versiebeheer

Een kritisch onderdeel van CD is automatisch versiebeheer. Version bump (versionCode en versionName voor Android, CFBundleVersion en CFBundleShortVersionString voor iOS) wordt uitgevoerd op basis van Git-tags of de vorige versie in de winkel. Fastlane increment_version_number en Gradle-opdrachten (versionCode auto-increment) automatiseren deze stap.

Metadata van de winkel

Google Play Console en App Store Connect vereisen: een beschrijving van de app, trefwoorden, categorie, rating, links naar het privacybeleid. CD omvat controle van de aanwezigheid en correctheid van metadata. Fastlane deliver en supply automatiseren het uploaden van beschrijving, screenshots en iconen samen met de build.

Gate-controles

Vóór verzending naar review voert de pipeline gate-controles uit: controle van de buildgrootte (APK groter dan 200 MB wordt afgewezen door Google Play), aanwezigheid van alle lokalisaties, afwezigheid van debug-symbolen in de releasebuild, controle van het ProGuard mapping-bestand voor het decoderen van crash-logs. Als een controle faalt, blokkeert de pipeline de release.

Geautomatiseerd testen voor CD

Het vertrouwensniveau in CD is recht evenredig met de kwaliteit van automatische tests. Als tests geen regressies opvangen, kan de release de productie breken en verliest het team vertrouwen in CD. Mobiele CD vereist een driedelige testpiramide, aangepast aan de specifieke kenmerken van het platform.

Unittesten

Unittests controleren de bedrijfslogica geïsoleerd. Code coverage moet minimaal 70% zijn voor kritieke modules (authenticatie, betalingen, netwerkwerk). CI voert unittests uit bij elke push, en als ze falen, wordt de CD-pipeline geblokkeerd totdat het is opgelost.

Integratietesten

Deze controleren de interactie tussen componenten: de netwerklaag met een echte API (of mock-server), database, bestandssysteem. Room DAO-tests voor Android, Core Data-tests voor iOS zijn voorbeelden van integratietests. Ze zijn langzamer dan unittests (1–5 minuten) en worden uitgevoerd in de CD-fase, niet bij elke commit in CI.

UI- en screenshot-tests

Screenshot-tests (snapshot testing) vergelijken de schermen van de app met referentieafbeeldingen. Als een codewijziging de UI heeft gewijzigd, faalt de test en controleert de ontwikkelaar of de wijziging verwacht is. Android ondersteunt Roborazzi en Paparazzi, iOS — SnapshotTesting van Point-Free. Screenshot-tests worden vóór de release uitgevoerd als onderdeel van de CD-pipeline.

Beste praktijken voor Continuous Delivery

De invoering van Continuous Delivery vereist niet alleen hulpmiddelen, maar ook een verandering van de teamcultuur. De onderstaande praktijken zijn gebaseerd op jarenlange ervaring van mobiele teams van Google, Spotify en Uber en zijn aangepast voor projecten van elke omvang.

Feature flags

De code van een nieuwe functie wordt naar productie geleverd, maar is verborgen achter een vlag. Feature flags maken het mogelijk code eerder uit te rollen dan de functie klaar is om aan gebruikers te tonen, en deze direct uit te schakelen bij problemen. Bibliotheken: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags zijn een verplichte voorwaarde voor CD in mobiele projecten.

Staging-omgeving

Vóór verzending naar productie wordt de build op staging geplaatst — een omgeving die identiek is aan productie, maar met testgegevens. QA-ingenieurs controleren de functie op de staging-build, geïnstalleerd via TestFlight of het Internal Testing-spoor. Als staging wordt doorstaan, krijgt de build goedkeuring voor verzending naar review in de winkel.

Releasenotities en changelog

CD genereert automatisch releasenotities op basis van commit-messages. Conventional Commits (feat:, fix:, chore:) en Git-tags in semantic versioning-formaat maken het mogelijk de wijzigingsgeschiedenis te parseren. Fastlane changelog_from_git_commits verzamelt de wijzigingen tussen de laatste twee tags en formatteert deze voor de app-winkel.

Monitoring na de release

CD eindigt niet met publicatie — na de release wordt monitoring gestart: crash rate, ANR rate voor Android, opstarttijd, frequentie van mislukte betalingen. Als metrieken buiten de norm vallen, moet de CD-pipeline de release automatisch terugdraaien of het team waarschuwen. Hulpmiddelen: Firebase Crashlytics, Sentry, New Relic.

// Voorbeeld van een Feature Flag met Firebase Remote Config voor 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")
    }
}

// Gebruik in code
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}