オオカミ少年な CI をなんとかする話

layerx.go #6

Transcript

1. オオカミ少年な CI をなんとかする話 2026-11-09 layerx.go #6 shibutani / @s_k_526
2. whoami shibutani / @s_k_526 株式会社 LayerX Platform Engineering 部 Enabling チーム 2025 年新卒入社 最近は、自分だけの便利ツールをふんだんに盛り 込んだアプリ盆栽にハマっています © LayerX Inc.
3. 今日の話 今日の話: Go の flaky test を自動で隔離、修正する仕組み 検知 隔離 → → 可視化 → AI による修正 の出力で flaky test を検知し、自動で隔離 隔離による品質低下を防ぎつつ継続運用のために、可視化と AI による修正に注力 go test -json © LayerX Inc. 3
4. 課題 課題: flaky testが増加 flaky: コードを変えていないのに、通ったり落ちたりするテスト テストが落ちるたびに「また flaky だろう」と再実行ボタンを押す 本当にコードが壊れてテストが落ちたときも、欠陥を見逃しやすくなる CI が落ちても信じてもらえない = オオカミ少年な CI © LayerX Inc. 4
5. 最初の試み（2026-03 〜 06） 最初の試み: AI が修正と隔離するPR を作り、チームがレビューする flaky を検知 CI で判定 → 隔離 PR テストを skip する 修正 PR → チームがレビュー テストの原因を直す CODEOWNERS から レビューを依頼 → マージ PR は 2 本とも Claude が作る あとはチームがマージしてくれる、はずだった © LayerX Inc. 5
6. 最初の試み（2026-03 〜 06） ほとんどマージされなかった 2 / 112 本 マージされた隔離 PR 2 / 63 本 マージされた修正 PR 残りの PR はほとんど触られず、レビューされないまま開き続けた（閉じるまでの中央 値 62 日） 7 月と 8 月に残りをまとめて閉じ、レビューに頼る形をやめた © LayerX Inc. 6
7. 学び 人の手を待つ工程は止まる flaky の修正は、多くのチームにとって、機能開発の横の仕事。優先度が上がらない レビューを頼むと後回しになり、数が増えるほど見られなくなる そこで、可能な限り人間の介入を不要とする仕組みへ 最初の試み 今 © LayerX Inc. 検知 検知 → PR 2 本 → automerge で隔離 → → レビュー待ちで止まる 台帳と週次通知 → AI が直す 7
8. 1 | 検知: もう 1 回実行して通れば flaky 検知 → 隔離 → 可視化 → 修正
9. 1 | 検知 落ちたテストだけもう 1 回実行し、通れば flaky 1 回目 go test -json で全部流す → 失敗を集める Action が fail の Test → 2 回目 -run '^(TestA|TestB)$' で落ちたものだけ 通れば flaky CI は成功 → 落ちれば本物 CI は失敗 Go 自体に flaky の判定機能は無い。 go test -json の出力を使って自前で判定する © LayerX Inc. 9
10. 1 | 検知 判定の中身はこれだけ: 落ちたテストを集める は、1 行 1 イベントの JSON を出す。 このイベントを順に読み、 があって が 取り出したテスト名を に、package を go test -json Test failedTests © LayerX Inc. Action Test fail pkgs がテスト名、 が結果 の行を取り出す（ が無い行は package の結果） に追加していく Action Test ref: https://pkg.go.dev/cmd/test2json 10
11. 1 | 検知 判定の中身はこれだけ: 落ちたテストをもう 1 回実行する テスト名を でつないで という正規表現を作り、 に渡す。これで落ちたテストだけが走る 2 回目も で実行し、出力のイベントを 1 回目と同じように読む が のテストが flaky。また になったテストは本物の失敗として CI を落とす | ^(TestA|TestB)$ -run -json Action © LayerX Inc. pass fail 元にした実装: https://github.com/tailscale/tailscale/tree/main/cmd/testwrapper 11
12. 1 | 検知 ちなみに: Vitest は retry で flaky を判定してくれる で、落ちたテストを Vitest が 1 回再実行する retry で通ると diagnostic().flaky が true になる。これを自作の reporter で集める 集めた結果は Go と同じ流れで隔離する。Vitest 上で動く Storybook も同じ retry: 1 © LayerX Inc. ref: https://vitest.dev/advanced/api/test-case#diagnostic 12
13. 2 | 隔離: レビューを待たずに skip する 検知 → 隔離 → 可視化 → 修正
14. 2 | 隔離 PR へのコメントに判定を残し、マージされた時点の結果で隔離する PR の間 マージ時 CI で flaky を検知 → コメントを読む → 2 回目で通るので CI は成功 最新の CI の結果 PR にコメント → push のたびに上書き マークを挿入 → 隔離 PR を作る テスト名と担当チーム flakytest.Mark を先頭に 1 行 最新の CI の結果だけ残す automerge 先ほどの仕組みで CI 上で flaky を検知し、PRにコメントとして記載 マージされたタイミングで別の CI ワークフローがコメントを確認し、 flaky を隔離する PR を作成 © LayerX Inc. 14
15. 2 | 隔離 隔離 PR はマークを 1 行足すだけで、automerge される は自前のヘルパー。中身は t.Skip 、引数は判定した CI job の URL 最初の試みとの違いは、人のレビューを待たないこと flakytest.Mark © LayerX Inc. 15
16. 3 | 可視化: skip したまま忘れさせない 検知 → 隔離 → 可視化 → 修正
17. 3 | 可視化 skip したまま忘れないように、台帳と通知を作成 skip 中のテストは失敗を検知できない。隔離だけでは品質の担保が弱くなる skip 中のテストを一覧できる台帳と週次での担当チームへの通知基盤を用意 テストが skip されたままにならない様な仕組み作りへ マーク コードの中の flakytest.Mark © LayerX Inc. → 定期実行で検索 コードベースから マークを洗い出す → 台帳に登録 社内の共通基盤へ。 隔離した日と 担当チームを付ける → Slack に週次通知 チーム別、 経過日数付き 17
18. 4 | 修正: 直すのは AI に任せる 検知 → 隔離 → 可視化 → 修正
19. 4 | 修正 社内クラウドエージェント基盤"haro"の活用 通知を見た担当者が、台帳の画面上からそのままテストの修正を依頼できるように 人が介入するのは、上がってきた PR のレビューだけ © LayerX Inc. 社内クラウドエージェント基盤"haro" について: https://tech.layerx.co.jp/entry/why-we-built-our-background-agent 19
20. 結果（2026-08-14 〜 11-04） 自動で隔離した 653 件のうち、半分強は直った 653 自動で隔離した Go 403 / Vitest 185 Storybook 65 © LayerX Inc. 355 (54%) 原因を直した 117 / 355 原因を直したうち haro が共著 20
21. 結果（2026-08-14 〜 11-04） 10 月は新規の隔離が減り、直すのは haro が中心になった ⾃動で隔離 外れた（haro 以外） 外れた（haro 共著） 309 300 243 202 200 121 100 81 76 21 0 8 © LayerX Inc. ⽉（14 ⽇〜） 9 ⽉ 10 ⽉ 11 9 ⽉（〜4 ⽇） 新しく隔離した数 9 月 309 → 10 月 121 10 月以降に原因を直したうち、 6 割強が haro 共著（48 / 73） 21
22. まとめ まとめ: 人間の介入を避けつつ品質を担保できる仕組み作りへ 課題: flaky testが増加し、テストエラーの信頼性が低下 = オオカミ少年 AIを活用したflaky testの隔離、修正を試みた レビュープロセスなど人間の介入が多く、形骸化してしまった 隔離までは全自動で行う一方で、トラッキング、通知による品質担保と社内エージェン ト基盤を活用した自動修正へ ほとんどのflaky testが隔離され、約半分が修正された © LayerX Inc. 22