コミット後テストポリシー

コミット後テストは、Beamがライブ環境で正しく動作することを検証します。また、設計および実装段階では予測が難しいエラーも検出します。

コミット後テストはコードがリポジトリにマージされた後に実行されますが、テストが確実に成功することが重要です。Jenkinsは、`master`ブランチのHEADに対してコミット後テストを実行します。コミット後テストが失敗した場合、HEADビルドに問題があります。さらに、コミット後テストの実行には時間がかかり、テストの失敗をトリアージするのが難しいことがよくあります。

ポリシー

Beamのコミット後テストの信頼性と健全性を確保するために、Beamコミュニティは次のコミット後テストポリシーに従います。

コミット後テスト失敗シナリオ

コミット後テストが失敗した場合は、状況に応じた手順に従ってください。

テストの失敗を発見しました

  1. GitHub issueを作成し、自分に割り当てます。
  1. 障害の高レベルなトリアージを実行します。
  2. 関連する担当者に課題を割り当てます.

テストの失敗に関する課題が割り当てられました

  1. 原因となった変更をロールバックします.
  2. ロールバックに8時間以上かかる場合は、ロールバックまたは修正を作成している間にテストを一時的に無効にします。

注：ロールバックは常に最初のアクションです。修正が簡単な場合は、ロールバックを実行しながら、修正案を含むプルリクエストを開きます。

テストの失敗により、変更がロールバックされました

ロールバック後、詳細な調査を行う時間があります。まず、GitHubのissueを見て、ロールバックの背景情報を確認します。これらのシナリオはすべて一般的です。

これらはすべて、ロールバックの正当な理由です。明確なシグナルを維持することが最優先事項です。

高レベルの手順は同じです

  1. 修正を作成し、コミット後テストを再実行します。
  2. 将来のコードがリポジトリにマージされる前に同様の失敗をキャッチする新しいコミット前テストを実装します。
  3. 修正と新しいコミット前テストを含む新しいPRを開きます。

バグがコードにない場合、「修正を作成する」方法は次のとおりです。

  1. 既存のバグのチケットをまだ存在しない場合は提出します。不安定なテストは重大なバグであることを忘れないでください。他の不適切なテストも同様です。テスト対象とは関係のない任意の理由で失敗する可能性があり、シグナルが信頼できないものになります。
  2. 問題のあるテストをスキップするようにマークし、GitHub issueへのリンクを付けます。

参考資料

  1. コミット後テストを正常に保つメーリングリストの提案スレッド。