Continuous Delivery (CD): What It Is and How It Differs from Continuous Deployment

What is Continuous Delivery

Continuous Delivery (CD) is an extension of Continuous Integration that adds automation for all release preparation stages: building the release build, signing with certificates, obfuscation, verifying app store metadata, and deploying to staging. The term was introduced by Jez Humble and David Farley in the book “Continuous Delivery” (2010), where they formalized the practice that enables teams to make releases predictable and low-risk.

Evolution of Software Delivery

Before CD adoption, releases were an event: the team gathered in a room, went through a 20-point checklist, ran scripts manually, and hoped nothing would break. Continuous Delivery turns a release from an event into a process: a small code change can be shipped to users within minutes, not weeks. Amazon, Netflix, and Etsy were the first to adopt CD in the 2010s — today it’s the standard for product teams.

Business Value of CD

Fast feature delivery is a competitive advantage. If a competitor ships new functionality in days while you take months, the market chooses the competitor. DORA metrics show: elite teams (with CD) have a deployment lead time under 1 hour, low teams (without CD) — from 1 week to 1 month. CD also radically reduces risk: small changes are harder to break things than a big quarterly release.

CD vs CI vs Continuous Deployment

The terms CI, CD, and Continuous Deployment are often confused, but there is a clear boundary between them. Understanding the differences helps design the pipeline correctly and choose the level of automation that matches team maturity and business requirements.

Continuous Integration

CI is the foundation on which CD is built. CI ensures that every commit goes through building and testing. Without CI, CD is impossible: if code is not verified, it cannot be released. CI verifies correctness, CD verifies readiness for business use.

Continuous Delivery

CD adds to CI the stages of building a release build, verifying metadata, signing, and deploying to staging or the app store for beta testing. The key difference — the decision to release to production is made by a person (manager, product owner). CD makes release “one click away” — simple and safe.

Continuous Deployment

Continuous Deployment is full automation: every change that passes all stages of the CD pipeline is automatically sent to production without manual approval. Continuous Deployment is applicable for SaaS products and web services, but is rarely used in mobile development due to app store policies (App Store Review, Google Play Review requires manual submission).

Continuous Delivery for Mobile Applications

CD for mobile applications has features that distinguish it from web and backend pipelines. Mobile releases go through app stores (App Store Review, Google Play Review), which adds a time and process barrier. CD automates everything that can be automated before submission for review to maximize the chance of passing verification on the first try.

Preparation for Publication on Google Play

Android CD pipeline includes: building AAB (Android App Bundle), signing with a release key, obfuscation via R8/ProGuard, APK size and multidex class checking, generating release notes. Using Gradle product flavors (free/paid, dev/staging/prod) allows managing multiple configurations from one pipeline.

Preparation for Publication on the App Store

iOS CD requires signing with certificates via Fastlane match, checking icon compliance (App Store requirement — 1024×1024 px), validating metadata (name, description, keywords), checking for the absence of private APIs. Technical validation is performed via altool --validate-app without uploading to App Store Connect, which provides fast feedback.

# Fastfile — complete CD pipeline for iOS and Android
platform :ios do
  desc "iOS CD — release preparation and upload to 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 — building AAB and uploading to 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 collects screenshots, obtains certificates via match, builds IPA and uploads to TestFlight. The deliver_to_internal lane for Android builds Release AAB via Gradle and uploads it to the internal track of Google Play Console. Both pipelines run from CI after tests pass.

CD Pipeline Components

A CD pipeline consists of sequential stages, each adding confidence that the release is ready for users. The stages are divided into technical (build, signing) and product (metadata, screenshots, description verification). Skipping any stage increases the risk of the release being rejected by the app store.

Version Management

A critical component of CD is automatic version management. Version bump (versionCode and versionName for Android, CFBundleVersion and CFBundleShortVersionString for iOS) is performed based on Git tags or the previous version in the store. Fastlane increment_version_number and Gradle commands (versionCode auto-increment) automate this step.

Store Metadata

Google Play Console and App Store Connect require: app description, keywords, category, rating, privacy policy links. CD includes checking the presence and correctness of metadata. Fastlane deliver and supply automate uploading descriptions, screenshots, and icons along with the build.

Gate Checks

Before submitting for review, the pipeline performs gate checks: build size check (APK > 200 MB is rejected by Google Play), presence of all localizations, absence of debug symbols in the release build, ProGuard mapping file check for decoding crash logs. If any check fails — the pipeline blocks the release.

Automated Testing for CD

The level of trust in CD is directly proportional to the quality of automated tests. If tests do not catch regressions — the release can break production, and the team loses confidence in CD. Mobile CD requires a three-level testing pyramid adapted to the platform’s specifics.

Unit Tests

Unit tests verify business logic in isolation. Code coverage should be at least 70% for critical modules (authentication, payments, networking). CI runs unit tests on every push, and if they fail — the CD pipeline is blocked until fixed.

Integration Tests

They verify component interaction: network layer with real API (or mock server), database, file system. Room DAO tests for Android, Core Data tests for iOS are examples of integration tests. They are slower than unit tests (1–5 minutes) and are executed at the CD stage, not CI on every commit.

UI and Screenshot Tests

Screenshot tests (snapshot testing) compare app screens with reference images. If a code change altered the UI — the test fails, and the developer checks whether the change is expected. Android supports Roborazzi and Paparazzi, iOS — SnapshotTesting by Point-Free. Screenshot tests are executed before release as part of the CD pipeline.

Continuous Delivery Best Practices

Implementing Continuous Delivery requires not only tools but also a change in team culture. The practices below are based on years of experience from mobile teams at Google, Spotify, and Uber and are adapted for projects of any size.

Feature Flags

The code for a new feature is shipped to production but hidden behind a flag. Feature flags allow deploying code before the feature is ready for users and instantly disable it in case of problems. Libraries: LaunchDarkly, Firebase Remote Config, Unleash. Feature flags are a mandatory requirement for CD in mobile projects.

Staging Environment

Before shipping to production, the build is deployed to staging — an environment identical to production but with test data. QA engineers verify the feature on a staging build installed via TestFlight or Internal Testing track. If staging passes — the build receives approval for submission to the store for review.

Release Notes and Changelog

CD automatically generates release notes based on commit messages. Conventional Commits (feat:, fix:, chore:) and Git tags in semantic versioning format allow parsing the change history. Fastlane changelog_from_git_commits collects changes between the last two tags and formats them for the app store.

Post-Release Monitoring

CD does not end with publication — after release, monitoring starts: crash rate, ANR rate for Android, launch time, payment failure rate. If metrics go beyond normal limits — the CD pipeline should automatically roll back the release or notify the team. Tools: Firebase Crashlytics, Sentry, New Relic.

// Example Feature Flag with Firebase Remote Config for 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")
    }
}

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