一、持續整合

　　持續整合（Continuous integration，簡稱CI）是一種軟體開發實踐，即團隊開發成員經常整合它們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建（包括編譯，釋出，自動化測試)來驗證，從而儘快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發內聚的軟體。

　　持續整合的目的與價值：

    持續整合的目的不是減少build失敗的次數，而是儘早發現問題，在最短的時間內解決問題，減少風險和浪費。從而讓產品開發流程更加敏捷，縮短產品開發週期，在產品上線後，讓使用者用得更加順暢。

    在沒有應用持續整合之前，傳統的開發模式是專案一開始就劃分模組，每個開發人員分別負責一個模組，等所有的程式碼都開發完成之後再整合到一起提交給測試人員，隨著軟體技術隊的發展，軟體已經不能簡單地通過劃分模組的方式來開發，需要專案內部相互協作，劃分模組這種傳統的模式的弊端也越來越明顯。由於很多bug在專案早期的設計、編碼階段就引入，到最後整合測試時才發現問題，開發人員需要花費大量的時間來定位bug，加上軟體的複雜性，bug的定位就更難了，甚至出現不得不調整底層架構的情況。這種情況的發生不僅僅對測試進度造成影響，而且會拖長整個專案週期。

    而持續整合可以有效解決軟體開發過程中的許多問題，在整合測試階段之前就幫助開發人員發現問題，從而可以有效的確保軟體質量，減小專案的風險，使軟體開發團隊從容的面對各種變化。持續整合報告中可以體現目前專案進度，哪部分需要已經實現，哪些程式碼已經通過自動化測試，程式碼質量如何，讓開發團隊和專案組瞭解專案的真實狀況。

　　持續整合的優點：

    1、快速發現錯誤。每完成一點更新，就整合到主幹，可以快速發現錯誤，定位錯誤也比較容易。

    2、防止分支大幅偏離主幹。如果不是經常整合，主幹又在不斷更新，會導致以後整合的難度變大，甚至難以整合。

　　持續整合的一些原則：

    1.所有的開發人員需要在本地機器上做本地構建，然後再提交的版本控制庫中，從而確保他們的變更不會導致持續整合失敗。

　　2.開發人員每天至少向版本控制庫中提交一次程式碼。

　　3.開發人員每天至少需要從版本控制庫中更新一次程式碼到本地機器。

　　4.需要有專門的整合伺服器來執行整合構建,每天要執行多次構建。

　　5.每次構建都要100%通過。

　　6.每次構建都可以生成可釋出的產品。

　　7.修復失敗的構建是優先順序最高的事情。

二、灰度釋出

　　網際網路產品的釋出大多都是做到這裡就直接上線，替換了原有的版本，這種跳躍式的釋出是非常危險的，如果產品影響面大，對專案成員的壓力是非常大的。灰度釋出是在釋出新版本的時候，先切分部分流量給新版本，穩定了之後再切分所有流量到新版本。這樣一旦有問題，馬上修改切分的流量就可以，不需要重新發布，減少了釋出風險。這種基於ABTest分流的灰度釋出方式已經成為很多公司釋出的一個必經流程。在灰度釋出過程中，產品團隊根據使用者的反饋及時完善產品相關功能。目前業界一些著名的網際網路公司（如google，百度）都是採用這種類似灰度釋出的方式。AB Test系統就是可以實現灰度釋出的系統。通過ABTest系統可以方便地以各種方式切換流量。

　　在敏捷開發領域，取消專職測試以後，灰度釋出就更加重要。一旦新版本出現問題，能夠通過我們的ABTest系統馬上將所有流量切回穩定的舊版本。這樣做的好處是：

　　1、即時生效，無需釋出，快速響應。

　　2、可以漸進地調整比例。

　　3、分流的維度豐富多樣。