1. 程式人生 > >持續整合與灰度釋出

持續整合與灰度釋出

一、持續整合

   

  持續整合(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、分流的維度豐富多樣。