ビルド安定性とは何か？解説

ビルド安定性とは、CIがどれだけ一貫して正しく信頼できる結果を生み出すかであり、コードが良好なときはグリーンに、本当に壊れているときにのみレッドになります。

高速なpipelineも、その出力を信頼できなければ無価値です。ビルド安定性はまさにその信頼に関わります。ビルドがグリーンなら出荷でき、レッドなら本当の問題があります。変更とは無関係な理由で結果が反転する不安定性は、CIの価値を静かに破壊します。

安定性が意味するもの

安定したビルドとは、その結果がテスト対象のコードを反映するものです。同じcommitが同じ結果を生み、グリーンは良好を、レッドは本当の欠陥を意味します。安定性は、mergeやdeployのゲートとして頼れるほどCIを信頼するための前提条件です。

何がそれを損なうのか

コードの変更なしに反転する、flakyで非決定的なテスト。
一時的なインフラ障害：ネットワークの瞬断、registryのタイムアウト。
サイズが不足したrunnerでのメモリ不足によるkillなどの機械的な失敗。
テストの分離が不十分なことによる、順序や並列度に依存した失敗。

安定性 vs 速度

速度と安定性は別の軸であり、どちらも重要です。高速だが不安定なpipelineは偽のレッドであなたを溢れさせ、安定しているが遅いものはすべてを遅らせます。チームには両方が必要ですが、安定性が先です。なぜなら、信頼できない結果はどれだけ速く届いても行動につながらないからです。

改善する方法

テストを決定的で十分に分離されたものにし、リソース枯渇によるkillを避けるためにrunnerを適正にサイジングし、本物の一時的な失敗を自動でリトライして偽のレッドとして現れないようにします。安定性またはfailure-rateの指標を追跡し、リグレッションが常態化するのではなく可視化されるようにしましょう。

Latchkeyの視点

不安定性のかなりの割合は、テストのバグではなく環境に起因します。Latchkeyの自己修復マネージドrunnerは一時的および機械的な失敗を検出して自動でリトライするため、一度きりの瞬断でビルドが失敗することはなく、安定性を蝕む環境由来の偽のレッドを取り除きます。

重要なポイント

ビルド安定性とは、CIがどれだけ一貫して信頼できる結果を出すかである。
flakyなテスト、一時的な失敗、リソース枯渇によるkillがそれを損なう。
安定性と速度は別の軸であり、どちらも重要だが安定性が先である。
決定性、分離、適正なサイジング、そしてリトライがそれを改善する。