依存関係アップデートにおける QA テストのバッチサイズを最適化する
はじめに
わたしの所属するチームでは Renovate を用いて依存関係のバージョンアップ Pull Request を自動生成しています。 また、プロダクションコードに一定の影響を与える更新に対しては QA チームによるテストを実施して品質を担保しています。
QA テストにおいては Renovate が作成した複数の Pull Request をまとめてバッチ化することで効率化を図っています。 このとき、どのくらいのバッチサイズが最もコスト効率が高いかは感覚で決められがちです。
本記事では、最もシンプルな前提から数学モデルを構築し、最適バッチサイズが概ね
前提と記号
記号 | 意味 |
---|---|
1 回のバッチに含める Pull Request の数(バッチサイズ) | |
単一の Pull Request がリグレッションを引き起こす確率( |
|
QA テスト 1 回の実行コスト |
運用仮定
以下のようなシンプルな運用を仮定します。
- バッチ(サイズ
)をまとめて 1 回テストn - テストが成功したら終了
- 失敗したら各 Pull Request を個別に再テスト(
回)n
期待コストの導出
バッチ化したテストの失敗確率は
テスト実行回数の期待値:
テストコスト期待値:
単一 Pull Request あたりに正規化:
よって
期待コストの可視化
いくつかの
-
は下に凸の関数f(n) - 小さい
ほど最適バッチサイズp が大きいn - 小さい
ほど最適バッチサイズを採用した際のコスト期待値が小さいp
例えば
最適条件と厳密解
Lambert
これはモデルに対する連続最適解の解析的表現です。
p に対する近似
小さい 小さい
実務上は「リグレッション率
例
|
推奨バッチサイズ(例) | |
---|---|---|
0.01 | 10.00 | 10 |
0.02 | 7.07 | 7〜8 |
0.05 | 4.47 | 4〜5 |
0.10 | 3.16 | 3 |
連続最適値・整数最適値・近似の比較
横軸に
黄色の実線が連続最適、オレンジの実線が整数最適、赤い破線が近似
- 小さい
ほど最適p は急速に増加するn - 近似
は広い範囲で連続最適に密接する1/\sqrt{p} - 実務は整数制約なので階段状に変化する
リグレッション率はバージョンアップの変更度合いやそのパッケージへの依存度などにより異なるため、過去数週間〜数ヶ月の実績を元に推定するとよさそうです。
まとめ
前提としたシンプルな運用において、依存関係アップデートの QA テストの最適バッチサイズは、リグレッション率
Discussion