テストが増えすぎてもう限界だったので、PRで全テストを回すのをやめた話 - Timee Product Team Blog

はじめに こんにちは、タイミーのプラットフォームエンジニアリングチームに所属している徳富(@yannKazu1)です。 この記事では、スキマバイトサービス「タイミー」のバックエンド（Rails API）に Datadog Test Impact Analysis（TIA） を導入し、PRごとのCIフィードバックを大幅に高速化した取り組みについて紹介します。 なお、バックエンドはRailsアプリケーションなので、テストフレームワークは RSpec を前提として話を進めます。 サービスが成長してプロダクトの機能が増えてくると、テストも当然増えていきますよね。開発者が増えればPRの数も増え、CIの待ち時間がボトルネックになってくるのも、割とあるあるな課題だと思います。同じような悩みを抱えているチームの参考になれば嬉しいです。 背景：膨れ上がるテストとの戦い タイミーのバックエンドはモジュラーモノ

[ngmy]

「増え続ける」と言っているからこの事例では導入が正なんだろうけど、テストが急激に増え続ける見込みがない場合、1並列あたりのテスト実行時間が10分くらいなら、運用コスト増で費用対効果が悪いという印象。

[threetea0407]

開発中は関連してそうなとこだけテスト回して、マージするときだけフルのテスト回すのは良さそう

[sd-craft]

うーん、並列数の割に時間かかりすぎてるけど、Railsのテストってそんな遅いの？

[mkusaka]

Datadog Test Impact Analysis(TIA)でPRは関連RSpecのみ実行しCIを1〜2分化、マージキューで全テスト+カバレッジ収集

[y_hirano]

AI使う開発だと品質を担保するためにユニットテストが増えるし、AIにテストを書かせるとすごい勢いで増えていくので、ユニットエストの実行がボトルネックになりそうなのはわかる。

[kiririmode]

テスト数が継続的・高速に増える大規模開発では、PRで全テストを高速に回すという前提が持続不能。CIの完全性を各PRに要求するのをやめ、PRではTIAでの選択的テストで高速FB、mainへのmerge時に全テスト実行の最終ゲート化

[sionsou]

わかりみがふかい。あとでしっかりよむ。

[chiroruxx]

やめた(やめてない)だった。良さそう。

[kikuchi1201]

良さそう

[tito1201]

おもしろい / PHPでも類似の仕組み作れんかな

[toaruR]

『 Datadog Test Impact Analysis（TIA）』

[finefinethankyou]

開発中はTIAほど高度じゃなくても雑に関係ありそうなものを回すだけで良いのでは

[fuji_haruka]

文字が小さくてスマホでは読めん…！

[hiroomi]

総量の問題で、PRでは必要なテストだけ回す。mainへ入れる直前には全テストを回す。

[nguyen-oi]

3万5千件のテストは草。マージキューとDatadog TIAの組み合わせで差分だけ回す構成は現場の苦労が偲ばれるな

[SWIMATH2]

TIAしらなかった