E2Eテストワークフローを高速化・安定化させる取り組み

E2Eテストワークフローを高速化・安定化させる取り組み GitHub Actions Meetup Tokyo #3 (2024/05/16) サイボウズ株式会社 生産性向上チーム 三村 遼 (@r4mimu)

自己紹介 ▌Ryo Mimura ▌2022年 4月 サイボウズ株式会社 新卒入社 ⚫ 2022年 7月 生産性向上チームジョイン ⚫ 組織横断支援チーム ⚫ 社内向け CI/CD 基盤構築・運用 生産性向上チームについて ⚫ GitHub Actions Self-hosted runner / CircleCI Server ⚫ Four Keys 計測基盤の構築 ▌スライドのリンクを 𝕏 でポストしたので参照ください 𝕏: @r4mimu 2

• https://speakerdeck.com/cybozuinsideout/engineering-productivity-team-recruitment-information
• https://twitter.com/r4mimu

話すこと・話さないこと ▌話すこと ⚫ 弊社の体験入部制度で Garoon リリース改善チームに行ってきた体験談 ⚫ GitHub Actions self-hosted runner 上で実行していた E2E テストを 高速化・安定化させるために取り組んだこと ⚫ E2E テストワークフロー視点の改善アイディア ▌話さないこと ⚫ E2E テスト本体の改善について Garoon リリース改善チーム 3

• https://blog.cybozu.io/entry/garoon-four-keys-growth-team

おことわりと謝辞(?) ▌発表時間の都合上、GitHub Actions の用語を説明無しで話すかもしれません ▌偉そうに話しますが、実際に実装したのは現場の Garoon チームの方々だったり、 生産性向上チームのメンバーのアドバイスのおかげだったりします ⚫ その説はありがとうございました ▌2024年3月当時の状況なのでもっと進化しているかも 4

サイボウズ Garoon ▌大規模組織向けグループウェア ⚫ スケジュール共有、メーラー、掲示板的な機能など仕事で必要なアプリケーションが ワンパッケージにまとまっているグループウェア ⚫ 2002 年リリース(!) ⚫ 22 歳なので今年の新卒みたいな感じ ⚫ リリース当時はパッケージ版のみ提供 ⚫ 現在はパッケージ版・クラウド版のどちらも提供 ⚫ 大規模、ご長寿なプロダクトなので技術的課題がたくさん 5

• https://garoon.cybozu.co.jp/

Garoon の E2E テスト ▌GitHub Actions self-hosted runner 上で実行 ⚫ terraform-aws-github-runner という OSS を利用してAWS EC2 にランナーを作成 ⚫ ジョブごとに使い捨てできてオートスケールする self-hosted runner 基盤 ▌本発表ではEC2 上で self-hosted runner を動かしていると覚えておけば OK ▌生産性向上チームが構築する Self-hosted runner 基盤については↓ 6

• https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
• https://github.com/philips-labs/terraform-aws-github-runner

E2E テストワークフローのツラみ(みんなの声) ▌ワークフローの実行時間 ⚫ 基本的に30分以上はかかる ⚫ そのうえ、30分で終わったり1時間以上かかったり予測・見積もりができない ▌ワークフローが Flaky ⚫ アプリケーション・テストコードに変更がないのにもかかわらず成功したり失敗したりする ➔ 実行時間 と 失敗率 の2つの観点のツラミ 7

ツラ E2E テストワークフローをどこから改善するか ▌実行時間のボトルネックを計測 ⚫ Kesin11/actions-timeline でワークフロー内のジョブの所要時間を可視化 ⚫ 予想通り E2E テストの実行がボトルネック Kesin11/actions-timeline の README より引用 8

• https://github.com/Kesin11/actions-timeline?tab=readme-ov-file

ツラ E2E テストワークフローをどこから改善するか ▌失敗のボトルネックを計測 ⚫ 拙作 workflow-stats でジョブ、ステップの成功率を計測 ⚫ E2E テストだけでなく、セットアップ系のステップでも失敗率が高いと判明 workflow-stats の README より引用 9

• https://github.com/fchimpan/gh-workflow-stats

ツラ E2E テストワークフローをどこから改善するか ▌実行時間 ⚫ E2E テストの実行時間が支配的なので E2E テストの改善優先度は高い ▌失敗率 ⚫ セットアップ系のジョブ ⚫ Service Container の立ち上げ ⚫ npm install ⚫ もちろん E2E テスト自体も Flaky で失敗しがち 10

テスト実行環境の不安定さ(Service Container編) ▌E2E テストのために Selenium を Service Container で起動 ⚫ Selenium のイメージは Docker Hub から pull ▌Service Container が Pull rate limit error になる ⚫ Docker login で認証しており 5000 pulls/day にも達していない ⚫ E2E テストでは大量に並列でジョブを実行するので分間あたりのリクエストで rate limit になっている？ 11

• https://docs.github.com/en/actions/using-containerized-services/about-service-containers
• https://www.docker.com/ja-jp/increase-rate-limits/
• https://matsuand.github.io/docs.docker.jp.onthefly/docker-hub/download-rate-limit/

テスト実行環境の不安定さ(Service Container編)：対策 ▌コンテナレジストリを Docker Hub から Amazon ECR に移行 ⚫ Docker Hub の Pull rate limit を回避 ⚫ Service Container 起動において Pull rate limit で失敗することはなくなった ⚫ さらに ECR Pull Through Cache を設定 ⚫ Service Container 起動ジョブが約 50s -> 25s へ ⚫ ランナーが同リージョンの EC2 上で動いているのも相まり高速化 ▌2024年2月に actions/runner の Docker pull にリトライ処理が実装されたので、 現在でも再現するかは不明 12

• https://github.com/actions/runner
• https://github.com/actions/runner/pull/3089

テスト実行環境の不安定さ(npm install編) ▌npm install が失敗する ⚫ npm ERR! code ERR_SOCKET_TIMEOUT ▌一時的なネットワークの不安定さが原因であり、対策を打つのは難しい？ ▌適切にキャッシュが効いていれば、ネットワークエラーを緩和できるのでは？と仮定 ▌リポジトリのキャッシュを確認すると最大容量である 10GB を上回っている ⚫ 10GB を上回ると GitHub によりキャッシュが削除される ⚫ キャッシュが削除されているせいで無駄に依存関係ダウンロードの機会も増えている 13

テスト実行環境の不安定さ(npm install編)：対策 ▌キャッシュ容量が溢れないようにし、キャッシュヒットを安定化させる ▌GitHub Actions のキャッシュにはスコープ制限が存在 ⚫Default branch、Base branch 以外のキャッシュにはアクセスできない ▌Feature branch でキャッシュ save するのは容量がもったいない ⚫Feature branch ではキャッシュの restore のみ、main branch ではキャッシュの save もする ⚫ actions/cache/save@v4 と actions/cache/restore@v4 ▌キャッシュヒットが安定し、npm install の安定化 & 高速化 14

• https://github.com/actions/cache/tree/main/save
• https://github.com/actions/cache/tree/main/restore

テストが Flaky ▌Flaky なテスト ⚫ 失敗したら手動再実行 ▌待ち時間が長い ⚫ テストにかかる時間にブレもある ▌E2E テストの面倒をみているのは別チーム ⚫ Flaky テストを解決することはスコープ外 ⚫ Flaky であることは受け入れて、その上でいかにして CI 体験を良くするか 15

テストが Flaky：改善(ワークフローのタイムアウト編) ▌経験則的に E2E テストジョブが成功するときは30分前後でジョブが完了 ⚫ E2E テストジョブに timeout-minutes を設定 ⚫ 40分以上ジョブが実行されていたら強制タイムアウトでさっさと終わらせて、 次のテストを実行したほうが効率が良い 16

テストが Flaky：改善(ワークフローの自動リトライ編) ▌ワークフローの自動リトライをするワークフローを作成 ⚫ E2E test のワークフロー終了時にテスト成否をチェックし、失敗していたら再実行 E2E テストワークフローの実行終了で トリガーされる 次ページの steps に続く ↵ 17

テストが Flaky：改善(ワークフローの自動リトライ編) ▌ワークフローの自動リトライをするワークフローを作成 ⚫ E2E test のワークフロー終了時にテスト成否をチェックし、失敗していたら再実行 3回のリトライまでは自動実行 18

テストが Flaky：改善(ワークフローの自動リトライ編) ▌ワークフローの自動リトライ ⚫ GitHub Apps Token を用いて gh cli で失敗したジョブを再実行 GITHUB_TOKEN ではワークフローを トリガー出来ないのでトークン生成 19

テストが Flaky：改善(ワークフローの自動リトライ編) ▌ワークフローの自動リトライ ⚫ GitHub Apps Token を用いて gh cli で失敗したジョブを再実行 gh cli でジョブ再実行 20

テスト時間かかりすぎ ▌テスト終了には 30 分以上を要する ▌前述の通り、テスト失敗で自動でテストが再実行される ▌自動で再実行はいいけど、毎回 30 分以上待つのはツライ 21

テスト時間かかりすぎ：対策 ▌失敗したテストケースだけ再実行 ⚫ E2E テストが失敗したらテスト結果を Amazon S3 にアップロード ⚫ 再実行時には S3 から前回のテスト結果をダウンロードし 失敗しているケースだけ実行 ▌並列数を上げる ⚫ おなじみ matrix strategy ⚫ マシンスペックは上げてもそこまで効果は無かったので据え置き ➔ ある実行例：26min -> 12min -> 7min(Success) 22

まとめ ▌E2E テストの安定化・高速化のために以下の取り組みをした ⚫ 実行時間・成功率のボトルネック洗い出し ⚫ Service Container の Rate limit 対策 ⚫ キャッシュの save タイミングの見直し ⚫ Flaky テストのリトライ ⚫ ジョブ並列化とテスト再実行を見直して高速化 23

宣伝 ▌Software Design 2024年7月号(6月18日発売)にて、 サイボウズ生産性向上チームで GitHub Actions 特集を執筆したので何卒 ▌開発生産性 Conference 2024 にて、 Four Keys計測基盤の構築と活用に向けた取り組みを話すので何卒 ▌ほぼ毎週、開発生産性にまつわる技術やニュースを取り上げている Productivity Weekly を Zenn で連載しているので何卒 Productivity Weekly 24

• https://dev-productivity-con.findy-code.io/2024?m=2024/m/DWSW2sZD
• https://zenn.dev/p/cybozu_ept