昨今のiOSのCI /CD環境において、マシンスペックと実行コストのトレードオフや、それに伴うクレジット管理に悩まされることが増えています。 6月27日〜28日にかけて開催した「CyberAgent Developer Conference 2023」では「iOS開発におけるGitHub Actions self-hosted runnerを利用したオンプレ CI/CD のすゝめ」というタイトルで下記についてご紹介しました。本ブログでは、そのセッションの様子をお届けします。
—————————
サイバーエージェントではCyberAgent group Infrastructure Unit（CIU）がMac OSの物理マシンを運用管理し、GitHub Actions self-hosted runnersを用いて提供することで、それぞれのプロダクトチームがGitHubの強力なエコシステムを活用した上で、高スペックなマシンで、実行時間を気にすることない CI / CD 環境を実現することができています。 本セッションでは、GitHub Actions self-hosted runners をどのように提供しているか、CI / CD 環境 のコスト削減とパフォーマンス向上をどう実現したかの事例について、タップルの永野とCIUの中西が発表しました。
サイバーエージェントのプライベートクラウド
まず私、中西から自己紹介させていただきます。2019年に新卒に入社し、グループIT推進本部 CIUでクラウドメーカー（ソフトウェアエンジニア）という肩書きで仕事をしています。まず最初に、プライベートクラウドについて簡単に説明させていただきます。プライベートクラウドというのは、会社独自でデータセンターを運用して、会社として必要なメモリーやCPUをチューニングした上で提供する仕組みのサービスです。
基本的にAPIベースでVMを作ったりができるというような感じで、その辺はパブリッククラウドと使用感等大きく変わりはないのですが、会社として使えるのでメリットが大きいという感じです。2000年代初頭とかだと、Web系のサービスをやられている会社であればデータセンターを契約されていたことも多いんじゃないかと思うのですが、そこから時間が経ち、やられている方も少なくなってきた印象があります。サイバーエージェントではまだデータセンターを契約していて、それをプライベートクラウドとして社内に提供しています。
最大のメリットは、一括サーバーを物理的に購入することによるコストメリットが挙げられます。その中でも我々は「Cycloud」というブランドを掲げて、IaaSやManaged Serviceを中心に提供しています。最近提供しているものは、Kubernetes as a Serviceや、Platform as a Service、認証認可を司るIAMを提供していたりしています。また今年は「大規模なAI開発に対応する「NVIDIA DGX H100」を国内初導入 －80基の「NVIDIA H100 Tensor コア GPU」でAI開発を大幅強化、機械学習モデルの大規模化・構築の高速化へ」についての発表を行っています。
サイバーエージェントのCI事情
まず、サイバーエージェントのCI事情について説明します。CIサービスは多くの会社で様々なものが使われていると思うのですが、サイバーエージェントは技術選定について、基本的に各プロダクトや事業部に権限が委ねられています。なので正直、めちゃくちゃ色んなものがあるんです。リポジトリの管理は、一番王道であるのは、やっぱり GitHub.com がよく使われている印象ですが、GHES や、GitLab が使われていたり、そもそも Git を使っていなくて、Subversionを使っている場合もありますし、これにさらに CI サービスを付け足すと、昔ながらの Jenkins や Travis CI、 Circle CI なんていうのもあります。今回話に出てくるようなモバイルのビルドであれば、Bitriseとかも使われている印象です。このように、多種多様な CI サービスが使われていたのですが、 GitHub Actions という比較的後発の CI サービスに移行する需要が高まってきました。
これはいくつか要因がありますが、もともとエンタープライズとしてすごく大きいものを契約していたけれど、コストメリットが出てこなくなったであったり、あとは世界的に物価が高騰している影響で、CI でも各サービスで価格見直しが行われている事実もあります。なので、新しいモデルを使おうとすると、値上がり幅がすごいことになってしまうケースも多々あり、こういった状況を解決するためにCycloudのようなプライベートクラウドをを提供することで、サイバーエージェントグループ全体のメリットに繋げようと、開発に取り組んだ背景があります。
GitHub Actions のrunnerというのは、いくつか種類がありますが大きく GitHub-hosted runner と self-hosted runner の2つが存在します。GitHub-hosted というのはその名の通り、GitHub が提供している動的に生成されるrunnerです。
皆さんの聞きなじみのあるところでいうと、`ubuntu-20.04` や `macos-latest` とか、そういったものを書いてGitHub Actions を使ったことがある方が多いと思いますが、それが GitHub-hosted runner と言われています。self-hosted runner というのは、例えば VM とかにインストールしたら、そこで CI を動かすことができますよということだったりです。ただ self-hosted runner を使って、いろんな事業部に対して様々なrunnerを提供するのは、いくつか課題がありました。大きいところでいうと、1回ジョブを受け取った self-hosted runner というのは、そのままジョブを終了させた後に、その self-hosted runner のプロセス自体はそのまま動いてしまうことです。
これでどういうことが起きるかというと、例えば `docker login`や `aws configure` とかで認証情報を CI 上で使うことってよくあると思うんですけれど、その時にその認証情報が残ったまま次のジョブが受け取られてしまうのです。自分たちだけで使うrunnerであれば、それでも全然問題はないのですが、他の人たちも使うrunnerだったら、認証情報を他のチームに見られてしまうことが起こるので、そこは避けたいという考えに至りました。他にもいろいろと問題点はあるのですが、これに関してDeNAの加瀬さんによる以下の資料が分かりやすくまとまっているので、宜しければご覧ください。
GitHub Actionsオタクによるセルフホストランナーのアーキテクチャ解説
https://www.docswell.com/s/Kesin11/K98GJJ-cicd_testnight_6_github_actions
この記事における「webhookをベースにrunnerを都度作成するOSS」として私が開発したのが「myshoes」です。
myshoesとは
myshoes とはというような話をさせていただくんですけども、READMEの一行を持ってきたんですけど、そのまんまですね。
Auto Scaling Self-Hosted Runner for GitHub Actions。完全にオートスケールするself-hostedなrunnerを提供するデーモンです。これが本当に一つの機能であり、これが重要なコアの機能になっているという形になっています。どう動いているかという話ですが、GitHub から Webhook を受信して、その Webhook 情報を元にrunnerを生成して、それを GitHub の API を実行して登録するという形になっています。
この特徴として面白いところがあるのは、インフラ、この場合だと AWS とか GCP とか皆さんいろんなクラウドを使われていて、いろんなところでサービス展開していると思うんですけども、どこのクラウドプラットフォームでも動く設計になっています。この辺についてはこれから説明しようかと思います。下記がrunnerの追加時の動きです。
左下に人間がいて、その人がPushしたりだとかPull Requestを作ったりだとかで、GitHub Actions のジョブがリクエストされるとなったときに、GitHub がそこから Webhook を myshoes に送信する。myshoes はそれを受け取って、こういった情報でrunnerを作ればいいんですねというのを確認した上で、後ろのクラウドプロバイダーに提供すると。
そのクラウドプロバイダーが API を叩かれて、その結果が VM として上がってきて、それがちゃんとself-hosted runnerとしてセットアップされたものが上がってきて、それが GitHub に登録されて、そうすると一番最初にリクエストしたジョブが動き出すという流れになっています。
削除はこれの逆側ですね。これ終わったrunnerとかいないかなというのを探した上で、それを GitHub 側が検知して、それを myshoes が確認してクラウドプロバイダーに消すという処理をやっています。ここのrunner追加時の動きのところになるんですけども、こういうような設計をとっています。先ほど、どんなインフラでも使えるという話がありましたが、基本的に myshoes からその後ろに起動させるものは、基本的にshoes-provider というバイナリを経由して行うことになっています。
この Provider って何やねんという話なんですけども、Hashicorpが提供している、 Terraform とか使ったことがある方だと結構イメージしやすいかなと思うんですけども、今回でいうと myshoes という一つのアプリケーションがあって、AWS であれば shoes-aws-provider っていう、AWS に対応したプロバイダーを実装してあげることで、myshoes としては一つのコードなんだけど、各クラウドごとに別のバイナリを用意することで、さまざまなクラウドプロバイダーに対応することができるようになっています。
この時だと、その Shoes に渡す値として、runnerの名前と、self-hosted runnersをセットアップするためのbashスクリプトと、リソースタイプというのは基本的にrunnerのスペックですね。例えばすごく小さいスペックでいいとか、そうじゃなくて、このジョブだけは結構大きめに作ってほしいとか、そういうのを切り替えられるようになっています。具体的に言うと AWS の例なんですけども、 AWS だとインスタンスの名前ってネームタグですね。そこにつけてやると動くようになっているし、セットアップスクリプトというのはcloud-initのbashスクリプトになっています。
なのでcloud-initのuser-dataに渡すと、そこにbashの起動がするというような形になっていますし、リソースタイプを切り替えることによって、 AWS だとインスタンスタイプがたくさん提供されていると思うんですけど、そのマッピングに対して大きいサイズだったりとか小さいサイズだったりとかというのを切り替えることができると。これ全く同じ話が LXD と言われている、これ今ちょうど我々が使っているオンプレミスで使っているサービスなんですけども、Linux Container Daemon の略ですね。これでも同じことができます。同じ myshoes のコードなんだけど、shoes-provider を切り替えることによって、どんなクラウドでも動くようになっているというのがわかるかなと思います。うちではどういう運用をしているかという話なんですけども、この myshoes を使って CI runnerサービスというのを展開しています。
先ほどの話にあった通りですね、Cycloud上で動いている、動的にrunnerを作成するマネージドサービスというのをやってまして、名前はCycloud-hosted runnerというような名前でやっています。GitHub-Hosted をモジッたというような感じですね。2021年の9月ぐらいから実際に GA して提供しているので、結構時間が経ったんですけども、そこでCycloud上、我々はrunnerが動く場所なのでStadiumと呼んだりするんですけども、StadiumをCycloud上のVMで作成し、その上で提供する形でやっています。OS イメージに関しても基本的には actions/runner-imageというリポジトリで公式が公開してくれているので、それを利用しているというような形になります。
こうすることによって、このワークフローだけ動かないんだけどみたいなことが結構問い合わせとして多くあったりするので、それを避けているというような意図になります。ちょうど規模感としてちょっといい感じの値を持ってきたんですけども、大体 GA から 1.5 年、もうちょいかな、経ったところなんですけども、ホストマシンとしては 16 コアでメモリー 160GB の VM が大体 80 台ぐらい使っていて、導入としても、チームとかプロダクトって結構この会社と数えにくいものではあるんですが、大体 50 ぐらいかなというイメージです。1日に大体1万件ぐらいリクエストが来ていて、それに対してrunnerを提供しているというようなことをやっているので、Prometheusとかのグラフで見てみると、大体500から700インスタンスぐらいは常時動いて、また消されているというのを繰り返しているという感じですね。実際に今までどのぐらい時間動いているのかを計算してみたところ、4億秒を突破していました。ここまでが Linux コンテナを使うことによって提供している Linux ベースなrunner基盤というものの話をしていました。ちょうど GitHub-hostedでいうと `ubuntu-latest` とかに値するところですね。ここから皆さんに対して新しいお知らせをすることができます。
Cycloud-hosted runner macOS runner
私たちは、2022 年から mac OS runnerの実現性をずっと検討してきました。今回の話にあるように、iOS でどうやってアプリをビルドしたいというのがかなり大きくて、そうなった時に我々はどうやったら提供できるかなというのをずっと考えていて、今回無事 GA にたどり着きました。
どうやって実現したかという話については、自社の DC に 2023年に出たM2 Mac Mini を設置して、それを並べました。基本的に Apple Silicon ベースな CI サービスとして提供するというのは一番最初に決まっていて、それこそ一番最初にお話しさせていただいたように、 CI のサービスというのを見ていると、割とまだ Intel の提供が多くて、最近ようやく Apple Silicon の提供が増えてきたというイメージです。我々が作っていく中でも、これは確かにパブリックなサービスとして作るには大変そうだなというような印象を受けたりもしたんですけども、なんとか提供するにこぎつけることができました。現在の仮想化は UTM と呼ばれているアプリケーションがあって、これを利用しています。Virtualization.frameworkというものがあるんですけども、それのフロントエンドアプリケーションですね。現状は安定して動いているんですけども、GitHub-hosted がこの UTM じゃなくて他のアプリケーションを使っているので、もしかしたらこれを切り替えるかもなと思っています。
OS イメージに関しては Linux 版同様、actions/runner-imageベースで、我々のイメージを焼いた上でそれを提供しているということがあるので、基本的にどんなワークフローでも動くような形になっています。ただ GitHub-hosted自体も、そもそも Linux と Mac って結構仕様がいくつか違うところがあって、ここでどうしても動かない部分というのはいくつかあるみたいなんですが、これは基本的に GitHub 側で直してくれるような話になっています。Virtualization.framework、聞き覚えがない方も多いと思うので、軽く説明しておきます。これ結構良い図なので、WWDC で公開された動画なんですけども、ぜひ見ていただければと思うんですが、Mac OS 上で VM を作るためのハイレベルな API になっています。
Big Sur から提供されていて、Linux だったり Mac の VM っていうのを作成することができるんですけども、このVirtuallization.frameworkの下に、Hypervisior.frameworkというのがあるんですね。これ名前にめちゃくちゃ似てて分かりづらいんですけど、基本的にこの2つのコンポーネントを利用することで、Mac の上で Mac を動かすというのが、Apple Silicon ではかなり安定して動くようになったというような感じですね。過去、いろんな仮想化のシステムが作られたりしていたんですけども、これに関しては私が以前ブログに書いたので、ぜひこれを見ていただければと思います。
Cycloud-hosted runnerの Mac OS どういうふうに動くの?というような話をしようかなと思うんですけども、基本的に我々Cycloud-hosted runnerというのは、各テナントごとに myshoes のデーモンを起動させて、ユーザーに提供しているというような形になっています。この時に myshoes 先ほども言った通り、いろんなインフラを使えるようにというような仕組みを作ったんですけども、この時に同時に運用するというのは無事実現しました。上にあるのが、Stadium VMなので、先ほど話していた Linux の我々だと Ubuntu を提供しているところになりますし、そうではなくて今回新しく Mac Mini を使った Mac のrunnerも同時に同じテナントで提供できるというような形になっています。
これをどういった形にしているかと言いますと、 GitHub Actions の `runs-on` という値があるんですね。これにいくつかタグを書くことによって Linux だけで動かしてよ、Mac だけで動かしてよ、というように切り替える手法があるんですけども、これをベースにしたルーティングをするための shoes-label-router という、これも myshoes のプロバイダーになるんですけども、これを作りました。この一番下にあるのが `runs-on` と書いてあるのが例になるんですけども、Linux の large というのは一番うちだと小さいインスタンスかな、2コアのインスタンスで OS のバージョンが 22.04 というものを動かしてよというような書き方もできますし、下にあるように macOS の large 小さいやつで OS のバージョンが 13 のものを動かしてよというようなことも設定できますし、こういった形でラベルベースにいろいろルーティングすることができるというような形になっています。
これが今実際に提供しているラベルではなくて、ちょっと違うものになりますし、今後将来こういうものも提供したいなというような部分も書いてあったりするんですが、基本的にこういった形で切り替えるようになっています。ちょっと前のスライドに戻るんですけども、こうすることによって、shoes-label-router が、このリクエストは Linux のものなんだとか、このリクエストは Mac のものなんだとか、そういったものをスイッチして切り替えてくれるという感じですね。そういったイメージで入れてくれればと思います。こういったものを使って提供しているというのが macOS runnerになります。
最後のまとめになります。サイバーエージェントのプライベートクラウドについてお話しさせていただきました。社内向けにクラウド基盤というものがあって、それをあることによって安価に計算機制が使える。それはつまり CI のrunnerも安価に提供することができるというような話になります。その上でサイバーエージェントの CI 事情というのは結構いろいろ、魑魅魍魎と言っていいのかわかんないですけど、そんなような状況になっていて、いろんな事情から私だと myshoes というようなプロダクトを作って開発とサービスの提供をしております。その上でcycloud-hosted runnerの macOS というものを提供、検討し続けた結果、今回 GA というようなことになって無事にリリースできたということを非常に嬉しく思っております。ここから先は、この macOS runnerを GA するまでに非常に多くの協力をしてくれたタップル の永野さんからの発表です。
タップルについて
ここからはCycloud-hosted runner をユーザー目線でどのように活用していったかについて私、永野からお話させていただきます。普段は タップル で iOS チームのリーダーをしており、マネジメントやアーキテクトを担当しています。Cycloud-hosted runnerは、GA になる前からユーザーとして使用させていただきながらフィードバックをして共に改善していったという経緯があります。まず タップル がどういった特徴や予見を持ったプロダクトなのか、また私たちのチームの抱えていた課題についてお話しした後、どのようにCycloud-hosted runnerで解決したかについてご説明したいと思います。
まず「タップル」について簡単にご紹介させていただきます。タップル は 2014 年にリリースされた国内安心安全評価 No.1 を獲得しているマッチングアプリで、現在10年目の運用に差し掛かっています。毎月1万人のカップルが誕生しており、一つの障害が起きてしまうと、たくさんのユーザーの人生に影響を与えてしまうという責任のあるサービスになっております。開発面で他のサービスにない特徴としては、マルチプラットフォームの技術として KMM を採用しており、各 OS 10 人弱、合計 20 人規模で一つのリポジトリで iOS、Android の運用を共にしています。iOS のビルド時に KMM のモジュールを直接ビルドすることで、両OS が KMM を活用しやすい環境を作っています。KMMの詳細は「KMM導入事例Tapple編」の動画も宜しければご参考ください。
下記はCI/CD 前のネイティブチームのパフォーマンスです。
リリース頻度、変更リードタイムはこれ以上の改善は見込めない状態ですが、修復時間、変更失敗率に関してはまだ改善の見込みがある状態でした。ちなみに移行後の結果はまだ取れていないため、今後の計測が楽しみです。
タップル の iOS チームの主な CI/CD 運用についてご紹介します。インテグレーションに関してはUnitTest / Linter / reg-suitを活用したSnapshot Testの3種類のテストを実行しています。また週次でライブラリーのアップデートを自動化で実行しています。デリバリーに関してはアプリのハイフリア、アップストアへのアプリ、一部のメタデータのサブミットというところを自動化しています。
iOSチームにおけるCI/CDの課題
ここからは、これまで利用していた CI/CD サービス BitriseからCycloud-hosted runnerにどのように移行していったかについてお話しします。
まずはこれまで利用していたBitriseの運用とその課題についてです。Bitriseは iOS プロダクトの中で最も利用されている CI/CDサービスの一つだと思います。GUI 操作でオンボーディング不要で簡単にワークフローを構築できるというところが強みにで、Xcodeの迅速なバージョンサポートや、Mac や Xcodeのバージョンをワークフローごとに細かく変更したり試したりできるなど、サポートがとても充実しています。タップルで特に利用していた独自機能としては、アプリを QR コードで配布してSlackに投稿する機能だったり、Webhook を利用したSlackの連携があります。
実際にタップルで利用されているワークフローの一例ですが、下記のようにSlackのワークフローから GUI でブランチ名を入力してサブミットすることで、Bitriseが Webhook 経由で起動してそのままアプリが配布されて、QR コードがSlackに返ってくるフローが実現されていました。
こちらの機能は機能テスト時やテスターの開発時にかなり使われている機能でしたので、GitHub Actions に移行する際にも必ず対応する必要がありました。次にBitrise運用の中で出ていた課題についてお話しします。タップルの iOS チームでは下記3つの課題を持っていました。
KMM導入に伴うコードベースの増加によって、ビルド時間の増加。Bitriseではインテルのスタンダードマシンを利用していたのですが、ビルドに最大40分近くかかってしまうこともあり、運用に困難な点になっていました。また先ほど説明があった価格の高騰の影響を受けた値上げとそれに伴うクレジット管理が難しくなってきていたということ、最後に今年の初めにあったCircleCIのインシデントを受けたセキュリティ面のリスクの部分が課題になっていました。タップルではこういった状況を受けて、専用のマシン台数を確保できるCycloud-hosted runnerの導入を進めていました。
Cycloud-hosted runnerへの移行
次にどのようにCycloud-hosted、MacOSのrunnerに移行していったかというところについてお話しします。Cycloud-hostedrunnerは前述した課題を解決するにもぴったりのソリューションでした。
まず強力なM2のMac miniが選択できることによって、大きなビルド時間の削減が見込まれました。またクレジットや実行時間を削減することなく実行できるというところも体験としてかなり大きかったです。さらに社内IPに閉じた運用が可能になるため、セキュリティリスクを低減できるだけでなく、シークレットを預ける先になるスキャンアカウント管理の対象をBitriseを捨ててGitHubに統一できるという点も大きかったです。導入に関しては前半の発表であったmyshoesのおかげでスムーズに導入することができました。具体的にはGitHub Appのインストールとラベル指定のみで、ほとんど苦労することなく導入することが可能です。またワークフローごとにLinux Mac OSのrunnerを指定してできた点も、モノレポの運用している僕らにとっては大きな理由でした。BitriseからGitHub Actionsへの利用については、キャッシュ機構やスケジューリング、またすでに実行中のワークフローがあった場合のキャンセルなどの基本的な機能についてはあったため、悩むことなく移行可能でした。
中でも工夫した点としては、Bitriseにしかない先ほど紹介した機能の代替案を用意しなければいけないという点と、GitHub Actionsに移行するので、そこを活かして、特徴を活かしたワークフローの最適化というところに挑戦していました。代替案の用意が必要だったのは、以下の2点でした。
アプリのQRコード配布に関しては、以前から一部の用途で利用していたFirebase App DistributionをFastlaneから実行するフローに移行することで解決しました。こちらは以前完全に移行できなかった原因として、アプリそれぞれのURLが取れなかったのでQRコードの生成ができなかったという点があったのですが、昨年そちらが追加されたことによって、アプリごとの個別のダウンロードURLをAPIの返り値として取得して、そこからQRコードを生成できるようになりました。もちろんFastlaneからも記載しているlaneコンテキストによって取得することが可能です。こちらをQRコードとしてSlackに投稿するというところを実現することで、今までと同様の使い心地を実現することができました。
最後にGitHub Actionsならではの機能活用についてです。ここでは、トリガー設定、Dockerイメージの実行、GitHub Actionsの親和性の3点について触れたいと思います。
タップルのようなモノレポプロジェクトに関しては、複数のディレクトリ回想にわたって依存を持っているみたいな場合があると思います。以前のBitriseの構築では、KMMを意図せず変更してしまった結果、iOSのビルドが通らなくなってしまって、別の人が直すみたいなケースが少なくありませんでした。しかしGitHub Actionsでは、柔軟なパスをトリガーに設定できるため、KMMの特定のファイルディレクトリを変更した場合でも、iOSのテストを動かすことができるようになっていました。また、KMM関連のファイルを変更した際に、ビルドは通るんだけど取り込むべきDiff、追加で生成されてしまうDiffがコミットされていない、みたいなことも起きていました。それらの変更が変更された際に、Diffのコミットし忘れをチェックするワークフローを設定することで防ぐことができています。また、Actions自体が一つのイメージ上で実行されているため、公開されているDockerイメージが利用できるという点もかなり大きい部分です。SwiftのメジャーなリンターとしてはSwift Lintが挙げられますが、プルリクのコメントを残すためには、RubyもしくはSwift経由でDangerを入れて、そこからDanger Swift Lintに依存させて、必要ある場合はDanger.jsなんてものも入れて依存解決するみたいな必要があるんですが、それらを公式の提供するDockerイメージを一ステップで動かすことで、速大に実行することが可能で、大きく依存を剥がすことができます。
また、プルリクエストそのものから得ることのできる情報やプルリク自体を操作するといったことも要因できる点も魅力的です。一例として、OSSとして紹介するんですけど、タップルで利用しているXCリザルトツールというものがあります。こちらはプルリクに長いテスト結果のコメントをつけたり、カバレッジのコメントをつけることなく、見やすい表示でプルリクのSummaryタブというところにテストの実行結果、もしくは失敗理由、ビルドの失敗理由なども合わせて表示することができます。
最後に本プロジェクトそのものの評価についても触れたいと思います。移行期間としては、僕が対応したんですが、合計2人月ほどの稼働を行っています。これにはBitriseで利用していたIntel MacからARM環境への移行作業も含まれているため、それがなければもっと早く対応できたと思います。Bitriseでは並列数が無制限だったところから、Cycloud-hosted runnerのMacOSを利用することで、5台しか並列に実行することができないという制限がついたんですが、マシンのスペックアップがあったおかげで、今のところスタックしてテストが詰まっていたりとか困るといったことは報告されていません。そして皆さんが一番気になっているであろうパフォーマンスの部分です。先ほどビルド時間最大40分と言いましたが、平均30分くらいかかっていたワークフローが平均9.5分、最短で6分前後で実行を完了するといったことが実現することができました。
実際にプルリクを立てて10分以内に結果がわかるというところは、長期運用のiOSプロダクトだと実現することが難しいのではないかと個人的には思います。要因としてはやはりマシンスペックによるところが大きいのかなと思っていて、あとはGitCloneがBitriseよりも仕組み上早いというところがあるので、そちらも実行時間に影響をしているかなというふうに個人的に観測しました。ただキャッシュ管理がBitriseより柔軟にできるので、今後KMM関連のキャッシュを今はあまり行っていないのですが、もちろん最適化することでより改善することができる見込みが立っています。
まとめ
ここではCycloud-hosted runnerのタップルOSの活用事例について紹介させていただきました。Cycloud-hosted runnerが提供するMacOSだけでなく、Linuxのマシンも両方使えるという部分が、僕らのKMMを生かしたモノレポ開発というところで利用可能になっていたというところが、とてもありがたい点だったと思います。また、BitriseからGitHub Actionsに移行した部分の工夫について、アプリのQRコード配布に対応したり、Actions自体の機能活用というところに取り組みました。移行後のパフォーマンス向上についても、Bitriseからビルド時間が3分の1程度になり、今後キャッシュを最適化することでさらなる改善見込みがあるというところまでつなげることができました。
皆さんも中規模以上のプロジェクトに関しては、オーダーメイトのセルフホステッドrunnerの導入を通じて、GitHub Actionsを活用していくというところを検討してみてはいかがでしょうか。ご静聴ありがとうございました。