CICD - 持續集成與持續交付

持續集成與持續交付是軟件開發和交付中的實踐。咱們項目中一直在踐行持續集成（CI：Continuous Integration）；持續交付（CD：Continuous Delivery）未能達到理想狀態，只能實踐一部分。這篇文章用於總結CI/CD的實踐。

持續集成

 

 

 

什麼是持續集成？

軟件開發中，集成是一個極可能發生未知錯誤的過程。持續集成是一種軟件開發實踐，但願團隊中的成員頻繁提交代碼到代碼倉庫，且每次提交都能經過自動化測試進行驗證，從而使問題儘早暴露和解決。

持續集成的好處是什麼？

持續集成可使問題儘早暴露，從而也下降了解決問題的難度，正如老馬所說，持續集成沒法消除bug，但卻能大大下降修復的難度和時間。

如何作到持續集成？

首先，持續集成須要：

1. 單一的代碼倉庫，團隊成員都像該倉庫提交代碼；

2. 自動化構建且構建過程須要包含自動化測試；

3. 有單獨的集成機器用於構建；

4. 保證構建速度不要太慢（曾經有一個項目構建須要20分鐘，就會很痛苦）；

5. 在類產品環境進行測試；

6. 可以方便獲取最新的可執行程序；

7. 可視化，你們都能看到構建過程及結果；

8. 自動化部署。

其次，咱們經過如下步驟進行持續集成：

1. 程序員將代碼下載到本地，並在完成修改後提交代碼；

2. CI服務器監測代碼庫，並在有提交時自動觸發；

3. CI服務器對代碼進行構建，運行單元測試和集成測試；

4. CI服務器發佈可部署的artefact用於後續測試，並加上本次構建版本的標籤。

5. CI服務器通知團隊構建成功或者失敗；失敗發生時團隊須要儘快修復，以避免耽擱後續的持續集成過程，由於失敗時處於持續集成的暫停階段。

最後，須要就團隊責任達成共識：

1. 頻繁提交；

2. 提交以前確保測試經過；

3. 不在持續集成失敗時提交代碼；

4. 提交代碼後保證持續集成成功，否則不許回家😄

 

CI工具

Jenkins + K8s + docker

持續交付

什麼是持續交付？

持續交付是持續集成的擴展，指的是將經過自動化測試的軟件部署到產品環境。持續交付的本質是把每一個構建成功的應用更新交付給用戶使用。在持續交付的世界裏，咱們對完成的定義不是測試完成，而是交付到客戶手中。這裏須要注意的是，CD表明持續交付（Continuous Delivery）而不是持續部署（Continuous Deploy），由於部署也包括部署到測試環境，而持續交付表明的是功能的上線，交付給用戶使用。

持續交付的好處是什麼？

持續交付的好處在於快速獲取用戶反饋；適應市場變化和商業策略的變化。開發團隊保證每次提交的修改都是可上線的修改，那麼決定什麼時候上線，上線哪部分功能則徹底由產品業務團隊決定。

雖然持續交付有顯著的優勢，但也有不成立的時候，好比對於嵌入式系統的開發，每每須要軟硬件的配合。

如何作到持續交付？

1. 保證每次提交的修改都是可上線的修改。

2. 完善的測試（包括單元測試，組件測試，驗收測試）來測試新功能和進行迴歸測試；

3. 持續交付的前提條件是自動化的集成和部署；須要開發/測試/運維人員一塊兒完成。

藍綠部署

 

 

藍綠髮布須要注意⚠️（轉載自小程故事多的博客https://www.jianshu.com/p/022685baba7d）

當你切換到藍色環境時，須要穩當處理未完成的業務和新的業務。若是你的數據庫後端沒法處理，會是一個比較麻煩的問題；

可能會出現須要同時處理「微服務架構應用」和「傳統架構應用」的狀況，若是在藍綠部署中協調很差這二者，仍是有可能會致使服務中止。

須要提早考慮數據庫與應用部署同步遷移 /回滾的問題。

藍綠部署須要有基礎設施支持。

在非隔離基礎架構（ VM 、 Docker 等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險。

做者：陳菲TW 連接：https://www.jianshu.com/p/67f345ebec9b 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。