Continuous Integration：持續集成，簡稱CI，是軟件開發周期的一種實踐，把代碼倉庫（Gitlab或者Github）、構建工具（如Jenkins）和測試工具（SonarQube）集成在一起，頻繁的将代碼合并到主幹然後自動進行構建和測試。簡單來說持續集成就是一個監控版本控制系統中代碼變化的工具，當發生變化是可以自動編譯和測試以及執行後續自定義動作。

簡化的含義為：頻繁的（一天多次的）将所有開發者的工作合并到主幹上。

以圖例說明：

從圖例上來看流程，分為3個步驟：

1. 首先，開發人員提交代碼到 Source Repository （源代碼倉庫）。
2. 然後，通過 git hook 等觸發 CI Server（持續集成服務器）的相關功能。執行 編譯 -> 測試 -> 輸出結果 等。
3. 最後，向開發人員反饋結果的 report。

可以看出，持續集成的 核心 在于 确保新增的代碼能夠與原先代碼正确的集成。與後續要介紹的持續交付以及持續部署，其最主要的差别也就在于其目标不同。

持續集成的優勢

和我們一直在使用的 階段集成（完成一個階段的開發後執行代碼的集成） 相比， 持續集成 的策略能夠為我們帶來哪些好處呢？

• 易于定位錯誤：每一次的代碼集成都需要執行相關的測試工作，持續集成頻繁的集成次數天然的将複雜的代碼邏輯切割為了小塊，也就使得每一次測試中遇到的錯誤能夠更加容易的被定位。
• 易于控制開發流程：更為細緻的工作提交也就意味着更容易判斷當前的工作進度，這對于管理者規劃開發流程而言提供了一個有效的參考，同時也為開發人員省下了彙報工作的時間。
• 易于CodeReview：對于大塊工作的切分自然也有助于做 CodeReview。
• 易于減少不必要的工作：build 以及 test 過程的自動化可以為你節約一大票的時間，從而投入到有價值的工作中去。

Continuous Delivery：持續交付，簡稱CD，是在CI的基礎進行了擴展，在CI環節完成了軟件構建和測試工作并形成了新的版本，那麼接下來就要進行交付，而這裡的交付并不是交付到生産環境，而是類生産環境（STAGING），我們可以理解為灰度環境或者預發環境，進而接受部分真實流量的測試。如果沒有問題的話則通過手動的方式部署到生産環境。

簡化的含義為：一種能夠使得軟件在較短的循環中可靠地發布的軟件工程方法。

與持續集成相比，持續交付的側重點在于 交付，其核心對象不在于代碼，而在于可交付的産物。

由于持續集成僅僅針對于新舊代碼的集成過程執行了一定的測試，其變動到持續交付後還需要一些額外的流程。

以圖例說明：

可以看到，與 持續集成 相比較，持續交付 添加了 Test -> Staging -> Production 的流程，也就是為新增的代碼添加了一個保證： 确保新增的代碼在生産環境中是可用的 。

在這一增加的流程中，Test 環節不僅僅包含基本的單元測試，還需要延伸到更為複雜的功能測試以及集成測試等。

在這裡，Staging 指的是 類生産環境 ，其盡可能地對真實的網絡拓撲、數據庫數據以及硬件設備等資源進行模拟，從而為測試人員反饋代碼在生成環境中的可能表現。

流程中每一個環節的執行結果都會對開發人員進行反饋，每一個出現的錯誤都會導緻版本的回滾。當測試完畢确認無誤之後，将由相關人員對其進行 手動部署到生産環境。

Continuous Deployment：持續部署，簡稱CD，它是在持續交付的基礎上打通最後一公裡的工作，就是把手動部署到生産環境的方式升級為自動部署。看下圖和上圖在最後部署到生産環境中的區别。

簡化的含義為：通過自動化部署的手段将軟件功能頻繁地進行交付。

與持續交付以及持續集成相比，持續部署強調了通過 automated deployment 的手段，對新的軟件功能進行集成。

以圖例說明：

可以看到，同 持續交付 相比 持續集成 的區别體現在對 Production 的自動化。

從開發人員提交代碼到編譯、測試、部署的全流程不需要人工的幹預，完全通過自動化的方式執行。

這一策略加快了代碼提交到功能上線的速度，保證新的功能能夠第一時間部署到生産環境并被使用。

持續集成、持續交付和持續部署其目的是減少代碼改動到投入生産的所需時間，提早發現風險、減少QA的測試時長、減少運維的人工幹預。整體上是一個提效的過程。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!