Xcode Cloudでの実用的ワークフロー作成

♪ ♪

こんにちは　Romainです Xcode Cloud開発のエンジニアです Xcode Cloudは強力なツールで チームの開発プロセスに 直接結合する柔軟性を備えています これにより生産性が向上し より良いアプリを 顧客に提供できるようになります このセッションでは 現実世界で起こりえる可能性に基づき Xcode Cloudでの ワークフローの作成を説明します チームには様々な形や規模があり 多様で独自の開発プロセスを行っています いくつかの実用的な ワークフローの設計に役立つように ３つの仮説的な事例研究を想定します 各事例はXcode Cloudを導入する時に みなさんが体験する可能性のある 通常の状況に似ています

最初に単一のアプリ開発に取り組んでいる 個人デベロッパから見ていき 次にレガシーコードと 複雑な開発プロセスを扱う 大規模なチームを取り上げます このセッションでは利用できるオプションを いくつかデモンストレーションします 様々なチームに適したワークフローの作成と カスタマイズが可能です

最初の事例研究から始めましょう １人のデベロッパがいるとします iOSとmacOSの両方で利用できる アプリが 1 つあります コーディングのほとんどは メインブランチで行われ 新しいコードの変更はすべて メインブランチに追加されます 新しいAPIや プラットフォーム機能を試す時に 別のブランチを使用することもありますが ほとんどの場合 メインブランチが使用されます コードは依存関係を頼りにしており ダウンロードしプロジェクトに統合するため Cocoapodsを選択しました 最後にTestFlight を通じて アプリの構築を一部の友人や家族に展開し テストしてフィードバックできます 時には手作業で新バージョンのアプリを App Storeにリリースします このデベロッパは個人企画で アプリの構築からApp Storeでの配信まで すべてを自分で管理しています シンプルさが鍵となるでしょう 信頼して維持できるものが必要です Xcode Cloudを使用すると 「新しいコードの追加」 「アプリの構築」「テスターへの配信」の 全過程が可能で 小さいながらも強力なワークフローで 実現できます このワークフローが どのようなものかを説明する前に Xcode Cloudワークフローとは何かについて 復習しておきます 例えば「アプリケーションの構築」 「テストの実行」 「テスターへの配信」などです 「where」は使用する Xcodeと macOSのバージョンに加え 環境変数などのその他の設定です これらが連携してワークフローを実行する 環境を形成します 最後に「when」はアクションを いつ実行するかを指定します

コードを特定のブランチに追加する時に 開始するか それとも毎日午後 4 時と指定するか １つ以上の開始条件を定義すると ワークフローをいつ実行するか 基準が設定されます 素晴らしい 記憶に新しいところで 個人デベロッパの状況に「when」「where」 「what」を当てはめてみます 全プロセスを自動化するために使用できる Xcode Cloudワークフローを作成します ここではプロジェクトが Xcode Cloudに すでにセットアップされています レポートナビゲーターで クラウド アイコンを選択し 製品名を右クリックして 「manage workflows」 を選択します

これでワークフロー エディターが開きます プラス記号をクリックしてメニューを開き 最初の項目を選択して アプリの新しいワークフローを作成します 名前フィールドに 「CI Workflow」と入力します 説明フィールドは省略しますが 詳細を自由に追加してください 次に環境セクションを見てみましょう このセクションでは XcodeとmacOSの最新バージョンが デフォルトで 選択されていることがわかります 良さそうなので ここでは何も変更しません 新しいワークフローにはそれぞれ デフォルトの開始条件が付いています 見てみましょう

この開始条件は変更が デフォルトブランチに追加されるたびに ビルドを作成します この場合はメインです これはほぼ正しいですが この個人デベロッパは コードがメインブランチだけでなく 任意のブランチに追加された時に ビルドを開始したいと考えています ソース ブランチ オプションを 「Any Branch」に変更します

このワークフローの目標は アプリを構築して配信することです 配布用のビルドを準備する アーカイブ アクションが必要です 「Actions」横のプラス側をクリックし 「Archive」を選択します

ご覧の通りiOSプラットフォームは すでに選択されているため 「Deployment Preparation」で説明した 「TestFlightとApp Store」オプションを 選択するだけです

これでワークフローで配信可能なビルドが 作成されるようになりました ビルドをApp Storeにアップロードする ポストアクションを追加します ポストアクションセクションの プラス記号をクリックし 「TestFlight External Testing」を 選択します

そこから「Groups」の プラス側をクリックし テスターの「Friends and Family」を 選択します

これで ほぼ完成です 個人デベロッパはiOSとmacOSをターゲットに アプリに取り組んでいるため アプリをアーカイブし両方で リリースしたいと考えています そのため別のアーカイブ アクションを 追加します

macOSプラットフォームと 「TestFlight App Store deployment preparation」を選択します

次に 別の「TestFlight External Testing」 ポストアクションを追加します

「Archive macOS」アーティファクトを 選択します

テスターには同じグループを選択します

最後に「Save」 をクリックして ワークフローを作成します

前にも述べたように このデベロッパは Cocoapodsを使って アプリケーション属性を組み込んでいます Xcode Cloudは すぐに使える Swift Package Managerを支持しています これはXcodeに直接組み込まれていますが 他の依存関係マネージャーも Xcode Cloudを使用できます ほんの少し設定が必要なだけです 一般的な依存関係マネージャーの 使用方法に関するドキュメントが いくつかあります このドキュメントは他の使用方法ガイドとして 使うことができます この個人デベロッパにドキュメントでは 次のように書かれています クローン後のカスタム スクリプトを使用し Cocoapodsをインストールし実行します

カスタム ビルド スクリプトは Xcode Cloudビルドの特定の時点で 追加のアクションを実行する方法を与えます この例ではすべてのソースコードが 一時的に構築環境に複製されたあと 複製後のスクリプトが実行されます カスタムスクリプトの別の例は あとの事例研究で説明します 個人デベロッパのワークフローは準備完了です 次回コードを追加すると Xcode Cloudビルドが開始され アプリはiOSとmacOSの 両方でアーカイブされます そのあと 新しいビルドが 友人や家族のグループの手に渡り アプリをテストして フィードバックを行います さらに一歩進んで2番目の使用例 中規模のチームを見てみましょう 「デベロッパ」「プロジェクトマネージャー」 「ＱＡエンジニア」で構成されたチームが 世界中に散らばっていると仮定します 彼らはiPhoneとiPadで利用できる iOSアプリを構築します 各デベロッパは独自の部門で作業します 彼らはプルリクエストを使用して 変更を「beta」という名前のブランチに マージし直します 社内のＱＡチームは特定の部門が 作成したビルドをインストールしてテストし アプリとその機能が意図した通りに 動作することを確認します

アプリの新しいバージョンを リリースしたい場合は ベータブランチを リリースブランチに統合します 新しいタグを追加して リリースを知らせます バグを見つけて戻るのを回避するために アプリは単体テストとUIテストの両方で 十分に確認されます 彼らはTestFlightを使用して 開発中の様々な時点で 内部および外部のテスターに アプリをデプロイします 最後にSlack上でコミュニケーションを取り 共同作業を行います これは非常に一般的な例です 高品質の水準を維持しながら ツールを使用し 並行して 共同作業を行っています このプロセスは３つの Xcode Cloudワークフローで実行できます まず ベータ ブランチへの 変更の取得に役立つ プルリクエスト ワークフローを作成します 次に 内部ビルドをＱＡチームに渡す ベータ ワークフローを作成します 最後に アプリの新しいバージョンを 外部テスターとApp Storeにリリースする 最終ワークフローを作成します 各ワークフローをこの順番で見てみましょう チームはプルリクエストを使用して すべての新しいコード変更を アプリに組み込み管理します デベロッパがプルリクエストを開くと チームメイトがコードレビューします そしてテストを実行し アプリが 期待通りに動作することを確認します 最初のワークフローは 新しいプルリクエストが開かれた時か 既存のプルリクエストが更新された時に テストが実行されることを確認します ワークフローを作成してみます まず プラス記号をクリックして 製品の新しいワークフローを作成します 名前フィールドに 「Pull Requests」と入力します プルリクエストが開かれた時に Xcode Cloudがビルド開始を考えますが 「beta」ブランチを ターゲットとする場合に限られます ビルドごとに テストを実行したいと考えます 新しい開始条件を 追加することから始めましょう 開始条件セクションの プラス記号をクリックし 「Pull Request Changes」項目を選択します デフォルトでは任意のブランチのビルドが 開始されるため ターゲットブランチ セクションで 「custom branches」を選択します 次にプラス記号ボタンをクリックして 「beta」と入力します

必要な開始条件は 1つだけなので 「branch changes」条件を 削除して構いません

次にテストを実行するための 新しいアクションを追加します 「Actions」セクションの横にある プラス記号をクリックし 「Test」を選択します

このアプリはiOSとiPadOSの 両方を対象としているため テストに合格することを 確認したいと考えています 様々な画面サイズと機能のデバイスで 使用できます 宛先セクションでは 「small iPhone」 「iPhone 13」 「large iPhone」「iPhone 14 Pro Max」

「small iPad」「iPad mini」

そして「large iPad」 「iPad Pro」を選べます

次に「save」を押します

素晴らしい さてXcode Cloudでのビルドが成功し チームメイトによる徹底的な コード レビューが行われたあと デベロッパはプルリクエストをマージし 変更をベータブランチに 取り込むことができます 便利なことに これで次のワークフローに進みます ベータ版ビルドのワークフロー ベータブランチには

すべての変更が配置されます デベロッパがプルリクエストをマージすると ＱＡチームは新しい変更が含まれた アプリのビルドを取得したいと考えます 検証テストを 実行できるようにするためです これがこの新しいワークフローの基礎となり ビルドをＱＡチームに配置します Xcodeに戻って このワークフローを作成しましょう

このベータ版のワークフローは 前に作成したものを組み合わせたものです チームは変更が「beta」ブランチに マージされるたびに ビルドをリリースしたいと考えています テストを実行してアプリをアーカイブし App Store Connectにアップロードする ワークフローが必要です これを実現する 新しいワークフローを作成しましょう

「Beta Release」という名前を付けます

それに応じて開始条件を更新します 既存のブランチ変更開始条件を選択し ブランチを「main」から「beta」 に変更します

次にアーカイブ ビルド アクションを 追加します

そして「deployment preparation」で 「TestFlight Internal Testing」を選択します

このビルドが誤って運用環境に デプロイされないように ここでは内部配信を使用します では App Store Connectにアップロードする ビルド後のアクションを追加します このポストアクションはアプリを テスターの内部グループに配信します TestFlight内部テストの ポスト アクションを追加します

グループセクションの下の プラス記号をクリックし 「ＱＡチーム」を選択します

ここで停止することもできますが 壊れたビルドをデプロイする 危険を冒したくありません セーフティネットとして ワークフローの一部として テストも実行する予定です プル リクエスト ワークフローから テスト動作を繰り返します もう一度「small iPhone」と 「large iPhone」を 1 つ選択します 「small iPad」が１台

「large iPad」が 1 台

「Save」を押して このワークフローの作成を完了できます

ベータ版のビルド ワークフローは ビルドを ＱＡチームの手に委ねますが やりたいことがもう1つあります ベータ版ビルドに代替アプリのアイコンを 使用したいと考えています これで 内部ビルド対応かApp Store対応か すぐに判断できます Xcode Cloudのカスタム スクリプトが 役立つもう 1 つの完璧な状況です

前にソース コードが複製されたあとに 実行されるカスタム スクリプトを見ました ここではビルド前スクリプトを使用して アイコンを変更します

スクリプトで使用できる環境変数を使うと ベータ版ワークフローのビルド段階でのみ アイコンを交換するようにします この方法について詳しく知りたい場合は WWDC21のセッション 「Customize your advanced Xcode Cloud workflows」を参照してください では正確な使用例について 詳しく説明しています 利用可能な3種類のカスタムスクリプト中 2つだけを使用しました 他にどのようなスクリプトを使用できるか またどの環境変数を利用できるか 知りたい場合は ドキュメントで詳しく説明しています ベータ版ビルドのワークフローは以上です 次に このチームの最終ワークフローである リリースワークフローを見てみましょう 多くの変更がベータブランチに反映され ＱＡによって検証されたあと チームは新しいリリースを準備します

ここでデベロッパの１人がベータブランチを リリースブランチにマージし リリースをマークするタグを 作成する必要があります タグの名前はリリースという単語で始まり そのあとにバージョンが続きます これが完了するとアプリが構築され App Store Connectにアップロードされ 社内関係者のグループと一部の熱心な顧客に 配信されます 3番目の最後のワークフローは 新しいリリースタグが追加された時に ビルドを作成することを除いて ベータ ワークフローと非常によく似てます Xcodeに戻ってこの ワークフローを作成しましょう このワークフローに必要な手順は ベータ版ワークフローで作成したものと ほぼ同じです 開始条件の作成アプリのアーカイブなど すべて同じ手順を実行できます 代わりにベータ版ワークフローを複製できる Xcode Cloud機能を紹介します まずベータ版ワークフローを 右クリックします 重複を選択しワークフローの名前を ベータからリリースに変更します

次に新しい開始条件を追加します 開始条件セクションの プラス記号をクリックし 「Tag Changes」を選択します

ブランチの変更と同様に タグが追加されるたびに ビルドを作成するのではなく 「release」という単語で始まる場合にのみ ビルドを作成したいと考えています 「tag」セクションで 「Custom Tags」を選択します 「release」と入力してください

「ags beginning with release」を メニューで選択します この開始条件を作成すると 既存の「branch changes」の 開始条件に戻って 削除します 次に既存のアーカイブ アクションに 移りましょう ベータ ワークフローは内部 特に ＱＡチームに ビルドをデプロイするために作成されました ここでチームは外部テストと App Store 用の リリースを準備したいと考えています 「Deployment Preparation」セクションで 「Testflight と App Store」オプションを 選択します でも 私たちは ビルドを関係者の内部チームに 配置したいと考えています 既存のビルド後のアクションを選択し ＱＡチーム グループを削除します

次にプラス記号をクリックして 「Executive Stakeholders」グループを 選択します 最後のステップとして 別のポストアクションを追加しますが 今回は「TestFlight External Testing」を 選択します 「Post Actions」 セクションの プラス記号をクリックし 「TestFlight External Testing」 を 選択します 次にグループセクションの プラス記号をクリックし 「Early Adopters」グループを選択します

これでリリース ワークフローの 準備がほぼ整いました このチームは Slackを使用して 互いに通信し共同作業を行うと前述しました このチームにとってSlackで ビルドに関する最新情報を取得することは 開発プロセスと完全に一致します これはビルドが失敗して リリースできない場合に特に重要です ワークフローに最後のステップを 追加しましょう リリースワークフローでは 投稿アクションセクションのプラス記号を クリックし「Notify」を選択します Xcode Cloudは電子メールとSlackを介した 通知の送信をサポートしています ここではSlackの下の プラス記号をクリックし 「Releases Feed」を選択して 「OK」を押します これで２番目の使用例は終わりです これら３つのワークフローは チームの開発プロセスすべてをカバーします アプリを構築してテストを 継続的に実行するため デベロッパは自信を持って提供できます アプリを頻繁にアーカイブして配信し 様々なグループの人々が フィードバックを 提供できるようにしています これは非常に一般的な状況で チームは優れた品質のアプリを 様々なプロセスに適応する ツールの助けを借りて リリースできます ３つ目の最後の使用例を見て これをさらに裏付けてみましょう この例では大規模なチームが Xcode Cloudに移行したいと考えています 最後のケーススタディとして 大規模なデベロッパチームがいるとします このチームは中規模のチームと 多くの類似点を共有していることを いくつかの曲面から見てみました チームは大きくなり コードベースはより複雑になりました iOSとiPadOSには App Store の初期から存在する アプリがあります それ以来 何度も再設計と更新が行われ デベロッパは多くのレガシーコードと 複雑さに対処しています 特にＱＡを行う時 たくさんのテストがあります 最近テスト駆動開発アプローチを 採用しました 新しいコードが変更されるたびに 多くの新しいテストが追加されます

アプリの更新を成功させるに 多くの人が関わっているため 新しいビルドを様々なTestFlightグループに 配信することがよくあります 社内外の両方でフィードバックを収集します チームには世界中で働いている 多くのデベロッパが含まれており Slackを使用してコミュニケーションと 共同作業を行っています ここに興味深い展開があります 彼らはすでに継続的インテグレーションと 継続的デプロイメントに依存して 業務を遂行しています 現在社内ソリューションを使用して チーム メンバーの 1 人が 保守および運用をします このシステムへのアクセスや知識は 限られているため 問題の調査が困難になり 解決がさらに難しくなります これらや他の理由から 切り替えを検討しています この社内システムを Xcode Cloudに置き換えます さらにプロジェクト管理ツールを使用して 行っている作業に 追跡調整 優先順位付けを行います また様々なダッシュボードや ステータス ページも作成しました こうすることでアプリの開発に 直接関与していない人でも プロジェクトの進捗状況を追跡できます Xcode Cloudはこの種のチームに最適ですが これほど複雑なプロジェクトを 新しいCIシステムに移行するのは難しく 圧倒的に感じるかもしれません この状況ではこの移行を 様々なマイルストーンに分割することを おすすめします 各マイルストーンには一定の期間をかけて ワークロードを既存のシステムから Xcode Cloudへの移動が含まれます ここでの主な焦点は チームの生産性と満足感を維持しながら 移行を成功させることです ワークフロー構成に注目する代わりに それらのマイルストーンが何であるかを 見てみましょう 私の推奨事項はこの移行を 個別のマイルストーンに分割することです 最初のステップはApp Storeにリリースできる バージョンのアプリを構築する ワークフローを作成することです ２つ目はテストを確実に 動作させることです ３つ目は チームの開発プロセスに適合させ改善し 残りのワークフローを確立することです リリース ワークフローの作成から始めて これらの各ステップを詳しく見ていきます

Xcode Cloudに移行する場合 ワークフローの作成から始めることを おすすめします アプリのApp Store対応ビルドを アーカイブしてアップロードします すでに作成したいくつかの サンプルワークフローとまったく同様で チームの他のメンバーを中断させることなく 達成できます そこから開始すると Xcode Cloudに直接組み込まれている クラウドコード署名機能を 使用できるようになります 証明書やプロビジョニング プロファイルを 署名のために変更する必要はありません これはアプリを正常に構築するために 何が必要かを確認する良い方法でもあります 依存関係やその他の構成変更に関して このワークフローの準備が完了したら チームの通常の開発プロセスに 組み込むことができます App Store対応ビルドを作成する部分として これは既存のシステムから Xcode Cloudに移行した 最初の作品です 次にテストを確実に動作させることに 焦点を当てます 継続的インテグレーションシステムでは テストは非常に難しい場合があります 多くの場合テストは作成時に使用されていた CI環境で実行されるように 調整されています 新しいCI環境で実行すると 信頼性が低くなり ビルドが失敗する可能性があります Xcode Cloud の作成中に この特定の問題について考えました そしてテストをスムーズに実行するのに 本当に役立つと信じている機能を 構築しました この機能により Xcode Cloud は ワークフロー内の一部のアクションの 失敗を無視しビルドを完了させます

この機能を有効にするには ワークフローのアクションの要件の下の 「requirement」オプションを選択します 「Not Required To Pass」と 指定するとアクションの結果は Xcode Cloudビルドの最終結果に 影響を与えません テストは失敗する可能性がありますが ビルドは成功します Xcode Cloudとビルドの ソース コード管理のコミットステータスに 緑色のチェックマークが表示されます

これはクリティカルパスを外して テストを継続的に 実行できることを意味するため便利です そうすることでデータを集約して パフォーマンスがどのように行われているか 十分に信頼できるかどうかを 評価できるようになります この機能を使用してXcode Cloudで テストを動作させる方法を見てみましょう

チームはアプリの多くの側面をカバーする かなりの数のテストを行っています この状況ではすべての プルリクエストに対して実行される 新しいワークフローを作成することから 始めることをおすすめします このワークフローではビルドアクションは すべてのテストを実行しますが 合格する必要はないとされます テストが成功しても失敗しても プルリクエストのマージは まだブロックされません 現時点ではテストの信頼性を 評価することが考えられています テストは既存のソリューションで まだ実行されているため プルリクエストは１週間ほど経っても 確実にマージされることに注意してください チームはプル リクエスト ビルドからの テスト結果データを確認し Xcode Cloudでどのテストが 確実に合格したかを確認できます これらのテストは信頼性の高い 新しいテスト計画に移動できます 次にチームは既存の プル リクエスト ワークフローを編集し その特定のテスト計画からテストを実行する 新しいテスト動作を追加できます 今回はプル リクエストをマージする前に テスト動作に合格する必要があります Xcode Cloudでの テスト計画の使用の詳細については WWDC22の「Author fast and reliable tests for Xcode Cloud」を 参照してください テスト計画を使用する コード評価の改善に関するドキュメントも 参照してください 残りのテスト つまり現在 信頼性の高いパフォーマンスが 得られていないテストは さらに調査して信頼性を高めるために どのような変更を加える必要があるか 判断できます 時間が経ち変更が加えられると テストは再び信頼できるようになります 最終的にはそれらを 信頼性の高いテスト計画に移し 変更を再度検証するために使用できます このアプローチにより テストを段階的にクリティカルパスに移行し 検証とテスト カバレッジを提供できます Xcode Cloudワークフロー内で

テストが実行されて満足したら これでApp Store対応の ビルドとテストが完成し Xcode Cloudで確実に実行されます これら２つのワークロードは 既存のCIソリューションから削除できます 残りは最後の３番目のステップです チームの開発プロセスに必要な 残りのワークフローを構築します これらの一部は このセッションのケーススタディで すでに見たものと似ています 条件やアクションを開始するために行なう 様々なカスタマイズを通じて 非常に強力なワークフローを作成でき CIおよびCDプロセスの自動化に役立ちます またこのチームが CIシステムの外部に ツールとダッシュボードを 作成したことにも触れました これらのツールは 開発プロセスを常に把握し続けるのに役立ち Xcode Cloudと統合することもできます 例えばWebhook機能を使用できます Webhookが構成されたあとは ビルドが完了するたびに ビルドを開始したワークフローなどに それに関する情報を含むリクエストが サーバーに送信されます そしてベータワークフローから ビルドが作成されそれが成功した場合は タスク管理システムで 新しいチケットを作成でき この特定のビルドのＱＡプロセスを 追跡します

Webhookのリクエストが送信される タイミングについて 特に詳しく知りたい場合の 利用可能な情報については ドキュメントを参照してください もう１つはXcode CloudパブリックAPIを 使用することです これにより特に 最近のビルドに関する情報を取得し ダッシュボードまたは ステータスページに表示できます

もう一度 ドキュメントを参照して Xcode CloudのパブリックAPIの 使用方法を学習でき それをワークフローに統合します Xcode CloudのパブリックAPIと Webhookメカニズムは チームの規模に関係なく 非常に役立つ機能です 利用可能なオプションを すべて組み合わせると可能性は無限大です WWDC22のセッションを参照できますが その他の例については 「Deep dive into Xcode Cloud for teams」を参照してください このセッションでは チームの生産性を高めるために 様々なタイプのシンプルだが強力な ワークフローを検討しました ビルドの様々な時点で ビルドスクリプトを使用して ビルドプロセスをカスタマイズする 方法の例をいくつか示しました 最後に一部の機能により Xcode Cloud上にツールを構築し 外部ツールと統合できることを示しました ３つのケーススタディが Xcode Cloudのチームを強化し より良い理解に役立つことを願って 日々の業務を改善します ご視聴ありがとうございました ♪ ♪