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就能夠結合到一起了。

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