一、持續集成
持續集成（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、分流的維度豐富多樣。
本文參考：
http://www.51testing.com/html/62/404362-822549.html
http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html