見出し画像

Bitriseで複数のWorkflowを並列実行できるようにしてみた!

SHOWROOM Blog

Bitriseで複数のWorkflowを1つのトリガーで動かすようにする！

SHOWROOMのiOSアプリを開発しているエンジニアの杉山です！
SHOWROOMのiOSアプリではCIサービスにBitriseを使用しています。
現在はPRのレビューを行う前に、PRの作成をトリガーに以下のチェック・処理を実行しています。

  1. SHOWROOMのアプリモジュールのUnitTestの実行

  2.  1. 以外のモジュールのUnitTestの実行

  3. 動作確認や社内検証用のInHouseのipaをDeployGateにアップロード

上記の処理がBitriseで①PRを作成した時、②PR作成後はCommitをPushするたびに実行されます。
しかしキャッシュがありの状態でも30~40分かかっていたので、PR作成やレビュー内容の修正→レビュアーによるレビューのサイクルを回すのに時間がかかってしまうという課題がありました。
基本的には1つのトリガーで1つのWorkflowしか実行できないのですが、上記の1~3を並列に実行できないかな？🤔と思って、その設定方法を調べてみました！

1つのトリガーで複数のWorkflowを実行する方法

1つのトリガーで複数のWorkflowを実行するには、build-router-startというステップを利用します。
以下にリポジトリで管理しているbitrise.ymlに記載しているこのステップの設定を抜粋して記載しました。

- build-router-start@0:
  inputs:
  - access_token: "$BITRISE_PERSONAL_ACCESS_TOKEN"
  - abort_on_fail: 'yes' # 実行するWorkflowが失敗したら、failにする
  - workflows: |-
    testShowRoom
    testModules
    inHouse
- build-router-wait@0:
  inputs:
  - access_token: "$BITRISE_PERSONAL_ACCESS_TOKEN"

必要な設定は2つです。

  1. BitriseのPersonal Access Token(access_token)

  2. 実行するWorkflowの名前(workflows)

1. BitriseのPersonal Access Token(access_token)

Personal Access Tokenは Bitriseのユーザーのアカウント設定のセキュリティーの画面から追加することができます。

生成したTokenはWorkflowEditorのSecretsに BITRISE_PERSONAL_ACCESS_TOKENという名前で登録しています。
ここでの注意点は、このSecretsをPR作成トリガーで実行するWorkflowで使用する場合、Expose for Pull Requests?を有効にしないと、このTokenをWorkflow実行中に参照できないため、このbuild-router-startのステップは失敗してしまいます。

(この設定に気づかず、PR作成時のテスト実行で毎回エラーになってしまい、解消するまでにだいぶ時間を溶かしました。。。)
この設定は、セキュリティー的にこの設定は有効にしないほうがいいという意見も調べたら出てきましたが、SHOWROOMのレポジトリはPrivateになっているので、社内のメンバーで話し合って、この点は問題ないという結論になりました。

2.実行するWorkflowの名前(workflows)

Workflowの名前には、文字通り並列実行したいBitriseのWorkflowを設定します。
今回は冒頭で記載した3つのWorkflowを実行するように設定しています。

build-router-waitの設定

上記のbuild-router-startのステップの設定が終わったら次に、build-router-waitのステップを追加しましょう。
これを設定することで、build-router-startの実行が完了するまで、次のステップに進まないように待機させることができます。
build-router-start同様に、Tokenの設定が必要です。

並列実行のWorkflowをトリガーから呼び出せるように設定する

ここまで設定できたら、並列実行するWorkflowをPR作成などをトリガーに実行できるようにします。
SHOWROOMのiOSアプリでは、bitrise.ymlのWorkflowの内容は、Git管理しており、トリガーマップはBitrise.ioで管理しています(トリガーマップをBitrise.ioで管理している理由はこちらを参照)。

workflows:
  runParallelTest:
    steps:
    - build-router-start@0:
        ・・・・
    - build-router-wait@0:
        ・・・・

上記のように設定したWorkflow runParallelTestを以下のようにBitrise.io上のトリガーマップに設定します。

trigger_map:
- pull_request_source_branch: "*"
  workflow: runParallelTest

上記の設定の場合、全てのブランチでPRを作成したら、そのたびにrunParallelTestのWorkflowが実行され、そこで設定済みの各Workflowが並列に実行されます。
以下のキャプチャは実際に実行した時のBitriseのビルド履歴のキャプチャですが、runParallelTest実行後に、並列実行している各Workflowが実行されているのがわかります。

並列ビルドのメリット・デメリット

次に実際に実装や検証してみて感じたメリット・デメリットをまとめます。

○ メリット

  • 直列で実行するときよりも実行時間は短くなる

    • 並列実行するWorkflowやテストの実行数などにもよりますが、検証時は10~15%ほど早くなりました。

× デメリット

  • 直列で実行するよりも、消費クレジット数が多い(総実行時間が長い)

    • 直列で実行する場合は、リポジトリのcloneは1回で済みますが、並列実行する場合は、Workflowの数だけcloneする必要があり、直列実行の時に共通で実行できていた処理も、Workflowの数だけ実行時間が増えます。

    • ビルド一覧を見ればわかりますが、並列実行している間も、build-router-startのWorkflowは実行扱いになっているため、その実行にもクレジットを消費します。

  • 設定方法や運用には時間やコストがかかる

    • Tokenを発行したり、設定後の動作確認するにも時間や工数がかかり、さらに実装した方法を開発者全体へ周知も必要になります。

まとめ

今回はBitriseで並列ビルドを実行する方法についてまとめてみました。
実際ビルド時間は短縮できましたが、運用や保守コストと、実際に消費するクレジットの量が増えるなどのデメリットもあるので、しばらく実際に動かしてみて、メリット・デメリットを比較し、どのように運用するかは決定したいと思います。

参考

SHOWROOM株式会社では、エンジニア職を絶賛募集中です。
・ライブ配信サービス「SHOWROOM」
・バーティカルシアターアプリ「smash.」

以下の求人内容をご確認の上、ご興味あればご応募ください。
心よりご応募お待ちしております。

■求人は以下になります
SHOWROOM株式会社採用情報
■その他SHOWROOM株式会社の情報
・ note（代表前田取材記事です！）
・ 社員インタビュー記事
・ SHOWROOM
・ smash.
・ SHOWROOM最新記事一覧（PRTimes）

いいなと思ったら応援しよう！