たまに壊れるビルド（flaky build）を18分の1に減らす

 (github.blog)
8 ポイント 投稿者 outsideris 2020-12-25 | 1件のコメント | WhatsAppで共有

GitHubでは、同じコードなのにある場合はビルドが壊れ、ある場合は通過するビルドを flaky build と定義している。flaky はそのコードを書いた本人が解決すべきで、他の人に影響を与えないよう自動化を導入し、flaky build を18分の1に減らしたという。

GitHub の内部 CI で flaky build を追跡し、問題の状況を整理したうえで、その問題を作ったと推定される人に割り当てる。

  • flaky build を追跡してみると頻度に差があり、100回以上失敗する flaky build は全体の 0.4% だった。そこでこの 0.4% に集中することにした。

  • 2016年に導入したときは、次の2つの方法でアプローチした。

    • ビルドが終わったら、同じコミットで実行されたビルドを探し、結果が異なる場合は flaky build と表示する

    • 同じビルドで再試行したときに結果が異なる場合は flaky build と表示する

  • この方法では、全体の flaky build のうち 25% しか区別できなかった。

改善する

  • 3回再実行する方法を使う

    1. 同じプロセスで再試行する。この flaky build は、コードの偶然性やレースコンディションによって発生する。

    2. 同じプロセスだが、時間をおいて再試行する。この flaky build は、時間に関する誤った前提を置いたときに発生する。

    3. 完全に別のホストで再試行する。この flaky build は、テスト順序への依存や共有状態のために発生する。

この方法によって、90% を自動で検出できるようになった。

影響度の測定

優先順位を決めるために、影響度を定量化する方法が必要だった。

ビルド、ブランチ、作成者、コミットなどの情報を使って、どれだけ多く失敗し、他のブランチや開発者に影響を与えるかという影響度スコアを付ける。

一定のスコアを超えると、開発者が修正できるように issue を作成して開発者に割り当てる。

関連記事

1件のコメント

 
ganadist 2020-12-25

私の場合、gradle の unittest で flaky build が頻繁に見つかっていたため、以下のソリューションを適用していました。