自己修復CIとは？解説

自己修復CIとは、一時的および機械的な失敗を検出し、人がjobを再実行することなく自動的にそこから回復するpipelineです。

従来のpipelineでは、コードとは無関係だった失敗も含めて、すべての失敗があなたがトリアージすべき問題でした。自己修復CIは、コード変更を必要としない失敗についてこれを反転させます。システムは環境的またはリソースの失敗を認識し、影響を受けた作業をリトライし、問題が本物のときだけあなたにエスカレーションします。

検出してから回復する

自己修復は2つの能力に基づいています。1つ目は検出です。失敗を一時的かつ機械的（ネットワークの瞬断、registryのタイムアウト、out-of-memory kill）か、決定論的（失敗したassertion、構文エラー、欠落したファイル）かに分類します。2つ目は回復です。一時的なクラスについては、buildを失敗させるのではなく作業を自動的にリトライします。

何を修復し、何を修復しないか

自己修復は、原因がコードの外にある失敗を対象とします。決定論的な失敗をリトライで「修正」することはできませんし、すべきでもありません。本物のバグをリトライしても分を浪費し、シグナルを隠すだけだからです。優れた自己修復システムは保守的で、一時的である可能性が高いものだけをリトライします。

なぜリトライだけでは不十分なのか

すべての失敗を無差別にリトライするのは自己修復ではなく、いつ起きてもおかしくないリトライストームです。本物の自己修復は選択的です。失敗のクラスを認識し、妥当な上限とbackoffを設けてリトライし、何を修復したのかを表面化させて、パターンが隠されるのではなく可視のままになるようにする必要があります。

どこに存在するか

自己修復はworkflow内（リトライラッパー、条件付き再実行）にも、runnerプラットフォーム自体にも存在できます。プラットフォームレベルの修復のほうが強力です。プラットフォームは、workflowのstepが決して観測しないout-of-memory killやプリエンプトされたインスタンスといった機械的なシグナルを見ることができるからです。

Latchkeyの視点

自己修復managed runnerはLatchkeyが提供するものの中核です。runnerプラットフォームが一時的および機械的な失敗（out-of-memory kill、ネットワークの瞬断、registryのタイムアウト）を検出し、自動的にリトライするため、一度きりの瞬断でbuildが失敗することはありません。修復がrunnerレベルで行われるため、workflowでは見えないインフラの失敗も捕捉し、一方で本物のコードの失敗は依然として素早く失敗します。

重要なポイント

自己修復CIは一時的な失敗を検出し、自動的に回復します。
一時的（リトライ可能）な失敗と決定論的（コード）な失敗を区別する必要があります。
選択的で上限のあるリトライが重要です。無差別なリトライはリトライストームを招きます。
プラットフォームレベルの修復は、workflowでは見えない機械的な失敗を捕捉します。