---
title: E2Eテストワークフローを高速化・安定化させる取り組み
tags: 
author: [Ryo Mimura](https://www.docswell.com/user/r4mimu)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/8EDYG8MKEG.jpg?width=480
description: GitHub Actions Meetup Tokyo #3 https://gaugt.connpass.com/event/317178/  このプレゼンテーションでは、サイボウズ社のGaroonのE2Eテストについて、GitHub Actions self-hosted runner 上で実行していたE2Eテストを高速化・安定化させるために取り組んだこと、E2Eテストワークフローの視点の改善アイディアについて話されます。GaroonのE2Eテストにおける実行時間とFlakyが問題となっており、その改善に取り組んだ内容が紹介されています。  おすすめタグ：GitHub Actions,E2Eテスト,self-hosted runner,Garoon,テストワークフロー
published: May 16, 24
canonical: https://www.docswell.com/s/r4mimu/ZXYR73-2024-05-16-184345
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/8EDYG8MKEG.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/V7P638R3J8.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/2JV34NRNEQ.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/5EG31KM57L.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JQ5DNRL7P.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/K749ZG85E1.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LJ1KRD227G.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJWD1YR272.jpg)

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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4EZGPXR4J3.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/Y76YM4RGEV.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/G75GZQ8X74.jpg)

テスト実行環境の不安定さ(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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/9J2YRPKQJR.jpg)

テスト実行環境の不安定さ(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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/DEYGD5NYEM.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/VJNG6NXR78.jpg)

テスト実行環境の不安定さ(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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/YE9WLR8ZE3.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GE8NXWZY7D.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LELP8ND97R.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/4JM46XPV7W.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/PJRWPN1W79.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/PEXP3NYV7X.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/3EKDYN35JD.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/L73R9VG1J5.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/87DYG81K7G.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/VJP638Q3E8.jpg)

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