最近做了一些持續集成相關的東西
定義
- 持續集成（continuous integration，縮寫：CI），維基百科上面的解釋是：is the practice of merging all developer working copies to a shared mainline several times a day。意譯為：在團隊協作中，一天里多次將所有開發人員的代碼merge到同一條主干上。
- 大公司的持續集成可以復雜到非常復雜(就是復雜到不可描述了，比如阿里云的專有云)，小公司的持續集成也可能簡單到只是一個系統部署過程。
- 瀑布模型中，軟件的開發過程大概可以分成這幾部：需求分析 -> 系統設計 -> 編碼實現 -> 測試 -> 集成 -> 部署 -> 維護。這里面所謂的【集成】就是在存在多個系統協作的情況下，將子系統集成為一個大系統的過程。而我理解的敏捷開發，實際上就是在瀑布模型的基礎上，加入持續迭代，既：需求不是一次全部確定清楚，每次可能只確定了一個部分，這部分開發、測試、集成、部署以后，進入下一個需求的開發，重復上述過程。
而持續集成可以說是敏捷開發的最佳實踐。 -
持續集成的關鍵不是集成，而是持續。所謂持續，就需要自動化。代碼的每次合并都會觸發持續集成服務器進行自動構建，這個過程包括了編譯、單元測試、集成、集成測試、質量分析、性能測試等步驟，每一步的結果只有兩個：成功或者失敗。這一步成功以后，才能進入到下一步，這一步失敗，就說明有人提交的代碼有問題。 -
每個團隊的持續集成應該根據自己產品的實際需求來確定集成步驟，關鍵在于持續，而不是步驟。不考慮實際業務需求的設計，都是耍流氓，我們應該秉承的是：在現階段，以最好的方式，完成所需的功能，而不是一味的追求擴展性，也不是一味的追求技術深度，更不是隨便一種的簡單實現。
持續交付和持續部署
- 持續交付的目標是讓軟件在短周期內產出，確保軟件隨時可以被可靠地發布，目標是持續產出可以可靠發布的軟件。我理解持續交付需要依賴于持續集成，在持續集成的過程中，通過了所有測試case并且可以正確發布的集成系統，就可以作為持續交付的結果。持續交付與DevOps的含義很相似。
- 持續部署意味著所有的變更都會被自動部署到生產環境中。持續交付意味著所有的變更都可以被部署到生產環境中，但是出于業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續交付。
我做了什么
- 啰嗦了這么多，其實我做的算是持續部署，就是用Jenkins給我們后臺系統，做了一個持續部署。??
- 使用到的主要是Jenkins pipeline。首先在centos 7.1系統上直接運行了jenkens blueocean的docker版本(有做volume的映射，可以保存docker運行時數據)
- 然后在Jenkins里面定義了一個pipeline的job，pipeline里面定義了這么幾個部分：拉取代碼->編譯->測試case->代碼打tag->二進制文件上傳到某個倉庫->腳本化部署到各個機器。
- 每次有代碼merge到master分支，都會以hook的方式觸發Jenkins job，執行持續集成，所有步驟通過以后，線上就會完成自動化部署。
- 有一點兒需要注意的是，jenkins可以創建多個job，而每個job可能會同時運行，而同一個job也可能同時被多次執行。為了解決沖突問題，所有的jenkins job都在docker中運行。這里的docker是我自己構建的，為了滿足我們自己的腳本化需求，和部署需求，有一些依賴需要添加。
- 我理解這個過程中比較重要的是：
1) 持續，每次有代碼merge到master，都會觸發持續部署。2) 測試，測試在持續集成、持續交付和持續部署中有著至關重要的作用，沒有完備的測試case，就無法保證部署上去的系統是可用系統。
