持續集成、交付與部署：區別以及如何配合運行

隨著DevOps軟體業的地位不斷增強，一個新的流行詞引起了我們的關注。「持續」目前已成為DevOps詞彙中最流行的詞語之一，被開發人員和公司廣泛使用。

儘管這個詞被廣泛使用，但它到底是什麼意思？當用在持續交付、持續部署和持續集成等概念中時，其含義有何變化？三者到底有什麼區別？企業、開發人員和項目經理如何才能在單個集成化的環境中更好地使用這些定義?

如果把開發工作流程分為以下幾個階段：

編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署

正如你在上圖中所看到的，「持續集成（Continuous Integration）」、「持續交付（Continuous Delivery）」和「持續部署（Continuous Deployment）」有著不同的軟體自動化交付周期。

在考察多個DevOps概念的細節時，我們首先要解釋持續在軟體領域的含義。

什麼是持續？

簡言之，持續指軟體在管道中以永不停止且完全連續的方式變化。

當然，這是DevOps人員的誇張說法，因為交付、部署和集成幾乎不可能做到100%持續。事實上，持續集成的應用可能接近每24小時就要重構和交付，而不是在每次代碼更改時進行。儘管這一速度並不像開發人員所承認的那樣具有即時性，但它仍然比DevOps出現之前常見的交付管道快得多。

什麼是CI（持續集成）？

持續集成是敏捷交付實踐的關鍵組件。它是一種DevOps軟體開發實踐，在這個過程中，代碼的更改在測試後定期合併到一個中央庫中。持續集成的主要目的是更快地查找並修復潛在問題，提高軟體質量，並且縮短發布新的更新的時間。

在持續集成實踐廣泛應用之前，開發人員一般以孤立的方式編寫代碼，在個人的工作完成後，僅嘗試將更改合併到主分支中。這種將多個代碼拼湊在一起的方法使得合併極為困難，而且非常耗時。

通過持續集成，開發人員可以頻繁地向中央庫分享，在集成前對代碼進行本地的單元測試。持續集成伺服器然後自動測試開發人員編寫的代碼，以保證代碼可以合併到主代碼庫中，而不會出現任何功能或集成錯誤。通過自動執行這個流程，伺服器可幫助開發人員幾乎連續編寫並測試少量代碼，這最大程度降低了嚴重錯誤出現的風險。

持續集成的優點：

• 「快速失敗」，在對產品沒有風險的情況下進行測試，並快速響應；

• 最大限度地減少風險，降低修復錯誤代碼的成本；

• 將重複性的手工流程自動化，讓工程師更加專注於代碼；

• 保持頻繁部署，快速生成可部署的軟體；

• 提高項目的能見度，方便團隊成員了解項目的進度和成熟度；

• 增強開發人員對軟體產品的信心，幫助建立更好的工程師文化。

做好持續集成，可為持續交付與持續部署打好堅實基礎。

什麼是持續交付？

持續交付是在持續集成的基礎上，將集成後的代碼部署到更貼近真實運行環境的「類生產環境」（production-like environments）中。持續交付優先於整個產品生命周期的軟體部署，建立在高水平自動化持續集成之上。

在大多數情況下，持續交付是一系列實踐，其設計目的是以幾乎連續的方式向用戶交付軟體。這些實踐保證了代碼可以快速部署到生產環境中，同時保證業務應用按預期運行。這種接近持續的更新交付方式由於在部署流程早期的優化而有可能實現。

一旦開發人員認為少量代碼已經準備就緒，他或她就可以將代碼發送給質量保證 (QA) 團隊進行測試和監控。由於應用基本上採用小批量單獨發送的方式，QA團隊可以快速檢查代碼，並找出可能出現的錯誤。在QA團隊進行這種評估的同時，構建的成果也發送到類生產環境中，經過嚴格測試後發布更改的結果。在完成所有評估後，軟體可以輕鬆部署。

試想想，如果說等到所有東西都完成了才向下個環節交付，導致所有的問題只能再最後才爆發出來，解決成本巨大甚至無法解決。比如，我們完成單元測試後，可以把代碼部署到連接資料庫的 Staging 環境中進行更多的自動化測試。如果代碼沒有問題，可以繼續手動部署到生產環境中。當然，持續交付並不是指軟體每一個改動都要儘快部署到產品環境中，它指的是任何的代碼修改都可以在任何時候實施部署。

持續交付使新功能的引入能夠以快速且可靠的方式實現，而且這對於試用新特性並立即看到客戶如何反應極有幫助。通過逐一提出新的想法，您可以知道該想法是否明確地傳達了預期的行為，而且能夠看到它是否正確運行，而不必發布大型的新系統。

持續交付的其他一些好處包括以下能力：

• 在後端安裝新特性，了解其在系統上的運行情況

• 迅速響應市場變化

• 根據業務戰略的改變而快速修改

• 減少錯誤，提高預測準確度

• 遠遠領先競爭對手

什麼是持續部署？

持續部署是指當交付的代碼通過評審之後，自動部署到生產環境中。持續部署是持續交付的最高階段。這意味著，所有通過了一系列的自動化測試的改動都將自動部署到生產環境。它也可以被稱為「Continuous Release」。

持續交付和持續部署兩者都簡稱CD，有些人將兩者互用，但二者有明顯的區別，需要明確理解和認識。

正如前文所述，持續交付是指幾乎連續地向用戶發布更新，然而，這些更新必須由DevOps團隊手動發布。與此相反，持續部署管道則完全自動運行。這樣，用戶能夠在編寫和測試代碼後儘快收到更新，而不必等待開發人員的手動干預。所需的任何測試在類生產環境中進行，並且在合併到主線分支之前完成。

隨著Docker等技術使得應用部署自動化更加輕鬆，持續交付和持續部署的區別肯定會越來越重要。這種易用性允許DevOps團隊將容器鏡像放到生產環境中，讓其自動部署。這種自動化流程是持續交付的關鍵，因為這個流程可由任何人在幾分鐘內完成。一旦開始部署，檢查日誌並確定關鍵指標是否受影響非常重要，無論是正面還是負面影響。

在某些情況下，使用持續交付可能不太實際，例如IT人員必須等待新特性上線的情況。儘管應用特性切換在有些情況下可以解決這個問題，但這並非始終可行。對於這一問題，關鍵在於公司必須根據業務需求而確定持續部署是否有意義，而不是根據IT限制。

持續部署的優點

持續部署主要好處是，可以相對獨立地部署新的功能，並能快速地收集真實用戶的反饋。

「You build it, you run it」，這是 Amazon 一年可以完成 5000 萬次部署，平均每個工程師每天部署超過 50 次的核心秘籍。

總結：如何配合運行

一旦進入到持續部署流程，您就有了多個自動化組件。持續集成和持續交付必須自動實現，而且您需要有能力自動將代碼部署到生產環境中。

理想的流程如下：

1. 開發人員將代碼提交到開發分支。

2. 持續集成伺服器收到更改，將其與主線合併。伺服器對代碼更改執行單元測試，並在測試成功後合併到暫存環境中。

3. 開發人員將代碼部署到暫存環境中，由QA對環境進行測試。代碼被移到生產環境，持續集成伺服器再次接收，進行測試後合併到生產環境中。

4. 將更改部署到生產環境。

最後，所有這些「持續行動」都有助於消除部署流程的開銷。合併代碼、合併後對特性進行重新測試、手動部署等任務一般會為服務帶來價值，因此，持續交付、部署和集成旨在從流程中消除這些費用。

如果您的公司與Flickr類似，每天部署多個更新和更改很有必要。另一方面，如果您是銀行這樣的機構，過於頻繁地在軟體中增加不同的特性和功能會使客戶感到困惑，並與您的業務戰略相悖。因此，您的公司要先確定DevOps的持續交付、持續部署和持續集成實踐的採用是否有益。

持續集成、持續交付和持續部署提供了一個優秀的 DevOps 環境，對於整個團隊來說，好處與挑戰並行。但是無論如何，頻繁部署、快速交付以及開發測試流程自動化都將成為未來軟體工程的重要組成部分。