持續集成、持續交付和持續部署

最近在瞭解項目自動化構建的時候接觸到了這三個概念，它們都來自敏捷開發的思想。敏捷的關鍵在於對變動的快速響應，下降變動所引發的代價，並及時地向客戶提交可運行的軟件增量。這種方式能夠快速交付成功的系統。

背景

傳統的軟件開發，從需求獲取到產品上線，會經歷必定的週期，可能數月，可能數年。一旦產品發生了變動，又須要必定時間才能將更新發布上線。這個週期若是很長，將會給競爭者帶來機會並佔領市場，用戶也須要等待好久才能看到本身想要的產品。因此，相當重要的一點就是縮短週期時間，這個時間包括設計、開發、測試、部署等階段。因而就有了持續集成，持續交付，持續部署這三個概念，它們旨在縮短這個週期時間，強調在任什麼時候刻軟件都處於可發佈的狀態。這樣咱們能夠及時地將軟件發佈出來，交由客戶使用，而且及時獲得客戶的反饋，產生新的更好的版本。

這三個過程都強調持續性，也就是說，每完成一個部分，就向下一個環節交付，及時發現問題，及時調整。由於不可能在事先就知道完整、正確的需求是什麼樣的，同時客戶的需求也在不斷變化，因此，應該儘可能縮短從獲取需求、開發、測試到部署等一系列活動的週期，儘快給用戶展示可用的產品，並及時獲得反饋，逐步求精。

概念

持續集成Continuous Intergration：頻繁地、及時地將代碼集成到主幹。好處是快速發現錯誤，防止分支大幅偏離主幹。核心措施是，代碼在集成到主幹以前，必須經過自動化測試，根據測試結果，全部測試用例都成功以後才能肯定新代碼和原有代碼能夠成功集成在一塊兒。

持續交付Continuous Delivery：將軟件的新版本，交付給質量團隊或者用戶，以供評審。它是持續集成的下一步，強調的是，無論怎樣更新，軟件都是隨時能夠交付的。

持續部署Continuous Deployment：當交付的代碼經過評審以後，自動部署到生產環境中。它是持續交付的下一步，可以自動化完成測試、構建、部署等步驟。

流程

1. 開發者向代碼倉庫提交代碼，這叫一次commit。
2. 當代碼倉庫檢測到此次commit以後，會進行第一輪測試。一般代碼倉庫會對commit操做配置鉤子（hook），由鉤子來執行相應的測試程序。
3. 經過了第一輪測試，此次commit就能夠成功地合併到主幹了。這時候就完成了集成階段，能夠進入到交付階段了。
4. 在代碼交付階段，會先進行構建，將源代碼轉換爲能夠運行的程序。這一步也能夠在第一輪測試以前進行。
5. 構建完成以後，會進行第二輪測試。全部的測試工做都會進行，包括單元測試、集成測試等等。以自動化測試爲主，輔以人工測試。這個過程必須保證全部更新點都被測試到，不然將不能保證部署階段的質量。
6. 經過了第二輪測試以後，當前代碼就能夠部署到生產服務器了。此時會生成當前代碼的一個可部署版本，將這個文件打包存檔，發佈到生產服務器上。
7. 若是當前版本發生了問題，能夠回滾到上一個版本的構建結果。

 

參考

1. The Product Manager’s Guide to Continuous Delivery and DevOps

2. Continuous Delivery vs Continuous Deployment

3. Continuous Intergration Essentials