Meet Xcode Cloud

ハイライト

Apple は、継続的インテグレーションと継続的デリバリーサービスを Xcode と App Store Connect に統合する Xcode Cloud をリリースします。これにより、チームは Apple のホスティング環境でアプリケーションを自動的にビルド、テスト、アーカイブ、配布し、ビルドレポートから直接問題を特定できるようになります。

主要内容

チームがアプリを開発する場合、通常、コードがマージされた後に問題が発生します。

Xcode でバグを修正し、機能を追加します。チームメイトはプルリクエストでフィードバックを提供します。テスターは TestFlight で新しいバージョンを試します。すべてのフィードバックはコードの変更につながります。変更を組み込んだ後は、iOS をコンパイルできるかどうか、macOS をアーカイブできるかどうか、テストが失敗したかどうか、ビルドをテスターに送信できるかどうかも確認する必要があります。

以前は、これらの作業はローカルの機械や手作業による検査によって結び付けられていたことがよくありました。空いている人がテストを実行します。誰が契約の発行に責任を負い、誰が証明書、製品の構築、アップロードのプロセスを処理するのか。問題は、チームが大きくなり、支店が増えるほど、漏れが発生しやすくなるということです。

Xcode Cloud はこのリンクを解決します。 Apple の開発ツールに継続的インテグレーション (CI) を組み込みます。開発者がコードをプッシュすると、ワークフローは Apple がホストするクラウド環境で実行されます。構築、テスト、アーカイブが可能で、結果は後続の配布プロセスに引き渡すことができます。

このトークでは、iOS と macOS のサンプルアプリである Fruta を使用したプロセス全体を説明します。開発者はまず Xcode でワークフローを作成し、Xcode Cloud がコードリポジトリにアクセスすることを承認し、最初のビルドを開始します。ビルドが失敗した後、Mac アーカイブアクションでインポートエラーが発生したことがレポートに示されます。開発者は問題をクリックしてソースコードにジャンプして修正し、送信してプッシュできます。

チームワークの変更も簡単です。ワークフローはチームの共有構成の一部です。 1 人のメンバーがビルドを作成して実行した後、別のメンバーが同じプロジェクトを開き、Xcode の [クラウド] タブでワークフロー、ビルド履歴、結果を確認できます。その後、ワークフローを編集し、リリースブランチにトリガー条件を追加し、iOS にテストアクションを追加できます。

ここで Xcode Cloud が登場します。Xcode Cloud はリモートビルドマシンを実行するだけではありません。 Xcode、App Store Connect、TestFlight、コードホスティングサービス、チーム通知をプレリリースパイプラインに接続します。

詳細

CI の最小モデル: コードをプッシュした後、一連のアクションを自動的に実行します。

(00:45) このスピーチでは、まず継続的統合について定義します。 CI は、問題をできるだけ早く発見して修正することを目的として、コードの変更を定期的に統合する実践です。一般的な CI ワークフローでは、あなたまたはチームメイトがコードをリポジトリにプッシュするときに自動化されたステップが実行されます。

これらのステップには、チームが必要とするビルド、テスト、またはその他の品質チェックが含まれます。 Xcode Cloud は、これらのステップをワークフローにラップします。

Workflow
- Start condition: 当代码推送到仓库时启动
- Actions: build, test, archive
- Result: build report

キーポイント:

WorkflowXcode Cloud がいつ何を行うかを決定するのは設定です。
Start conditionがトリガー条件で、講義ではデフォルトでメインブランチにプッシュすることになっています。
Actionsそれは実行されるべきアクションです。スピーチでは、ビルド、テスト、アーカイブについて言及しました。
build reportこれはワークフローの実行後の結果エントリであり、テストレポート、ログ、および問題を表示するために使用されます。

ワークフローは Apple がホストする環境で実行されます

(02:34) Xcode Cloud で実行されるワークフローはビルドと呼ばれます。これらのビルドは、Apple が管理するクラウドインフラストラクチャ上で実行されます。

この講演では、クラウド環境ではコード署名が提供されること、複数のオペレーティングシステムバージョンが提供されること、異なる Xcode バージョンが提供されることという 3 つのことが明確に述べられました。開発者は、ビルドマシンごとにこれらの機能を個別に準備する必要はありません。

Xcode Cloud Build Environment
- Code signing
- Multiple operating system versions
- Xcode releases

キーポイント:

Code signingクラウドビルド環境を利用し、ローカルビルドマシンでの証明書管理の負担を軽減します。
Multiple operating system versionsチームがさまざまなシステムバージョンでアプリを検証できるようにします。
Xcode releasesビルド環境と Xcode バージョン関連の構成をワークフローに組み込みます。
ビルド結果は、Xcode のレポートナビゲーターの [クラウド] タブに表示されます。

初めてワークフローを作成する: Xcode メニューから開始します

(06:04) Xcode の [製品] メニューから Xcode クラウド領域に入り、[ワークフローの作成] を選択する例を示します。 Xcode はローカルプロジェクト内のアプリを検出し、デフォルトの最初のワークフローを生成します。

Fruta は iOS と macOS をサポートします。 Xcode Cloud はローカルプロジェクトをチェックした後、両方のプラットフォームをデフォルト設定に自動的に含めます。

Product > Xcode Cloud > Create Workflow

Detected app: Fruta
Platforms: iOS, macOS
Default workflow:
- Start condition: every push to main
- Environment: latest released Xcode
- Actions: archive iOS, archive macOS

キーポイント:

Create Workflowスピーチの入り口です。
Detected appXcode からローカルプロジェクトを確認します。
every push to mainはデフォルトのトリガー条件です。
latest released Xcodeはデフォルトの環境選択です。
archive iOSそしてarchive macOSFruta によるプラットフォームのサポート。

認可コードリポジトリ: プライベートリポジトリには明示的な権限が必要です

(07:24) Xcode Cloud プロジェクトをビルドするには、ソースコードを読み取る必要があります。講演での承認は 1 回限りの操作であり、メインリポジトリ、サブモジュール (サブモジュール)、プライベート Swift パッケージ (プライベート Swift パッケージ) など、プロジェクトのビルドに必要なすべてのソースコードリポジトリが対象になります。

パブリックリポジトリには追加の承認は必要ありません。プライベートウェアハウスは、コードホスティングサービスによって承認される必要があります。デモでは、Fruta には 2 つのプライベートリポジトリがあり、ソースコードは GitHub でホストされているため、GitHub は App Store Connect Web プロセスで承認される必要があります。

Source access
- Primary repository
- Submodules
- Private Swift packages

Public repositories: no additional authorization
Private repositories: grant provider access

キーポイント:

Primary repositoryこれはメインのプロジェクトリポジトリです。
SubmodulesそしてPrivate Swift packagesも認可範囲に含まれます。
grant provider accessコードホスティングサービスのネイティブ認証プロセス中に発生します。
講演では、開発者がいつでもアクセスを取り消すことができると述べられました。

レポートの作成: 失敗したアクションからエラーコードまでジャンプします

(09:18) 最初のビルドの後、ビルドグループの概要にアクティブなビルドと完了したビルドが表示されます。単一のビルドページに入ると、ビルド期間、環境構成、すべてのアクションとポストアクションのステータスを確認できます。

アクションが失敗した場合は、アクションの概要を展開できます。プレゼンテーション内の Mac アーカイブアクションが失敗し、Xcode Cloud でインポートの問題が発生しました。開発者は、Xcode の問題リストのジャンプボタンをクリックして、変更が必要なソースコードに直接ジャンプします。

Build report
- Overview: duration, environment configuration
- Action summary: status, logs, artifacts
- Issues: filter by type, jump to source

キーポイント:

Overviewビルドに関する基本情報を表示します。
Action summaryアクションの実行を表示します。
logsタスクごとに整理されており、フィルタリングも可能です。
artifactsバイナリ、ログファイル、およびその他のビルドアーティファクトが含まれます。
jump to source開発者が CI の問題からローカルソースコードに戻れるようにします。

本当の修正: UIKit は非 macOS プラットフォームにのみインポートされます

(11:04) Fruta は iOS と macOS の両方向けにビルドされます。最初の CI ビルドでは、ソースコードに macOS に適さないインポートがあったため、Mac アプリのアーカイブアクションが失敗したことがわかりました。講演で示された修正は、条件付きコンパイルです。つまり、非 macOS プラットフォームでのみ UIKit をインポートします。

import SwiftUI
#if !os(macOS)
import UIKit
#endif

キーポイント:

import SwiftUIクロスプラットフォームインターフェイスコードで使用できるように SwiftUI をインポートします。
#if !os(macOS)コンパイル条件を開始します。これは、現在のターゲットシステムが iOS などの macOS 以外のプラットフォームである場合にのみ、次のコードがコンパイルされることを意味します。
import UIKitMac のアーカイブ操作で不一致のフレームインポートが発生するのを防ぐため、iOS などの macOS 以外のプラットフォームでのみインポートしてください。
#endif条件付きコンパイルブロックを終了します。

このコードは CI の値を示しています。問題は発売まで待たされませんでした。クラウドアーカイブアクションにより、プラットフォーム間の違いが即座に明らかになります。開発者が問題を修正した後、それを送信してプッシュすると、新しいビルドが自動的に実行を開始します。

チーム共有ワークフロー: 1 人が作成し、他の人が編集を続ける

(11:43) Geoff がワークフローを作成して修正した後、Holly は同じチームのメンバーとして Fruta プロジェクトを開き、デフォルトのワークフローとビルド履歴を確認することもできます。講演ではチーム内でのワークフローの共有が強調されました。

次に、デフォルトのワークフローの名前を Releases に変更し、開始条件を編集して、リリースブランチをビルドスコープに追加しました。

Workflow: Releases
Start condition:
- main
- release/v1

キーポイント:

Releasesは、デモでワークフローに設定された新しい名前です。
mainデフォルトの分岐トリガー条件です。
release/v1チームがリリースに使用するブランチです。
ブランチを追加した後、同じワークフローで異なるブランチのビルド結果を個別に表示できます。

テストアクションの追加: iOS のスキームとデバイスを選択します

(13:18) デフォルトのワークフローは、すべての Fruta プラットフォームのアーカイブアクションを作成します。カバレッジを増やすために、テストアクションがデモに追加されました。

このテストアクションでは、iOS プラットフォームを選択し、Fruta iOS スキームを選択して、テストデバイスを追加します。 Xcode Cloud は iPhone シミュレーターを推奨し、もう一度クリックすると推奨される iPad が追加されます。デモでは、アプリがiPhone 12で適切に動作することを確認するために、デバイスも最新のiPhoneに変更されました。

Action: Test
Platform: iOS
Scheme: Fruta iOS
Destinations:
- Recommended iPhone simulators
- Recommended iPads
- iPhone 12
OS version: latest

キーポイント:

Testワークフロー内のアクションのタイプです。
Platform: iOSテストを実行するプラットフォームを指定します。
Scheme: Fruta iOSXcode がテストを実行するために使用するスキームを指定します。
Destinationsテストデバイスまたはエミュレータを指定します。
OS version: latestトークで言及したデフォルトのデバイスシステムバージョン設定から。

手動でビルドを開始: コードを変更せずにワークフローを確認します

(14:41) ワークフローを変更した後、Holly はワークフローが実行されることを確認したいと考えていますが、CI をトリガーするために別のコード行を送信することは望んでいません。 Xcode Cloud は、レポートナビゲーターでワークフローを右クリックし、[ビルドの開始] を選択することによる手動起動をサポートしています。

起動時に分岐を選択できます。新しく追加したワークフローを選択するデモrelease/v1をクリックし、「ビルドの開始」をクリックします。

Report navigator > Workflow > Start Build
Branch: release/v1
Result: Build 3 starts under release/v1 section

キーポイント:

Start Build開発者がワークフローを手動で実行できるようにします。
Branch: release/v1新しく追加されたリリースブランチを確認するために使用されます。
Build 3ビルドグループの概要に表示されますrelease/v1パーティションの下。
このステップはワークフロー構成をチェックするために使用され、追加のコード変更は必要ありません。

プライバシー設計: 一時環境、分離された負荷、ソースコードは保存されません

(04:59) Xcode Cloud ではソースコードへのアクセスが必要なため、講演ではプライバシーバイデザインについて別途説明します。

ビルド環境は一時的なものです。ワークロードは互いに分離されています。環境はビルドごとに破壊され、再作成されます。ソースコードは保存されず、Xcode Cloud は一時的なビルド環境でコードをフェッチするだけです。ビルドデータは暗号化されて保存され、プライベート CloudKit データベースに保存されます。開発者は自分のデータを削除できます。

Privacy model
- Temporary build environments
- Isolated workloads
- Source code is never stored
- Build data encrypted at rest
- Dedicated CloudKit database
- User-controlled deletion

キーポイント:

Temporary build environmentsビルド環境の残留状態によってもたらされるリスクを軽減します。
Isolated workloadsさまざまなビルドワークロードを互いに分離しておきます。
Source code is never storedと演説の中ではっきりと述べています。
encrypted at rest保存時のビルドデータの暗号化について説明します。
User-controlled deletionチームが自分でデータを削除できるようにします。

重要ポイント

やるべきこと: master ブランチに最小限の CI ワークフローを設定します。 実行する価値がある理由: 講義のデフォルトのワークフローは、メインにプッシュした後にアーカイブアクションを実行します。これにより、ビルドの問題をできるだけ早く検出できます。 開始方法: Xcode で開きますProduct > Xcode Cloud > Create Workflow、デフォルトのメインブランチトリガー条件を受け入れ、iOS と macOS のアーカイブアクションを最初に実行します。
やるべきこと: リリースブランチに別のビルドビューを追加します。 実行する価値がある理由: ビルドグループの概要では、結果がブランチごとに整理されます。 1 つのワークフローで、独立したステータスを維持しながら複数のブランチをカバーできます。 開始方法: ワークフローの開始条件を編集し、カスタムブランチに追加します。release/v1このタイプのリリースブランチは、手動でビルドの開始が検証されます。
対処方法: CI キャプチャに対するクロスプラットフォームのインポートの問題を処理します。 実行する価値がある理由: Fruta の Mac アーカイブアクションは UIKit インポートの問題を検出し、マルチプラットフォームプロジェクトがクラウドアーカイブアクションによる継続的な検証に適していることを示しています。 開始方法: iOS と macOS の両方をアーカイブするワークフローを有効にします。プラットフォームの違いに遭遇した場合は、次を使用します。#if !os(macOS)このタイプの条件付きコンパイルは、プラットフォーム固有のインポートを制限します。
やるべきこと: iOS アプリにデバイスマトリックステストを追加します。 実行する価値がある理由: スピーチでは、テストアクションでスキームと複数の宛先を選択でき、iPhone、iPad、最新のシステムバージョンをカバーします。 開始方法: ワークフローのアクションにテストを追加し、iOS プラットフォームとプロジェクトスキームを選択し、推奨されるシミュレーターを宛先として使用します。
やるべきこと: 失敗したビルドの通知をチームコラボレーションツールに統合します。 実行する価値がある理由: 講演では、チームメンバーが失敗したビルドの Slack 通知など、App Store Connect で独自の通知を設定できると述べられました。 開始方法: まず、ビルドレポートで安定した結果が生成されるようにしてから、App Store Connect で個人通知を構成し、最初に失敗したビルドをサブスクライブします。

Meet Xcode Cloud

ハイライト

主要内容

詳細

CI の最小モデル: コードをプッシュした後、一連のアクションを自動的に実行します。

ワークフローは Apple がホストする環境で実行されます

初めてワークフローを作成する: Xcode メニューから開始します

認可コードリポジトリ: プライベートリポジトリには明示的な権限が必要です

レポートの作成: 失敗したアクションからエラーコードまでジャンプします

本当の修正: UIKit は非 macOS プラットフォームにのみインポートされます

チーム共有ワークフロー: 1 人が作成し、他の人が編集を続ける

テストアクションの追加: iOS のスキームとデバイスを選択します

手動でビルドを開始: コードを変更せずにワークフローを確認します

プライバシー設計: 一時環境、分離された負荷、ソースコードは保存されません

重要ポイント

関連セッション

コメント

ハイライト

主要内容

詳細

CI の最小モデル: コードをプッシュした後、一連のアクションを自動的に実行します。

ワークフローは Apple がホストする環境で実行されます

初めてワークフローを作成する: Xcode メニューから開始します

認可コード リポジトリ: プライベート リポジトリには明示的な権限が必要です

レポートの作成: 失敗したアクションからエラー コードまでジャンプします

本当の修正: UIKit は非 macOS プラットフォームにのみインポートされます

チーム共有ワークフロー: 1 人が作成し、他の人が編集を続ける

テスト アクションの追加: iOS のスキームとデバイスを選択します

手動でビルドを開始: コードを変更せずにワークフローを確認します

プライバシー設計: 一時環境、分離された負荷、ソース コードは保存されません

重要ポイント

関連セッション

コメント

認可コードリポジトリ: プライベートリポジトリには明示的な権限が必要です

レポートの作成: 失敗したアクションからエラーコードまでジャンプします

テストアクションの追加: iOS のスキームとデバイスを選択します

プライバシー設計: 一時環境、分離された負荷、ソースコードは保存されません