centos wordpress 编程 开源 程序员 java Python Ubuntu linux nginx php 微软 shell apache google 云计算 mysql Windows Android Firefox

我們離DevOps有多遠–持續集成思想的延伸

Wikipedia對DevOps的定義是:

  DevOps是軟件開發、運維和質量保證三個部門之間的溝通、協作和集成所采用的流程、方法和體系的一個集合。 它是人們為了及時生產軟件產品或服務,以滿足某個業務目標,對開發與運維之間相互依存關系的一種新的理解。 ...... DevOps並不僅僅關註軟件部署,它是部門間溝通協作的一組流程和方法。

持續集成思想

  怎樣才能達到這樣一種狀態呢,我們先放一下,看看持續集成(Continuous Integration)體現出來的一些思想。

縱覽全局(打破職責界限)

  rd,qa,op,如果僅僅按照這樣的角色標簽去處理事情,那就和聖經裏的巴別塔一樣,大家不說同一種語言怎麽能勁往一處使呢。

  我們把目標放得更遠一些,不再為了趕代碼而將質量保障交給qa和op,不是為了增加測出bug的數量而和rd爭論,不是為了減少變更而是積極的適應變更,我們共同的目標是實現商業目的,確保軟件質量(也包括變更質量和運行質量)也是其中的一部分。頻繁的變更不是質量的殺手,而應該在軟件開發整個流程多個環節進行質量的保障,並頻繁的運行這些保障。

  這種方法就打破了目前的rd->qa->op流水線的流程,而是將三者緊密的結合在一起。從實踐的結果來看,rd每次提交代碼都會觸發一系列的自動化步驟,包括編譯,單元測試,代碼覆蓋率,功能測試,部署測試,性能/容量測試(註:後兩者受限與時間要求,實際實施不會每次提交代碼都觸發)。Rd,qa,op都在過程中做質量保障。

   

是努力減少變化還是在變化發生時做好準備。一定是後者,因為當一件事情頻繁發生時,問題才會大量的暴露。解決暴露出來的問題才能促進業務更好的發展,也是對團隊能力的提升。

  拿一個的實際例子,部署測試(Deploy check)和性能/容量測試(capacity test),我們比QA有更多的資源和條件,那麽我們就應該主動承擔起這份工作,然後將其加入到整條質量保障線的必要環節上。

 

 

浑然一体(而非七零八落)

  代码树被管理起来——主干开发

  

主幹開發的好處是每個rd都知曉整體的變更,所有的feature作為一個整體發布,對OP的現實意義就是上線變得更有規律,非計劃的、臨時的上線最後消失。

  代碼和周邊(配置,數據,構建腳本,單元測試,測試用例)統一作為產品被管理起來——一鍵式產構建,測試,部署,完成產品的最終發布。

SVN结构样例

module

|--product

|----code

|----bin

|----scm_product.conf(描述程序地址)

|----module_control

|----conf

|----data

|----data_description(描述数据存放地址)

|----ci-script

|----test_case

|----build_script

|----test_script

|----deploy_script

|--development

|--test

  

好處易見,生成一個完整的產品的所有原料都被管理起來,上線僅需要一個版本號,不會出現上線時冗長的步驟,做版本diff,部署環境diff,測試case diff都非常簡單。而且,環境的備份也變得簡單和純粹了。

  研發(開發,測試,發布,部署)全過程被管理起來。所有角色在一個界面下工作,使用共同的平臺,統一的源碼管理,共享。

 

 大家都在一個平臺上工作,所有的任務都在這個平臺下,各角色間對互相的工作有更深入的了解,並且,工作狀態也可以共享。

少就是多,簡潔就是美(用簡單的方法解決問題)
持續集成的解決方案是簡潔的。產品由SVN去管理,構建過程由CI server負責,而構建過程包含了編譯,測試,發布,部署過程

 

  

沒有封閉的系統,沒有蹩腳的流程,配合開放的系統(Code Review/wiki)所有的信息被自然的整合在一起。而一切都是以提高變更速度,提高產品質量為目標。

  當解決方案讓你覺得不自然(或有很多內容無法囊括,或需要人為幹預)的時候,那這個方案就不是一個完美的方案,必定在某一些方面受到了限制,這些限制有可能是歷史造成的。要勇於質疑,擴展角度,提升高度。去掉角色的限制,站在產品的角度去思考,對於整體的優化的解決方案就產生了。

以終為始(一直以發布級的質量要求產品)

  寫代碼都是為了要發布的,也就是需要上線使用的,那在開始編碼就以產品的質量要求代碼,要求check in的代碼就是能夠完成編譯的,具備一定功能並且可以部署的產品。

  將質量內建於產品中。每次代碼的提交都會經歷單元,功能,部署,性能/容量測試。在上線前我們就能夠知道是否能成功部署,線上的服務器是否能撐住。這樣的產品在上線時我們就不會有那麽大的壓力了,OP也不需要擔心回滾的風險了,即使回滾,那麽回滾也是one step。小菜一碟。

我們與DevOps的距離

  那麽我們離DevOps有多遠呢。從各個公司放出來的技術資料(flickr最全面),最經典的是flickr的10+ deploys per day,他們的最佳實踐有以下幾點,而起穿針引線作用的是持續集成(技術上)和思考方式(文化上)。

 

Culture:

1.respect

2.trust

3.healthy attitude about failure

4.avoiding blame

 從文化上,我們需要一種氛圍,不僅僅把自己看作rd,qa,op這樣的角色,哪裏有質量缺口,我們就要把它補起來;哪裏有不通暢的地方,我們就要把它疏通。RD了解op的部署方式,能夠獲取OP提供的監控指標;OP也了解RD的開發方法,開發流程,所面對的問題。放開自己的眼界,從更高的視角看待和解決問題。

 

Tools:

1.Automated infrastructure(自动化,系统之间可集成)

2.shared version control(SVN共享源码)

3.one step build and deploy(持续构建和部署)

4.feature flags(公司内部称为single branch,主干开发)

5.Shared metrics

6.IRC and IM robots(信息整合)

 

  

技術上的這些要點被3(持續集成/部署)一線貫穿。

  4點(主幹開發)是持續集成的前提

  1點(自動化),2點(代碼及周邊集中管理)是實施持續集成的必要條件

  5點是1的一部分(圖表是由自動化系統產生的)

  可見,技術上的核心是持續集成/部署

  5所提到的有較高的技術要求。要求我們將業務/運維上的指標變得可測量,直至可預測。這裏面的兩個核心技術內容就是:

  容量測量(Capacity management)

  容量的變化體現在用戶行為(流量)系統變更(軟件性能)和資源(服務器數量,冗余度計劃)等幾個因素的變化上,將容量和這些變化掛鉤,在每一個因素變化下重新得到系統的容量,從而在變更中控制容量不足造成的風險。有一個要點,我們需要的是系統的容量而不是單個模塊的性能。

  質量反饋(Quality feedback)

  變更會導致質量變化,而質量變化體現在各種指標上,而測量這些指標(包括應用指標:平響,處理效率等和系統指標:負載,網絡流量),發現指標之間的規律,將指標share給整個團隊,從而有效的達成質量的反饋,控制變更(包括內部變更和外部條件的變化)造成的質量下降的風險。本質上說,容量測量也是質量反饋的一部分。

  在實施持續集成的過程中,並行實施的三個項目:

  持續部署/一鍵式部署(continuous deployment/one step deploy),

  容量測試/管理(Capacity Test/Management)

  質量反饋(Quality feedback)

  分別對應於上面三個要點,共同支撐系統的高速叠代,減少系統頻繁變更引發的風險。

  借助於持續集成,我們在實踐中向DevOps邁進了一大步,離業界的最佳實踐已不遠。dev和ops說著同一種語言,共同為業務發展和質量保障做出貢獻。

  敏捷/精益開發方法可以提高應變業務變化的能力,並內建質量。DevOps把開發和運維的溝壑抹平。那麽我們的development和ITIL就能夠結合到一起了。

 

 

 我們曾經願景將服務器放到機架上,一鍵就能完成服務上線,我們已經有了一個好的開始,這個目標就會實現。

延伸阅读

    评论