詳解CI、CD & CD

CI, CD AND CD

當我們在談論現代的軟體編譯和釋出流程的時候，經常會聽到CI 和CD這樣的縮寫短語。CI很容易理解，就是持續整合。但是CD既可以指程式碼持續交付，也可理解為程式碼持續部署。CI和CD之間有很多相似的部分，但是也有很大的區別。這裡我們將給大家介紹它們之間的區別和聯絡。

持續整合（CONTINUOUS INTEGRATION）

在持續整合環境中，開發人員將會頻繁的提交程式碼到主幹。這些新提交在最終合併到主線之前，都需要通過編譯和自動化測試流進行驗證。這樣做是基於之前

持續整合過程中很重視自動化測試驗證結果，以保障所有的提交在合併主線之後的質量問題，對可能出現的一些問題進行預警。

持續交付（CONTINUOUS DELIVERY）

持續交付就是講我們的應用釋出出去的過程。這個過程可以確保我們儘可能快的實現交付。這就意味著除了自動化測試，我們還需要有自動化的釋出流，以及通過一個按鍵就可以隨時隨地實現應用的部署上線。
通過持續交付，您可以決定每天，每週，每兩週釋出一次，這完全可以根據自己的業務進行設定。

但是，如果您真的希望體驗持續交付的優勢，就需要先進行小批量釋出，儘快部署到生產線，以便在出現問題時方便進行故障排除。

持續部署（CONTINUOUS DEPLOYMENT）

如果我們想更加深入一步的話，就是持續部署了。通過這個方式，任何修改通過了所有已有的工作流就會直接和客戶見面。沒有人為干預（沒有一鍵部署按鈕），只有當一個修改在工作流中構建失敗才能阻止它部署到產品線。

持續部署是一個很優秀的方式，可以加速與客戶的反饋迴圈，但是會給團隊帶來壓力，因為不再有“釋出日”了。開發人員可以專注於構建軟體，他們看到他們的修改在他們完成工作後幾分鐘就上線了。基本上，當開發人員在主分支中合併一個提交時，這個分支將被構建、測試，如果一切順利，則部署到生產環境中。

合併CI CD and CD？

當然，正如我所說，他們每部分都更加接近生產環境。你可以構建自己的持續整合環境，然後，一旦團隊適應，你可以新增持續交付流，最後，可以新增持續部署流到整個工作流中。

舉例CI, CD and CD 流水線

到底值不值這樣做呢?

持續整合:

你需要具備哪些條件:

• 你的團隊需要為每個新功能，程式碼改進，或者問題修復建立自動化測試用例。
• 你需要一個持續整合伺服器，它可以監控程式碼提交情況，對每個新的提交進行自動化測試。
• 研發團隊需要儘可能快的提交程式碼，至少每天一次提交。

你能獲得什麼呢？:

• 通過自動化測試可以提早拿到迴歸測試的結果，避免將一些問題提交到交付生產中
• 釋出編譯將會更加容易，因為合併之初已經將所有問題都規避了
• 減少工作問題切換，研發可以很快獲得構建失敗的訊息，在開始下一個任務之前就可以很快解決。
• 測試成本大幅降低-你的CI伺服器可以在幾秒鐘之內執行上百條測試。
• 你的QA團隊花費在測試上面的時間會大幅縮短，將會更加側重於質量文化的提升上面。

持續交付

需要具備什麼條件？:

• 你需要有強大的持續整合元件和足夠多的測試項可以滿足你程式碼的需求
• 部署需要自動化。觸發是手動的，但是部署一旦開始，就不能人為干預。
• 你的團隊可能需要接受特性開關，沒有完成的功能模組不會影響到線上產品。

你能收穫什麼？:

• 繁瑣的部署工作沒有了。你的團隊不在需要花費幾天的時間去準備一個釋出。
• 你可以更快的進行交付，這樣就加快了與客戶之間的反饋環。
• 輕鬆應對小變更，加速迭代

持續部署

需要具備的條件:

• 研發團隊測試理念比較完善。測試單元的健壯性直接決定你的交付質量。
• 你的文件和部署頻率要保持一致。
• 特徵標誌成為釋出重大變化過程的固有部分，以確保您可以與其他部門（支援，市場營銷，公關…）協調。

可以獲得什麼？:

• 釋出頻率更快，因為你不需要停下來等待發布。每一處提交都會自動觸發釋出流。
• 在小批量釋出的時候，風險降低了，發現問題也可以很輕鬆的修復。
• 客戶每天都可以看到我們的持續改進和提升，而不是每個月或者每季度，或者每年。

如前所述，您可以採用持續整合，持續交付和持續部署。你怎麼做取決於你的需求和你的業務情況。如果你剛剛開始一個專案，並且還沒有客戶，那麼你就可以去建立這些工作流，最好是將這三個方面都實現，並且在你的專案迭代和需求增長中同時迭代它們。如果您已經有一個生產專案，那麼您可以一步一步地分階段去實現他們。