提交後政策詳情

提交後測試失敗表示程式碼中有錯誤。錯誤存在時間越長，由於持續的程式碼貢獻，修復起來就越困難。因此，我們希望快速修復錯誤。Beam 社群的提交後測試政策有助於保持我們的程式碼和測試結果處於良好狀態。

優先回滾

Beam 使用「優先回滾」方法：解決測試失敗的第一個動作是回滾有問題的程式碼變更。此方法的兩個主要優點是實作時間短和高可靠性。當我們優先回滾時，我們會快速回到先前驗證過的良好狀態。

在高層次上，此方法包含以下步驟

  1. 還原有問題的提交。
  2. 重新執行提交後測試以驗證測試是否通過。
  3. 推送還原提交。

有關此政策的背景資訊，請參閱郵件列表討論串和設計文件。

測試失敗是嚴重/P1 問題

很難正確驗證在有錯誤的程式碼之上所做的變更。在某些情況下，新增額外的程式碼可能會使問題變得更糟。為了避免這種情況，修復失敗的測試是我們的最高優先事項。

不穩定的測試是嚴重/P1 問題

不穩定的測試被視為失敗的測試，修復不穩定的測試是嚴重/P1 問題。

不穩定的測試是指在使用相同程式碼版本時，隨機成功或失敗的測試。不穩定測試失敗是最危險的失敗類型之一，因為它們很容易被忽略 – 再次執行不穩定測試可能會成功通過。但是，這些失敗可能會隱藏真正的錯誤，而不穩定的測試通常會慢慢累積。必須有人重複分類失敗，而不穩定的測試通常是最難修復的。

不穩定的測試無法提供可靠的品質訊號，因此快速修復不穩定性非常重要。如果修復需要一段時間才能實作，則在修復準備就緒之前停用測試會更安全。

Martin Fowler 有一篇關於測試中不確定性的好文章。

不穩定的測試必須修復或移除

不穩定的測試無法提供可靠的品質訊號，這對所有測試都有害，並可能導致對我們的測試套件失去信任。因此，貢獻者可能會開始忽略測試失敗。

我們希望每個人都信任我們的測試，因此盡力修復所有不穩定的測試非常重要。如果無法修復不穩定的測試，我們必須移除該測試。

將新的提交前測試新增為提交後修復的一部分

提交後測試是一個重要的安全機制，但我們希望快速失敗。快速失敗表示我們希望在提交前測試中偵測到錯誤，而不是在提交後測試中偵測到錯誤。

當您實作提交後測試失敗的修復時，請新增一個新的提交前測試，以在未來偵測到類似的失敗。例如，您可以實作一個新的單元測試，涵蓋有問題的程式碼分支。

如果 Beam 破壞了下游專案，請通知社群

有多個外部專案依賴於 Beam，其中包含 Beam 儲存庫之外的測試。例如，Dataflow、Samza 執行器和 IBM Streams。

當外部專案遇到由 Beam 中的（PR）引起的 issue，並因此要求變更 Beam 儲存庫時，第一件事是建立一個 GitHub Issue，以解決以下三個問題

  1. 有關 issue 是什麼的描述。
  2. 回滾是否可以解決問題？（或者應該以不同的方式修復）
  3. 回滾是修復它的最佳方法嗎？

鼓勵將討論帶到開發郵件列表。理想情況下，在事件發生後，我們更希望討論是否應該擴展 Beam 儲存庫中的測試，目的是在未來儘早發現類似的問題。