CIのflakinessとは? 解説

CIのflakinessとは、pipelineが信頼できず再現不能な結果を生み出す全般的な性質です。実際にはコードに関係のない赤いbuildです。

flakinessは、単一のフレーキーテストより広い概念です。それはCI全体の信頼性の低さであり、rerunすれば消える理由や、テスト対象の変更とは無関係な理由でbuildがどれだけ頻繁に失敗するかです。高いflakinessは、シグナルとしてのCIの価値を静かに破壊します。

flakiness vs フレーキーテスト

フレーキーテストは1つの信頼できないテストです。CIのflakinessは信頼できない結果が出るシステムレベルの割合であり、フレーキーテストだけでなく、一時的なインフラ障害、out-of-memory kill のような機械的な障害、そして環境ノイズを含みます。それは、赤いbuildを信頼できないものにするすべての総和です。

何がそれを引き起こすか

フレーキーで非決定的なテスト(タイミング、共有状態、乱数)。
一時的なインフラ: network blip、registryのタイムアウト、レート制限。
機械的な障害: out-of-memory kill、ディスク枯渇、プリエンプション。
過度に厳しいタイムアウトと、プロビジョニング不足のrunner。

なぜこれほどコスト高なのか

flakinessはあらゆる変更に負担を課します。何も見つからない調査、手動のrerun、遅れるmergeです。さらに悪いことに信頼を損なうため、チームは赤を無視し始め、誰も失敗を信じなかったために、やがて本物のリグレッションが出荷されます。

測定と削減

測定しないものは管理できません。flakyテスト率やpipeline失敗率を追跡し、一時的な障害を決定的なものから分離し、最大の要因から先に攻略します。テストを決定論的にし、runnerを適切なサイズにし、本物の一時的障害を自動でretryします。

Latchkeyの観点

CIのflakinessの大きな割合は、テストのバグではなく環境的なものです。Latchkeyの自己修復するマネージドrunnerは、network blip、registryのタイムアウト、out-of-memory kill のような一時的および機械的な障害を検出して自動でretryするため、一度きりのblipがbuildを失敗させず、flakinessの環境的な部分を直接削減します。

重要なポイント

CIのflakinessは、信頼できず再現不能な結果が出るシステム全体の割合です。
フレーキーテストに加え、一時的および機械的な障害を含みます。
あらゆる変更に負担を課し、シグナルとしてのCIへの信頼を損ないます。
それを測定し、テストとインフラを別々に攻略します。