Create practical workflows in Xcode Cloud

ハイライト

Xcode Cloud は、「いつトリガーするか (Start Conditions) + 何を実行するか (Actions) + どの環境で実行するか (Environment)」という 3 次元の構成モデルを使用しており、個々の開発者は単一のワークフローを使用して自動ビルドと配布を実現でき、中規模のチームは 3 つのワークフロー (PR 検証 / ベータ内部テスト / リリースリリース) を使用して開発プロセス全体をカバーでき、大規模なチームは「パス不要」テストモードを通じてレガシーテストをクラウドにスムーズに移行できます。

主要内容

個人開発者: 1 つのワークフローですべてを処理

1 人が iOS + macOS デュアルプラットフォームアプリケーションを保守し、CocoaPods を使用して依存関係を管理し、TestFlight を通じて親戚や友人と一緒にテストします。手動での作成と配布には多くの時間がかかります。

Xcode Cloud の解決策は、CI ワークフローを作成することです。

トリガー条件: 任意のブランチのコードプッシュ (Any Branch)
ビルドアクション: iOS と macOS のデュアルプラットフォームアーカイブ、[TestFlight と App Store] 展開の準備を選択します。
ポストアクション: TestFlight の「友達と家族」テストグループに自動的にアップロードします。

CocoaPods の依存関係は、クローン後のカスタムスクリプトを通じて処理されます。 Xcode Cloud は Swift Package Manager をネイティブにサポートしており、他の依存関係マネージャーはci_scripts/post_clone.shインストールするだけです。

（02:28）

中規模チーム: 分業とコラボレーションのための 3 つのワークフロー

開発者、プロジェクトマネージャー、QA からなるクロスタイムゾーンのチーム。作業モード: 開発者は独自のブランチで開発し、PR を通じてベータブランチにマージし、タグ付けとリリースのための QA テスト後にリリースブランチにマージします。

PR ワークフロー:

トリガー条件: ターゲットブランチがベータであるプルリクエスト
アクション: 4 つのデバイスでテストを実行します: iPhone 13、iPhone 14 Pro Max、iPad mini、iPad Pro
目的: マージ前にコードの品質を確認する

ベータ版リリースのワークフロー:

トリガー条件: ベータブランチのコードプッシュ
アクション: 最初にテストを実行し、次にアーカイブ (TestFlight 内部テストを選択)
事後処理: 「QA チーム」テストグループに配布します。
カスタムスクリプト: プリビルド段階でアプリのアイコンをベータ版のアイコンに置き換えます。

リリースワークフロー：・発動条件：タグ名が「release/」で始まるプッシュ

アクション: アーカイブ (TestFlight と App Store を選択)
事後アクション: 最初に社内の「幹部関係者」に配布され、次に社外の「早期採用者」に配布されます。
通知: ビルドが完了したら、「リリースフィード」チャネルに Slack メッセージを送信します。

（07:30）

大規模チーム: 段階的な移行戦略

複雑なコードベースと広範なレガシーテストを行う大規模チームは、すでに自家製の CI/CD システムを使用しています。すべてを直接移行するのはリスクが高すぎます。

次の 3 つのステップで進めることをお勧めします。

最初にリリースワークフローを構築します: App Store アーカイブビルドを Xcode Cloud に移動し、組み込みの Cloud Code Signing を使用して、証明書と説明ファイルの管理の必要性を排除します。
再移行テスト: PR ワークフローを作成し、すべてのテストを「合格する必要はない」としてマークします。テストの失敗によってマージが妨げられることはありませんが、テストの信頼性データは収集できます。一定期間実行した後、安定したテストと合格したテストを「信頼できるテスト」テスト計画に移動し、これらの安定したテストのみを実行する新しい必須テストアクションを作成します。不安定なテストは引き続き修正され、段階的に移行されます。
最後に他のワークフローを完了します: Webhook と Xcode Cloud Public API を使用して、既存のプロジェクト管理ツールおよびダッシュボードと統合します

（19:12）

詳細

ワークフローの中心的な概念

Xcode Cloud のワークフローは、次の 3 つの次元で定義されます。

内容: ビルド、テスト、アーカイブ、分析、その他のアクション
どこ (どの環境): Xcode バージョン、macOS バージョン、環境変数
いつ (トリガーされたとき): ブランチの変更、プルリクエストの変更、タグの変更、スケジュール

カスタムビルドスクリプト

Xcode Cloud は、ビルドのさまざまな段階でフックスクリプトを提供し、プロジェクトのルートディレクトリに配置されます。ci_scripts/フォルダー内:

スクリプト名	実行時間	目的
`ci_post_clone.sh`	コードの複製が完了したら	依存関係 (CocoaPods など) をインストールします。
`ci_pre_xcodebuild.sh`	Xcode ビルドが開始される前	ビルド構成を変更する (アイコンの置き換えなど)
`ci_post_xcodebuild.sh`	Xcode のビルドが完了したら	追加の製品をアップロードして通知を送信する

ベータ版アイコン置換スクリプトの例

（14:38）

#!/bin/sh
# ci_pre_xcodebuild.sh

if [[ "$CI_XCODEBUILD_ACTION" == "archive" && "$CI_WORKFLOW" == "Beta" ]]; then
    echo "Replacing app icon with beta icon"
    mv BetaAppIcon.appiconset ../App/Assets.xcassets/AppIcon.appiconset
fi

キーポイント:

CI_XCODEBUILD_ACTION環境変数は、現在実行されているアクション (アーカイブ/ビルド/テストなど) を識別します。 -CI_WORKFLOW環境変数は現在のワークフローの名前を識別します
ベータワークフローのアーカイブ段階でのみ条件判断によりアイコンを置き換えます
スクリプトは次の場所に配置されます。ci_scripts/ci_pre_xcodebuild.sh, Xcode Cloud が自動的に識別して実行します。

「合格する必要はない」テスト移行モード

（23:21）

大規模チームのテストを移行する際の主な問題点: テストは古い CI 環境では安定して実行されますが、新しい環境ではタイミングやリソースなどの違いにより失敗する可能性があります。 Required に直接設定すると、通常の開発がブロックされます。

Xcode Cloud では、テストアクションの要件を「合格する必要はない」に設定できます。

テストの失敗によってビルドが失敗することはありません
PR は引き続きマージ可能
チームは新しい環境でのテストの安定性を観察できます

一定期間実行した後、安定して合格したテストを新しいテスト計画に移動し、これらのテストを具体的に実行するために必須のテストアクションを作成します。不安定なテストは 1 つずつ修正され、段階的に必須に移行されます。

Webhook とパブリック API の統合

（26:44）

Xcode Cloud は 2 つの外部統合方法をサポートしています。

Webhook: ビルドが完了したら、ビルドステータス、ワークフロー情報、送信情報などを含む HTTP リクエストを指定された URL に送信します。作業指示書を作成し、独自のサーバーで受信した後にダッシュボードを更新できます。

パブリック API: App Store Connect API を介してビルド履歴をクエリし、ビルドの詳細を取得し、ビルド製品をダウンロードします。内部ダッシュボードまたはステータスページにビルドデータを表示するのに適しています。

ワークフロー再利用スキル

（16:16）

Xcode Cloud は、右クリックのコピーワークフローをサポートしています。リリースワークフローとベータワークフローは通常非常に似ており、直接コピーして変更できます。

トリガー条件の変更（分岐変更→タグ変更）
導入準備オプションの変更 (内部テスト → TestFlight および App Store)
テストチームを変更します (QA チーム → 幹部関係者 + 早期導入者)
通知チャネルの追加 (Slack/電子メール)

重要ポイント

1. 異なるブランチのアプリケーション構成を自動的に切り替える

対処方法: ビルド対象 (デバッグ / ベータ / リリース) に応じて、バンドル ID、アプリケーションアイコン、API エンドポイントを自動的に切り替えます。

実行する価値がある理由: 複数のターゲットまたはスキームを手動で保守することを避け、構成エラーを減らします。 Xcode Cloud のカスタムスクリプトと環境変数により、これが完全に自動化されます。

開始方法:ci_pre_xcodebuild.sh中程度の基準CI_WORKFLOWそしてCI_BRANCH環境変数、使用しますplutilInfo.plist の API エンドポイントを次のように変更します。mvAppIconを置き換えます。

2. ビルドが失敗した場合に Jira/Linear 作業指示書を自動的に作成する

内容: Xcode Cloud のビルドが失敗した場合、プロジェクト管理ツールで修復チケットが自動的に作成され、関連する開発者に割り当てられます。

実行する価値がある理由: 大規模なチームではビルドの失敗が見落とされがちです。 Webhook 経由でビルドステータスを受信し、チケットを自動的に作成して、問題が確実に追跡および修正されるようにします。

開始方法: 独自のサーバーを指すように Xcode Cloud Webhook を構成し、ビルド失敗情報を解析し、Jira/Linear API を呼び出して作業指示書を作成します。コミット作成者は Webhook ペイロードから取得できますscmCommit.authorフィールド獲得。

3. テスト安定性ダッシュボード

何をすべきか: Xcode Cloud Public API を使用して、履歴ビルドデータを取得し、テスト合格率の傾向グラフを生成します。

実行する価値がある理由: 「合格する必要はない」モードのテストデータは、どのテストが不安定であるかを定量化し、チームが不安定なテストの修正に優先順位を付けるのに役立ちます。

開始方法: App Store Connect API の使用/ciBuildRunsエンドポイントはビルド履歴を取得し、各テストケースの失敗率と失敗理由をカウントし、Grafana または自作ページを使用して表示します。

4. PR ビルド時間の最適化

何をすべきか: PR によって変更されたファイルパスに基づいて、関連するテストのサブセットのみを実行します。

実行する価値がある理由: 大規模プロジェクトのテストスイートの実行には数十分かかる場合があります。変更されたファイルを git diff で分析し、関連するモジュールのテストのみをトリガーすることで、PR フィードバック時間を大幅に短縮できます。

開始方法: PR ワークフローのプリビルドスクリプトで使用しますgit diff変更されたファイルを分析し、テストマッピングテーブル (たとえば、Models/ディレクトリの変更はモデルテストのみを実行します)、動的にテスト計画を生成して渡します。xcodebuild。