BitriseのBuild Pipelines機能を使って、並列ビルドを実行する
SHOWROOMのiOSアプリを開発しているエンジニアの杉山です！
以前ブログでBitriseで複数のWorkflowを並列実行できるようにしてみた!という記事を書きましたが、ちょうどその記事を書いた後に、BitriseのBuild Pipelines: efficient CI/CD workflows with parallelizationという記事を見つけました。
見てみると、このBuild Pipelinesを使った方がbuild-router-startの機能を使用するよりも、実装しやすく、かつ使用クレジット数も抑えられそうだったので、執筆時はbeta機能ですが、試しに使ってみました！
Build Pipelinesの仕組みを知る
この記事を見ると、Build Pipelinesは単に複数のWorkflowを並列に実行するだけでなく、1つのトリガーから複数のWorkflowを体形的に実行する機能のようです。
具体的には記事の画像に記載されているように、
アプリをビルドする
1.でビルドしたアプリで複数のSimulatorで並列にテストを実行する
アプリをデプロイする
というように、Workflow、もしくは並列実行するWorkflowを1つの単位として、それらを直列に実行することもできます。
この単位をBuild Pipelinesでは、Stepと呼び、複数のStepをまとめたタスク全体をPipelineと呼んでいます。
Bitrise.io上でも上記のように各Stepの実行結果や順番、時間、使用クレジット数がわかりやすく確認できるようになったのも嬉しい改善です！
もちろんこの各ステップのいずれかのWorkflowが失敗した場合、後続のStepが実行されないようにすることもできます。
特定のWorkflowで失敗した場合、以下のキャプチャのように表示されます。
また実行を失敗したPipelineを再実行する場合、以下のキャプチャのように、
①失敗したWorkflowからやり直す
②Pipeline全体のWorkflowを全て実行し直す
の2つを選ぶことができ、①を実行することで、かかる時間とクレジット数を節約することができます
SHOWROOMのiOSアプリにBuild Pipelinesを組み込んでみる！
Pipelineの構成
以前の記事に記載した通り、SHOWROOMのiOSアプリではPR作成後に以下のタスクをBitriseで実行しています。
SHOWROOMのアプリモジュールのUnitTestの実行
1.以外のモジュールのUnitTestの実行
動作確認や社内検証用のInHouseのipaをDeployGateにアップロード
上記を踏まえて、今回は以下のようなStageを持つPipeline develop_pipelineを作ってみました。
GitHubのPRにBitriseのビルドステータスを連携(GitHub Status)
テストの並列実行
SHOWROOMのアプリモジュールのUnitTestの実行
1.以外のモジュールのUnitTestの実行
dangerを実行(Slackでレビュアーへのレビュー依頼通知などを実行)
GitHubのPRにBitriseのビルドステータスを連携(Pipelineの実行結果をPRに反映)
動作確認や社内検証用のInHouseのipaをDeployGateにアップロード
この修正以前は、2-1のWorkflowでdangerを実行していましたが、それだと2-2のWorkflowで失敗した場合でも、レビュアーにレビュー通知が飛んでしまうという課題がありました。
そこでdangerの処理を1つのStepに切り出し、2のStepのテストが確実に完了してから、3のStep、つまりdangerによるレビュー通知が飛ばないようにしました。
また今回はテスト→レビューまで最速で実行できることを優先し、時間がかかるInHouseのビルドを1番最後に実行し、その前にテスト実行→PRレビュー依頼が完了するような構成にしています。
Pipelineの実装
次にPipelineの実装です。
実装の手順は以下の通りです。
①レポジトリのbitrise.ymlの修正
②Bitrise.io上のbitrise.ymlの修正
①については、bitrise.ymlに以下のようにPipelineとStageの定義を追加します。
Workflowの書き方については、今まで通りです！
pipelines:
develop_pipeline:
stages:
- github-status: {}
- runParallelTest: {}
- run-danger: {}
- github-status: {}
- deployInHouse: {}
stages:
github-status:
workflows:
- github-status: {}
run-danger:
workflows:
- run-danger: {}
runParallelTest:
workflows:
- testShowRoom: {}
- testModules: {}
deployInHouse:
workflows:
- InHouse: {}また記事のサンプルにもあった通り、一番上に記載されているフォーマットのバージョンも11に変更しました。
format_version: '11'②についても同様に、上記のPipelineとStageの定義を追加します。
Pipelineを実行できるようにする
実装や設定が完了したら、実際に動かしてみましょう！
Bitrise.io上で手動実行する場合は、Start/Scheduleのメニューをクリックすると、元々Workflowを選択する画面から、設定したPipelineを実行できるようになっています。
PRの作成やPushをトリガーに、Pipelineを実行したい場合も、今まで同様、Triggersの画面から設定したPipelineを選択できるようになっています。
実行するとビルド一覧に Pipeline名(pipeline)という形で表示されます。
なお今まで通り単独のWorkflowを実行した場合、Workflow名(standalone)と表示されます。
Build Pipelines機能のまとめ
今回出たばかりのBuild Pipelinesの機能を触ってみました。
現状beta版ですが、今のところ目立った不具合もなさそうで、とても便利な機能でした。
自分の感じた、主にbuild-router-startの機能と比べた場合の改善点は以下の通りです。
消費クレジットが少なくなった！
build-router-startのような並列ビルドを管理するWorkflowがなくなったので、その分使用クレジット数が少なくて済む。
途中で実行失敗したPipelineを実行しなおす場合、途中の失敗したPipelineから実行することができる。
実装や設定がしやすい
Pipeline, Stage, Workflowという単位に分かれているため、各Workflowを柔軟に直列・並列で実行させることができる。
基本bitrise.ymlの書き換えだけで済む。
bitrise.ymlもPipeline, Stage, Workflowが階層で記述できるので、見やすい、書きやすい！
Personal Access Tokenなどの設定が不要
Bitrise.ioのUIが見やすい
Pipelineの進捗や結果が見やすい
ビルド一覧で実行中のWorkflowが全て表示されるわけではないので、ビルド一覧が見やすくなる。
自分が最初並列ビルドをやろうとした時に実現したかったことや期待した機能が用意されていて、beta版でも十分に使える機能だと思いました！
今後は各Stepの構成を試行錯誤したり、テストの実行時間を削減することで、実行時間や使用クレジットの削減を目指していきたいと思います！
参考
SHOWROOM株式会社では、エンジニア職を絶賛募集中です。
・ライブ配信サービス「SHOWROOM」
・バーティカルシアターアプリ「smash.」
以下の求人内容をご確認の上、ご興味あればご応募ください。
心よりご応募お待ちしております。
■求人は以下になります
SHOWROOM株式会社採用情報
■その他SHOWROOM株式会社の情報
・ note（代表前田取材記事です！）
・ 社員インタビュー記事
・ SHOWROOM
・ smash.
・ SHOWROOM最新記事一覧（PRTimes）