持續集成

持續集成是什麼？

轉載自：https://kb.cnblogs.com/page/529677/

　　互聯網軟件的開發和發佈，已經造成了一套標準流程，最重要的組成部分就是持續集成（Continuous integration，簡稱 CI）。

　　本文簡要介紹持續集成的概念和作法。

　　1、概念

　　持續集成指的是，頻繁地（一天屢次）將代碼集成到主幹。

　　它的好處主要有兩個。

一、快速發現錯誤。每完成一點更新，就集成到主幹，能夠快速發現錯誤，定位錯誤也比較容易。

二、防止分支大幅偏離主幹。若是不是常常集成，主幹又在不斷更新，會致使之後集成的難度變大，甚至難以集成。

　　持續集成的目的，就是讓產品能夠快速迭代，同時還能保持高質量。它的核心措施是，代碼集成到主幹以前，必須經過自動化測試。只要有一個測試用例失敗，就不能集成。

　　Martin Fowler 說過，"持續集成並不能消除 Bug，而是讓它們很是容易發現和改正。"

　　與持續集成相關的，還有兩個概念，分別是持續交付和持續部署。

　　2、持續交付

　　持續交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。若是評審經過，代碼就進入生產階段。

　　持續交付能夠看做持續集成的下一步。它強調的是，無論怎麼更新，軟件是隨時隨地能夠交付的。

　　3、持續部署

　　持續部署（continuous deployment）是持續交付的下一步，指的是代碼經過評審之後，自動部署到生產環境。

　　持續部署的目標是，代碼在任什麼時候刻都是可部署的，能夠進入生產階段。

　　持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別，能夠參考下圖。

　　（圖片來源）

　　4、流程

　　根據持續集成的設計，代碼從提交到生產，整個過程有如下幾步。

　　4. 1 提交

　　流程的第一步，是開發者向代碼倉庫提交代碼。全部後面的步驟都始於本地代碼的一次提交（commit）。

　　4. 2 測試（第一輪）

　　代碼倉庫對 commit 操做配置了鉤子（hook），只要提交代碼或者合併進主幹，就會跑自動化測試。

　　測試有好幾種。

• 單元測試：針對函數或模塊的測試
• 集成測試：針對總體產品的某個功能的測試，又稱功能測試
• 端對端測試：從用戶界面直達數據庫的全鏈路測試

　　第一輪至少要跑單元測試。

　　4. 3 構建

　　經過第一輪測試，代碼就能夠合併進主幹，就算能夠交付了。

　　交付後，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換爲能夠運行的實際代碼，好比安裝依賴，配置各類資源（樣式表、JS 腳本、圖片）等等。

　　經常使用的構建工具以下。

• Jenkins
• Travis
• Codeship
• Strider

　　Jenkins 和 Strider 是開源軟件，Travis 和 Codeship 對於開源項目能夠無償使用。它們都會將構建和測試，在一次運行中執行完成。

　　4. 4 測試（第二輪）

　　構建完成，就要進行第二輪測試。若是第一輪已經涵蓋了全部測試內容，第二輪能夠省略，固然，這時構建步驟也要移到第一輪測試前面。

　　第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要作端對端測試。全部測試以自動化爲主，少數沒法自動化的測試用例，就要人工跑。

　　須要強調的是，新版本的每個更新點都必須測試到。若是測試的覆蓋率不高，進入後面的部署階段後，極可能會出現嚴重的問題。

　　4. 5 部署

　　經過了第二輪測試，當前代碼就是一個能夠直接部署的版本（artifact）。將這個版本的全部文件打包（ tar filename.tar * ）存檔，發到生產服務器。

　　生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號連接（symlink）指向這個目錄，而後從新啓動應用。這方面的部署工具備 Ansible，Chef，Puppet 等。

　　4. 6 回滾

　　一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的作法就是修改一下符號連接，指向上一個版本的目錄。

　　5、參考連接

• Gergely Nemeth, Continuous Deployment of Node.js Applications
• Codeship, Continuous Integration Essentials