CI,CD理解

一.什麼是CI,CD

​ 當咱們在談論現代的軟件編譯和發佈流程的時候，常常會聽到CI 和CD這樣的縮寫短語。CI很容易理解，就是持續集成。

​ 可是CD既能夠指代碼持續交付，也可理解爲代碼持續部署。CI和CD之間有不少類似的部分，可是也有很大的區別。

它們之間的區別和聯繫。

1. 持續集成（CONTINUOUS INTEGRATION）
在持續集成環境中，開發人員將會頻繁的提交代碼到主幹。這些新提交在最終合併到主線以前，都須要經過編譯和自動化測試流進行驗證。這樣作是基於以前持續集成過程當中很重視自動化測試驗證結果，以保障全部的提交在合併主線以後的質量問題，對可能出現的一些問題進行預警。

2. 持續交付（CONTINUOUS DELIVERY）
持續交付就是講咱們的應用發佈出去的過程。這個過程能夠確保咱們儘量快的實現交付。這就意味着除了自動化測試，咱們還須要有自動化的發佈流，以及經過一個按鍵就能夠隨時隨地實現應用的部署上線。經過持續交付，您能夠決定天天，每週，每兩週發佈一次，這徹底能夠根據本身的業務進行設置。

可是，若是您真的但願體驗持續交付的優點，就須要先進行小批量發佈，儘快部署到生產線，以便在出現問題時方便進行故障排除。

3. 持續部署（CONTINUOUS DEPLOYMENT）
若是咱們想更加深刻一步的話，就是持續部署了。經過這個方式，任何修改經過了全部已有的工做流就會直接和客戶見面。沒有人爲干預（沒有一鍵部署按鈕），只有當一個修改在工做流中構建失敗才能阻止它部署到產品線。

持續部署是一個很優秀的方式，能夠加速與客戶的反饋循環，可是會給團隊帶來壓力，由於再也不有「發佈日」了。開發人員能夠專一於構建軟件，他們看到他們的修改在他們完成工做後幾分鐘就上線了。基本上，當開發人員在主分支中合併一個提交時，這個分支將被構建、測試，若是一切順利，則部署到生產環境中。

合併CI CD and CD？
固然，正如我所說，他們每部分都更加接近生產環境。你能夠構建本身的持續集成環境，而後，一旦團隊適應，你能夠添加持續交付流，最後，能夠添加持續部署流到整個工做流中。

cd

舉例CI, CD and CD 流水線

二.到底值不值這樣作呢?

持續集成:

• 你須要具有哪些條件:

你的團隊須要爲每一個新功能，代碼改進，或者問題修復建立自動化測試用例。
你須要一個持續集成服務器，它能夠監控代碼提交狀況，對每一個新的提交進行自動化測試。
研發團隊須要儘量快的提交代碼，至少天天一次提交。

• 你能得到什麼呢？:

經過自動化測試能夠提前拿到迴歸測試的結果，避免將一些問題提交到交付生產中
發佈編譯將會更加容易，由於合併之初已經將全部問題都規避了
減小工做問題切換，研發能夠很快得到構建失敗的消息，在開始下一個任務以前就能夠很快解決。
測試成本大幅下降-你的CI服務器能夠在幾秒鐘以內運行上百條測試。
你的QA團隊花費在測試上面的時間會大幅縮短，將會更加側重於質量文化的提高上面。

持續交付

• 須要具有什麼條件？:

你須要有強大的持續集成組件和足夠多的測試項能夠知足你代碼的需求
部署須要自動化。觸發是手動的，可是部署一旦開始，就不能人爲干預。
你的團隊可能須要接受特性開關，沒有完成的功能模塊不會影響到線上產品。

• 你能收穫什麼？:

繁瑣的部署工做沒有了。你的團隊不在須要花費幾天的時間去準備一個發佈。
你能夠更快的進行交付，這樣就加快了與客戶之間的反饋環。
輕鬆應對小變動，加速迭代

持續部署

• 須要具有的條件:

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

• 能夠得到什麼？:

發佈頻率更快，由於你不須要停下來等待發布。每一處提交都會自動觸發發佈流。 在小批量發佈的時候，風險下降了，發現問題也能夠很輕鬆的修復。 客戶天天均可以看到咱們的持續改進和提高，而不是每月或者每季度，或者每一年。 如前所述，您能夠採用持續集成，持續交付和持續部署。你怎麼作取決於你的需求和你的業務狀況。若是你剛剛開始一個項目，而且尚未客戶，那麼你就能夠去建立這些工做流，最好是將這三個方面都實現，而且在你的項目迭代和需求增加中同時迭代它們。若是您已經有一個生產項目，那麼您能夠一步一步地分階段去實現他們。