Monorepo における Go テストの差分実行 / Running Differential Go Tests in a Monorepo

Transcript

1. © LayerX Inc. Monorepo における Go テストの差分実行 layerx.go #1 @ktr
2. © LayerX Inc. 2 • LayerX ◦ バクラク事業部 ◦ 申請・経費精算チーム • 経歴 ◦ 株式会社メルカリ (2019.04 - 2024.03) ◦ 株式会社 LayerX (2024.04 -) 自己紹介 @ktr (きたろー)
3. 目次 Agenda • Monorepo とは • なぜ差分テストが必要なのか？ • 差分テストのアプローチ • 効果測定と課題 • まとめ
4. Monorepo とは
5. © LayerX Inc. 5 Monorepo(モノレポ)とは、アプリケーションやマイクロサービス の全コードを単一のモノリシックなリポジトリ (普通は Git) に保存 するパターンを指します。 Monorepo とは —— Monorepo開発のメリット vs デメリット | CircleCI
6. © LayerX Inc. 6 • Web アプリ、マイクロサービス、ライブラリ、スキーマ定義などが同居 ◦ もともと一つのリポジトリ (= Polyrepo) だったプロダクトのバックエンドもいる LayerX における Monorepo Monorepo とは layerone go web pkg services apps packages repos proto
7. © LayerX Inc. 7 👍 メリット • コードや仕組みを共有できる • 横断的な改善がしやすい • FE/BE 関係なくあらゆるコードに手を入れ ることができる 👎 デメリット • コードベースの巨大化 • ビルドやテストに時間がかかる • コンフリクトの増加 Monorepo におけるメリット・デメリットの例 Monorepo とは
8. なぜ差分実行が必要なのか
9. © LayerX Inc. 9 • すべてのコードが一つのリポジトリに収まるため、Polyrepo に比べて急速に大きくなっていく • つまりビルド時間もテスト時間もどんどん遅くなっていく… Monorepo は急速に大きくなっていく なぜ差分実行が必要なのか
10. © LayerX Inc. 10 • ある程度テストを高速化したとしてもいずれまた遅くなる • テストコードがどんどん追加されていっても実行時間が比例して伸びない仕組みが必要 ◦ 👉テストの差分実行 テスト全実行の限界 なぜ差分実行が必要なのか
11. 差分テストのアプローチ
12. © LayerX Inc. 12 • CI でのテスト実行を短縮する ◦ ローカルでのテストは個別に実行できるので問題ない • `go test` による単体テストを対象とする • Pull Request をトリガーとしたテスト実行に適用する ◦ main へマージした際やスケジュール実行では引き続きテストをすべて実行する • パッケージ単位での差分実行を行う ◦ 別のアプローチとして関数単位の実行があるが、今回はパッケージ単位とする ◦ 実装難易度が跳ね上がる (パッケージ単位だとシュッとできる) 前提 差分テストのアプローチ
13. © LayerX Inc. 13 • 今回は Pull Request のみ対象 • gh コマンドで当該 PR の変更されたファイルを取得 大きく 3 つのステップ - ① 差分の特定 差分テストのアプローチ $ gh api \ --paginate \ --jq '.[] | select(.status == "modified" or .status == "added") | .filename | select((startswith("go/") and endswith(".go")) or test("(go.mod|go.sum)"))' \ /repos/LayerXcom/layerone/pulls/17034/files
14. © LayerX Inc. 14 • 静的解析 • `golang.org/x/tools/go/packages` を使い、パッケージの依存グラフを作成 • 依存グラフをもとに影響を受けるパッケージを洗い出す ◦ 影響を受けたパッケージを再帰的に取得していく 大きく 3 つのステップ - ② 影響範囲の特定 差分テストのアプローチ
15. © LayerX Inc. 15 • ② のパッケージを指定してテストを実行する 大きく 3 つのステップ - ③ テスト実行 差分テストのアプローチ $ go test -timeout 120s -race -shuffle=on -covermode=atomic -coverprofile=coverage.out \ github.com/LayerXcom/layerone/go/services/all/cmd \ github.com/LayerXcom/layerone/go/services/universal/cmd \ github.com/LayerXcom/layerone/go/services/universal/internal/runner \ github.com/LayerXcom/layerone/go/services/universal/servers
16. 効果測定と課題
17. © LayerX Inc. 17 平均で 1 分以上高速化 🎉 効果測定と課題
18. © LayerX Inc. 18 • 変更内容によるが、テストの実行時間が大きく改善 🚀 ◦ 依存の少ない変更であれば 2 分台で完了することも • 副次的な効果 ◦ 変更に対して影響のないフレーキーテストを回避できるように ▪ 本当は直さないといけない…!!! 実際に得られた効果 効果測定と課題
19. © LayerX Inc. 19 • パッケージ構成により大きく実行時間が変わる ◦ 例: あるパッケージに大量の重いテストがあるとき、そのパッケージにちょっとした変更をするだ けでパッケージ全体のテストを実行する必要がある • 外部パッケージの変更をどう扱うか ◦ 現在は go.mod が更新されたときは一律すべてのテストを実行するように 課題 効果測定と課題
20. まとめ
21. © LayerX Inc. 21 • LayerX の Monorepo ではテストの実行時間が課題となっていた • 差分実行を取り入れることで改善を図った ◦ 変更内容に影響されるパッケージのみをテストする • 差分実行により得られた恩恵 ◦ テストが高速化した ◦ 今後テストが増えていっても実行時間の増加がゆるやかになる (ハズ) • 差分実行の課題 ◦ パッケージ単位なのでテスト対象のパッケージによっては引き続き時間がかかる ▪ ただし、現時点では問題になっていない まとめ まとめ