BitriseのCredits-Basedな 新プランの利用と改善

「【GMOペパボ x hey】iOS Meetup」にて使用した登壇資料です。
同僚が主にで進めてくれたプロジェクトを、ノウハウの共有やサポートを行う形で関わっていたk-koheyがまとめて発表しました。

Transcript

1. 　　 ©hey, Inc BitriseのCredits-Basedな 新プランの利用と改善 　　　github : k-kohey twitter: k_koheyi あれBitriseでビルドすると何かが減っていくよ？！
2. 背景と目的 • 弊社のBitriseの契約プランがCredits-Basedなプランとなりました ◦ 従来の並列に実行可能なビルド数に基づくプランは Concurrency-basedなプランと呼ばれます • 今回の発表では新プランを移行して得たメリットと 弊チームが新プランに適応するために行った改善を紹介します🙌
3. BitriseのCredit-Basedなプランについて
4. Credit−BasedなTeamプラン ｜概要 • 特徴（*1） ◦ Gen2と呼ばれる高速なマシンを利用できる ◦ 最大10個のMacOSで同時にビルドできる ◦ ビルドのタイムアウト時間が大幅に向上 ▪ 45（90）分から4時間に ◦ ビルドするためにはCreditの消費が必要 ▪ 標準的なスペックでは2credits/minを消費する ▪ さらに高いCreditsを消費することによってスペックの高いマシンを選択することも可能 • 2021/8からの新規ユーザはCredit-Basedなプランのみ選択できる状態（*２） （*1）https://blog.bitrise.io/post/faster-more-flexible-plans-on-bitrise-introducing-teams （*2）https://devcenter.bitrise.io/en/comparing-credit-based-and-concurrency-based-plans.html#:~:text=As%20of%20August%202021%2C%20you,depending%20on%20your%20subscription%20plan.
5. Credit−BasedなTeamプラン｜従来のConcurrency-basedプランとの比較 • Gen2と呼ばれる高速なマシンを利用できる ◦ 従来のマシンと比較してビルド時間が短くなる ▪ 弊社プロダクトではテスト開始から完了までの時間が半分程度になった • ビルドするためにはCreditの消費が必要 ◦ 従来のプランと同じ感覚でビルドを回すと不必要にCreditsを消費し お金を無駄にしてしまう可能性がある GOOD BAD
6. Credit−BasedなTeamプラン｜従来のConcurrency-basedプランとの比較 • Gen2と呼ばれる高速なマシンを利用できる ◦ 従来のマシンと比較してビルド時間が短くなる ▪ 弊社プロダクトではテスト開始から完了までの時間が半分程度になった • ビルドするためにはCreditの消費が必要 ◦ 従来のプランと同じ感覚でビルドを回すと不必要にCreditsを消費し お金を無駄にしてしまう可能性がある GOOD BAD Bitriseにおけるビルドの 実行時間の改善ニーズ 🆙🆙🆙🆙🆙
7. Creditsの消費量を示す メータがなるべく 振り切れないように ビルド時間の改善を行い ました • 期間：２週間程度 • 人数：１人（たまに２人）
8. 行った改善
9. 下準備①｜ワークフローの整理 • ワークフローの整理から始めた ◦ 各ワークフローのビルド時間 ◦ 各ワークフローのトリガー 例） • 整理した情報はボトルネックの特定に利用 ◦ 時間が顕著にかかっているビルドの特定 ◦ 不必要に実行されているビルドの特定
10. 下準備②｜bitrise.yml（＊） の導入 • 概要 ◦ bitriseのワークフローやスタックの設定をyml形式にて記述したもの ◦ リポジトリにymlを配置すると設定が反映される • メリット ◦ bitriseに対して行った変更をGit管理に含めることができるため今後の変更に伴う事 故を防げる ◦ 各Branch毎に別の設定を適応できる （＊）https://devcenter.bitrise.io/en/references/basics-of-bitrise-yml.html#basics-of-bitrise-yml
11. 不要なワークフローの実行を削除 • ワークフローのスケジュールやトリガーの設定を見直し、 必要ないものは消去、あるいは実行頻度を下げた • 変更例 ◦ 時間がかかるUIテスト（60分以上）の実行頻度を下げる ◦ pushするたびに実行されているワークフローをpull requestにて実行される ワークフローと結合して実行頻度を下げる • 技術的な挑戦は無いがワークフローの実行時間が丸ごと減るので 大きな改善に繋がった
12. Build Phaseのスクリプトを調整 • 背景 ◦ Build Phaseにて実行しているSwiftLintやSwiftFormatのスクリプトに 次のような問題があった ▪ 実行しなくていいタイミング（CI上）で実行されていた ▪ SwiftLintでは実行対象に含めなくていいソースファイル（差分が無いファイル） も対象となっていた • SwiftFormatは差分検知の仕組みがあり、この点は問題なかった
13. Build Phaseのスクリプトを調整 • 方法 ◦ gitのdiffがあるときだけdiff のあるソースファイルに対し てコマンドを実行するように スクリプトを変更 • 結果 ◦ CI上において毎ビルドそれぞ れ1~2分かかっていた処理が ０秒で終わるように改善 下記issue内にあるスクリプトに修正をくわえたもの コマンドの実行回数が最小になるように修正してある https://github.com/realm/SwiftLint/issues/413
14. 外部のアプリケーションの終了を待っていたワークフローの改善 • 背景 ◦ 外部のテスティングサービスを使用しており、Bitriseのワークフローから そのサービスへテスト対象のアプリのデプロイとテスト結果のSlack通知を行っていた アプリの ビルド アプリの デプロイ テストの 実行 Slack 通知 終了 ワークフロー テスティングサービス
15. 外部のアプリケーションの終了を待っていたワークフローの改善 • 問題 ◦ テスティングサービスの結果を待つ時間が５０分ほどあった ◦ 従来のプランは従量課金制では無かったので問題にならなかったが、 Credit-Basedなプランではこの待機時間が問題に アプリの ビルド アプリの デプロイ テストの 実行 Slack 通知 終了 ワークフロー テスティングサービス
16. 外部のアプリケーションの終了を待っていたワークフローの改善 • 方法 ◦ アプリのデプロイを終えたら即ワークフローを終了するように変更 ◦ テスト結果はサービスから送られてくるテスト結果通知メールをhookして Slackに流すようにした • 結果 ◦ 無駄になっていた50分ほどの時間を節約できた アプリの ビルド アプリの デプロイ 終了 ワークフロー
17. cacheの利用｜仕組み - bitriseではcacheのpushとpullを行う処理（step）が簡単に使えるように 用意されている - このstepをワークフローに組み込むことによって、 任意のディレクトリを同じbranchで実行される別のワークフローでも 使用できるようになる - branchに紐づくcacheが存在しない場合は、bitriseに設定した default branchのcacheが使用される - cacheを利用すると依存関係をcloneしcheckoutする時間や ビルドする時間を省略でき、ビルド時間が低減すると考えられる 詳細：https://devcenter.bitrise.io/en/builds/caching.html
18. cacheの利用｜RubyGemsのcache - 背景 - fastlaneやdangerをgemとして導入している - 仮説 - gemがinstallされているディレクトリをcacheするように 設定するとGemの依存解決処理を省略できるはず
19. cacheの利用｜RubyGemsのcache - 方法 - gemがインストールされるディレクトリのパス をcache push stepにて指定 - pushのトリガーを設定できるため、 Gemfile.lockの変更をトリガーに指定 - cache pull stepを追加 - 結果 - RubyGemsの依存が少なかったこともあり cacheのpushおよびpullのオーバーヘッドの方 が大きくなり改善に繋がらなかった - 見積もりが甘く反省する結果となった （＊）https://devcenter.bitrise.io/en/builds/caching/caching-ruby-gems.html 公式ドキュメント（＊）にも方法が記載されている
20. cacheの利用｜Swift Pakcage Manager（SPM）のcache - 背景 - ProjectやCommand Line ToolにSPMを利用している - Project：FirebaseやOHHTTPStubなど - Command Line Tool：SwiftLintやSwiftFormatなど - Projectの依存関係とは分けて管理 - 仮説 - Swift Packageされているディレクトリをcacheするように設定すると Swift Packageのソースコードをcloneしてくる時間を省略できるはず
21. cacheの利用｜Swift Pakcage Manager（SPM）のcache - 方法 - Swift Packageのソースコードがcloneされる場所を確認 - Projectの依存の場合はDerivedDataに入る（*） - xcodebuildコマンドのcloned_source_packages_pathオプションで変更可能 - Package.swiftで解決する依存の場合はPackage.swiftと同じ ディレクトリに存在する.build/の中に入っている（自分調べ。例外あるかも。） - Ruby Gemsと同じ要領でPackage.resolveの変更をhookして ソースコードがcloneされるパスをcacheとしてpushする - 結果 - 期待通り１分と少しほどかかっていたソースコードのcloneを省略することができた - ビルド済みバイナリはcacheしてないのでさらなる改善にはCarthargeの導入が必要か？ （*）https://asmz.hatenablog.jp/entry/cache-swift-package-manager-on-bitrise
22. 結果 - 新しいプランを利用しさらに改善を加えることで 特定のワークフローのビルド時間を５割ほど削減できた - 今まで40~50分ほどかかっていたPull RequestのPushによってトリガー されるワークフローが20分前後に - Gen2が大きく削ってくれた - Pull Requestに紐づくビルドがすぐ終わるのは開発体験的な観点でもいい - ワークフローの実行頻度や実行の有無も調節したため、 特定のワークフローに限らず全体のビルド時間も軽減されている
23. おわりに • Gen2を利用するとビルド時間を大幅に減らすことができる • 従量課金になったことにより今まで気にしてなかったようなワークフロー のビルド時間も改善の必要性がでてくる • ビルド時間が短くなるとPull Requestのレビューリクエストを送る 待ち時間が減ってコスト削減以外の効果も感じた • 今後もビルドパフォーマンスの改善など引き続き改善を進めていきます ヘイ株式会社 k-kohey BitriseのCredit-Baseな 新プランの利用と改善 あれBitriseでビルドすると何かが減っていくよ？！