構建服務器可以隨心所欲地傳遞出錯誤和代碼質量問題的信號，如果開發團隊不關心這些問題，那么這些通知和可視化的投資收益為零。

對此，中培技術專家袁老師認為，這并不是技術本身可以解決的。流程需要每個人都同意，讓人人都能看見自己參與所帶來的利益是達成共識的最簡方法。

問題是企業里總是有一大堆迫在眉睫的事。構建錯誤會比產品錯誤更重要嗎？還有代碼質量指標方面，如果改進代碼質量需要數年，值得著手解決這個問題嗎？

我們怎樣解決這類問題？這里有一些想法：

不要過分追求代碼質量指標。可以先減少測試的數量，直到代碼質量報告達到了可以修復的水平。解決之后再把測試加回來。

定義問題的優先級。產品問題優先，然后才是構建錯誤。在問題被完全解決之前，不要在損壞的代碼之上提交新代碼。

盡管想讓構建服務器成為持續交付流水線的中心之一，但我們也要考慮當構建服務器癱瘓的時候，構建和部署的流程不應該停滯不前。為此，構建本身應該盡可能健壯，并且可以在任何主機上重復工作。

這對像Maven那樣的一些構建來說相當容易。可即便如此，一個Maven構建也可能有無數的缺陷而使其無法被正常移植。

一個基于C語言的構建會很難移植，如果你沒有幸運到所有的依賴都在操作系統庫里可用的地步。還是那句話，健壯性通常能夠值回票價。

總結

我們快速掃過了構建代碼的系統。看過了用Jenkins構建持續集成服務器，也檢查了許多可能發生的問題，DevOps工程師的生活總是很有意思，但并不總是很容易。

想了解更多IT資訊，請訪問中培偉業官網：中培偉業