持續(xù)集成和持續(xù)交付（CI/CD）是DevOps背后的助推力之一。如果你的企業(yè)正在考慮使用DevOps，那么CI/CD絕對是需要考慮的其中一部分。但是CI/CD到底意味著什么？為什么它如此重要呢？為了對你的DevOps工具包和IT部署進(jìn)行戰(zhàn)略規(guī)劃，深入理解CI/CD至關(guān)重要。本文中，我們將探討CI/CD所需解決的難點(diǎn)、需要的工具以及預(yù)期的收益。

首先，我們從大局著手。DevOps旨在創(chuàng)建一個流暢的工作流程，并盡可能減少越區(qū)切換和建立快速反饋回路。這意味著什么呢？工作會從第一步開始一直向前推進(jìn)，并且在理想狀態(tài)中，無需倒退再進(jìn)行修復(fù)，因?yàn)樗鼈儜?yīng)該能夠驗(yàn)證和修復(fù)問題。為此，開發(fā)人員需要快速的反饋回路。該反饋通過快速自動化測試提供，并且該測試將驗(yàn)證代碼在進(jìn)入下一階段之前能否按照預(yù)期工作。

為了減少越區(qū)切換，成員較少的小組將使用較小的功能并且掌控整個流程：創(chuàng)建請求、提交、QA以及部署。其重點(diǎn)是快速推出小段代碼，因?yàn)樽兏叫?，診斷、修復(fù)和補(bǔ)救就越容易。

持續(xù)集成（CI）實(shí)現(xiàn)了從第一步到最后一步的快速流程，并通過持續(xù)交付（CD）將其擴(kuò)展到實(shí)際生產(chǎn)部署。我們將其稱為CI/CD?，F(xiàn)在，我們開始深入了解它們。

深入探索持續(xù)集成

首先，我們關(guān)注CI/CD的CI（持續(xù)集成）部分。實(shí)際上，大部分公司僅執(zhí)行了CI。而完成整個CI/CD，需要該企業(yè)已經(jīng)是一個成熟的DevOps企業(yè)。

說到集成，我們指的是程序員在其本地計算機(jī)上開發(fā)的代碼（包括更新或添加新特性）集成到代碼庫中。這一過程會面臨以下3個挑戰(zhàn)：

1. 跟蹤所有變更，以便在發(fā)生錯誤時仍然可以恢復(fù)到之前的狀態(tài)，以最大程度地避免服務(wù)中斷。

2. 當(dāng)多個開發(fā)人員同時在同一個項(xiàng)目中工作時需要管理沖突

3. 將新代碼添加到代碼庫之前需要捕捉到錯誤

接下來，我們將討論可以解決以上幾個痛點(diǎn)的3個工具。

1、 版本控制

隨著代碼從開發(fā)人員轉(zhuǎn)移到運(yùn)維人員，它會根據(jù)測試結(jié)果不斷進(jìn)行調(diào)整。所有的更改都會被版本控制系統(tǒng)捕捉。版本控制是一個軟件工具可以幫助開發(fā)者管理源代碼更改。在特殊類型的數(shù)據(jù)庫中它會一直跟蹤所有更改。

理想狀態(tài)下，軟件系統(tǒng)的所有部分都會被捕獲到，包括：

• 源代碼

• 資產(chǎn)

• 環(huán)境

• 軟件開發(fā)文檔

• 對系統(tǒng)中存儲的文件的任何更改

2、master和開發(fā)分支

通常情況下，在同一個項(xiàng)目中會有多個開發(fā)人員一起工作，可能是幾個人也可能是上百個程序員，因此這可能會導(dǎo)致混亂。為了不讓穩(wěn)定性遭受破壞或減輕在版本控制主分支中引入錯誤的風(fēng)險，每個開發(fā)人員應(yīng)該并行處理系統(tǒng)的不同部分。他們通過本地計算機(jī)上的“分支機(jī)構(gòu)(branch）”執(zhí)行這一操作。

但是在分支機(jī)構(gòu)上工作本身并不是解決方案，每個開發(fā)人員正在處理的代碼必須集成到不斷擴(kuò)充的代碼庫中。

開發(fā)人員在分支機(jī)構(gòu)中工作而無需提交主分支的時間越長，與每個人在master中所做的更改進(jìn)行集成和合并的難度就越大。所以，由于開發(fā)人員在不提交代碼的情況下處理代碼的時間越長，獲得代碼的難度就越大，因此從邏輯上來說就應(yīng)該增加提交代碼的頻率。但是更好的方法是，使其持續(xù)集成。

下圖描繪了如何可視化不同分支。藍(lán)色是master分支，其他顏色都是在自己的分支上工作的單個開發(fā)人員，這些分支最終合并到master分支中。

不過，就算有分支機(jī)制也并非一帆風(fēng)順。即使開發(fā)人員每天提交代碼，沖突仍然會發(fā)生。因?yàn)槠渌麍F(tuán)隊(duì)成員會繼續(xù)做出更改，而沒有考慮各方的訴求。實(shí)際上，集成問題經(jīng)常需要返工，包括手動合并沖突的更改。但是比起開發(fā)團(tuán)隊(duì)整周或一個月都在埋頭工作而不處理沖突，找出并解決一天工作中的沖突要簡單很多。因此，盡管無法避免集成問題，但CI可以大大減少集成問題。

3、部署流水線和自動化測試

QA的部分工作是找出錯誤并確保代碼是可部署的。傳統(tǒng)流程中，在部署完成后會由一個單獨(dú)的團(tuán)隊(duì)來負(fù)責(zé)QA。因?yàn)殚_發(fā)人員通常每年僅執(zhí)行幾次測試，因此在引入更改幾個月后他們才了解到錯誤。到那時，因果之間的聯(lián)系可能已經(jīng)很難查證，導(dǎo)致診斷越來越困難。但是自動化測試解決了這個問題。

使用部署流水線之后，每次將代碼添加到版本控制中都會觸發(fā)一系列測試。流水線會自動構(gòu)建和測試代碼以確保它可以按預(yù)期工作，并且一旦集成到代碼庫中就可以繼續(xù)工作。雖然在測試環(huán)境中代碼可以完美執(zhí)行，但它仍有可能在生產(chǎn)環(huán)境中不幸失敗，因?yàn)樯a(chǎn)中的環(huán)境和所有依賴項(xiàng)都會影響代碼性能。依賴項(xiàng)并不屬于app中的一部分，但仍需要運(yùn)行它。例如數(shù)據(jù)庫、數(shù)據(jù)/對象存儲以及服務(wù)和應(yīng)用程序可能需要調(diào)用的API。因此，開發(fā)和測試環(huán)境必須模仿生產(chǎn)環(huán)境。另外，必須對所有依賴項(xiàng)進(jìn)行代碼測試。

簡而言之，部署代碼時有3個測試階段，每個階段都會額外增加復(fù)雜性：

（1）驗(yàn)證代碼本身是否按照預(yù)期工作；

（2）在代碼庫中繼續(xù)進(jìn)行驗(yàn)證；

（3）驗(yàn)證性能在具有所有依賴項(xiàng)的類生產(chǎn)環(huán)境中保持不變。

如果代碼每天都被提交到版本控制中，則可以對其進(jìn)行自動化測試，并且在引入代碼之日會標(biāo)記出任何構(gòu)建、測試或集成錯誤，從而可以立即進(jìn)行修復(fù)。這確保代碼總是處于可部署和可運(yùn)送的狀態(tài)，稱為綠色構(gòu)建。

自動測試允許開發(fā)人員提高測試和集成的頻率——從周期性執(zhí)行到持續(xù)測試集成，并在約束最少的情況下發(fā)現(xiàn)問題。最糟糕的情況也不過是一天的工作都浪費(fèi)了。

關(guān)于版本控制的爭議

關(guān)于是否改在版本控制中存儲敏感信息（如 access token、密鑰和密碼）進(jìn)行了一些討論。一方面，有人認(rèn)為應(yīng)該將一切（包括secret）都存儲在這里，從而將這一方法推向極限。但是有人認(rèn)為這是不良做法，并認(rèn)為敏感信息應(yīng)該單獨(dú)存儲。

版本控制允許開發(fā)人員比較、合并和還原以前的修訂。通過允許他們在出現(xiàn)問題時將生產(chǎn)中的系統(tǒng)快速還原到以前的版本，從而將風(fēng)險降到最低。為此，無論版本多小，所有更新和更改都必須在版本控制中進(jìn)行跟蹤。如果不是這樣，生產(chǎn)中的代碼將開發(fā)和測試環(huán)境中的代碼不匹配，從而導(dǎo)致不一致。

簡而言之，版本控制是事實(shí)的單一來源，包含了系統(tǒng)的預(yù)期狀態(tài)以及所有以前的狀態(tài)。通過將所有生產(chǎn)環(huán)境中的組件放置到版本控制中，開發(fā)人員可以重復(fù)可靠地重現(xiàn)工作軟件系統(tǒng)中的所有組件。這是啟用所謂的不可變基礎(chǔ)架構(gòu)的關(guān)鍵，我們將在稍后討論。

持續(xù)交付：擴(kuò)展CI以實(shí)現(xiàn)流暢的代碼部署

即使使用了持續(xù)集成，將代碼部署到生產(chǎn)中的過程依舊是手動、乏味且容易出錯的。如果真是這樣，那么顯然不會頻繁地將代碼部署到生產(chǎn)中。IT部門會盡可能避免執(zhí)行艱巨而危險的任務(wù)，這會導(dǎo)致要部署的代碼與生產(chǎn)中運(yùn)行的代碼之間差異越來越大，進(jìn)一步加具危險，然后形成一種惡性循環(huán)。那么解決這一惡性循環(huán)的答案是啟用CI/CD中的CD部分。

CD擴(kuò)展了CI，確保在將代碼推廣到整個用戶群之前讓代碼在生產(chǎn)環(huán)境中能夠平滑運(yùn)行。最常見的CD方法是金絲雀和藍(lán)綠部署。

進(jìn)行藍(lán)綠部署期間，IT會與當(dāng)前版本一起部署一個新的組件或應(yīng)用程序版本。新版本（綠）被部署到生產(chǎn)中并對其進(jìn)行測試，與此同時當(dāng)前版本（藍(lán)）依舊可以使用。如果新版本的代碼運(yùn)行良好，那么所有用戶將會切換到新版本中。

金絲雀部署也有兩個版本：當(dāng)前版本和更新版本。IT開始將一小部分用戶請求路由到新版本。代碼和用戶的行為會被持續(xù)監(jiān)控。如果錯誤率或用戶投訴并沒有增加，則路由到新版本的請求份額將逐漸增加（例如，1%、10%、50%最后到100%）。一旦所有請求都發(fā)送到新版本中，那么舊版本就會自動退休或刪除。

通過按需環(huán)境創(chuàng)建自助服務(wù)

現(xiàn)在，我們已經(jīng)研究了CI、CD及其各自的工具和方法，下面我們來討論環(huán)境和基礎(chǔ)架構(gòu)。CI / CD需要一種創(chuàng)新的方法。

如我們所見，自動化測試使開發(fā)人員可以自己執(zhí)行QA。為了確保一切都能在生產(chǎn)中正常運(yùn)行，他們必須在整個開發(fā)和測試過程中使用類似于生產(chǎn)的環(huán)境。

傳統(tǒng)上，開發(fā)人員必須向Ops團(tuán)隊(duì)請求（手動）設(shè)置的測試環(huán)境。此過程可能需要數(shù)周，有時甚至數(shù)月。此外，手動部署的測試環(huán)境通常會出現(xiàn)配置錯誤，或者與生產(chǎn)環(huán)境有很大差異，因此即使代碼通過了所有預(yù)部署測試，仍然會導(dǎo)致生產(chǎn)問題。

CI / CD的關(guān)鍵部分是為開發(fā)人員提供按需類似于生產(chǎn)的環(huán)境，使其可以在自己的工作站上運(yùn)行。為什么這很重要？開發(fā)人員只有在相同的條件下進(jìn)行部署和測試時，才能知道代碼在生產(chǎn)中的行為。如果他們在不同的環(huán)境中測試代碼，則當(dāng)最終將代碼部署到生產(chǎn)環(huán)境中時，他們可能會發(fā)現(xiàn)代碼不兼容，那么此時對客戶造成了重大影響，再解決問題已經(jīng)為時已晚。

不可變基礎(chǔ)設(shè)施：牛與寵物

在討論版本控制系統(tǒng)時，我們談到了將環(huán)境與所有其他應(yīng)用程序組件進(jìn)行編碼的需求，接下來讓我們進(jìn)一步討論這些環(huán)境。

如果在版本控制中定義了環(huán)境規(guī)范并進(jìn)行了編碼，那么在容量增加（水平擴(kuò)展）時復(fù)制環(huán)境就像按一個按鈕一樣簡單（盡管之后它很有可能通過Kubernetes自動化了）。

擴(kuò)展意味著在高峰時段增加計算能力。例如，Netflix的使用率在每個星期五晚上達(dá)到峰值，然后在午夜之后的某個時間再次恢復(fù)正常。為了確保享受無緩沖的視頻，Netflix復(fù)制了其流控制組件（已在版本控制中進(jìn)行了編碼），以滿足需求。然后，流量恢復(fù)后所有所謂的副本都被破壞，使流容量恢復(fù)正常。

為了實(shí)現(xiàn)這一點(diǎn)，至關(guān)重要的是，每當(dāng)實(shí)施基礎(chǔ)架構(gòu)或應(yīng)用程序更新時，這些基礎(chǔ)架構(gòu)或應(yīng)用程序都會自動復(fù)制到其他地方并置于版本控制中。這將確保無論何時創(chuàng)建新環(huán)境，它都將與整個流水線（從dev到QA到生產(chǎn)）的環(huán)境匹配。例如，如果Netflix要更新其流服務(wù)而忘了捕獲版本控制的更改，它將在高峰時段復(fù)制有故障或過時的組件，從而導(dǎo)致問題甚至服務(wù)中斷。

由于掌握了版本控制中的環(huán)境編碼，因此手動更改環(huán)境不是最佳實(shí)踐，因?yàn)槿魏问謩硬僮鞫既菀壮鲥e。而應(yīng)該將更改放入版本控制中，并從頭開始重新創(chuàng)建環(huán)境（和代碼）。這稱為不可變基礎(chǔ)架構(gòu)。這些與CI / CD部分中討論的應(yīng)用于基礎(chǔ)架構(gòu)的原則相同。

你也許聽過牛與寵物的比喻。這個比喻放在這里十分合適。以前，基礎(chǔ)設(shè)施被視為寵物。如果有問題，你會盡力解決它，以便它可以生存。今天，基礎(chǔ)設(shè)施被視為牛。如果它無法正常工作或需要更新，請殺死它并啟動新環(huán)境。這非常強(qiáng)大，并且大大降低了問題潛入系統(tǒng)的風(fēng)險。

發(fā)布與部署解耦

傳統(tǒng)上，軟件發(fā)布是由市場啟動日期驅(qū)動的。因此，要發(fā)布的新功能會在宣布日期的前一天部署到生產(chǎn)中。但是，我們知道將特性或更新發(fā)布到生產(chǎn)中總是有風(fēng)險的，尤其是如果你一次發(fā)布整個特性時。因此，將部署與發(fā)布捆綁在一起將使IT部門總是需要為失敗膽戰(zhàn)心驚。試想一下，如果在廣泛推廣的前一天發(fā)生了重大問題，IT團(tuán)隊(duì)就會感到恐慌，并且會在客戶和媒體中引起巨大不良反響。

更好的方法是使部署與發(fā)布解耦。盡管這兩個詞經(jīng)常互換使用，但它們是兩個獨(dú)立的過程。部署意味著將軟件版本安裝到任何環(huán)境（包括生產(chǎn)環(huán)境）中。它不一定必須與發(fā)布相關(guān)聯(lián)。另一方面，發(fā)布意味著向客戶群提供新功能。在整個功能開發(fā)過程中頻繁進(jìn)行生產(chǎn)部署的目的是降低服務(wù)中斷的風(fēng)險，該風(fēng)險由IT部門承擔(dān)。另一方面，何時向客戶展示新功能應(yīng)該是業(yè)務(wù)決策，而不是技術(shù)決策。

部署周期長會決定新功能發(fā)布的頻率。如果IT可以按需部署，那么公開新功能的速度應(yīng)該成為業(yè)務(wù)和市場營銷的決定。

結(jié) 論

總而言之，CI要求將代碼連續(xù)集成到代碼庫中，以在發(fā)生錯誤時捕獲錯誤，從而最大程度地減少返工。要實(shí)現(xiàn)這種方法，需要三個工具：版本控制，以跟蹤所有更改并使整個團(tuán)隊(duì)都可以使用最新的源代碼版本；master，負(fù)責(zé)自己分支的開發(fā)人員每天合并更新；部署流水線將觸發(fā)一系列測試，基本上是自動進(jìn)行QA。

CD擴(kuò)展了CI，以驗(yàn)證代碼是否處于可部署狀態(tài)，并自動將其釋放到生產(chǎn)環(huán)境中。為此，需要一個成熟的DevOps組織，該組織必須先掌握CI，然后才能嘗試使用CD。

如果實(shí)施得當(dāng)，CI（/ CD）將大大提高你的IT團(tuán)隊(duì)的生產(chǎn)力。你的系統(tǒng)或應(yīng)用程序在不斷改進(jìn)，同時將部署風(fēng)險降至最低，從而增強(qiáng)了生產(chǎn)力和員工滿意度的積極循環(huán)。此外，快速推出新功能和更新可推動創(chuàng)新，進(jìn)而更快，更頻繁地為用戶帶來價值。顯然，隨著越來越多的組織采用這些DevOps方法，由于傳統(tǒng)方法無法與CI / CD競爭，因此對那些沒有采用DevOps方法的企業(yè)，壓力會越來越大。

附錄：部署流水線測試套件

• 集成測試檢查應(yīng)用程序如何與其他應(yīng)用程序和服務(wù)交互，以確保代碼與這些依賴項(xiàng)正確交互。遠(yuǎn)程服務(wù)的虛擬或模擬版本可用于準(zhǔn)確地重新創(chuàng)建生產(chǎn)環(huán)境。

• 驗(yàn)收測試會驗(yàn)證是否滿足業(yè)務(wù)需求，以確保功能或應(yīng)用程序?yàn)樽罱K用戶提供所需的價值。

• 性能測試可驗(yàn)證該應(yīng)用程序在類似生產(chǎn)的負(fù)載下如何在整個堆棧（代碼、數(shù)據(jù)庫、存儲、網(wǎng)絡(luò)、虛擬化）中工作。由架構(gòu)決策或網(wǎng)絡(luò)、數(shù)據(jù)庫、存儲或其他系統(tǒng)的意外限制引起的問題應(yīng)在此處解決。

• 非功能測試包括可用性、可伸縮性、性能、容量、安全性等。這些要求取決于環(huán)境的正確配置。測試將驗(yàn)證環(huán)境是否已正確構(gòu)建和配置。

• 冒煙測試驗(yàn)證該應(yīng)用程序可以連接到所有支持系統(tǒng)，例如數(shù)據(jù)庫、服務(wù)或信息傳遞系統(tǒng)；冒煙測試通常是手動的。

也有自動安全性測試以及探索性和其他手動或資源密集型測試。我們的目標(biāo)是盡早捕獲更多錯誤，并使用這些更耗時的測試來驗(yàn)證高層次的需求，并將產(chǎn)品完全集成到盡可能接近生產(chǎn)的環(huán)境中。