799
《配置管理最佳實踐》——2.7 把構建做得更好
本節書摘來自異步社區《配置管理最佳實踐》一書中的第2章，第2.7節，作者： 【美】Bob Aiello , Leslie Sachs著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
2.7 把構建做得更好
在很多公司，已經建立了良好的構建流程，我的角色就是幫助改善現有流程，以支持更多的環境（比如QA環境和生產環境）。有段時間，我發現有的構建過程隻有技術背景很強的專業技術人員才能理解和使用好，且在使用中極易出錯，結果也不可靠。構建工程的目的是提供一個可靠、快速、清晰的構建過程來支持產品的構建和部署。
2.7.1 鮑勃的構建秘方
這一小節將介紹建立可靠的、可重複的構建過程的秘訣。在很多環境中，我的方法都可以幫助開發團隊成功地完成構建，並且部署到QA環境（生產環境）中去。通常情況下，我都是在項目或者公司瀕臨失敗時才加入其中。如果采用我的方法，通常可以在3個構建之內解決他們的構建問題。我的很多技術都是基於在紐約大學工業組織心理學研究生課程中學到的方法。在其他學科學到的知識幫助我建立了一套獨特的方法。團隊失敗的原因有很多，隻要是構建工程的問題都可以通過改進構建來解決。
2.7.2 測試驅動的構建
構建工程師不僅要隨時關注構建的過程，還要關注開發人員調試構建、解決構建問題的方法，甚至是每一步的操作。有這樣一個實例，我觀察到每當構建失敗，開發人員就會查看某個特定的 JAR 文件是否被創建，是否包含在了 WAR 文件當中。我並不完全了解為什麼有的時候這個 JAR 文件沒有被創建成功。之後在構建腳本中，我也加入了這一步驟，在以後的每次構建中，構建腳本都會檢查這個JAR文件是否存在。如果某步檢查到這個 JAR 文件沒有成功生成，那麼構建腳本就會提前通知我們，JAR文件缺失將會導致構建失敗。雖然這樣做可能有點小題大做，但是主動測試構建將會幫助你生成可靠的構建，並且一旦出現錯誤你也會很早就得到提示。開發人員一般都堅信自己的構建是完全沒問題的，因此並不會主動地去測試自己的構建。
2.7.3 信任，但仍要核查
作為構建工程師，我的做法是“信任，但仍要核查”。也就是說我們信任生成的每個構建，但仍然需要對它們進行測試。當你的構建結果事關他人的健康和安全時，這就尤其重要。也許一個構建的錯誤可能就會導致飛機相撞或者其他更嚴重的事件。他人的健康和安全都是至關重要的事情。例如，航空工程師花費了大量時間製造準確、易理解的控製器，以避免出現問題。
2.7.4 飛機的駕駛艙
在某些領域，經常需要付出大量的努力去避免可能出現的錯誤。之所以這樣關注整體質量，是因為任何一個錯誤都可能導致有人喪生。就像本節前麵討論的一樣，采用這樣的思路設計駕駛員座艙就是為了減少錯誤的發生。上麵的控製器都容易理解，接口也很清晰。我覺得軟件工程師需要向飛機駕駛艙設計師學習，把它應用到應用程序構建、部署過程和自動化的設計上。曾經嚐試創建可以避免錯誤，且可以主動檢測構建問題的構建係統。構建和部署的自動化需要想辦法避免可能的錯誤發生。我做過多次構建工程改進的項目，每次都是把團隊從不穩定、不可靠的構建狀態中解救出來，成功地實現一個完全可重複的可靠的流程。下麵列出來一些重要的關注點，供設計或改進構建係統時參考：
構建過程的每一步都要易讀且易執行
自動檢查構建過程中可能的出錯點，核實構建是否成功
結構化組織自動構建過程，避免一個錯誤破壞整個構建
通過狀態公告板和構建報告展示構建狀態
最後更新：2017-06-05 10:01:48