Xcode Cloudを最大限に活用する

♪ ♪ こんにちは, 私の名前はAdamです Developer Experienceチームの マネージャーをしています Xcode Cloudチームの エンジニア Sasanです このセッションでは 既存ワークフローをレビューし 全く新しいXcode Cloud使用状況 ダッシュボードに ハイライトを当てることで Xcode Cloudを最大限に 活用する方法を お見せしたいと思います 次に 既存のプロジェクトの 使用状況を見ることで 学んだことを利用して さらに最適化し 新しいWatch OS App版の プロジェクトを 開発する方法を見ていきます その前に Xcode Cloudの 概要を簡単に説明します WWDC 2021で Xcodeに組み込まれ Appleの開発者のために 設計された継続的インテグレーションと デリバリサービスである Xcode Cloudを発表しました Xcode Cloudでは コードの開発と保守 テスターとユーザーへのApp配信を支援する 標準的なソフトウェア開発手法の 継続的インテグレーションとデリバリを 採用することができます Xcode Cloudは Appのビルド 複数の自動テストの並列実行 テスターへのAppの配信 ユーザーフィードバックの表示と管理を 支援するクラウドベースの ツールをまとめることにより ユーザープライバシーを 保護しながら 高品質のApp の開発と配信を加速できます Xcode Cloudの最初の設定を 詳しく知りたい方は WWDC 2021の「Xcode Cloudについて」で 最初のワークフロー設定を 詳しくご覧ください では 既存のワークフローと Xcode Cloud での Food Truck Appの ビルドを見てみましょう これは App Store Connectの Xcode Cloudダッシュボードで Food Truckプロジェクトの ビルドの概要を示しています 最近コンパニオンwatchOS Appを追加しました Food Truckの運営者は 新しい注文が入るたびに 携帯に手を伸ばすことなく 腕時計から素早く注文を受けられます Xcode Cloudで新しいwatchOS Appの構築を始める前に 現在のワークフローと プロジェクトが完全に最適化され 望む構築とテスト結果をなるべく早く 得られることを確認します ここで時間やリソースを節約できる方法が あるかもしれないと考えています

このような最適化を行うには どこから始めればよいかを 理解する必要があります ビルドの詳細概要を 詳しく見てみましょう まず 9時15分にビルドを開始し 14分で完了し結果を提示しています また この場合は32分の使用時間が 設定されていることがわかります 14分間のビルドですべてのアクションが 完了するまでに かかった合計時間です 使用状況の横に このビルドのアクションの 分布を表示する オプションがあります

各アクションは 各使用量とともに分けられ 下部には32分間の 合計が表示されます この使用法分布から いくつかの最適化が 可能な場所を 知ることができます しかしその前に Xcode Cloudが これらのアクションを どのように実行するのか ビルド期間と使用状況の違い について詳しく見てみましょう

各ビルドは ワークフローの設定に応じて 一連のアクションに 分割されます Xcode Cloud は各アクションを 分析 アーカイブ ビルド テストなどの 複数の並列アクションに 分割しています これらのアクションは 並行して実行されるため ビルド所要時間は最も長く実行された アクションと同じになります この場合 ワークフローで 設定したテストは 完了までに 14分かかっています 使用状況を計算する場合 これらのアクションを 順番に観察すると ビルドの総計算量 この場合は 32分が得られます これがXcode Cloudが ビルド期間と 与えられたビルドの 使用状況を計算する方法です

ではApp Store Connectの Xcode Cloudの 使用状況ダッシュボードを 見てみましょう！ 一番上には Truck to Tableチームの 月次サイクル開始からの 使用概要があり 使用率の合計が表示されています さらに 使用状況の合計が 分単位で表示され チームの現サイクルで利用可能な 残り時間も表示されます

その下には チームの 使用傾向を示すエリアがあり 作成されたビルドや 全体の使用状況 過去30日間の増減率 などが表示されています 別の期間の 使用状況を見たい場合は トレンドセクションの上部 右側で期間を変更 することで可能です

もう少し下のページでは 上記で選択した期間内に 現在 Xcode Cloudを使う プロダクトごとの 総使用量が表示されます 「Food Truck」を選択して 使用状況の内訳を確認しましょう

ここでは チームビューで 見たのと同じ傾向を Food Truckプロジェクトに 特化して見ていきます さらにその先のページでは 各ワークフローの使用状況を 確認することができます ざっと見たところ リリースのワークフローが いくつか最適化を始めるのに 最適な場所なのがわかります では Sasanに引き継ぎます 観察したビルドの詳細と使用状況を元に プロジェクト最適化の方法を いくつか示してくれます Susan お手本を 見せてあげてください ありがとう Adam Food Truckプロジェクトを使い Xcode Cloud使用時の ベスト プラクティスを いくつか説明します 新しいwatchOSAppの 開発を迅速に開始できます ワークフローは開始条件を使って ビルド開始のタイミングを定義します ワークフローが意図する 変更に対してのみビルドが 開始されるよう 開始条件を 設定することが重要です これをFood Truckプロジェクト のリリースワークフローに どのように適用するか 見てみましょう その前に「Xcode Cloud ワークフローの詳細」で より詳細な情報を 確認することをお勧めします

先ほどAdamが見せてくれたのと 同じビルドをXcodeで開いています リリースワークフローを エディタウインドウで開いてみます

ナビゲーションパネルで ワークフローを右クリックし 「Edit Workflow」 を選択しました

エディタウインドウには ワークフローの構成設定項目が すべて表示され 開始条件の 項目も表示されています スケジュールされた ビルドに新しい変更が 含まれないことが あるとわかりました 既存のスケジュールされた 開始条件を置き換えるため ブランチ変更の 新開始条件を追加してみましょう これで 重複したコミットを 構築しないようにできます 「プラス」ボタンを押し 「Branch Changes」を選択します

ここで スケジュールされた 開始条件を削除するため それを選択してゴミ箱 アイコンをクリックします

ブランチ変更開始条件は リモートブランチに新しい コミットがプッシュされる たびに実行されます デフォルトではSource Branchは Any Branchに設定されています あなたのレポのどのブランチ に対して行われた変更も このワークフローによって ビルドが開始されます リリースワークフローは徹底するよう 設定されているので これを制限し リリースブランチの ビルドのみを開始させます

「Custom Branches」をクリック すると カスタムブランチを 指定する必要があることが すぐにわかります

プラスボタンをクリックし ブランチ名を入力します

エディタでは 正確なブランチ名か 接頭辞のどちらかを選択できます 複数のリリースブランチが あることが分かっているので 「release」で始まるブランチ を選択することにします

次に リリースブランチから ビルドを開始できるファイルや フォルダを指定します 目標はdocsフォルダの変更時に ビルドを開始しないことです このフォルダには開発用書類しか 入っていないので飛ばしても大丈夫です これには ファイルとフォルダのオプションで 「Custom Conditions」を選択します

「Start a Build」ドロップダウンから 「Don't start a build」を選択します

プラスボタンをクリックし 新しい条件を追加します

「Any Folder」を選択して 「Choose...」で 除外するフォルダを 指定します

最後に ファイルピッカー が表示されます これで docsフォルダを選択し 「Open」をクリックできます

最後に「Save」をクリックし 変更内容を保存します

開始条件をより 選択的にするために release接頭辞を持つ ブランチのみに制限し docsフォルダの変更を 無視するように設定しました ワークフローでは 予め定義されたアクションを使い ビルドを実行する 方法を定義します アクションを使うと 変更内容の分析 アーカイブ ビルド テストを行えます テストアクションの重要要素 の1つは テスト先の選択です テスト結果を早く出すため テストプロダクトが出来上がると それぞれの行先が 並行して実行されます

テストのために シミュレータの行先を選ぶ際 簡潔に選択 できるようにすることは重要です ビルドの スピードアップに加え 同様のデバイスで 失敗する可能性のある テストによるノイズを 減らすことができます

Xcode Cloudは 推奨される 宛先のエイリアスを提供します 画面サイズに 応じたシミュレータを 厳選して掲載しています

もう一度 Releaseワークフローを見て iOSのテストアクションのための シミュレータの宛先の妥当な セット選択の方法を見ましょう iOSのテスト アクションを選択すると 選択されたテスト先が 多岐にわたることがわかります テスト先を削除するために それぞれのテスト先を選択し マイナスボタンをクリックします 最後の項目のドロップ ダウンメニューをクリックし 「Recommended iPhones」 を選択してみます

もう一度　「Save」をクリックし 変更内容を確定します

リグレッションが発生した場合に 明確なシグナルを出すのに役立つ 一連のテスト先があります

先に説明したように Xcode Cloud はリポジトリに 新しい変更をプッシュすると ワークフローを実行します コミットする変更の 種類によっては CIでのビルドを 省略したい場合もあります そのための機能を 追加しました Xcodeで 見てみましょう

Xcode Cloudでコミットを スキップするには メッセージの 最後に「ci skip」 を追加するだけです リモートにプッシュ時に Xcode Cloud はこのイベントを無視します

ここに示すci skipタグの書式を 正確に使用してください

各アクションにカスタムスクリプトが 複数ポイントで実行されます 未使用の依存関係を整理し 信頼性が低いAPIリクエストを 再試行することで ビルドを高速かつ一貫して 完了させることができます カスタムスクリプトやその他の 高度なカスタマイズの詳細は 「高度なXcode Cloudのワークフロー カスタマイズ」をご確認ください

テストを行う場合 通常ではない 信頼性の低いテストは迅速に 修正される必要があります 通常でないテストが失敗すると 直感的にすぐやり直したくなります テストスイートの 信頼性にもよりますが 何度もビルドをやり直す ことになりかねません 信頼性の高いテストを書くため より多くの時間を費やしましょう

効果的な方法については 別のセッション 「Xcode Cloud用の高速で信頼性の 高いテストを作成する」をご覧ください いくつかのベスト プラクティスについて説明し それをFood Truckプロジェクトに 適用してきました 先ほどのと今回の ワークフローのビルドを比較し この変更がどんな影響を 及ぼすかを見てみましょう ベストプラクティスを適用して 開始されたビルドです Adamが見せてくれた 前回のビルドと比較すると 所要時間は1分減少しましたが 使用状況は4分減少しています 全体的に良い 改善がなされたようです

使用状況ダッシュボードに戻り その影響をより理解しましょう

1回のビルドですぐに効果を 実感するのは難しいので ベストプラクティスを 別のワークフローである 統合ワークフローに 適用してみました しばらくベストプラクティスを 適用したビルドを実行しておきました 使用状況が減少傾向に あることから 変更が効果的で あったことが分かります

watchOSApp開発を開始するため より多くのワークフローを追加し より多くのビルドの開始が 可能になったということです

使用状況ダッシュボードを使い 既存のプロジェクトや ワークフローに同ベストプラクティス を適用し続けることで Xcode Cloudを最大限に 活用することができます 大規模なチーム向けXcode Cloudの 管理方法の詳細については 「チーム用のXcode Cloudについて 詳しく見る」をご覧ください 私達のセッションは 楽しんでいただけたでしょうか ご視聴ありがとうございました

♪ ♪