PRのCI稼働時間を7割削減した話

度々上限停止していたGitHub ActionsのCIを、目的を崩さず3つの施策で見直した話。影響パッケージのみテスト・Draftはスキップ・DBコンテナ共有で、1 runあたり144分→39分（-73%）を達成しました。

Transcript

1. PRのCI稼働時間を7割削減した話
2. 自己紹介 名前: 寺田邦人 入社日: 2025/12/01 所属: プロダクトディベロップメントユニット メディアディベロップメントBチーム ITトレンドリプレイスPJ 趣味: 筋トレ、サイクリング slack: #times_kuni 2
3. GitHub Actionsが度々上限停止・・・ 4〜7 月に上限到達の報告が 6 回 → 上限追加後に再度上限停止することも・・・ 3
4. サブプロジェクトでCI改善 ITトレンドの開発メンバーは、メインのタスクとは別に サブプロジェクト にも取り組 んでいる（業務の 1 割くらい） 大野さんから「API リポジトリの CI 改善、やってみない？」 → 上限で止まる報告も多いし改善してみよう！ 4
5. 余談：一番使っていたのは it-trend-api 組織の利用のうち 約 4 割が it-trend-api 出典: #engineer_all のスレッド（2026-04-13） 5
6. it-trend-api のCIを見る GitHub Actions の稼働時間のうち PR の CI が 9 割 PR の CI のうち テストが 9 割 1 run あたり平均 144 分（並列ジョブの合計） PR を出すたびに約 30 分待つ 2026-06 の集計 6
7. CIの目的は崩さない PR の CI の目的は、マージする時点で次を保証するためにある 1. build / format / lint が全部通っている 2. 必要十分なテストがされている → この 2 つを守ったまま削減する 7
8. やったこと 1. 変更の影響があるパッケージだけテスト 2. Draft の状態ではテストしない 3. DB コンテナをパッケージ内で共有 8
9. 1. 変更の影響があるパッケージだけテストする 変更前：PR で結合テスト以外の全部 / 日次で結合テスト → 結合テストが検査されない、変更に関係ないテストが走る 変更後：PR で 変更の影響があるパッケージだけ / 日次で全テスト(保険) go list -deps -test -f '{{.ImportPath}} {{join .Deps " "}}' ./... 依存グラフから「変更パッケージに依存するもの」を拾う 9
10. 2. Draft の状態ではテストしない PR の 7〜8 割が Draft で作られていた （AI が読む規約でも Draft 作成を指示している） マージの判定に使うのは 最後に走った CI だけ Draft 中のテストは、ほぼ無駄になっている → Draft の状態ではテストをしない、Ready にしたときに回す （build / format / lint は軽いので Draft でも回す） 10
11. 3. DB コンテナをパッケージ内で共有する 変更前：テストケースごとに MySQL コンテナを起動 → 破棄 起動に 1 回 約 13 秒。1 ケースの 6〜9 割が起動待ち 変更後：パッケージごとにDBコンテナを 1 回だけ起動し、テストケース間で共有する テストケースが終わるたびにデータを消して、ケース同士が影響しないようにす る 11
12. 結果 対応 週 稼働時間(分)/run 対応前 2026-06-29 144 影響パッケージのみテスト 2026-07-13 54 Draftでテストしない 2026-07-20 47 共有DB化 2026-09-07 39 144 → 39 分（-73%） 12
13. まとめ CIの目的は崩さずに、稼働時間を 73%削減 AI で生まれた余白で PJ 改善をやってみるのはどうでしょうか？ 13
14. ご清聴ありがとうございました！