持續集成是什麼

互聯網軟件的開發，已經成熟、標準化，其中最重要的組成部分就是持續集成（Continuous integration，簡稱CI）。

持續集成是一種軟件開發實踐，即團隊開發成員常常集成它們的工做代碼，每一個成員天天至少集成一次，也可能會發生屢次集成。每次集成都經過自動化的構建（包括編譯，發佈，自動化測試）來驗證，從而儘早地發現集成BUG，並解決。

簡單說就是：

頻繁地提交代碼，集成進主幹分支，及早發現問題，並解決。

舉個例子：

1. 公司某項目在代碼倉庫存在三個分支：dev（開發分支）、master（主幹分支）、release（預發佈分支）
2. 開發組有兩個以上的人員在分別開發A、B、C...等不一樣的功能模塊
3. 每一個開發人員完成自身某個功能模塊的開發後，須要將本地檢驗合格的代碼push到dev分支，
4. 代碼倉庫配置的webhooks會根據commit動做回調測試服務器，測試服務器對提交的代碼進行單元測試
5. 單元測試經過，則集成進主幹分支；不經過則不集成，並通知生成方完善處理
6. 集成進主幹分支後，主幹分支進行編譯、構建（主要包含環境配置、安裝依賴、資源整理）
7. 構建完成，進行集成測試（總體測試 [, 端對端測試]），測試經過則將主幹分支合併至預發佈分支（release）
8. 合併至預發佈分支後，預發佈分支根據實際需求選擇是否直接實施部署
9. 若是部署，則部署服務器則會將最新預發佈分支的代碼，打包爲當前版本，並推送至生產服務器
10. 生產服務器解壓最新代碼包至指定目錄，修改程序的路徑指向最新代碼目錄，並重載生產服務
11. 如若出現異常，生產服務器則直接將程序路徑指向上一個版本的目錄，進行回滾

如上所述，一個完整的持續集成流程至少須要包含：測試服務、部署服務、生產服務三部分；
單元測試、集成測試、功能測試這些自動化測試方法，是項目持續部署的基礎，大部分測試都應該是自動化完成的，自動化測試覆蓋不到的，應由人工測試；
而一切的一切都是從push代碼那一刻開始。

如圖：

持續集成最少能帶來如下兩點好處：

• 快速發現錯誤。每完成一點更新，就集成到主幹，能夠快速發現錯誤，定位錯誤也比較容易。
• 能幫助項目在短期內安全的發佈新特性，而不用等上幾個月甚至幾年。

能夠看出，持續集成的目的，就是讓產品能夠快速迭代，同時還能保持高質量。它的核心措施是，代碼在進行下一步活動以前，必須經過自動化測試，只要有一個測試用例失敗，就不能集成，從而保證軟件質量，其也是TDD（測試驅動開發）的一個重要實踐。

實際上，在生產環境裏的 Bug 使你付出的代價每每要數倍於在自動化測試時發現的 Bug。
換句話說，若是你計算投資與回報的話，持續集成（TDD/測試驅動開發）將具備壓倒性的優點。

下面咱們瞭解三個關於測試的概念：

單元測試

單元測試（unit testing），也叫模塊測試，是指對軟件中的最小可測試單元進行檢查和驗證，小到每一個變量、每一個函數、每一個類。

簡單說：單元測試能夠發現你編寫的每一個函數、模塊的錯誤，並輸整理出。

以下測試用例：

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    });
  });
});複製代碼

使用工具執行該測試用例以後，其會輸出正確率、錯誤率、錯誤節點及測試報表，從而判斷咱們所編寫程序的質量和錯誤，固然，實際測試的測試用例是須要引入並配置咱們的程序代碼，執行測試的。

集成測試

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將全部模塊按照設計要求組裝成爲子系統或系統，進行總體測試。

簡單說：集成測試是把各個模塊合併在一塊兒，做爲總體進行功能測試，發現錯誤，並輸出。

軟件開發的生命週期中，集成是必然的，具體的集成過程多是顯性的也多是隱性的。只要有集成，老是會出現一些常見問題，工程實踐中
，幾乎不存在軟件模塊合併過程當中不出任何問題的狀況。且集成測試須要花費的時間遠遠超過單元測試，但進行集成測試是極有必要的。

端對端測試

端對端測試，也叫交互測試，是軟件被用於各類模擬真實使用場景中的測試，包含UI、交互、功能等各個方面。

在測試中，把程序看做一個不能打開的黑盒子，在徹底不考慮程序內部結構和內部特性的狀況下，對程序測試，它只檢查程序功能是否按照需求規格說明的規定正常使用，
程序是否能適當地接收輸入數據而產生正確的輸出信息。端對端測試着眼於程序外部結構，不考慮內部邏輯結構，主要針對軟件界面和軟件功能進行測試。

簡單說：就是用工具來模擬人的真實操做，對軟件進行測試，相似黑盒測試。

舉個例子：咱們須要測試一款web產品，咱們須要知道在鼠標點擊某個按鈕時背景顏色發生了哪些變化，
跳轉到了哪一個頁面，是否彈出了預期的窗口，頁面是否在預期的時間內加載到了完整的數據，在各類瀏覽器環境下的異常是否在預期範圍內，
這些都屬於端對端測試的部分。

說完了測試，咱們能夠總結一下：

總體來講，持續集成能夠分爲：持續交付（持續測試）、持續部署兩個部分，對於開發人員來講，最重要的就是交付（測試）部分。

在真實的生產實踐中，咱們能夠搭建本地的自動化測試+集成環境來提升效率。

如：咱們能夠經過本地腳本，來實現咱們在輸入project push那一刻，
程序開始進行代碼檢查、構建編譯、單元測試、總體測試，測試經過後則自動提交，不經過則生成報表，繼續優化Debug。

以上即對持續集成的理解和分享。

部份內容摘錄自：阮一峯的博客

原文地址：surmon.me/article/17

完