CI/CD Pipeline — その概要、自動化の段階とツール

CI/CD Pipelineとは

CI/CD Pipelineは、リポジトリへの変更コミットから本番環境へのデプロイまでコードが通過する、形式化された自動プロセスのセットです。この用語は2つのプラクティス、Continuous Integration（継続的インテグレーション）とContinuous Delivery（継続的デリバリー）を組み合わせたもので、これらが一緒になってソフトウェア配信パイプラインを形成します。

CI/CDの歴史

Continuous Integrationの概念は、1991年にGrady Boochによって記述され、2000年代にMartin Fowlerによって普及しました。Continuous Deliveryという用語は、Jez HumbleとDavid Farleyの著書“Continuous Delivery”（2010年）によって確立されました。現代のCI/CD Pipelineは、2015年以降、クラウドCIサーバーとアプリストア自動化の登場により、モバイル開発における事実上の標準となりました。

モバイル開発にCI/CD Pipelineが必要な理由

モバイルアプリケーションには、ビルドと公開に関する固有の要件があります：証明書による署名、複数の設定（debug、release、staging）、ProGuard/R8による難読化、複数のビルドタイプ（APK、AAB、IPA）、アプリストアとの統合。これらの手順を手動で実行すると数時間かかり、エラーが発生しやすくなります — CI/CD Pipelineがルーチンを自動化します。

モバイルアプリ向けCI/CD Pipelineの段階

AndroidまたはiOSアプリ向けの標準的なCI/CD Pipelineは、7つの主要な段階で構成されています。一部の段階は並行して実行され、その他は順次実行されます。正確な段階のセットはテクノロジースタックとチームの成熟度に依存しますが、核となる部分は変わりません。

1. チェックアウトと依存関係のインストール

パイプラインはリポジトリのクローンと依存関係のインストールから始まります：Androidの場合はGradle/Maven、iOSの場合はCocoaPodsまたはSPM。実行間の依存関係のキャッシングにより、インストール時間が3～5分から数秒に短縮されます — 最新のCIサービスはすべてこの最適化をサポートしています。

2. 静的解析とリンティング

ビルド前に、コードはリンター（Android用のktlint、detekt、iOS用のSwiftLint）と静的解析ツール（Android Lint、SonarQube）によってチェックされます。リンティングはテスト実行前に潜在的なバグ、コードスタイル違反、非推奨APIを検出します — fail-fastの原則がチームの時間を節約します。

3. プロジェクトのビルド

ビルド段階では、プロジェクト全体がコンパイルされ、成果物が生成されます：Androidの場合はAPKとAAB、iOSの場合はIPA。AndroidではGradleタスク（assembleDebug、bundleRelease）が使用され、iOSではxcodebuildまたはxcrunが使用されます。ビルドはCIサーバーの分離された環境で実行され、再現性が保証されます。

# GitHub ActionsでのAndroid用CI/CDパイプライン例
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. 自動テスト

ビルド後、ユニットテスト、統合テスト、UIテストが実行されます。ユニットテストにはJUnitとMockK、Android UIにはEspressoとCompose Test、iOSにはXCTestとXCUITestが使用されます。結果はレポートで公開され、重要なテストが失敗した場合はパイプラインをブロックします。

5. 署名と難読化

リリースビルドでは、デジタル証明書による署名（Androidの場合はAPK Signer、iOSの場合はcodesign）とコードの難読化が実行されます。Android向けのProGuardまたはR8はAPKサイズを15～30%削減します。署名キーはCIサーバーのシークレットに保存され — リポジトリにコミットされることは決してありません。

6. 配信とデプロイ

パイプラインの最終段階は成果物の公開です：Google Play Consoleの内部テストへのAPKアップロード、TestFlightへのIPA送信、Firebase Distributionへの公開。Continuous Deliveryはこのステップに手動承認が必要であることを意味し、Continuous Deploymentは自動的に実行されます。

7. 通知とレポート

パイプライン完了後、チームは結果の通知を受け取ります：成功/失敗、実行時間、成果物へのリンク。Slack、Telegram、メール — 通知チャネルはチームのニーズに応じて選択されます。段階が失敗した場合、通知には特定のエラーログへのリンクが含まれます。

CIとCDの違い

CIとCDという用語は、しばしば単一の概念CI/CDとして使用されますが、両者には根本的な違いがあります。CI（Continuous Integration）はコード統合のたびに品質チェックを担当し、CD（Continuous Delivery）はコードのリリース準備を保証します。パイプラインを設計する際、この違いを理解することは極めて重要です。

Continuous Integration — 品質チェック

CIはすべてのプッシュまたはプルリクエストで実行され、ビルド、静的解析、テストを含みます。CIの目標は、修正コストが最小であるうちに、できるだけ早く問題を検出することです。CIが失敗した場合 — コードはメインブランチに入りません。モバイルプロジェクトの平均CI実行時間は5～15分です。

Continuous Delivery — リリース準備

CDはCIにリリース準備の段階を追加します：署名、難読化、リリースノート作成、ライセンス確認、テスター向けストレージへの公開。CDは保証します、メインブランチへの任意のコミットがワンクリックで本番環境に出荷可能であることを。ただし、リリース自体には手動承認が必要です。

CI/CD Pipeline構築ツール

モバイル開発向けのCI/CDツールエコシステムには、クラウドサービス、セルフホステッドソリューション、専門プラットフォームが含まれます。ツールの選択は、チームサイズ、予算、セキュリティ要件によって異なります。以下に最も人気のあるオプションを示します。

GitHub Actions

GitHubに組み込まれたCI/CDで、パブリックリポジトリには月2000分の無料枠があります。GitHub Actionsは、既成アクションの巨大なエコシステム（マーケットプレイス）、YAMLによる簡単な設定、GitHubリポジトリとのシームレスな統合により人気があります。制限 — 無料プランではiOSビルド用のWindowsランナーをサポートしていません。

GitLab CI/CD

強力なYAMLコンフィギュレーターを備えたセルフホステッドおよびクラウドソリューション。GitLab CIは並列ジョブ、キャッシング、成果物、環境をサポートします。自社インフラへのデプロイが可能でデータを完全に制御できるため、エンタープライズセグメントで人気があります。

Jenkins

クラシックなオープンソースCIサーバー。Jenkinsはプラグイン（1800以上）で設定され、Groovy形式のDeclarative Pipelineをサポートし、Windows、macOS、Linuxの任意の環境で動作します。専任の管理が必要ですが、最大限の設定柔軟性を提供します。

CircleCI

速度とシンプルさに焦点を当てたクラウドCIサービス。CircleCIは依存関係を自動的にキャッシュし、分離ビルド用のDockerイメージをサポートし、iOSビルド用にmacOSと統合します。料金はクレジットベース — パフォーマンスを重視するチームに適しています。

CI/CD Pipeline設定例

GitHub ActionsとFastlaneを使用したiOSアプリ向けの完全なCI/CD Pipelineを見てみましょう。Fastlaneはモバイルプロジェクト向けの自動化ツールで、複雑なビルド、署名、公開操作をシンプルなコマンドに抽象化します。

# Fastfile — iOS CI/CD用のFastlane設定
default_platform(:ios)

platform :ios do
  desc "テストの実行とリンティング"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "リリースビルドとTestFlightへのアップロード"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlaneのmatchは証明書とプロビジョニングプロファイルを管理し、build_appはIPAをビルドし、pilotはビルドをTestFlightにアップロードします。fastlane releaseコマンドはすべての段階を順次実行します：証明書を取得し、ビルドし、署名し、ベータテスター向けにApp Store Connectにアップロードします。

GitHub Actionsを使用したiOS向けCI/CD Pipeline

FastlaneをGitHub Actionsと統合することで、メインブランチへのプルリクエスト時に完全なパイプラインを自動的に実行できます。iOSコードのコンパイルにはmacOS上のセルフホステッドランナーが必要です — GitHubは無料プランでmacOSランナーを提供していません。

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

CI/CD Pipelineのベストプラクティス

効果的なCI/CD Pipelineを構築するには、ツールを選ぶだけでなく、実証されたプラクティスに従う必要があります。適切な組織化がなければ、パイプラインはボトルネックとなり、開発を加速するどころか遅らせる可能性があります。以下は、成熟したモバイルチームの経験に基づく主要な推奨事項です。

Fail Fast（迅速な失敗）

最も高速なチェック（リンティング、ユニットテスト）が最初に実行されます。これらが失敗した場合 — パイプラインは長時間のUIテストやリリースビルドを実行せずに終了します。Fail fastはCI時間を節約し、開発者へのフィードバックを迅速化します。最初の失敗までの平均時間は2～3分を超えないようにする必要があります。

依存関係のキャッシング

Gradleキャッシュ、CocoaPodsキャッシュ、SPMキャッシュは実行間で復元される必要があります。GitHub Actionsはactions/cacheを介したキャッシングをサポートし、GitLab CIはcacheキーワードを介してサポートします。キャッシングがない場合、各ビルドはすべての依存関係を新たにダウンロードし — パイプライン時間に3～10分追加されます。

並列実行

独立した段階（AndroidとiOSのリンター、異なるモジュールのユニットテスト）は並列ジョブとして実行されます。並列化により、パイプライン全体の時間が20～30分から5～10分に短縮されます。ほとんどのCIサービスは並列ジョブを別途課金します — プラン選択時に留意してください。

環境の分離

各パイプライン実行はクリーンな環境で実行されます：Dockerコンテナ、仮想マシン、またはエフェメラルランナー。分離は以前のビルドが現在のビルドに影響を与えるのを防ぎます。プロジェクト間で共有ランナーを使用しないでください — クロスプロジェクトの環境汚染は非決定的な障害を引き起こします。

シークレットのセキュリティ

APIキー、署名証明書、アプリストアアクセストークンは、CIサーバーの暗号化された保管庫に保存されます。SECRET_プレフィックスなしで、ログ、成果物、環境変数にシークレットを絶対に含めないでください。iOS証明書管理にはFastlane matchなどのツールを使用してください。