GitHub Actions — その概要、CI/CDパイプラインと自動化

GitHub Actionsとは？

GitHub ActionsはGitHubに組み込まれたワークフロー自動化プラットフォームで、2019年にローンチされました。リポジトリに直接保存されるYAMLファイルでCI/CDパイプラインを定義できます。各ワークフローはプッシュ、プルリクエスト、タグ作成、スケジュールなどのトリガーで起動されます。JenkinsやTeamCityとは異なり、CIサーバーをホストするための個別のインフラストラクチャは必要ありません。

モバイル開発のコンテキストでは、GitHub ActionsはAPKやIPAのビルド、エミュレータでの単体テストやUIテストの実行、リンターによるコードチェック、署名、Google PlayやApp Storeへの公開を自動化します。このプラットフォームは無料分を提供しており、パブリックリポジトリ向けとプライベートリポジトリ向け（料金プランによる）があります。オープンソースのモバイルプロジェクトにとって、これはコストのかからない本格的なCI/CDソリューションです。

GitHub Actionsのアーキテクチャ: Workflows、Jobs、Steps

GitHub Actionsのアーキテクチャは4つのレベルで構成されています。Workflowは自動化を定義するルートYAMLファイルです。WorkflowはJobで構成され、各Jobは個別のRunnerで実行されます。Job内ではSteps（順次コマンドまたは外部アクション）が実行されます。Eventsはトリガー（push、pull_request、schedule、workflow_dispatch）を定義します。ワークフローはGitHubインターフェースのActionsタブから手動でトリガーすることもできます。

GitHubはOSがプリインストールされたホステッドランナー（Ubuntu、macOS、Windows）を提供しています。iOSビルドにはmacOSランナーが必須で、AndroidにはLinuxまたはmacOSが必要です。セルフホステッドランナーを使用すると、カスタム環境の独自サーバーでジョブを実行でき、特別なハードウェア要件がある大規模プロジェクトに役立ちます。GitHubはジョブ実行キューの編成のためにセルフホステッドランナーグループもサポートしています。

ワークフローファイルの構造

基本的なワークフローファイルには、name、on（トリガー）、jobsのセクションが含まれます。各ジョブはruns-on（ランナータイプ）、strategy（マトリックス）、steps（アクションリスト）を指定します。Stepsはシェルコマンドまたはマーケットプレイスからの既製アクションで、owner/repo@versionの構文で接続されます。

GitHub Actionsでのモバイルアプリケーションのビルド

Androidビルドの場合、ワークフローには通常、リポジトリのチェックアウト、JDKのインストール、Gradleキャッシュの設定、assembleReleaseの実行が含まれます。iOSの場合はmacOSランナーが必要で、xcode-selectによるXcodeのインストール、プロビジョニングプロファイルの解決、xcodebuildの実行が必要です。iOSビルドの複雑さはコード署名と証明書管理にあります。Apple固有の設定には、apple-actions/import-codesign-certsによるプロビジョニングプロファイルの管理が含まれます。

Matrix strategyを使用すると、複数のバージョンで同時にビルドを実行できます。例：iOSバージョン（15.0、16.0、17.0）とXcode（14、15）のマトリックス。これにより検証が高速化され、異なるOSバージョンとのアプリケーション互換性が確認できますが、ランナー分数の消費が増加します。CI予算が限られているプロジェクトでは、マトリックスを主要な構成のみに制限できます。

Androidの環境設定

GitHub ActionsはJDKインストール用のsetup-javaアクションとGradleキャッシング用のcachingを提供しています。Android SDKはUbuntuランナーにプリインストールされています。カスタムAPIレベルの場合は、別のステップでsdkmanagerを使用します。AndroidとiOSのビルドでは異なるランナーとビルドツールを使用するため、個別のワークフローを作成することをお勧めします。

GitHub Marketplaceと既製アクション

GitHub Marketplaceには、コミュニティと公式開発者によって作成された15,000以上のアクションがあります。モバイル開発の主要カテゴリには、コード署名（apple-actions/import-codesign-certs）、テスト（react-native-community/action）、デプロイ（google-github-actions/release-google-play）、通知（slackapi/slack-github-action）が含まれます。Firebase App Distribution、TestFlightアップロード、Fastlane用のアクションも利用できます。各アクションには特定のランナーOSとの互換性ラベルがあります。

各アクションにはバージョン、説明、README、ライセンスがあります。アクションを選択する際は、ベンダー（Google、Apple、Microsoft）からの公式アクションとVerified Badgeで検証されたものを優先する必要があります。固定のメジャーバージョン（actions/checkout@v4）を指定することが重要で、@mainを指定して予期しない変更を避けます。必要なアクションがMarketplaceにない場合は、カスタムアクションを作成できます（リポジトリ内のDockerアクションまたはJavaScriptアクション、あるいはMarketplaceに公開）。

モバイルCI/CDで人気のアクション

• actions/checkout — リポジトリをランナーにクローン
• actions/setup-java — Androidビルド用にJDKをインストール
• gradle/actions/setup-gradle — Gradleを設定してキャッシュ
• apple-actions/import-codesign-certs — iOS用に証明書をインポート
• google-github-actions/submit-release — Google Play Consoleに公開

iOSプロジェクトのワークフロー例

iOSアプリケーションを開発する際は、シミュレーターとデバイスでの正しい動作を設定することが重要です。macOS-14ランナーは、ARMアーキテクチャでIntelビルドを実行するためのRosetta 2を備えた環境を提供します。ワークフローには複数のビルドスキーム（プルリクエスト用のDebugとタグ用のRelease）を含めることができます。GitHub Actionsは、テスト結果を表示するためのxcparse/sonarqubeアクションによるxcresult解析をサポートしています。ビルドステータス通知を送信するために、SlackやTelegramのアクションを追加できます。

iOSのコード署名には、証明書とプロビジョニングプロファイルのインポートが必要です。Apple-actionsはP12証明書のインポートとプロビジョニングプロファイルのインストールのためのステップを提供しています。証明書はGitHub Actionsのシークレットとして保存され、ビルド段階でのみ復号化されます。署名の自動化にはFastlane matchが使用され、ワークフロー内の個別のステップとして呼び出すことができます。

Swiftで書かれたiOSアプリのワークフローを見てみましょう。プロジェクトをビルドし、テストを実行し、アーカイブビルドを作成します。このワークフローはmacOS-14ランナー、Xcode 15.4、証明書管理用のアクションを使用します。

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

GitHub Actionsでの依存関係のキャッシュ

キャッシュはワークフロー実行間で依存関係を保持することでビルド時間を短縮します。GitHubはactions/cacheによる組み込みキャッシュを提供しています。Gradleの場合は~/.gradle、CocoaPodsの場合はPods/、SPMの場合は.build/がキャッシュされます。キャッシュキーには依存関係リストファイルのハッシュが含まれ、依存関係が変更されるとキャッシュは自動的に無効化されます。

キャッシュ復元戦略（restore-keys）には特別な注意を払う必要があります。正確なキーが見つからない場合、GitHub Actionsはrestore-keysによる部分一致を試みます。これは1つの依存関係のみが変更された場合に有用で、キャッシュは部分的に使用可能なままです。Gradleの場合は、プロジェクトの異なるモジュール間でビルド結果をキャッシュするGradle Build Cacheを有効にすることをお勧めします。

Gradleキャッシュの例

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

キャッシュ効率（Androidプロジェクト）：キャッシュなしの初回ビルド — 8–12分、キャッシュありの後続ビルド — 2–4分。CocoaPodsを使用するiOSの場合も同様の節約効果があります。最適なキャッシュ管理のために、actions/cacheをGradleのsetup-gradleアクションと組み合わせることをお勧めします。React Nativeのnpm依存関係の場合は、package-lock.jsonのハッシュ化とともにactions/cacheが使用されます。適切なキャッシュ設定により、ビルド時間を最大70%削減できます。

GitHub Actionsはワークフロー、ジョブ、ステップレベルで環境変数をサポートしています。環境変数は上書き可能で、ステップレベルが最も優先されます。機密データには常にシークレットを使用してください。シークレットはAES-256で暗号化され、ログに表示されません。環境保護ルール（デプロイ前の必須手動承認）も利用できます。追加のセキュリティとして、特定のユーザーやチームからの必須承認を設定できます。

GitHub ActionsはReusable Workflowsもサポートしています。これは他のワークフローから呼び出し可能な再利用可能なパイプラインです。これにより集中化されたビルドワークフローを作成し、組織のすべてのリポジトリで再利用できます。Reusable workflowは1行で呼び出され、入力パラメータとシークレットを受け入れることができます。これは大規模チームでのCI/CDプラクティスの標準化に特に役立ちます。

セキュリティとベストプラクティス

モバイルプロジェクト用にGitHub Actionsを設定する際は、セキュリティの原則に従うことが重要です。OIDC（OpenID Connect）を使用すると、長期有効な認証情報を排除し、クラウドプロバイダー用の一時的なトークンを取得できます。スクリプトで平文のシークレットを使用しないでください。GitHub Actionsはログ内のシークレットを自動的にマスクします。

モバイルプロジェクトでは、サードパーティのフォークからのワークフローアクセスを制限することが重要です。pull_request_target設定は注意して使用してください。これはフォークではなくベースブランチからコードを実行します。iOSアプリのコード署名については、証明書を暗号化して保存し、gpgやopensslを使用してビルド段階でのみ復号化することをお勧めします。