モバイル開発におけるBuild Pipeline — 本質、段階、設定

Build Pipelineとは

Build Pipelineは、コードが変更されるたびに自動的に実行される正式な一連のステップです。各ステップは、コンパイル可能性、テストの正確性、脆弱性の有無、コードスタイルの準拠など、品質の特定の側面をチェックします。いずれかのステップが失敗すると、パイプラインは停止します。

パイプラインの概念は生産ラインから来ています — 工場で各ステーションが製品に価値を付加するのと同じです。開発において、各段階はコードがリリースの準備ができているという自信を追加します。現代のパイプラインはコードとして定義され（Pipeline as Code）、プロジェクトとともにGitリポジトリに保存されます。

Continuous Delivery Foundation、2025によると、成熟したbuild-pipelineはコミットからリリースまでの時間を週単位から分単位に短縮します。これは完全な自動化と独立した段階の並列実行によって達成されます。

Pipeline as Code

ウェブインターフェースを通じて設定する代わりに、現代のパイプラインはYAMLまたはGroovyファイルで記述されます。Jenkinsfile、`.gitlab-ci.yml`、`.github/workflows/build.yml`はPipeline as Codeの例です。利点：バージョン管理、コードレビュー、再現性。

宣言型パイプライン vs スクリプト型パイプライン

Jenkinsには2つの構文があります。宣言型はよりシンプルで、明確なstages/steps構造を持ちます。スクリプト型はより柔軟で、Groovyに基づいています。ほとんどのプロジェクトでは、読みやすく予測可能な宣言型アプローチが推奨されます。

標準的なパイプラインの段階

モバイルアプリケーションの標準的なbuild-pipelineには、いくつかの主要な段階が含まれます。各段階はその機能を実行し、潜在的な問題を早期にフィルタリングします。

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

パイプラインはリポジトリのクローンから始まります。次に依存関係がインストールされます：Gradle/Mavenパッケージ、CocoaPods、SPM（Swift Package Manager）、npmパッケージ。この段階でキャッシュを使用すると、後続のビルドが50〜70%高速化されます。

リンティングと静的解析

コンパイル前に、コード品質ツールが実行されます：Kotlin用のDetektまたはktlint、Swift用のSwiftLint、JavaScript用のESLint。これらはコードスタイルの準拠をチェックし、コード解析レベルで潜在的なバグを見つけます。

コンパイルと単体テスト

コードはバイナリ形式にコンパイルされ、単体テストは並行して実行されます。Androidの場合は`./gradlew testDebugUnitTest`、iOSの場合は`xcodebuild test -scheme App -destination 'platform=iOS Simulator'`です。テストの失敗は直ちにパイプラインを停止します。

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

統合テストとUIテスト

コンパイルが成功した後、アプリケーションの実行を必要とするテストが実行されます：Android用のEspresso、iOS用のXCTest/XCUITest、React Native用のDetox。この段階では、アーティファクトはファームサービス（Firebase Test Lab、BrowserStack、Sauce Labs）を通じてシミュレーターまたは実機にデプロイされます。

パイプラインの設定

パイプラインの適切な設定は、CI/CDプロセス全体の効率を決定します。設定にはトリガーの選択、並列段階と順次段階の定義、パラメータ化、外部サービスとの統合が含まれます。

パイプラインのトリガー

主なトリガー：リポジトリへのプッシュ、プルリクエスト（特に自動チェックによるコードレビュー）、Gitタグの作成（リリースビルド用）、スケジュール（ナイトリービルド）。プルリクエストトリガーは、コードマージ前に問題を特定できるため、チームワークに最も実用的です。

並列段階と順次段階

独立した段階（リンティング、異なるOSバージョンでのテスト）は、高速化のために並行して実行する必要があります。依存する段階は順次実行します。最新のCIシステムは、並列タスクを自動的に管理し、利用可能なエージェントに分散します。

• Fail-fast — 並列ブランチのエラー時に即座に失敗するように設定
• Matrix build — 複数の設定（API Level、Xcodeバージョン）で1つのビルドを実行
• 条件付き段階 — 一部の段階は特定のブランチでのみ実行（例：mainからのみデプロイ）

Build Pipelineの最適化

長いパイプラインは開発サイクルを遅らせ、チームのモチベーションを低下させます。ビルド時間の最適化は、build pipelineを扱うDevOpsエンジニアの主要なタスクの1つです。

依存関係のキャッシュ

Gradle Build Cacheは以前のコンパイル結果を保存します。モジュールのソースコードが変更されていない場合、再コンパイルされません。SwiftとKotlinのインクリメンタルコンパイルも同様に機能します。キャッシュサイズはギガバイトに達する可能性がありますが、時間の節約は30%から70%の範囲です。

テストの並列実行

単体テストは複数のエージェントで同時に実行し、テストクラスを分散できます。Shardingはテストをグループ（shard）に分割する手法です。GitHub Actionsは`strategy.matrix`、JenkinsはParallel Test Executor、Gradleは`--parallel --max-workers`をサポートしています。

パイプライン層の最小化

余分な段階ごとに時間が追加されます。定期的にパイプラインを分析してください：どの段階を統合できますか？ 例えば、リンティングはコンパイルの前ではなく並行して実行できます。統合テストはすべてのコミットではなく、プルリクエストのみで実行します。

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Build Pipelineのセキュリティ

Build pipelineはソフトウェアサプライチェーンの重要な要素であり、そのセキュリティを無視することはできません。パイプラインの侵害は、リリースアーティファクトへの悪意のあるコードの注入につながり、アプリケーションのすべてのユーザーに影響を与える可能性があります。

パイプラインへのサプライチェーン攻撃

既知の攻撃：SolarWinds（2020年）、Codecov（2021年）、3CX（2023年） — すべてCI/CDパイプラインの脆弱性を悪用しました。共通ベクトル — 攻撃者がビルドサーバーの認証情報にアクセスし、ビルド段階でコードを変更します。結果 — 正当な証明書で署名された悪意のあるリリース。

認証情報の保護

絶対に保存しないでください署名キー、APIトークン、パスワードをリポジトリやCIシステムの環境変数に平文で。CIシステムのシークレット（GitHub Secrets、GitLab CI Variables）、HashiCorp Vault、AWS Secrets Managerを使用してください。シークレットへのアクセスを最小限に — 各パイプラインは特定のステップに必要なキーのみを受け取る必要があります。

パイプラインアーティファクトの検証

パイプラインから出力されるすべてのアーティファクトは暗号的に署名され、証明（attestation）— 出所の証明（provenance）を含める必要があります。ツール：SLSAフレームワーク、in-toto attestation、コンテナ署名用のcosign。署名の検証は、任意の環境へのデプロイ前に行う必要があります。

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

パイプラインの監視とデバッグ

Build pipelineは継続的な監視を必要とする複雑なシステムです。メトリクスなしでは、パイプラインが遅くなったかどうか、どの段階がボトルネックになったかを判断することは不可能です。

パイプラインのメトリクス

追跡する項目：パイプラインの合計時間、各段階の時間、ビルド失敗率、キュー待機時間。大規模なチーム（20人以上の開発者）の場合は、GrafanaやDatadogで週/月の集計統計を含むダッシュボードを設定することをお勧めします。

障害時のアラート

パイプラインの障害には毎回対応が必要です。エラーログへのリンクとコミット作成者の名前を含む通知をメッセンジャー（Slack、Telegram、Discord）に設定してください。重大な障害には — エスカレーション付きのPagerDutyまたはOpsgenie。

ローカルでのパイプラインのデバッグ

Act（GitHub Actions用）やJenkins Pipeline Unit Testなどのツールを使用すると、コミットせずにパイプラインをローカルで実行できます。これにより、特に新しい段階の追加や設定変更時のパイプラインの開発とデバッグが高速化されます。