Explore Xcode Cloud workflows

ハイライト

Xcode Cloud ワークフローは、起動条件、ビルド環境、ビルド アクション、およびその後の配布を結び付け、チームが Xcode および App Store Connect でビルド、分析、テスト、アーカイブ、TestFlight 配布を自動化できるようにします。

主要内容

チームがアプリを開発するとき、変更がマージされて初めて問題が見つかることを最も恐れます。テストの実行を忘れる人、自分のマシンでのみ検証する人、再チェックせずにプル リクエストを変更する人もいます。最終的には、master ブランチがすべてのリスクを負います。

Fruta チームには、メイン ブランチを構築するためのデフォルトのワークフローがすでにあります。ただし、プルリクエストも使用します。マージする前に、チームはこの変更とメインをコンパイル、テスト、アーカイブできるかどうかを確認し、ビルド結果をチーム メンバーに送信する必要があります。

Xcode Cloud のワークフローはこの問題を解決します。 CI/CD プロセスは、いつ実行するか、どの macOS および Xcode 環境で実行するか、実行するアクション、終了後に誰に通知するか、TestFlight に配布するかどうかなど、いくつかの構成可能な部分に分割されます。

マージ前のプルリクエストの検証

以前は、Pull Request の検証は開発者のイニシアチブに依存することが多かった。ローカルでテストを実行する人もいれば、コードの差分だけを見る人もいます。みんながよく確認していても、現地の環境は違うかもしれません。

Xcode Cloud は起動条件を次のように設定できます。Every Change to a Pull Request。ソース ブランチは任意のブランチにすることができ、ターゲット ブランチは main に設定されます。誰かがプル リクエストを作成または更新するたびに、ワークフローが自動的に実行され、マージされたソース ブランチとターゲット ブランチが構築されます。

この設定はリスクを直接的に前進させます。チームはマージ前に実際の影響を確認できるため、メインブランチが壊れるのを待ってからそれを理解するために戻る必要がありません。

ビルド環境はワークフローによって修正されます

ローカル ビルドに関するもう 1 つの問題は、環境の違いです。 1 人は Xcode の新しいバージョンを使用しており、もう 1 人はまだ古いバージョンを使用しています。一部の問題はクリーン ビルドでのみ発生し、インクリメンタル ビルドでは問題が隠蔽される可能性があります。

Xcode Cloud の環境領域では、macOS と Xcode のバージョン、および最新リリースまたはベータを選択できます。ワークフローでは、増分ビルドとクリーン ビルドのどちらかを選択することもできます。プル リクエストのシナリオでは、速度と引き換えに増分ビルドを使用できます。リリース シナリオではクリーン ビルドを使用して、製品が確実に再生成されるようにすることができます。

このようにして、チームは「ローカル環境は何ですか?」と尋ねる必要がなくなります。ワークフロー自体が環境宣言です。

アクションとその後の操作の分離

ワークフローの中心的なタスクはアクションによって定義されます。このセッションは、アーカイブ、テスト、分析、構築に焦点を当てています。これらは、Xcode にネイティブな一般的なビルド操作をカバーしています。

ワークフローがこれらのアクションを完了すると、ポストアクションが実行されます。 Xcode Cloud は、通知の送信と、TestFlight の内部または外部のテスト グループへのアーカイブされた製品のデプロイをサポートしています。

この分割により、プロセスがより明確になります。最初にコードが検証され、次にチームに通知され、その後、インストール可能なバージョンがテスターに​​与えられます。

詳細

1. 開始条件を使用してプル リクエスト ワークフローをトリガーする

(03:37) 開始条件は、ワークフローがいつ実行されるかを定義します。講義でのプル リクエスト ワークフローの選択Every Change to a Pull Request、ソースブランチの選択Any Branch、対象ブランチ選択Main。

workflow:
  name: Pull Requests
  startCondition:
    type: Every Change to a Pull Request
    sourceBranch: Any Branch
    targetBranch: Main
    autoCancelPreviousBuilds: true

キーポイント:

• name: ワークフロー名。スピーチで名前を挙げられたPull Requests。
• type：トリガータイプ。Every Change to a Pull Requestプル リクエストが作成または更新されるときに実行されます。
• sourceBranch: ソースブランチ。Any Branchチームメンバーがどのブランチからでもプルリクエストを開始できるようにします。
• targetBranch:対象ブランチ。これは次のように設定されていますMain、マージターゲットに対応します。
• autoCancelPreviousBuilds: 講演では、以前に実行中のビルドをキャンセルできると述べましたが、これは複数の送信が継続的にプッシュされるシナリオに適しています。

(04:30) プル リクエストがビルドされると、Xcode Cloud はソース ブランチとターゲット ブランチのマージ結果をビルドしてテストします。球団が見たのは合併後の本当の姿だ。

Pull Request build input:
  source: feature branch
  target: main branch
  build: merged source + target

キーポイント:

• source: 開発者が送信している機能ブランチ。
• target: チームがマージされるメインブランチ。
• build: Xcode Cloud はマージ結果をチェックして、マージ後の失敗を減らします。

2. Xcode、macOS、クリーンビルドおよび環境変数を構成する

(05:24) 環境は、ワークフローの実行方法を定義します。 Xcode Cloud は Apple のクラウド インフラストラクチャ上で実行され、macOS バージョンと Xcode バージョンで利用できます。

environment:
  xcode: Latest Release
  macOS: selected in workflow editor
  clean: false

キーポイント:

• xcode: 特定のバージョンを指定することも、選択することもできます。Latest Releaseまたはベータ。
• macOS: ワークフロー エディターでビルドに使用する macOS バージョンを選択します。
• clean: プル リクエスト ワークフローでは、クリーンをオフにし、増分ビルドを使用して時間を短縮できます。

(06:18) クリーン ビルドは最初からコンパイルされます。この講演では、TestFlight の外部テスターに​​デプロイされるビルド、または App Store に送信されるビルドには Clean が必要であると説明されています。

releaseEnvironment:
  clean: true
  reason:
    - External Beta Testing with TestFlight
    - App Store submission

キーポイント:

• clean: true: 既存の派生データを使用せずに、ビルド プロダクトを最初から生成します。
• External Beta Testing with TestFlight: 外部 TestFlight テストにはクリーン ビルドが必要です。
• App Store submission: App Store 公開プロセスに送信するには、クリーン ビルドも必要です。

(07:28) 環境では、環境変数を構成し、機密変数をシークレットとしてマークすることもできます。

environmentVariables:
  - name: API_CONFIGURATION
    value: staging
    secret: false
  - name: SERVICE_TOKEN
    value: stored in Xcode Cloud
    secret: true

キーポイント:

• API_CONFIGURATION: 共通の環境変数。ビルド構成の制御に適しています。
• SERVICE_TOKEN: 機密情報。ウェアハウスに送信すべきではない API トークンなどの値に適しています。
• secret: true: 講演では、シークレット タグが追加の保護を提供すると述べています。

3. アクションを使用してアーカイブ、テスト、静的分析を実行する

(08:12) アクションは、ワークフローが実行されるたびに実行する内容を定義します。 Xcode Cloud は、ネイティブ Xcode の主要なアクション (ビルド、分析、テスト、アーカイブ) をサポートします。

actions:
  - type: Archive
    platform: iOS
    scheme: Fruta iOS
  - type: Test
    requiredToPass: true
    testSource: Use Scheme Settings
    simulators: Recommended
  - type: Analyze
    requiredToPass: false

キーポイント:

• Archive: TestFlight または App Store の配布に備えて、アーカイブされた製品を作成します。
• platform: 講義内の例では iOS プラットフォームを選択しています。
• scheme: 講演内の例では、Fruta の iOS スキームを使用しています。
• Test: 安定したクラウド環境でテストを実行し、ローカル マシンをリリースします。
• requiredToPass:テストまたは静的解析が全体のビルド結果に影響を与えるかどうかを設定できます。
• Use Scheme Settings: テストは Xcode スキームの設定を継承できます。
• Recommended: Xcode Cloud は、さまざまな画面サイズをカバーする推奨シミュレーターのコレクションを提供します。

(09:55) テスト アクションでは、特定のテスト計画を選択するか、エミュレータを推奨するか、エミュレータを指定するかを選択できます。エミュレータを指定する場合は、古いシステム バージョンを選択することもできます。

testAction:
  source: Use Scheme Settings
  alternative: Select a test plan
  destinations:
    option: Recommended
    coverage: different screen sizes

キーポイント:

• source: ローカル テスト構成の再利用に適したスキーム設定を使用します。
• alternative: 特定のテスト セットのみを実行するのに適したテスト計画を選択します。
• destinations: テスト機器を定義します。
• coverage: 画面サイズ別のおすすめエミュレータをまとめました。

(11:06) [分析] アクションでは静的分析が実行されます。講演では、コンパイラが特定できるバグ カテゴリを見つけて、チーム内に問題が蓄積するのを防ぐためにこれを使用することが提案されました。

analyzeAction:
  type: Analyze
  requiredToPass: false
  purpose: monitor static analysis results

キーポイント:

• type: Analyze:静的解析を実行します。
• requiredToPass: false注: スピーチ内のプル リクエストの例では、結果のみを監視しており、静的解析の失敗が全体的なビルド ステータスに影響を与えることは許可されていません。
• purpose: 静的解析の問題を継続的に観察して、長期的な蓄積を避けるために使用されます。

4. ポストアクションを使用してチームに通知し、TestFlight にデプロイします

(12:35) ポストアクションは、ビルド、分析、テスト、アーカイブが完了した後に実行されます。 Xcode Cloud は通知と TestFlight の展開をサポートしています。

postActions:
  - type: Notify
    buildSuccess: All
    buildFailure: All
    slackChannels:
      - ci-builds
    emails: []

キーポイント:

• Notify:ビルド通知を送信します。
• buildSuccess: All:成功したすべてのビルドが通知されます。
• buildFailure: All:失敗したすべてのビルドが通知されます。
• slackChannels：スピーチ中にSlackを選択ci-buildsチャネル。
• emails: グループ メールボックスに参加できるユーザー、または自分以外のユーザーが作成したビルドの通知を受け取る必要があるユーザー。

(14:42) TestFlight の展開は、内部テストと外部テストに分かれています。内部テストでは、プル リクエストによって生成されたビルドを開発チーム メンバーに迅速に送信できます。

archiveAction:
  deployment: TestFlight Internal Testing Only

postActions:
  - type: TestFlight Internal Testing
    artifact: Archive iOS
    groups:
      - QA team

キーポイント:

• deployment: アーカイブ アクションを次のように設定する必要があります。TestFlight Internal Testing Only。
• TestFlight Internal Testing: 内部テストのフォローアップ アクションを追加します。
• artifact: アーカイブされた製品を選択します。スピーチでArchive iOSすでに選択されています。
• groups: App Store Connect で既存の内部 TestFlight グループを選択します。

(17:25) 外部 TestFlight テストにはより厳しい条件があります。起動条件として単一のブランチを選択し、環境として Clean を選択し、アーカイブ展開を TestFlight と App Store に設定します。

externalTestingWorkflow:
  startCondition:
    branch: release
  environment:
    clean: true
  archiveAction:
    deployment: TestFlight and App Store
  postAction:
    type: TestFlight External Testing
    targets:
      - external groups
      - individual testers

キーポイント:

• branch: release: ビルド ソースの一貫性を確保するために、外部テストには単一のブランチを使用することをお勧めします。
• clean: true: 派生データが製品に影響を与えないように再構築します。
• TestFlight and App Store: アーカイブ アクションは、TestFlight および App Store 配布の準備ができている必要があります。
• external groups: 外部テスト グループに展開できます。
• individual testers: 外部テストでは、個々のテスターへの展開もサポートされています。

5. 3 つの推奨ワークフロー戦略

(18:47) 講演の最後には、プルリクエスト、リリース、夜間テストの 3 種類のワークフローが説明されました。これらはそれぞれ、マージ前の検証、リリース候補の検証、夜間の詳細なテストに役立ちます。

workflows:
  - name: Pull Requests
    trigger: Every Change to a Pull Request
    actions:
      - Archive
      - Test
      - Analyze
    postActions:
      - Notify
      - TestFlight Internal Testing

  - name: Release
    trigger: Every Change to a Branch on Release
    environment:
      clean: true
      xcode: pinned version
      macOS: pinned version
    actions:
      - comprehensive tests
      - Archive with TestFlight and App Store
    postActions:
      - TestFlight External Testing

  - name: Overnight Testing
    trigger: On a Schedule for a Branch
    schedule: Monday through Friday at 1:00 a.m.
    actions:
      - required test plans on multiple simulators
      - required Analyze
    postActions:
      - Notify failures to QA

キーポイント:

• Pull Requests: ビルドをマージしてテストのために QA チームに引き渡す前に、自動的に検証します。
• Release: リリース ブランチは Clean を使用してビルドされ、Xcode と macOS のバージョンを修正して、外部の TestFlight テスターに​​送信されます。
• Overnight Testing: 営業日の早朝に定期的に追加のテストと静的分析を実行し、失敗した場合にのみ QA に通知します。

重要ポイント

1. プル リクエストごとに内部テスト パッケージを自動的に生成する

• やるべきこと: プル リクエストが更新されるたびに、アプリを自動的にアーカイブし、内部 QA TestFlight グループに送信します。
• 実行する価値がある理由: この講演では、プル リクエスト ワークフローがマージされた結果を構築し、内部 TestFlight グループにデプロイする方法を示します。
• 起動方法：起動条件を選択Every Change to a Pull Request、ターゲット ブランチを main に設定し、アーカイブ アクションを追加して、デプロイメント オプションを に設定します。TestFlight Internal Testing Onlyを追加します。TestFlight Internal Testing post-action。

2. リリース ブランチのツール チェーンを修正します。

• やるべきこと: リリース ブランチ用に別のワークフローを作成し、Xcode と macOS のバージョンを固定し、クリーン ビルドを有効にします。
• 実行する価値がある理由: スピーチのリリース ワークフローでは、固定ツール チェーンを使用してリリース環境を統合し、クリーン ビルドを使用してキャッシュの影響を排除します。
• 開始方法: 起動条件のリリース ブランチを選択し、環境で特定の Xcode および macOS バージョンを選択し、クリーンにチェックを入れて、アーカイブ アクションを選択しますTestFlight and App Store。

3. 長いテストを夜間に実行するように移動する

• やるべきこと: 平日の早朝に複数のテスト計画とシミュレーターの組み合わせを実行するための夜間テスト ワークフローを作成します。
• 実行する価値がある理由: この講演では、スケジュールされたワークフローが長期テストに適していることを指摘しています。この場合、チームは日中は開発を継続し、夜は Xcode Cloud でチェックアウトできます。
• 開始方法: 開始条件の選択On a Schedule for a Branch、頻度は月曜日から金曜日の午前 1 時に設定されます。テスト アクションは、合格する必要があるテスト計画とシミュレーターを選択し、失敗した場合は QA Slack チャネルに通知します。

4. 静的解析を連続信号にする

• 何をすべきか: プル リクエストまたは夜間ワークフローに分析アクションを追加して、静的分析結果を継続的に観察します。
• 実行する価値がある理由: スピーチでは、静的分析はローカル反復プロセスによってスキップされることが多く、チーム内に問題が蓄積されると述べられていました。
• 開始方法: 分析アクションを追加します。初期段階では、次のことができます。Required to Passオフにして結果のみを監視します。問題が収束したら、「must pass」に変更します。

5. 通知戦略を使用してノイズを軽減する

• 対処方法: ワークフローの種類ごとに異なる通知ルールを設定します。すべてのプル リクエストが通知され、夜間テストは失敗のみが通知されます。
• 実行する価値がある理由: この講演では、通知を成功イベントと失敗イベントに分けて構成し、Slack または電子メールに送信する方法を示します。
• 開始方法: プル リクエスト ワークフローの [ビルド成功] と [ビルド失敗] を [すべて] に設定します。夜間テストの場合は、「ビルド成功」を「通知しない」に設定し、「ビルド失敗」を「すべて」に設定し、ターゲットとして QA Slack チャネルを選択します。

関連セッション

• Xcode Cloud の紹介 — Xcode Cloud の基本概念、最初のワークフロー、およびビルド レポートを紹介します。
• 高度な Xcode Cloud ワークフローをカスタマイズする — 環境変数、カスタム スクリプト、マルチウェアハウスの依存関係、Webhook について引き続き説明します。
• クラウド署名を使用して Xcode でアプリを配布する — Xcode の配布プロセスとクラウド署名について説明し、アーカイブから配布の詳細を補完します。
• Xcode でのコードのレビューとコラボレーション - Xcode のプル リクエストとコード レビュー機能について説明しており、プル リクエスト ワークフローと一緒に表示するのに適しています。