ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
Xcode Cloudのワークフローの詳細
Xcode Cloudワークフローを利用して、Appやフレームワークのビルド、分析、テスト、アーカイブ、配布を自動化する方法について確認します。ワークフローは柔軟で拡張性があり、チームの開発と配信プロセスに合わせて設定できます。Xcode Cloudワークフローの基本を理解してから設定方法をすべて確認し、Appleの継続的インテグレーションシステムを使い始めるための推奨ワークフローについて解説します。 このセッションを最大限活かしていただくためには、WWDC21の「Xcode Cloudについて」を先にご確認いただくことをお勧めします。
リソース
- Configuring your first Xcode Cloud workflow
- Developing a workflow strategy for Xcode Cloud
- Xcode Cloud
- Xcode Cloud workflow reference
関連ビデオ
WWDC23
Tech Talks
WWDC21
-
ダウンロード
こんにちは Xcode Cloudワークフロー セッションへようこそ 私の名前はJustinですエンジニアです TestFlightチームで 同僚と一緒に協働しています WesleyとKevinです Xcode Cloudでワークフロー を作成する際の詳細を紹介します ワークフローはXcode Cloudの中心です 継続的インテグレーションを推進し 皆さんやチームが 構築 分析 テスト アーカイブを自動化 することを可能にします そして Appとフレームワークを配布します これは柔軟で拡張可能であるので 既存の開発や配布プロセスの チームのワークフローをカスタマイズできます Xcode Cloudを使用すると ワークフロー管理が統合されています すでに使用しているAppleデベロッパツールに XcodeとApp Store Connect このセッションではワークフローを その特定構成要素に分解していきましょう まず 条件を設定する方法について説明します ワークフローを自動的に実行します 次に オプションについて説明します 環境を構成するためです また 複数のアクションを作成する方法も示します 自動化したいタスクについては 後で実行するアクションと一緒に ビルドに関する通知を送るようなもので または そのビルドをTestFlightに 自動的にデプロイします 最後に さまざまな戦略があります 有益で非常に便利なワークフローで チームの協力と生産性を高めることができます 取り上げたいことがたくさん あります では 始めましょう Wesleyに引き渡します
ありがとう Justin! 私は開発者チームメンバーと FrutaというAppで協働しています Xcode Cloudですでに稼働しています セッションをまだご覧になっていない方は 最初のワークフローの設定について ”Meet Xcode Cloud”で ぜひ学んでください ここで Xcodeのレポート ナビゲーターに統合された 新しいCloudタブです チームのワークフローとビルドを確認できます Frutaの搭載でデフォルトの ワークフローが作成される メインブランチを構築します このワークフローは素晴らしい働きをしてきました しかし プルリクエストも使用するチームなので チームが活用できるプルリクエスト固有のワーク フローを作成します プルリクエストが作成されるたびに実行します チームの誰かが Appの分析 テスト 保管 をし プルリクエストの ビルドが終了するとチームに通知します Appのバージョンをチームメンバーに配信します メインの統合ブランチに機能が統合される前に テストできるようにします ワークフローの作成は簡単です 製品メニューからワークフローの管理に移動 プラスをクリックしてAppを選択します
これで新しいワークフロー エディターが表示されます ワークフローは設定可能な要素で構成されています 一般的なセクションで名前を付けることができます これを”プルリクエスト”と名付けます
個人の少数のチームに所属していると ワークフローに変更を 加える責任があります 意図しない更新を防ぐために編集を制限できます チームに影響を与える可能性があります デフォルトでは Xcode Cloudがプライマリ リポジトリを設定します ローカル設定の知識のある プロジェクト情報です しかしプライマリリポジトリ を移動することになったり または Xcodeプロジェクト からワークスペースに移行 する場合は ここでその設定を変更できます 次に 開始条件セクションを見てみましょう ここではワークフローをいつ 実行するかを定義します
Xcode Cloudにはいくつかの 条件の種類があります このワークフローでは 開始条件を設定し メインブランチに統合予定の すべてのプルリクエストに対して実行します そのために タイプメニューから選択できます そして プルリクエストへの すべての変更を選択します この条件の種類を使用すると ソースとターゲットブランチ を指定できます
ソースブランチを任意のブランチに設定し ターゲットブランチをメインに設定します
チームメンバーがプルリクエストを作成するたびに メインに対して それに変更を加えます Xcode Cloudはこのワーク フローを自動的に実行します プルリクエストの構築時に Xcode Cloudがビルドし ソースとターゲットブランチの統合をテストします したがってチームメンバーは 自信を持つことができます チームの他のメンバーと変化の実際の影響を 知っています 特定のファイルやフォルダにその条件を狭める こともできます ワークフローの実行時に 以前に実行していたビルドを 自動キャンセルするかどうかを選択します これは 1つのコミットをすばやく連続して 別のものの上にプッシュする場合に便利です ワークフローに設定できる開始条件の プルリクエストへのすべての変更は1つだけです チームのニーズに応じて 他の条件の種類があります そのニーズに合わせて設定できます ブランチへのすべての変更はソースブランチに 常にビルドされ プルリクエストの状態は無視されます タグへのすべての変更はいつでもビルドされ 新しいタグが作成されます スケジュールに基づいて選択可能な定期的なスケ ジュールで皆さんが選んだブランチをビルドします これは 長期に及ぶテストや たまに実行したい場合に最適です 開始条件を設定したので このワークフローがいつ実行されるかが決まります 環境セクションを設定してみましょう これは ワークフローの実行方法を決定します Xcode CloudはApple Cloudの 下部構造で実行されます macOSとXcodeのバージョン を利用することができます
XcodeとmacOSのバージョン を選択するには メニューから選択するだけです ワークフローを最新リリース に設定することもできます ベータ版なので いつでもビルド または最新の ソフトでテストできます 開発者として 非常に関心があることは 生産性でその大部分を占めるのが 使用するツールの性能です 皆さんの多くは大きなプロ ジェクトに取り組んでいます 多くのファイルを扱い長時間 に対処する可能性があります Xcode内のローカルと同様に 変更を段階的にビルドするオプションがあり 変更されたファイルをビルドするだけです Xcode Cloudにもこの オプションがあります これは通常 ビルドの高速化につながります しかし場合によっては クリーンビルドを実行したい場合もあるでしょう 重要なのは最終ビルドで すべてが機能していることを 確認することで また以下を 生成する必要もあります 外部ベータテスターにデプロイできるビルド TestFlightを使用するか App Storeに送信します 環境セクションでは クリーンを選択するオプションがあります これはプルリクエストワークフローであるため 性能上の利点を活用できるように チェックを外しておきます すべてのチームは独自の方法で活動しています チームには柔軟に対応できるツールが必要です 働きたいように働くことができます Xcode Cloudは創造的で最も一般的な 開発タスクだと信じているオプションを提供します しかし それはまた拡張性のためのさまざまな オプションを提供します この拡張性により Xcode Cloudは他のツールや システムと接続でき チームは仕事を成し遂げることができます Xcode Cloudは包括的なAPIを提供し アクセスしてワークフローを 設定しビルドを開始します Xcodeが提供する既存のスクリプトオプション に加えて Xcodeは カスタムスクリプト の作成機能を追加します デバイス上で実行され ビルドとテストを実行しています 環境セクションで Xcode Cloudがカスタム スクリプトで利用できる 環境変数を指定できます ソースコードリポジトリにチェックしたくない 設定や秘密に便利です
追加レベルの保護を提供し秘密として 環境変数を指定する機能もあります これに関する詳しい情報は以下の ”高度なXcode Cloud ワークフローカスタマイズ” セッションやドキュメントをご覧ください 今まで以下をご紹介しました ワークフローがいつ実行されるかを設定する方法と どのような環境で実行するかについてです 次に アクションについて説明します アクションはワークフローが実行されるたびに 皆さんとチームのために行うべき作業を定義します Xcodeにローカルで実行 させる主なアクションは Xcode Cloud内ですべて 利用できるようになりました 構築 静的解析の実行 テスト およびアーカイブです 私が設定したいアクションはアーカイブと テストおよび分析です まず アーカイブアクションを追加してみましょう アクションでプラスアイコンをクリックし アーカイブを選択します
アーカイブを作成したい プラットフォームとスキーム を選択する必要があります すでにiOSプラットフォーム を事前に選択しています そしてiOSスキームは まさに 欲しかったものです 登録するオプションもあります TestFlightに登録か App Storeで配布もできます しかし詳細は後で説明します プロビジョニングプロファイルやコード署名IDを 管理する必要がなかったこと に気付くかもしれません Xcode Cloudはこれを自動的 に処理してくれます これについての詳細は セッションをご覧ください ”Cloud署名を使用して XcodeでAppを配布” アーカイブアクションが設定されたので テストアクションに注目してみましょう Appのテストは 開発プロセスの非常に重要な一部です ユーザーのバグが減ることで役立つだけではなく 皆さんが行っている変更に自信が持てることで 開発プロセスをスピードアップすることができます テストをローカルで実行 するのは面倒で時間がかかる 場合があります 時には ただ忘れてしまうかもしれません Xcode Cloudでテストを行う ワークフローを設定し 安定し信頼でき再現性のある 環境でテストを実行できます 他の仕事をしている間に裏で実行されます ローカル環境を解放し 自動的に実行されます 手動で実行することを覚えて おく必要もなくなります テストアクションの追加には プラスボタンをクリックして テストを選択するだけです
テストアクションの場合 合格することが必須かどうか 選択できます アクションを必須とマーク することはテストアクション が失敗するとビルド全体が 失敗することを意味します テストスイートを構築している場合 合格の必要がないものとして設定を選択できます したがって 全体的なビルド状態には影響しません 選択することになると どのテストを実行するかオプションがあります スキーム設定を使用を選択できます Fruta iOSスキームの設定を参照するか 特定のテストセットに焦点を合わせたい場合は 特定のテストプランを選択できます セットを手に入れたらやるべきことは テストを実行するシミュレーターを選ぶことです Xcode Cloudは推奨される オプションを提供します さまざまな画面サイズの シミュレーターのコレクションです 推奨されるオプションは常に Xcodeに対してテストします 環境セクションで選択され しかし特定のシミュレーターを選択した場合 古いOSバージョンのリスト から選択することもできます
実行したい最後のアクションは分析アクションです コンパイラは自動的に多くの種類のバグを発見し 警告することができます この警告を聞き入れて修正し実行時にこの問題を 追跡するのに比べて開発時間を 大幅に短縮できます ユーザーにはるかに安定したものを提供し Appを利用することで バグのない体験を提供します しかし 静的解析を実行することは 典型的な ローカル反復型開発ワーク フローの一部ではないため 多くの人は実行するのを忘れてしまい 時間が経ちチーム全体に問題が蓄積されていきます Xcode Cloudで 以下を確認できます 静的解析は コードを変更するたびに実行されます 分析アクションの追加には プラスボタンをクリックし 分析を選択します
テストと同様に静的解析の問題を 合格が必須かどうかのオプションがあります 今は 静的解析の結果だけを監視します 合格必須とはマークしません
最後のアクションはビルドアクションです 時折 実行する必要があるかもしれません 単純なXcodeビルドアクションです これは特定のことを確認する のに役立つかもしれません セカンダリビルド構成または スキームがまだ蓄積され あるいは Appの一部であるフレームワークを 独自に構築できます これで アーカイブとテストを設定しました プルリクエストワークフロー のアクションを分析します ポストアクションの追加からKevinに引き渡します ありがとう Wesley Xcode Cloudワークフローで ポストアクションを設定することができます ポストアクションは ビルド分析 テスト およびアーカイブアクション が完了した後で実行されます Xcode Cloudで設定できる ポストアクションは 通知を送信し TestFlightで デプロイします まず 通知について説明しましょう 通知イベントには送信できる 2つのタイプがあります 1つ目はビルドが成功したときです 通知を送信するオプションがあります すべてのビルドが成功した 場合と修正のみの場合です ブランチやプルリクエストの ビルドが移行するときで 失敗から合格への移行です または通知しないことです もう1つの通知イベントは ビルドが失敗したときです すべてのビルドの失敗に対して通知を送信できます ブレイクとは ブランチや プルリクエストのビルドが 合格から失敗への移行時で 通知をしないこともできます このワークフローではプル リクエストビルドが終了後 チームに通知します アクションセクションの下に ポストアクションがあります 通知アクションの追加には プラスボタンをクリックして通知を選択します
ビルドの成功とビルドの失敗のために すべてを残します 通知イベントの下に 通知を送信する場所についてオプションがあります Xcode Cloudは 人気の コラボレーションツールSlackと統合されます Slackアカウントが認証されると プラスボタンのクリックでリストが表示されます
”ci-builds”チャネルを 選択しOKをクリックします
メールアドレスを追加するオプションもあります デフォルトでは すべてのユーザーが自動的に 開始したビルドの通知を受け取るので このリストに追加する必要はありません ただし グループメールをお持ちの場合 ビルドを受け取りたいがキックオフをしなかった ユーザーがいる場合は ここにメールを追加できます 最後に皆さんにお伝え致します Xcode Cloudワークフローの お気に入りの機能の1つは TestFlightで自動的に デプロイできる機能です そして今 Mac上のTestFlightで Appleが提供するプラット フォームにデプロイできます Xcode Cloudには 2つのTestFlightデプロイ メントオプションがあります 内部テスターへのデプロイが強化され ビルドをすばやく 開発チームのメンバーに送信することができます 皆さんのチームのメンバーなので プルリクエストから作成されたビルドを 受け取ることができます クリーンを選択せずにビルドされます 本日TestFlightを使用すると 外部テストとApp Storeは 皆さんがすでに知っている ことと同等です 候補ブランチとリリースブランチに推奨され ベータ版Appの審査を経て外部のテスターや App Storeに配布することができます TestFlightはAppのビルド を得るための優れた方法です チームメイトや組織外の ベータテスターのデバイスに Appのビルドを得ることができます ワークフローを設定し自動的に 任意のTestFlightグループに ビルドをデプロイします TestFlightグループの管理は 本日と同じ方法で App Store Connectの TestFlightタブで行います ここでは 複数の内部と外部のグループがあります それぞれがワークフローで利用可能です 自動的にデプロイするには 内部のTestFlightグループで 3つのことをしてください まず アーカイブアクションを追加します 次に デプロイメントオプションを内部テストへの アーカイブに設定します 最後に TestFlight内部テストのポス トアクションを追加します では そのためにワーク フローを設定してみましょう このワークフローを 自動的にQAチームにデプロイします まず iOSのアーカイブ アクションをクリックします TestFlight Internal Testing Onlyを選択します
ビルドがTestFlightで 利用できるようになります ビルドを自動的に誰にも送信 したくない場合に最適です しかし 後でそれを行うオプ ションを保持しています App Store ConnectのTest Flightセクションからです このAppでは ビルドが作成されるたびに 同僚に自動的にデプロイしたいと思います そのためには TestFlightの ポストアクションを追加し ポストアクションの横にある プラスボタンをクリックし TestFlightの内部テストを追加します
アーカイブiOSアーティ ファクトは事前の選択です これが望んでいることです プラスボタンを押して内部グループを追加します
最後に QAチームを選択します
これでQAチームのメンバーが確認できます メインブランチに統合される前にすべての 機能をテストします TestFlightの外部テストで 組織外のテスターにビルドを送信することは App Storeに送信する前に Appと機能のフィードバックを得るのに最適です こうすることで 幅広いユーザーから変更に対する 信頼を得ることができます App Storeにリリースされる前に 変更や問題の修正ができる可能性があります TestFlightの外部テストで デプロイするには さらにいくつかの条件を設定する必要があります 開始条件で単一のブランチを選択します これによりビルドの一貫性が確保されます 外部のベータテスターに送信する予定です 次に 環境セクションでクリーンを選択します これによりコードがビルド されることが保証されます 派生データを使用せずに最初からです TestFlightとApp Storeへの アーカイブアクションで 最後にデプロイメントの設定をします すべて設定が完了すると TestFlight外部テストの ポストアクションの設定は TestFlight内部テストの設定と同様です TestFlightで作成された外部グループを 追加するだけです TestFlight外部テストにも テスターにデプロイする 追加機能があります プルリクエストのワークフローをXcodeで 作成しました しかし App Store Connectで ワークフローを作成 編集 および管理もできます Xcodeから離れている場合は 最適なオプションです ワークフローを変更する必要があります ここでJustinに戻って いくつかの提案をします チーム用に作成できるワーク フローの種類についてです Justin? ありがとう Kevin FrutaQAチームはビルドへの アクセスが好きになります プルリクエストワークフローでより高速になります ご覧のとおり ワークフローには大きな力と チームの作業方法をモデル化する柔軟性があります 仕事を成し遂げるために 必要なだけのワークフローを 作成できます チームはいくつも作成するでしょう Kevinがプルリクエストの ワークフローを紹介しました ここではアイデアをご紹介します 試すことができるワークフローをご紹介します Appをユーザーに表示するには 開発チームの外では 外部のTestFlightグループに 配布する場合があります または AppをApp Storeに送信します ここでの考え方は 高品質を 強制したいということです Appのユーザーは素晴らしい経験をしています ブランチでワークフローを実行する必要があります リリースに指定されています 包括的な一連のテストを実行する必要があります ビルドをアーカイブし最後に 外部のTestFlightグループにデプロイし そしてユーザーの手に わかりやすく リリース ワークフローをお見せします ワークフローが確実にビルドされるように 今後のリリースもすべて リリースブランチで開始条件をブランチへの すべての変更に設定しました 徹底して このワークフローのすべてのビルドを ゼロから生成したいので 環境セクションでクリーンをチェックしました これを行うと通常はビルド時間が長くなります すべてが再びコンパイルされるからです しかし これでキャッシュに 起因する問題はないという 自信につながります Xcodeの特定バージョンと このワークフローのmacOSの 選択にも注意してください ツールを固定することはリリースの収束と完成の 重要な部分です Appが動作することを確認するために さまざまなユーザーのiPhoneやiPadでの テストセクションでさまざまなシミュレーターで テストを行います TestFlightを介してAppの ビルドを配布するには アーカイブアクションを含め TestFlightとApp Storeへの デプロイメントの準備を 設定します ベータテスターに 常に最新のビルドを提供するために ポスト アクションを設定しました 外部のTestFlightグループに デプロイするためです 新しいコードがリリースブランチに統合されると 自動的にビルドされてテストされ ベータテスターにデプロイされます 変更へのフィードバックをすばやく得ることができ 品質の高さに対する自信を維持できます 作成したい別のワークフローは 毎晩 より深い一連のテストを行います オーバーナイトテストワーク フローは定期的に実行され 複数のシミュレーターに対するテストを行い 必要なだけ多くのプラットフォームをカバーします テストの失敗はQAチームに報告されます 焦点は完全にテストにあるので ビルドをどこかにデプロイする必要はありません このワークフローを実行する ために開始条件を設定し ブランチのスケジュールを 選択し 毎週平日夜に実行し 開始条件の種類として 週単位の頻度としています 次に 月曜日から金曜日まで午前1時を 選択しました 環境セクションで 新しいツールがリリースされ Appが正常にビルドされて いるか確認のため 最新の Xcodeを選択しました Appを徹底的にテストしたいので 合格するために必要な テストプランやシミュレーターを選択しました 静的解析も実行したいので 分析アクションを追加し合格することが必要です 前のテストのいずれかが失敗すると QAチームは 通知のポスト アクションで確認します ビルドの成功を通知しない に設定し ビルドの失敗を 全員に設定しました QAチームには独自のSlack チャネルがあります ただし メールアドレスを指定することもできます どちらにしてもQAチームは 翌朝までにビルドの失敗を解明します このようにワークフローを実行すると 時間を節約するのに最適です チームは日中も開発を続けることができるので 夜 Xcode Cloudを離れて Appを徹底的に テストします 最後に Xcodeの製品メニューの下にあるのが ワークフローの管理です チームが使うワークフローを すべて見ることができます 先程作成したオーバーナイトテストの ワークフローと WesleyとKevinが以前に作成した ワークフローが一緒に表示されています プロジェクトの成長につれて チームのニーズに合わせて ワークフローの追加や編集あるいは削除します 以上でチームのワークフローは終わりです プルリクエストのワークフローを作成する方法や さまざまなプラットフォーム のアクションを設定する方法 TestFlightユーザーに リリースを配布する方法 オーバーナイトテストの設定 方法など紹介してきました しかし もっとたくさんのことをワークフローで 行うことができます その上で App Store Connectから ワークフローを作成および 管理することもできます ワークフローについて詳細は以下ご確認ください ”高度なXcode Cloud ワークフローカスタマイズ” まだ機会がない方は ”Meet Xcode Cloud”を ご覧ください プロジェクトをオンボードする方法を学びます クラウド署名やXcodeのプル リクエストの新サポートなど さらに深く掘り下げた素晴 らしいセッションもあります Xcode Cloudは チームに柔軟 で拡張性のあるワークフロー を作成する能力を与えてくれます 皆さんの働き方に適応でき チームが一貫して開発手法をフォローするのに 役立ちます このセッションがワークフローの作成に役立ち チームが開発を繰り返し 高品質なAppを提供する際の活用を願っています ご視聴ありがとうございます WWDCをお楽しみください [音楽]
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。