構(gòu)建服務(wù)器可以隨心所欲地傳遞出錯(cuò)誤和代碼質(zhì)量問(wèn)題的信號(hào)，如果開(kāi)發(fā)團(tuán)隊(duì)不關(guān)心這些問(wèn)題，那么這些通知和可視化的投資收益為零。

對(duì)此，中培技術(shù)專(zhuān)家袁老師認(rèn)為，這并不是技術(shù)本身可以解決的。流程需要每個(gè)人都同意，讓人人都能看見(jiàn)自己參與所帶來(lái)的利益是達(dá)成共識(shí)的最簡(jiǎn)方法。

問(wèn)題是企業(yè)里總是有一大堆迫在眉睫的事。構(gòu)建錯(cuò)誤會(huì)比產(chǎn)品錯(cuò)誤更重要嗎？還有代碼質(zhì)量指標(biāo)方面，如果改進(jìn)代碼質(zhì)量需要數(shù)年，值得著手解決這個(gè)問(wèn)題嗎？

我們?cè)鯓咏鉀Q這類(lèi)問(wèn)題？這里有一些想法：

不要過(guò)分追求代碼質(zhì)量指標(biāo)。可以先減少測(cè)試的數(shù)量，直到代碼質(zhì)量報(bào)告達(dá)到了可以修復(fù)的水平。解決之后再把測(cè)試加回來(lái)。

定義問(wèn)題的優(yōu)先級(jí)。產(chǎn)品問(wèn)題優(yōu)先，然后才是構(gòu)建錯(cuò)誤。在問(wèn)題被完全解決之前，不要在損壞的代碼之上提交新代碼。

盡管想讓構(gòu)建服務(wù)器成為持續(xù)交付流水線(xiàn)的中心之一，但我們也要考慮當(dāng)構(gòu)建服務(wù)器癱瘓的時(shí)候，構(gòu)建和部署的流程不應(yīng)該停滯不前。為此，構(gòu)建本身應(yīng)該盡可能健壯，并且可以在任何主機(jī)上重復(fù)工作。

這對(duì)像Maven那樣的一些構(gòu)建來(lái)說(shuō)相當(dāng)容易。可即便如此，一個(gè)Maven構(gòu)建也可能有無(wú)數(shù)的缺陷而使其無(wú)法被正常移植。

一個(gè)基于C語(yǔ)言的構(gòu)建會(huì)很難移植，如果你沒(méi)有幸運(yùn)到所有的依賴(lài)都在操作系統(tǒng)庫(kù)里可用的地步。還是那句話(huà)，健壯性通常能夠值回票價(jià)。

總結(jié)

我們快速掃過(guò)了構(gòu)建代碼的系統(tǒng)。看過(guò)了用Jenkins構(gòu)建持續(xù)集成服務(wù)器，也檢查了許多可能發(fā)生的問(wèn)題，DevOps工程師的生活總是很有意思，但并不總是很容易。

想了解更多IT資訊，請(qǐng)?jiān)L問(wèn)中培偉業(yè)官網(wǎng)：中培偉業(yè)