📉

Bitrise Pipelines に移行して、クレジットを節約しながら並列でビルド・テストを回す

treastrain / Tanaka Ryoga2022/11/04に公開

本記事の内容は iOS Test Online(2022年10月24日 開催)の登壇資料(原稿)です。
https://testonline.connpass.com/event/261910/

Bitrise Pipelines とは

弊社では開発プロジェクトの CI・CD として Bitrise を採用しているプロダクト・チームがあります。

Bitrise において、何か物事を実行したいときの最小単位は「ステップ」になります。たとえば、「git clone する」や「xcodebuild をする」といった具合です。

これらの「ステップ」を直列に実行するときには、それらを「ワークフロー」として構成します。

git push だったり、プルリクエストをトリガーとしてビルドを実行したりする際には、この「ワークフロー」単位で実行することになります。このワークフローの実行には「クレジット」を消費します(クレジットの消費量はワークフローを実行するマシンのスペックやその実行時間による)。

2022年7月12日、Bitrise のブログ記事にて Bitrise Pipelines のオープンベータ版が告知されました。

これまでの「ワークフロー」の上に「パイプライン」というレベルが登場し、複数の「ワークフロー」を含めることができます。この複数の「ワークフロー」の実行を「パイプライン」を用いることで、1つのトリガーをきっかけに開始することができるようになりました。

ワークフローを並列に実行する従来の方法

しかし、これまでも1つのトリガーをきっかけに複数の「ワークフロー」の実行を行う方法はありました。

たとえば、いろいろなモジュールのテストを実行するステップが、1つのワークフローで直列に並んでいたとすると、いくつかは並列に実行しても問題ないかもしれません。これができれば実行時間を短縮できる可能性があります。

そんなときは、トリガーを受け付けるワークフローから、さらに「別なワークフロー」の実行を開始するステップを用いることで、ワークフローを並列に実行させることができました(プラン等により同時並行数に制限がある場合あり)。

最後に、テスト結果などを成果物として元のワークフローで受け取り、適宜 Slack に最終結果を通知するなどしてワークフローを終えるイメージです。

2021年10月21日に行われた iOS Test TeaTime #3 ではこのワークフローの並列化について、弊社の Pococha での事例を紹介していました。

Bitrise Pipelines を使ったワークフローの並列実行

では、このワークフローの並列実行を Bitrise Pipelines で行うとどうなるか見てみましょう。

「パイプライン」の中で「ワークフロー」を実行できるため、従来の方法で使っていた「"ワークフロー" を実行するためのワークフロー」が不要になります。

ここまでの説明では省略していましたが、この「パイプライン」の中にある「ワークフロー」はすべて、「パイプライン」の中で構成される「ステージ」に属します。

この「ステージ」は直列で実行されますが、「ステージの中の "ワークフロー"」は並列で実行されます。この図の場合だと、ワークフロー0 が終わった後にワークフロー1・2・3が並列で実行され、それらが全て終わるとワークフロー4が実行されます。

実際に Bitrise でパイプラインを実行すると、ステージごとにワークフローが成功・失敗したかどうか、パイプライン全体として成功・失敗したかどうかを確認できるページが生成されます。

Bitrise Pipelines を活用するために iOS App プロジェクトでできること

従来の方法とパイプラインを使う方法、どちらも同じことが実現可能ですが、従来の方法だと「並列実行したワークフローたちの結果をマージしたい」など後処理を行うステップが残っている場合、待機時間もクレジットを消費していってしまいます。

これをパイプラインを用いる構成にすると、「ワークフローの実行を待っているワークフロー」がなくなり、その役割は「ステージの完了」が担うことになります。クレジットの消費はワークフローの実行にかかっていることから、クレジット消費の節約が見込めます。

またこのイメージのように、ワークフローが並列で実行される状態において、もしどれか1つの実行に、自分たちの変更が原因ではない理由(git clone に失敗した、依存関係解決時のネットワークエラーなど)で失敗し、その失敗の仕方が後続に影響が出るようなワークフローの作り方だった場合、この4つのワークフローすべてをやり直さなければいけないかも… という不安が生じます。

しかし、パイプラインを用いるとステージ内の失敗したワークフローから手動で再実行を行うことができ、その際は続くステージも再実行されます。つまり、無駄なワークフローの実行をしなくて済むため、これもクレジット消費の節約が見込めます。

さて、すでにワークフローで並列してビルド・テストを行う仕組みが整っている場合、これを時間・消費クレジット・再実行の面で Bitrise Pipelines にもっとも適した形にするには、どうすれば良いでしょうか。

まず、はじめのステージでビルドまで行うのが良いでしょう。もしテストに進む前、ビルドの段階で何か問題が起きた時はこのステージまでで実行を止めさせることで、無駄な時間やクレジットの消費を抑えることができるでしょう。

次のステージでテストを並列で実行します。ここでは合計6つのモジュールや環境のテストを、3つのワークフローにまとめて実行しています。これは6つすべて並列に行っても良いですね。

最後にテスト結果のマージを行い、Slack などに通知を送りましょう。ステージは、1つ前のステージが失敗しても実行させる… といったオプションも用意されています。

なお、Bitrise が提供している Pipelines のサンプルでは、Xcode 11 以降で使えるようになった Test Plans を用いた例になっています。

UI テストとユニットテストを並列で行うサンプルや、iPhone・iPad・iPod touch の3つのシミュレータで並列にテストを行うサンプルがあるため、参考になるかと思います。

最後に、早速パイプラインを使ってみよう!と、Bitrise のワークフローの編集画面を開いてみますが、オープンベータである現時点では GUI によるエディターが存在しません。

そのため、bitrise.yml に直接、パイプラインやステージについて書いていくことになります。一応、Bitrise の中の人が作った非公式なビジュアルエディタも存在しており、これを試すのも良いでしょう。

今回の発表で、Bitrise Pipelines がどのようなものなのかについて、簡単に皆さんにお届けできましたら幸いです。

https://testonline.connpass.com/event/261910/

DeNA Engineers

DeNAに所属するエンジニアの個人記事を集めています。 記事内容はあくまでも個人の見解であり、会社としてレビュー等はしておりません。あらかじめご了承ください。

Discussion

ログインするとコメントできます