コミット後ポリシーの詳細

コミット後テストの失敗は、コードにバグがあることを意味します。バグが存在する期間が長くなるほど、継続的なコードの貢献により、バグの修正が難しくなります。そのため、バグを迅速に修正する必要があります。 Beamコミュニティのコミット後テストポリシーは、コードとテスト結果を良好な状態に保つのに役立ちます。

まずロールバック

Beamは「まずロールバック」のアプローチを採用しています。テストの失敗を解決するための最初のアクションは、原因となったコード変更をロールバックすることです。このアプローチの2つの主な利点は、実装時間が短く、信頼性が高いことです。最初にロールバックすると、以前に検証済みの良好な状態にすばやく戻ります。

大まかに言うと、このアプローチは次の手順で構成されます

1. 原因となったコミットを元に戻します。
2. コミット後テストを再実行して、テストに合格することを確認します。
3. 元に戻すコミットをプッシュします。

このポリシーの背景については、メーリングリストスレッドと設計ドキュメントを参照してください。

テストの失敗はクリティカル/P1の問題です

バグのあるコードに加えられた新しい変更を適切に検証することは困難です。場合によっては、コードを追加すると問題が悪化する可能性があります。このような状況を回避するために、失敗したテストの修正が最優先事項です。

不安定なテストはクリティカル/P1の問題です

不安定なテストは失敗したテストと見なされ、不安定なテストの修正はクリティカル/P1の問題です。

不安定なテストとは、同じコードバージョンを使用しているにもかかわらず、ランダムに成功または失敗するテストです。不安定なテストの失敗は、無視しやすい最も危険なタイプの失敗の1つです。不安定なテストをもう一度実行すると、正常に合格する可能性があります。ただし、これらの失敗は実際のバグを隠す可能性があり、不安定なテストはしばしばゆっくりと蓄積されます。誰かが繰り返し失敗をトリアージする必要があり、不安定なテストは多くの場合、修正するのが最も難しいテストです。

不安定なテストは信頼できる品質シグナルを提供しないため、不安定さを迅速に修正することが重要です。修正の実装に時間がかかる場合は、修正が準備できるまでテストを無効にする方が安全です。

Martin Fowlerは、テストにおける非決定性についての良い記事を書いています。

不安定なテストは修正または削除する必要があります

不安定なテストは信頼できる品質シグナルを提供しません。これはすべてのテストに悪影響を及ぼし、テストスイートの信頼を失う可能性があります。その結果、貢献者はテストの失敗を無視し始める可能性があります。

全員にテストを信頼してもらいたいので、すべての不安定なテストを熱心に修正することが重要です。不安定なテストを修正できない場合は、テストを削除する必要があります。

コミット後修正の一環として、新しいコミット前テストを追加します

コミット後テストは重要なフェイルセーフですが、迅速に失敗させたいと考えています。迅速な失敗とは、コミット*後*テストではなく、コミット*前*テストでバグを検出したいことを意味します。

コミット後テストの失敗の修正を実装する場合は、将来同様の失敗を検出する新しいコミット前テストを追加します。たとえば、問題のあるコードブランチをカバーする新しい単体テストを実装できます。

Beamがダウンストリームプロジェクトを壊した場合、コミュニティに通知します

Beamに依存する外部プロジェクトは複数あり、Beamリポジトリ外にテストが含まれています。たとえば、Dataflow、Samzaランナー、IBM Streamsなどです。

外部プロジェクトがBeamの（PR）によって引き起こされた問題に遭遇し、その結果、Beamリポジトリの変更を要求した場合、最初にすべきことは、次の3つの質問に対処するGitHub Issueを作成することです。

1. 問題点の説明。
2. 元に戻すと修正されますか？（または、別の方法で修正することになっていますか）
3. 元に戻すことが最良の修正方法ですか？

ディスカッションを開発メーリングリストにも持ち込むことをお勧めします。理想的には、インシデントの後、将来同様の問題を早期に捕捉することを目標に、Beamリポジトリでテストを拡張する必要があるかどうかについて話し合うことをお勧めします。