Continuous Delivery (CD): その概要とContinuous Deploymentとの違い

Continuous Deliveryとは

Continuous Delivery (CD) はContinuous Integrationの拡張であり、リリース準備のすべての段階（リリースビルドの作成、証明書による署名、難読化、アプリストアのメタデータ検証、ステージングへのデプロイ）に自動化を追加します。この用語はJez HumbleとDavid Farleyが著書 “Continuous Delivery” (2010) で紹介し、チームがリリースを予測可能で低リスクにするプラクティスを形式化しました。

ソフトウェアデリバリーの進化

CD採用前は、リリースはイベントでした。チームは部屋に集まり、20項目のチェックリストを実行し、手動でスクリプトを実行し、何も壊れないことを願っていました。Continuous Delivery はリリースをイベントからプロセスに変えます。コードの小さな変更を数分でユーザーに出荷でき、数週間かける必要はありません。Amazon、Netflix、Etsyが2010年代に最初にCDを採用しました — 現在ではプロダクトチームの標準となっています。

CDのビジネス価値

迅速な機能提供は競争上の優位性です。競合他社が数日で新機能をリリースするのに、あなたは数ヶ月かかる場合、市場は競合他社を選びます。DORAメトリクス が示すように、エリートチーム（CD採用）のデプロイリードタイムは1時間未満、低いチーム（CD未採用）は1週間から1ヶ月です。CDはリスクも根本的に低減します。小さな変更は、大きな四半期リリースよりも問題を起こしにくいのです。

CD vs CI vs Continuous Deployment

CI、CD、Continuous Deployment という用語はよく混同されますが、それらの間には明確な境界があります。違いを理解することで、パイプラインを正しく設計し、チームの成熟度とビジネス要件に合った自動化レベルを選択できます。

Continuous Integration

CIはCDが構築される基盤です。CIはすべてのコミットがビルドとテストを通過することを保証します。CIなしではCDは不可能です。コードが検証されていなければリリースできません。CIは正確性を検証し、CDはビジネス使用への準備状態を検証します。

Continuous Delivery

CDはCIに、リリースビルドの作成、メタデータの検証、署名、ステージングまたはベータテスト用のアプリストアへのデプロイの段階を追加します。主な違い は、本番環境へのリリースの決定を人間（マネージャー、プロダクトオーナー）が行うことです。CDはリリースを “ワンクリック” でシンプルかつ安全にします。

Continuous Deployment

Continuous Deploymentは完全な自動化です。CDパイプラインのすべての段階を通過したすべての変更が、手動承認なしで 自動的に本番環境に送信されます。Continuous DeploymentはSaaS製品やWebサービスに適用可能ですが、アプリストアのポリシー（App Store Review、Google Play Reviewでは手動提出が必要）により、モバイル開発ではほとんど使用されません。

モバイルアプリケーションのContinuous Delivery

モバイルアプリケーション向けCD には、Webやバックエンドのパイプラインと区別される特徴があります。モバイルリリースはアプリストア（App Store Review、Google Play Review）を通過するため、時間とプロセスの障壁が追加されます。CDは、レビューのための提出前に自動化できるすべてを自動化し、初回で検証を通過する可能性を最大化します。

Google Play公開の準備

Android CDパイプラインには以下が含まれます：AAB（Android App Bundle）のビルド、リリースキーによる署名、R8/ProGuardによる難読化、APKサイズとmultidexクラスのチェック、リリースノートの生成。Gradleのproduct flavors（free/paid、dev/staging/prod）を使用すると、1つのパイプラインから複数の設定を管理できます。

App Store公開の準備

iOS CDには、Fastlane match による証明書の署名、アイコンの準拠チェック（App Storeの要件 — 1024×1024 px）、メタデータ（名前、説明、キーワード）の検証、プライベートAPIの不在確認が必要です。技術検証は altool --validate-app を介してApp Store Connectにアップロードせずに実行され、迅速なフィードバックを提供します。

# Fastfile — iOSとAndroidのための完全なCDパイプライン
platform :ios do
  desc "iOS CD — リリース準備と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ビルドと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 はスクリーンショットを収集し、matchで証明書を取得し、IPAをビルドしてTestFlightにアップロードします。Androidの deliver_to_internal レーンはGradleでRelease AABをビルドし、Google Play Consoleの内部トラックにアップロードします。両方のパイプラインはテスト通過後にCIから実行されます。

CDパイプラインの構成要素

CDパイプライン は順次的な段階で構成され、各段階がリリースがユーザーの準備ができているという確信を高めます。段階は技術的（ビルド、署名）とプロダクト（メタデータ、スクリーンショット、説明の検証）に分けられます。どの段階をスキップしても、アプリストアによってリリースが拒否されるリスクが高まります。

バージョン管理

CDの重要な構成要素は自動バージョン管理です。バージョンアップ（AndroidのversionCodeとversionName、iOSのCFBundleVersionとCFBundleShortVersionString）は、Gitタグまたはストアの前のバージョンに基づいて実行されます。Fastlane increment_version_numberやGradleコマンド（versionCode auto-increment）がこのステップを自動化します。

ストアのメタデータ

Google Play ConsoleとApp Store Connectでは、アプリの説明、キーワード、カテゴリ、評価、プライバシーポリシーのリンクが必要です。CDには メタデータの存在と正確性のチェックが含まれます。Fastlaneのdeliverとsupplyは、ビルドと一緒に説明、スクリーンショット、アイコンのアップロードを自動化します。

ゲートチェック

レビューのために提出する前に、パイプラインはゲートチェックを実行します：ビルドサイズチェック（APK > 200 MBはGoogle Playで拒否）、すべてのローカライゼーションの存在、リリースビルドでのデバッグシンボルの不在、クラッシュログをデコードするためのProGuardマッピングファイルチェック。いずれかのチェックが失敗すると、パイプラインはリリースをブロックします。

CDのための自動テスト

CD への信頼レベルは、自動テストの品質に正比例します。テストが回帰を捕捉しない場合、リリースが本番環境を壊し、チームはCDへの信頼を失います。モバイルCDには、プラットフォームの特性に適応した3層のテストピラミッドが必要です。

単体テスト

単体テストはビジネスロジックを独立して検証します。重要なモジュール（認証、支払い、ネットワーキング）の コードカバレッジ は少なくとも70%であるべきです。CIはプッシュのたびに単体テストを実行し、失敗した場合は修正されるまでCDパイプラインがブロックされます。

統合テスト

コンポーネントの相互作用を検証します：実際のAPI（またはモックサーバー）とのネットワーク層、データベース、ファイルシステム。Androidの Room DAOテスト、iOSのCore Dataテストは統合テストの例です。単体テストより遅く（1〜5分）、CD段階で実行され、すべてのコミットでのCIでは実行されません。

UIとスクリーンショットテスト

スクリーンショットテスト（スナップショットテスト）は、アプリの画面を参照画像と比較します。コード変更がUIを変更した場合、テストは失敗し、開発者は変更が予期されているか確認します。AndroidはRoborazziとPaparazziをサポートし、iOSはPoint-FreeのSnapshotTestingをサポートします。スクリーンショットテストはCDパイプラインの一部としてリリース前に実行されます。

Continuous Deliveryのベストプラクティス

Continuous Delivery の導入には、ツールだけでなくチーム文化の変革も必要です。以下のプラクティスは、Google、Spotify、Uberのモバイルチームの長年の経験に基づいており、あらゆる規模のプロジェクトに適応されています。

Feature Flags

新機能のコードは本番環境に出荷されますが、フラグの背後に隠されています。Feature flags を使用すると、機能がユーザーに公開される前にコードをデプロイし、問題が発生した場合に即座に無効にできます。ライブラリ：LaunchDarkly、Firebase Remote Config、Unleash。Feature flagsはモバイルプロジェクトのCDに必須の要件です。

ステージング環境

本番環境に出荷する前に、ビルドは ステージング にデプロイされます。これは本番環境と同一だがテストデータを使用する環境です。QAエンジニアはTestFlightまたはInternal Testingトラックを介してインストールされたステージングビルドで機能を検証します。ステージングに合格すると、ビルドはストアのレビューに提出する承認を得ます。

リリースノートとチェンジログ

CDはコミットメッセージに基づいてリリースノートを自動生成します。Conventional Commits（feat:、fix:、chore:）とセマンティックバージョニング形式のGitタグにより、変更履歴を解析できます。Fastlane changelog_from_git_commitsは最後の2つのタグ間の変更を収集し、アプリストア用にフォーマットします。

リリース後の監視

CDは公開で終わりません — リリース後、監視が開始されます：クラッシュ率、AndroidのANR率、起動時間、支払い失敗率。メトリクスが通常の限度を超えた場合、CDパイプラインは自動的にリリースをロールバックするか、チームに通知する必要があります。ツール：Firebase Crashlytics、Sentry、New Relic。

// CDのためのFirebase Remote Configを使用したFeature Flagの例
class FeatureManager(
    private val remoteConfig: FirebaseRemoteConfig
) {
    fun isNewCheckoutEnabled(): Boolean {
        return remoteConfig.getBoolean("new_checkout_enabled")
    }

    fun getRecommendedVersion(): String {
        return remoteConfig.getString("minimum_app_version")
    }
}

// コードでの使用
if (featureManager.isNewCheckoutEnabled()) {
    showNewCheckoutScreen()
} else {
    showLegacyCheckoutScreen()
}