理解問題架構(gòu)給持續(xù)交付帶來的難題，一種方式就是舉個(gè)反例。 讓我們假設(shè)有一個(gè)大的web應(yīng)用程序，它有許多不同的功能。

中培偉業(yè)專家龔老師在這里做了比喻，他指出，在這個(gè)應(yīng)用里有一個(gè)靜態(tài)網(wǎng)站。整個(gè)web應(yīng)用部署成一個(gè)單獨(dú)的Java企業(yè)版應(yīng)用程序。所以，如果只是想改正一個(gè)靜態(tài)網(wǎng)站的拼寫錯(cuò)誤，我們就需要重新構(gòu)建整個(gè)網(wǎng)絡(luò)應(yīng)用，然后重新部署。

雖然這個(gè)例子看上去很蠢，有見識(shí)的讀者都不會(huì)這么干，但是我還真看到過這樣的反模式。作為DevOps工程師，這可能是我們要解決的真實(shí)場(chǎng)景。

讓我們把上面這團(tuán)亂麻分解一下。在想要改正拼寫錯(cuò)誤的時(shí)候發(fā)生了什么？讓我們來看一看：

1．雖然知道拼寫錯(cuò)誤是哪一個(gè)，但是我們需要修改哪一個(gè)代碼庫(kù)呢？因?yàn)檫@是一個(gè)單塊系統(tǒng)，我們需要在代碼庫(kù)的版本控制系統(tǒng)里創(chuàng)建一個(gè)分支。這個(gè)新分支與生產(chǎn)環(huán)境的代碼相符。

2．新建分支并改正拼寫錯(cuò)誤。

3．用修改后的代碼構(gòu)建一個(gè)新的工件。賦給它一個(gè)新版本號(hào)。

4．將這個(gè)新工件部署到生產(chǎn)環(huán)境。

好了，乍一看并不是太壞。但是考慮一下：

變更是在整個(gè)業(yè)務(wù)系統(tǒng)上做的。如果我們?cè)诓渴鹦掳姹镜臅r(shí)候出了什么錯(cuò)，其間的每分鐘都會(huì)遭受損失。我們真的那么肯定這個(gè)變更不會(huì)影響其他部分？

事實(shí)上并不只是改正了拼寫錯(cuò)誤。我們還在生成新成品的時(shí)候改變了版本號(hào)。但是改變版本號(hào)應(yīng)該是安全的，對(duì)吧？你確定嗎？

這里的關(guān)鍵是我們已經(jīng)在確認(rèn)變更是否安全這件事上費(fèi)了相當(dāng)大的精力。系統(tǒng)太復(fù)雜了，即使考慮微不足道的變更所帶來的影響也變得相當(dāng)困難。

現(xiàn)實(shí)中，一個(gè)變更通常要比改正拼寫錯(cuò)誤要復(fù)雜得多。所以，我們需要為所有變更考慮部署鏈上包括人工校驗(yàn)在內(nèi)的所有方面。

這樣一來我們就到了一個(gè)不該去的地方。

架構(gòu)經(jīng)驗(yàn)法則有一些架構(gòu)法則可以幫助我們處理上文描述的惡劣情形。

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