持續交付的實踐與思考

【編者的話】一直以來都在作團隊裏的基礎性工做，直到最近，成果開始慢慢展示，尤爲是上週剛看完《持續交付》這本書後，總結已經作的工做，又有了些新的感悟。

【3 天燒腦式基於Docker的CI/CD實戰訓練營 | 北京站】本次培訓圍繞基於Docker的CI/CD實戰展開，具體內容包括：持續集成與持續交付（CI/CD）概覽；持續集成系統介紹；客戶端與服務端的 CI/CD 實踐；開發流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及實踐經驗分享等。

過去一段時間，我都是圍繞着 Gitlab 的一些功能來開展的，從最開的代碼與應用配置管理，而後到 CI 系統，提高代碼質量，到最後完整的持續交付流程提高團隊工做效率。

那麼我就結合《持續交付》這本書的內容，正文開始。

爲何要有持續交付

1. 不敢發佈新功能：每次發佈都會心驚膽戰，由於一會兒發佈了太多功能，測試又沒作好，而這時候產品催着要上線。另外按照以往的經驗，由發佈而出問題的的機率最高；
2. 線上事故處理時間長：每次出線上事故，不能很快定位問題，若是是因爲同事線上改動了什麼，就更難定位問題了，而在以後你們可能會狠狠責怪那個同事，事實上，他也很無辜，由於沒有人告訴他什麼能作，什麼不能作，或者該怎麼作；
3. 發佈週期太長：因爲每次功能徹底開發完以後纔會發佈上線，而若是涉及到數據庫更改或者遷移，發佈週期可能會拖得太長；
4. 協做問題：好比新人來到團隊時，因爲被限制了各類線上的權限，尤爲是發佈權限，會致使不少工做開展不順利，而每次發佈求助於其餘同事的話，會形成溝通問題，進一步形成了協做上的問題。另外一個，每每因爲習慣於口頭上說下要發佈了，而後發佈過程對其餘人而言是不可見的，如果線上還須要操做些什麼的話，幾乎對其餘人是更不可見的；

持續交付能作到什麼

1. 讓軟件構建、部署、測試和發佈過程對全部人可見：由此，你們能夠學習過程，瞭解其餘人作了什麼，在一個規範的流程中工做，促進協做；
2. 改善反饋，更早發現問題：在一個完整的流水線中，能夠設置多個『檢查點』，簡答來講，就是加入多個測試環節，保證代碼質量，而在這個過程當中，越早發現問題，修復的成本越低；
3. 經過一個徹底自動化的過程在任意環境上部署和發佈軟件的任意版本：在陳浩大神的 《從 Gitlab 誤刪除數據庫想到的》 這篇文章裏，提到： 人管代碼，代碼管機器，其實持續交付就能達到這個效果。而且在一種極端狀況下，假如你使用的雲服務商掛了，你也能在其它雲服務商上面快速重建你的整個線上系統（固然，沒那麼簡單）。

持續交付的幾個原則

1. 爲軟件發佈建立一個可重複且可靠的過程：一鍵發佈與回滾，若是發佈出了問題，你幾乎能夠肯定不是發佈腳本自己的問題，由於這個腳本已經通過屢次檢驗；
2. 將幾乎全部的事情自動化：手工發佈及漫長又不可靠，採用自動化腳本，節省時間，節省精力；
3. 把全部的東西歸入版本控制：採用變動管理，方便審計，將全部的變動都在掌控之中，出問題能夠快速定位問題；
4. 提交併頻繁作讓你感到痛苦的事情：小步快走，分散痛苦與風險；
5. 提升內建質量：越早發現問題，修復成本越低，等 QA 或者用戶告訴你應用有問題的時候，修復成本很是高，也增長了你計劃外的工做；
6. 『Done』意味着『已發佈』：沒有完成百分之多少這種說法，反推着你將任務分解，將功能儘快發佈到生成環境中去，減小了產品反饋時間，提升了競爭力，也減小了風險；
7. 交付是每一個成員的責任：流程標準，每一個人均可以參與到流程的每個部分，促進協做，也幫助新人適應與提升；
8. 持續改進：不斷演進，改善發佈流程，這個流程須要持續的改進，提升吞吐，增長產量，提升質量；

持續交付的實踐

在目前的團隊持續交付流程中，咱們在每一個環節的實踐以下：

1. 提交：單元測試 Mocha/AVA，以及測試覆蓋率 nyc；
2. 編譯打包：即打包 Docker 鏡像，推送到 Registry ，目前尚未徹底引入 Docker 集羣，所以部署過程省略；
3. 部署文檔：用 Ansible 腳本自動將 API 文檔以及測試覆蓋狀況部署至靜態網頁文檔服務器，這個時候能夠直接將分支對應的文檔給客戶端開發，還能夠直接查看測試覆蓋率狀況，確認與改進單元測試；
4. Review：即提交 Merge Request，你們一塊兒 Code Review；
5. 部署應用：須要 Review 經過後，將代碼合併至 master 分支，而後手工點擊按鈕部署；
6. 回滾：假如應用出問題，能夠點擊按鈕一鍵回滾；

能夠看到，目前主要是缺失預發佈環境，這一步還須要將環境搭建腳本完善以後才能作到，而目前公司運維團隊仍是與咱們開發團隊分離的，所以達到相要的效果仍是得作些努力。

###總結
目前我已經作到：將應用配置單獨管理起來，以及部署相關的腳本都已經實現，所以才能很快地將持續交付流程跑起來。其實能夠這麼說：應用配置管理與自動部署腳本是持續交付流程的前提與基礎。

而持續交付流程一旦完善了，能極大改善咱們開發團隊的交付能力，甚至倒逼產品與運維團隊提升他們的效率：

• 對於產品團隊，咱們能要求他們將需求拆分儘量的細，一旦開發完成咱們能快速部署，因而他們能更快獲得反饋，從而提升產品的試錯能力。
• 對於運維團隊，咱們已經將部署流程優化了，因而他們能更專心於基礎設置的維護與改善，同時也能夠促進協做，推行全面的配置管理。

Reference

• about.gitlab.com/direction/
• about.gitlab.com/2016/08/26/…
• github.com/everpeace/c…
• docs.gitlab.com/ce/ci/envir…
• about.gitlab.com/2016/08/05/…

原文連接：持續交付的實踐與思考