株式会社バニッシュ・スタンダードのヒダです。弊社で提供している「STAFF START」というtoBのサービスのiOSアプリ開発を担当しています。今回は弊社テックブログに初投稿ということで、何を書くかかなり迷ったのですが、アプリの自動テスト&ビルドに使ってきたサービスについて自分なりの比較を書きたいと思います。
結論からどうぞ
そもそも今はXcode Cloudを利用しているので、弊社の使い方としてはXcode Cloudの方が良かった、ということではありますが、とはいえXcode Cloudに足りないものも色々あります。以下にそれぞれの良かった点をあげます。
-
GitHub Actionsの良かった点
- Xcode Cloudよりは情報が多い
- 問題や不具合がある場合、Issueとしてそれが可視化されるので状況が分かりやすい
- AWSからビルドに必要なAPIキー等の情報を取得する際に安全な方法が利用できる
- カスタマイズ性が高い
- 実行環境に必要なソフトウェアが大体揃っている
- ビルドステップをコードで管理可能
- ワークフローに必要な情報を実行時に指定できる
- Xcode Cloudの良い点
- 最新のOSやXcodeでビルドできる
- 安い
- 設定がGUIでできる
- TestFlightへの配信が簡単
- 証明書の指定が不要
※ GitHub Actionsについては当時の話なので、今は変わっていることもあるかもしれません
それではここからはそれぞれの良い点について1つ1つ説明していきます。GitHub Actionsの良かった点は[GHA]、Xcode Cloudは[XC]をタイトルの前に付けています。
[GHA] Xcode Cloudよりは情報が多い
ユーザ数やリリースからの期間が違うと思うので、ブログなどの情報の差はもちろんあると思いますが、そもそもXcode Cloudは公式のドキュメントが自分にとっては分かりづらかったです。既存のCI/CDサービスからの移行がしたかったので、そういう想定のドキュメントが欲しかったです。
[GHA] 問題や不具合がある場合、Issueとしてそれが可視化されるので状況が分かりやすい
GitHub Actionsでは何かうまくいかないな、ということが起きた場合、通常のGitHubのレポジトリと同じく、Issuesで問題を報告したり、既にあがっている報告を確認できるので、Actionsに何か問題があるのか、それともこちらの使い方が悪いのかがある程度分かります。
例えば新しいmacOSやXcodeが出たときに、その環境の提供についてのIssueがrunner-imagesのIssuesにあがるので状況を確認できます。
ちなみにFastlaneのバージョンが上がって問題が起きる、ということがちょくちょくあったのでどちらかというとFastlaneのIssuesを見にいくことが当時は多かった気がします😅
Xcode Cloudはどうかというと、去年不具合というよりは疑問をサポートに問い合わせたのですが、起票はしていただけたもののそれから音沙汰はなくなりました。
[GHA] AWSからビルドに必要なAPIキー等の情報を取得する際に安全な方法が利用できる
弊社のアプリではビルド時に、AWSのSecrets ManagerからサードパーティライブラリのAPIキーなどソースに含めたくない情報を取得して利用していますが、GitHub ActionsではOIDCを利用したAWSでの認証ができ、私の理解でものすごくざっくり説明すると、要はAWS側で対象のGitHubレポジトリや権限を指定しておけば、GitHub Actions側に何かAWSの認証情報を設定しなくても、そのAWSのサービスが利用できます。
もっと具体的にいえば、AWSの認証情報を誰かが管理してそれをGitHubの各レポジトリのSecretsに入れておく、という過程が不要になり、よりセキュアです。ただ現実的なデメリットを挙げると、利用時にたまにこの認証方法が失敗しました。大体再実行で何とかなった気がしますが…
[GHA] カスタマイズ性が高い
GitHub Actionsはビルドのステップを自分で書く上に、そのステップで使うアクションも公式だけでなくサードパーティが作成したものを利用できるので、やろうと思えば大体のことはできそうなイメージがあります。
Xcode Cloudでもシェルスクリプトを書けばできることは色々あると思いますが、そもそもそういうことをしなくて済むことを目指しているサービスだと思います。分かりやすいところでいうと、ビルドキャッシュの対象ディレクトリやキャッシュとリストアのタイミングをこまかく指定したりはできず、そもそもキャッシュするか的なチェックボックスが1つしかありません。逆にいうとそれを意識する必要がない、というメリットがあります。GitHub Actionsの場合、ビルド結果のSlack通知は自分でYAMLファイルに書く必要がありますが、Xcode Cloudの通知方法はむしろ最初からSlackとメールしかなく、画面でぽちぽち設定するだけです。通知内容のカスタマイズもできませんが、逆にいうとそれを考える必要がありません。
[GHA] 実行環境に必要なソフトウェアが大体揃っている
実行環境に入っているソフトウェアの一覧はここの各イメージの「Included Software」で確認できますが、かなり色々なものが最初から入っています。iOSはFastlaneなどRuby系のツールが多いのでBundlerが入っているのは割と分かりますが、ComposerやNPM、GradleにGoやRustなんかも入っているようです。
ただこれにはデメリットがあり、インストールされているFastlaneが最新になったらエラーが出るようになった、みたいな時は最初から入っているバージョンをアンインストールしてから前のバージョンをインストールし直す必要がありました。
一番ありがたかったのはAWS CLIで、Xcode Cloudでは入っていないのでHomebrewでインストールしていましたが、どこかのタイミングでそれがエラーになるようになってしまい、公式のインストール方法に書き換えるために10行くらいシェルスクリプトの行数が増えました。
[GHA] ビルドステップをコードで管理可能
これは完全に善し悪しですが、GitHub Actionsはビルドの仕方をYAMLで記述するため、バージョン管理ができ、いつ誰がどんな変更をしたのかがすぐに分かります。元に戻すのも簡単です。ただその一方、メンテナンスするためにはメンバーがこの書き方を理解しておく必要があります。
一方Xcode Cloudでは自分のマシンのXcode(動画)かApp Store Connectのサイトでぽちぽちするだけで、やろうと思えばエンジニアでなくても設定ができます。とはいえ前回の設定に戻す、みたいなことはできないですし、複数のワークフローのある設定項目を一括で変更する、みたいなことはできないのでひたすら各ワークフローのページを開いてぽちぽちします。とはいえビルド時に使うスクリプトはバージョン管理に含めるので、全くコードで管理しない訳ではありません。
[GHA] ワークフローに必要な情報を実行時に指定できる
カスタマイズ性が高い、という内容と近いのですが、テスト用のアプリのビルドを開始する時に、そのビルドでテストしてほしいことをその場で入力して、例えばSlack通知であるとか(実際にはやっていませんが)その内容をアプリ内に表示する、といったことができます。そう、GitHub Actionsならね。
もうちょっと技術的な言い方をすると、workflow_dispatch.inputsを使えば実行時にワークフローに対して好きなパラメータを渡すことができます。ワークフローからは${{ inputs.input名 }}のようにしてその値を参照できます。これを使うと実行開始時にそのビルドの説明を書いて、完了したらその内容をSlackに通知する、みたいなことが可能です。
ちなみにXcode CloudだとTestFlightの「テスト対象 (What to Test)」に何をテストしてほしいか書きたい場合、決められたファイルにそれを書いてあらかじめGitレポジトリにコミットしておく必要があります。
GitHub Actionsのいいところを書く、と見せかけて実はちょくちょくデメリットを書いていることに気付かれたかもしれませんが、つまりはそういうことです。それではここからがXcode Cloudのいい点です。
[XC] 最新のOSやXcodeでビルドできる
基本的にはローカルの環境は最新のXcodeやmacOSを使うようにしている、というか少なくともXcodeについては新しいiOSが毎年出るのでそうせざるを得ないと思いますが、CI/CDで同じ環境が作れないのはちょっと不安があります。現実には新しいAPIを使わなければ新しめの環境でなくても問題ない気もしますが、とはいえ新しいのに越したことはないと思います。
さらにいうとXcode CloudではベータのOSも利用できます。このおかげでローカルにXcodeやmacOSの最新版をインストールしなくても新しい環境でのビルドで問題が起きないか確認できます。
[XC] 安い
GitHub Actionsは、macOSのイメージを動かすとLinuxのイメージの10倍の時間を使った扱いになるので、普段Linuxで使いがちだからこそ高く感じると思います。
一方Xcode Cloudは無料期間が終わると思ったらデフォルトで毎月25時間分が無料で使えるようになったので、この時間に収まるなら安いってレベルじゃないぞ、ということになります。
[XC] 設定がGUIでできる
既にGitHub Actionsの方でそのメリットもデメリットも挙げてしまったので省略しますが、改めて学習コストはXcode Cloudの方がさすがに低いかなと思います。コードで書くのに慣れている人にとってはむしろ同じことをどうやって実現するのか(あるいはそもそもできないのか)が分かりづらいかもしれませんが…
[XC] TestFlightへの配信が簡単
そもそも今のApp Store ConnectのWebのUIだと「TestFlight」と「Xcode Cloud」はタブとして隣り合っていたりするので、親和性が高いってレベルじゃないです。
実をいうとGitHub Actions時代は今と配信方法が違っていたため、TestFlightへの配信はそもそも頻度が低く、やる時は手動でやっていました。これを自動でやるとなると、GitHub ActionsからApp Store ConnectにアクセスできるようにAPIキー等を設定しなければならないはずで、その管理の手間が生じます。
Xcode Cloudであれば単にAppleのシステム間でやってる話なので、設定画面でTestFlightに配信する、的なやつをぽちぽち選んでおけば一瞬で終わります。少なくともこちらがセキュリティの心配をする必要はありません。
[XC] 証明書の指定が不要
これはXcode Cloudだけのメリットではないのですが、クラウド署名(動画)を使うことにより、CI/CD環境に証明書やプロビジョニングプロファイルを配置しなくとも配信用のビルドができるようになりました。これはGitHub Actionsでも可能ですが、API経由で利用しないといけないのでTestFlight配信と同様にAPIキーの設定／管理が必要そうです。
ちなみに以前は自動署名も使わずに中途半端にFastlane Matchを使っていたので、証明書の期限を気にしたり手動で更新する作業が必要でしたが、そもそもそういうことを気にしなくてよくなりました。
また細かいですが、以前はビルド番号という、ビルドを識別するためだけの数字をリリースする度にインクリメントしてコミットする、という作業をしていました。Fastlaneにはそれ用のアクションもあります。これが辛いところは、例えば一度、配信用のビルドを作成・テスト配信したあとで問題が見つかったら、修正して配信し直すためにはこの数字もインクリメントしないといけないところです。Xcode Cloudはこのビルド番号も管理してくれるのでこちらは何もする必要がありません。勝手にインクリメントされます。
いかがでしたか?
「いかがでしたか?」と書いたことがなかったので古い気がしますが書いてみました。
今回触れなかった点として、Xcode Cloudの罠は結構色々あるのですが、そこに目をつむれば、とりあえず今からミニマムでCI/CDを始めたい、という方にはXcode Cloudは学習コスト的にもお値段的にもおすすめできると思います。もっと色んなサービスと連携したいとか、複雑なことがしたかったり、全体をコード管理したい、という場合はGitHub Actionsなどを使うといいと思います。
Discussion