你好，我是悟空。

圖片

一、前言

我們先來看一封 Break Build（BB） 郵件，如下圖所示，這封郵件清楚的展示誰 BB 了，以及如何 BB 的。

圖片

今天我們要聊的話題是在自動化部署的過程中，如何找到造成本次部署失敗的人。而在持續集成領域，部署失敗被稱作 Break Build，簡稱 BB。

你是否遇到過自己提交了的代碼，導致整個項目的代碼編譯失敗？

你是否因為編譯失敗而被郵件通報？

你是否因為被郵件通報而被罰money？

這些都是我們之前項目組里面開發同學親身經歷。

他們因為將未經本地編譯通過的代碼直接往代碼倉庫提交，導致服務器編譯打包部署時，直接報錯，而耽誤了整個測試進度。

然后這些開發同學就會收到一封 “BB” 郵件，凡是收到這封郵件的人，所在的小組會被記一筆小黑賬，后續需上交一點點 money~

二、Break Build 是什么？

“Break build”是一個軟件開發和持續集成（CI）領域的術語，通常指的是在構建軟件的過程中遇到的失敗或錯誤，導致整個構建過程無法完成。它提醒開發團隊存在問題需要修復，確保只有穩定且無錯誤的代碼才能進入后續階段或部署到生產環境。

2.1 定義

構建過程包括從編譯源代碼、運行測試到打包成可部署的應用程序。當這個過程中的某一步失敗時，我們稱之為“break build”。

2.2 常見原因

• 代碼錯誤：如語法錯誤、編譯錯誤或邏輯錯誤。
• 測試失敗：單元測試、集成測試或端到端測試未通過。
• 依賴問題：缺少必要的庫或版本沖突。
• 配置錯誤：構建腳本或配置文件中的錯誤。
• 環境問題：構建環境中的配置或資源問題，例如磁盤空間不足或網絡問題。

2.3 影響

• 開發效率：開發人員需要花時間查找和修復錯誤，可能會延遲項目進度。
• 團隊協作：其他開發人員可能無法在代碼庫的最新版本上繼續工作，直到構建問題解決。
• 質量保障：未能通過構建的代碼不能部署到生產環境，確保了只有通過所有測試的代碼才會被發布。

2.4 處理方法

• 快速反饋：通過持續集成工具（如 Jenkins、GitLab CI、Travis CI 等）提供即時反饋，幫助開發人員迅速發現和解決問題。
• 自動化測試：在構建過程中自動運行各種測試，確保代碼的正確性和穩定性。
• 代碼審查和靜態分析：在提交代碼前進行代碼審查和使用靜態分析工具，減少引入錯誤的機會。
• 分階段構建：將構建過程分成多個階段（編譯、測試、打包等），可以更快地定位和解決問題。

三、如何找到 Break Build 之人

3.1 通知邏輯

我們可以編寫 Jenkins 的 Pipeline 腳本，如果此次打包失敗了，則找出此次構建中的提交記錄，并將代碼提交者、提交注釋、受影響的文件列表及提交時間都打印出來，并通過郵件形式發送給觸發構建者以及提交代碼的同學。如果打包成功了，則發送郵件給觸發構建者。流程如下所示：

圖片

對應的 pipeline 腳本如下圖所示：

圖片

3.2 找出代碼提交者

思路：遍歷當前構建及其之前的構建成功之間構建記錄，然后收集每個構建中的提交者信息，最后發郵件給提交者。

流程如下圖所示：

圖片

這里有個地方非常拗口：遍歷當前構建及其之前的構建成功之間構建記錄，怎么理解呢？

如下圖所示，構建記錄 #53 是成功的，那么本次要遍歷的構建記錄就是 #54~#58 這幾條記錄。

為什么不是直接找本次構建中的代碼提交提交記錄呢？原因是上一次構建后，下一次就拿不到提交記錄了，

圖片

對應的 pipeline 腳本如下圖所示：

圖片

四、執行結果

執行構建后，可以看到本次構建中，有兩次代碼提交，有兩個提交者，可能為同一個人。那么這兩個提交者都會收到 Break Build 郵件，至于是誰最終造成的，得看部署日志了。

4.1 打印提交記錄

圖片

對應的失敗通知的郵件模板中打印提交記錄的 html 如下所示：

圖片

4.2 打印詳細的提交記錄

在失敗通知郵件中還會打印構建日志，如下圖所示：

圖片

對應的失敗通知郵件模板中的打印構建日志的 html 如下所示：

圖片

4.3 查看完整的構建日志

從郵件中還是無法確認是誰提交的代碼造成的問題，這個時候可以看下構建日志。

如下圖所示，可以看到具體哪個地方報錯了，然后找下誰改的這個文件以及代碼行就能知道是誰造成編譯失敗了。

郵件模板

五、總結

在自動化部署過程中，找到導致構建失敗的提交者至關重要。

構建失敗（Break Build，簡稱BB）通常由于代碼錯誤、測試失敗、依賴問題等原因引起，影響開發效率和團隊協作。

我們可以通過編寫 Jenkins Pipeline 腳本，在構建失敗時遍歷當前構建及其之前的構建記錄，收集每個構建中的提交者信息，并將這些信息通過郵件發送給相關人員。這不僅能迅速通知提交者修復問題，還能確保代碼的穩定性和質量。

通過持續集成工具的快速反饋和自動化測試，我們能夠有效地預防和處理 Break Build，提高整體開發效率。