GitLab CI：パイプラインと継続的インテグレーション

GitLab CIとは？

GitLab CIは、統合DevSecOps GitLabアプリケーションの一部であり、継続的インテグレーション、デリバリー、デプロイメントを含みます。このシステムは2012年に別個のプロジェクトとして始まりましたが、後にGitLabに直接統合されました。基本原則は、リポジトリルートの.gitlab-ci.ymlファイルによる設定 as Codeです。GitLab CIはクラウドSaaS版とセルフマネージドインストールの両方で利用できます。

モバイル開発向けに、GitLab CIはAPKおよびIPAビルドの自動化、インストルメントテストの実行、静的コード分析、アプリ署名、ストア公開を提供します。プラットフォームはカスタム環境向けのDockerイメージをサポートし、Android SDK、NDK、Xcode、その他のツールをプリインストールできます。組み込みのContainer Registryにより、チーム内でのイメージの保存と配布が簡素化されます。

GitLab CIのアーキテクチャ：Runners、Pipelines、Stages

GitLab CIのアーキテクチャは3つの主要コンポーネントで構成されています。GitLab Runnerはジョブを実行するエージェントです。ランナーには共有（GitLab提供）、グループ（プロジェクトグループ用）、特定（単一プロジェクト用）があります。各ランナーはExecutor（Shell、Docker、Kubernetes、VirtualBox）を指定して登録されます。GitLab Runnerはピーク負荷に対処するための自動スケーリングをサポートしています。

パイプラインは順次実行されるステージの集合です。1つのステージ内ではジョブが並列実行されます。モバイルプロジェクトの典型的な構造は、build → test → deployです。testステージのジョブが失敗した場合、deployはトリガーされません。デプロイメントには手動トリガー（when: manual）を設定できます。リポジトリ間の複雑なCI/CDシナリオ向けに、マルチプロジェクトパイプライントリガーもサポートされています。

GitLab RunnerのExecutor

Docker ExecutorはモバイルアプリCI/CDで最も人気があります。各ジョブはクリーンなDockerコンテナ内で実行され、分離性と再現性を保証します。AndroidビルドにはSDKプリインストール済みのandroid-sdkイメージを使用します。iOSにはShell Executorを使用するmacOSランナーを使用します。

モバイルプロジェクトの.gitlab-ci.yml設定

.gitlab-ci.ymlファイルはYAML形式でパイプラインを定義します。主要なセクションには、image（Dockerイメージ）、stages（ステージリスト）、variables（環境変数）、before_script（各ジョブ前のコマンド）、およびscript、artifacts、cacheセクションを含むジョブがあります。GitLab CIはincludeをサポートしており、プロジェクト間で共通設定を再利用するための外部YAMLファイルのインクルードが可能です。

GitLab CIの変数は複数レベルで設定できます：UIでのグローバル設定、設定ファイル、グループおよびプロジェクト設定。変数の優先順位は階層に従います：トリガー変数が最優先、次にUIからのCI/CD変数、最後に.gitlab-ci.ymlからの変数です。変数は保護可能で、保護されたブランチとタグからのみアクセス可能になります。

基本変数とイメージ

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

アーティファクト付きビルドジョブ

generate-apkジョブはGradleプロジェクトをビルドし、APKをアーティファクトとして保存します。アーティファクトはステージ間で受け渡され、deployジョブはbuildステージのAPKを使用できます。アーティファクトの保存期間はexpire_inで設定します。

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions：主な違い

モバイルプロジェクトにGitLab CIとGitHub Actionsのどちらを選ぶかは、チームのインフラが重要な要素です。GitLab CIはAndroid SDKを含むDockerイメージを保存するための組み込みContainer Registryを提供します。GitHub ActionsはGitHub Packagesまたは外部レジストリに依存します。GitLabにはコード脆弱性分析のための組み込みSAST（静的アプリケーションセキュリティテスト）もあります。

GitLab CIはより柔軟なランナーモデルを提供します — Kubernetes Executor、自動スケーリング、カスタムイメージをサポートします。GitHub ActionsはGitHubエコシステムとの統合とアクションマーケットプレイスで優れています。GitLab CIは、GitHub Actionsが既製のアクションで解決する多くのタスクに手動設定が必要です。

モバイルCI/CDの観点から：GitLab CIは既にGitLab Self-Managedを使用しており、Docker/Kubernetesでセルフホストランナーを必要とする企業に適しています。GitHub Actionsは、既製のアクションと設定の容易さを重視するクラウドGitHub上の小規模チームに便利です。

機能比較

Androidプロジェクトのパイプライン例

完全なAndroidパイプラインには、lint、単体テスト、ビルド、Firebase App Distributionへのデプロイが含まれます。パイプラインは Android SDKを含むDockerイメージ、Gradleキャッシング、同じステージでのlintとtestの並列実行を使用します。このアプローチにより、lintとtestタスクが互いに独立しているため、パイプライン全体の時間が短縮されます。

iOSプロジェクトの場合、パイプライン構造はmacOSランナーとコード署名の必要性により異なります。典型的なiOSパイプラインには、CocoaPodsまたはSPMのインストール、シミュレーターでのテスト実行、Xcodeプロジェクトのアーカイブ、IPAのエクスポート、TestFlightへのアップロードが含まれます。GitLab CI for iOSはmacOSランナーを使用します — 時間制限のあるGitLab SaaS macOSランナー、またはMac MiniやMacStadium上のセルフホストランナーです。

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

GitLab CIでのビルド時間の最適化

GitLab CIでのモバイルビルドパイプラインの最適化には細部への注意が必要です。cacheとartifactsの適切な設定により、ビルド時間を数分の一に短縮できます。パフォーマンス分析のために、GitLabはCI/CD Analyticsを提供しています — パイプライン実行時間、ランナー負荷、ボトルネックのメトリクスを表示するダッシュボードです。最適化の機会を見つけるために、これらのメトリクスを定期的に分析してください。resource_groupを設定すると、パイプラインの並列実行がブロックされ、デプロイ競合の防止に役立ちます。

CIのブランチ戦略も重要です。推奨されるのは、完全なパイプラインはmainブランチとreleaseブランチのみで実行し、フィーチャーブランチではlintと単体テストのみを実行することです。これによりランナーの分数を節約し、開発者へのフィードバックを高速化します。GitLab CIはworkflow:rulesをサポートしており、ブランチ、変更ファイル、環境変数に基づいてジョブを含めたり除外したりする条件付きルールが可能です。

依存関係のキャッシングが主要な高速化方法です。GitLab CIは実行間で.gradle、Pods、node_modulesをキャッシュします。キャッシュキーには$CI_COMMIT_REF_SLUGまたはロックファイルのハッシュが含まれます。適切なキャッシングにより、Androidプロジェクトのビルド時間は10〜15分から2〜4分に短縮されます。キャッシュは分散可能で、GitLabは以前のキーへのフォールバック付きのcache:keyをサポートしています。

ツールがプリインストールされたDockerイメージはインストール時間を節約します。推奨されるのは、Android SDK、NDK、必要なAPIレベルを含むカスタムイメージを作成することです。異なるステージでのジョブ（lint、test、assemble）の並列実行により、パイプライン全体の時間が短縮されます。イメージのプルポリシー（if-not-present）によりジョブの起動が高速化されます。GitLabインスタンスレベルでイメージをキャッシュするための依存関係プロキシも使用できます。

最適化のもう1つの重要な側面は、ステージ間でのアーティファクトの使用です。APKやIPAのような大きなファイルは、各ジョブで再ビルドするのではなく、dependencyを介して渡す必要があります。数十のモジュールを持つ大規模プロジェクトでは、パイプラインレベルでGradle Build Cacheを有効にし、共有ストレージにリモートキャッシュを設定することをお勧めします。各ジョブのタイムアウトは予想ビルド時間に基づいて設定する必要があります — これによりプロセスのハングアップを防ぎます。

キャッシングとプルポリシーの例

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present