DevOps是軟體開發、運維和品質保證三個部門之間的溝通、協作和內建所采用的流程、方法和體系的一個集合。 它是人們為了及時生産軟體産品或服務，以滿足某個業務目标，對開發與運維之間互相依存關系的一種新的了解。 ...... DevOps并不僅僅關注軟體部署，它是部門間溝通協作的一組流程和方法。
持續內建思想
縱覽全局（打破職責界限）
rd，qa，op，如果僅僅按照這樣的角色标簽去處理事情，那就和聖經裡的巴别塔一樣，大家不說同一種語言怎麼能勁往一處使呢。
我們把目标放得更遠一些，不再為了趕代碼而将品質保障交給qa和op，不是為了增加測出bug的數量而和rd争論，不是為了減少變更而是積極的适應變更，我們共同的目标是實作商業目的，確定軟體品質（也包括變更品質和運作品質）也是其中的一部分。頻繁的變更不是品質的殺手，而應該在軟體開發整個流程多個環節進行品質的保障，并頻繁的運作這些保障。
這種方法就打破了目前的rd->qa->op流水線的流程，而是将三者緊密的結合在一起。從實踐的結果來看，rd每次送出代碼都會觸發一系列的自動化步驟，包括編譯，單元測試，代碼覆寫率，功能測試，部署測試，性能/容量測試（注：後兩者受限與時間要求，實際實施不會每次送出代碼都觸發）。Rd，qa，op都在過程中做品質保障。
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153522909.jpg"></a>
是努力減少變化還是在變化發生時做好準備。一定是後者，因為當一件事情頻繁發生時，問題才會大量的暴露。解決暴露出來的問題才能促進業務更好的發展，也是對團隊能力的提升。
拿一個的實際例子，部署測試（Deploy check）和性能/容量測試（capacity test），我們比QA有更多的資源和條件，那麼我們就應該主動承擔起這份工作，然後将其加入到整條品質保障線的必要環節上。
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153537986.png"></a>
渾然一體（而非七零八落）
代碼樹被管理起來——主幹開發
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153553930.gif"></a>
主幹開發的好處是每個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都非常簡單。而且，環境的備份也變得簡單和純粹了。
研發（開發，測試，釋出，部署）全過程被管理起來。所有角色在一個界面下工作，使用共同的平台，統一的源碼管理，共享。
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153607170.jpg"></a>
大家都在一個平台上工作，所有的任務都在這個平台下，各角色間對互相的工作有更深入的了解，并且，工作狀态也可以共享。
少就是多，簡潔就是美（用簡單的方法解決問題）
持續內建的解決方案是簡潔的。産品由SVN去管理，建構過程由CI server負責，而建構過程包含了編譯，測試，釋出，部署過程
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153627122.png"></a>
沒有封閉的系統，沒有蹩腳的流程，配合開放的系統（Code Review/wiki）所有的資訊被自然的整合在一起。而一切都是以提高變更速度，提高産品品質為目标。
當解決方案讓你覺得不自然（或有很多内容無法囊括，或需要人為幹預）的時候，那這個方案就不是一個完美的方案，必定在某一些方面受到了限制，這些限制有可能是曆史造成的。要勇于質疑，擴充角度，提升高度。去掉角色的限制，站在産品的角度去思考，對于整體的優化的解決方案就産生了。
以終為始（一直以釋出級的品質要求産品）
寫代碼都是為了要釋出的，也就是需要上線使用的，那在開始編碼就以産品的品質要求代碼，要求check in的代碼就是能夠完成編譯的，具備一定功能并且可以部署的産品。
将品質内建于産品中。每次代碼的送出都會經曆單元，功能，部署，性能/容量測試。在上線前我們就能夠知道是否能成功部署，線上的伺服器是否能撐住。這樣的産品在上線時我們就不會有那麼大的壓力了，OP也不需要擔心復原的風險了，即使復原，那麼復原也是one step。小菜一碟。
我們與DevOps的距離
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的一部分（圖表是由自動化系統産生的）
可見，技術上的核心是<b>持續內建/部署</b>
5所提到的有較高的技術要求。要求我們将業務/運維上的名額變得可測量，直至可預測。這裡面的兩個核心技術内容就是：
容量測量（Capacity management）
容量的變化展現在使用者行為（流量）系統變更（軟體性能）和資源（伺服器數量，備援度計劃）等幾個因素的變化上，将容量和這些變化挂鈎，在每一個因素變化下重新得到系統的容量，進而在變更中控制容量不足造成的風險。有一個要點，我們需要的是系統的容量而不是單個子產品的性能。
品質回報（Quality feedback）
變更會導緻品質變化，而品質變化展現在各種名額上，而測量這些名額（包括應用名額：平響，處理效率等和系統名額：負載，網絡流量），發現名額之間的規律，将名額share給整個團隊，進而有效的達成品質的回報，控制變更（包括内部變更和外部條件的變化）造成的品質下降的風險。本質上說，容量測量也是品質回報的一部分。
在實施持續內建的過程中，并行實施的三個項目：
持續部署/一鍵式部署（continuous deployment/one step deploy），
容量測試/管理（Capacity Test/Management）
分别對應于上面三個要點，共同支撐系統的高速疊代，減少系統頻繁變更引發的風險。
借助于持續內建，我們在實踐中向DevOps邁進了一大步，離業界的最佳實踐已不遠。dev和ops說着同一種語言，共同為業務發展和品質保障做出貢獻。
靈活/精益開發方法可以提高應變業務變化的能力，并内建品質。DevOps把開發和運維的溝壑抹平。那麼我們的development和ITIL就能夠結合到一起了。
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153649140.gif"></a>
我們曾經願景将伺服器放到機架上，一鍵就能完成服務上線，我們已經有了一個好的開始，這個目标就會實作。
<a target="_blank" href="http://blog.51cto.com/attachment/201112/153702302.jpg"></a>
本文轉自百度技術51CTO部落格，原文連結：http://blog.51cto.com/baidutech/748587，如需轉載請自行聯系原作者
![更改LYNC SIP位址[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)