閱讀全文大概需要 10分鐘，更多原創幹貨，請關注公衆号：【測試開發技術】
1. 前言
借着公司今年新組建的中台研發部東風，我作為其中的主要負責人，在研發中心主導推行DevOps研發管理模式轉變及品質管理建立立設，本篇文章摘取自今年9月底，筆者在公司内部針對全體研發人員的一次DevOps教育訓練PPT中的部分内容，涉及公司敏感資訊和部分章節内容順序已經作過處理。
相信公衆号内，大部分讀者此前，對DevOps沒并有過多或全面的接觸，為了回饋讀者，是以将此次公司内訓其中涉及DevOps一些核心理念和實踐經驗抽取出來，分享給大家。（如有不正确的，歡迎糾正）
2. 到處都在說DevOps，到底DevOps是什麼？
最近幾年，相信大家經常會看到DevOps這個詞，也有很多專門以DevOps為主題的大型行業技術峰會。雖然DevOps最近幾年才在國内公司流行，但實際上DevOps早在2009 年就已經被提出來了。
那經常一直說DevOps，DevOps到底是個什麼東西？
DevOps目前其實并沒有一個權威的定義，即便一些在DevOps領域耕耘很久的大師，對DevOps也無法給出一個統一的定義，久而久之，行業也有這樣的一個說法：“如果有1000個人在說DevOps，那DevOps可能就有一千種意思。”
Anyway，無論有多少種意思，但我想說的是DevOps它最根本的那個意思是基本上類似的。
2.1 聊一聊DevOps組成
看到上面這張圖，可能有人就會說DevOps是不是Dev+Ops。
單純從字面上來了解，DevOps 是Dev（開發人員）+Ops（運維人員），雖然名字來源于開發和運維的縮寫，但DevOps并不是簡單的就是開發加運維。
DevOps 所涵蓋的角色範圍會更廣：除了開發、測試、運維還會涉及到項目經理、産品經理，甚至和銷售、市場等各個部門，跨職能部門互相合作，完成某一項目或任務。
2.2 DevOps不是什麼
在幫助大家了解 DevOps 到底是什麼之前，先說說 DevOps 不是什麼，很多人對 DevOps 可能存在一些誤解：
誤解一：DevOps不是一種工具，有人可能會說我在用Docker又或Jenkins等工具，是不是就表明在做DevOps了？然而這些并不意味着就在做DevOps的事情。
誤解二：DevOps不是一個新角色或者說是一個新的職位， 雖然說國内确實有些公司有單獨的職位是DevOps工程師，但并不代表，DevOps是一個職位，嚴格來說它是一類工程師的統稱。
誤解三：還有人說，DevOps出來之後，是不是由一個獨立的團隊去做所有事情，從開發到運維，一個部門就都幹掉。
其實上面這幾點都沒有錯，但對于DevOps這個概念而言，太過于狹隘了，不是簡單的說DevOps就是開發加運維，DevOps是由一個團隊或者由開發加運維就能搞定的。
實際上DevOps從需求到設計到開發、到測試到運維，甚至是線上的營運回報整個全生命周期的，是以它應該是一個打通多個部門協調，協作的這樣的一個平台。至于工具和自動化實際上隻是DevOps實作的一種手段。或者說DevOps是通過工具，自動化，來達到這種通過工具鍊與持續內建、傳遞、回報、優化進行端到端整合，完成無縫的跨團隊、跨系統協作。
3. DevOps包含一系列工具鍊、平台
DevOps實踐涉及到開發部門以及軟體研發的整個生命周期，這意味着在整個開發生命周期中，涉及到一大批新舊工具，包括從規劃、編碼、測試、釋出、監控等自動化的流程工具。
3.1 DevOps包含了一系列工具鍊
DevOps融合了一系列基本原則和實踐的方法論，并從這些實踐中派生出了各種工具。這些工具展現在軟體開發和傳遞過程的不同階段：
- 編碼：代碼開發和審閱，版本控制工具、代碼合并工具
- 建構：持續內建工具、建構狀态統計工具
- 測試：通過測試和結果确定績效的工具
- 打包：成品倉庫、應用程式部署前暫存
- 釋出：變更管理、釋出審批、釋出自動化
- 配置：基礎架構配置和部署，基礎架構即代碼工具
- 監控：應用程式性能監視、最終使用者體驗
3.2 國内主流的三大DevOps管理平台
除了上面說的這些工具鍊以外，也有一些DevOps管理平台服務，國内比較出名的就三個。
- 雲效
- TAPD
- 靈雀雲
其中雲效和TAPD屬于SaaS類平台，靈雀雲是基于容器技術，以DevOps為理念，面向微服務應用的新一代PaaS平台。
3.3 對DevOps工具鍊、平台存在的誤區
好的工具、平台可以對DevOps的實施提供出非常強有力的支援，但并不代表，實施DevOps，就一定需要重新去引入或購買一堆工具、平台。
問題的關鍵在于：如何解決問題，而不是具體應用哪一款的工具、平台。如果組織僅僅是購買工具而不改變工作流程，這樣不會改變任何事情。
4. DevOps成功的關鍵：組織文化的轉變
DevOps 成功的關鍵在于文化轉變，除了上面提到的工具，組織文化的轉變也同等重要，我們總結出了很多 DevOps 的其他因素，比如人（People）的思想和思考方式、開發和運維的流程（Process）、精益（Lean）、自動化（Automation）、測量（Measurement。
在組織文化方面，DevOps 推崇：
- 尊重（Respect）
- 正視失敗（Healthy attitude about failure）
- 不埋怨（Avoiding Blame）
- 精益求精
- 工程品質文化
- 快速驗證文化
- 客戶導向文化
5. 重新定義DevOps
到此你大概能對DevOps有一個概要的認識和了解，DevOps它是由一些規範方法，自動化實踐，合作文化等在組織内部不斷演進修複而産生的一種提升軟體工程釋出品質和效率的方法和實踐。
總結為三點：
DevOps 理念：以客戶、業務需求為導向，向着同一個目标前進，強調多個部門緊密溝通與協作的軟體傳遞過程。它包括産品管理，軟體開發及營運等各個方面。
DevOps核心實踐：人員協作文化+持續傳遞能力支撐
DevOps目标是建立一種精誠合作的文化和環境，通過工具鍊與持續內建、傳遞、回報、優化來實作跨團隊、跨系統協作方式。
6. 實踐DevOps需要建立哪些能力
6.1 能力一：DevOps不可或缺的自動化能力
自動化是DevOps底線！！！如果軟體系統沒有一套較完善的自動化測試體系，就請不要談DevOps，要想同時提升釋出效率和産品穩定性，以自動化替代手工方式快速、頻繁的對軟體品質進行驗證是首要的手段。
主要展現在三點上：
- 自動化比手動快。
- 工具不會像人一樣容易犯錯誤。
- 通過自動化按照定義執行確定每次執行的一緻性。
6.2 能力二：建立持續傳遞能力
實作DevOps，需要給産品傳遞團隊提供一個軟體持續傳遞平台或者能持續傳遞的部署流水線，讓軟體從代碼送出建構到傳遞給使用者的整個過程都能自動在流水線上完成。
- 通過統一的部署流水線将從代碼送出到傳遞給使用者的整個過程高度可視化出來，資訊透明；讓開發、測試和運維以高度一緻的方式工作在同一個流水線上，真正建立起協作。
- 每一次的軟體變更在這個完整的流水線中得到充分的驗證，盡早發現有缺陷的變更。
- 将一些必不可少的控制環節內建到自動化過程中，比如品質保障過程、過程度量、過程審計資訊等，進而弱化很多傳統依靠人為檢查的管理流程。
6.3 能力三：利益共同利的合作文化
以提高業務響應效率出發，要有一榮俱榮，精誠合作，共同進步的工作态度。
7. 實踐DevOps應該如何實施
DevOps所涉及的内容是非常廣的，根據不同的公司現狀的不同，實施落地的方式也會有所不一樣。
不要盲目的去追從DevOps，不是因為大家都做，是以我也要做，需要具備更高的全局觀，從瓶頸點開始着手。
應該出于解決某個業務問題的角度出發，知道要解決什麼樣的問題，這是非常非常重要的。如果你的傳遞品質和傳遞效率在自身企業内覺得沒有問題，如果你們覺得沒有問題，想想平時更新發版加班的苦逼。
當你用一些實踐來解決一些業務中的實際問題，将他們串聯起來，并且形成以管道式的釋出流水線後，你會發現，其實你已經開始在做DevOps了。
8. DevOps轉型的實踐手段
8.1 實踐一：以小批量的方式工作（開發、架構、組織文化的演進）
以小批量、持續的方式進行，通過反複實驗、根據回報循環快速學習，找到最正确的實施路徑。這樣需要把大的問題拆成一系列小的問題逐個、漸進式解決。
8.2 實踐二：建立回報循環
在小批量工作的基礎上，我們要建立起回報循環。回報循環讓我們能夠持續學習，基于學習進行持續改進，持續傳遞流水線就是回報循環的具體實作。
9.實踐DevOps最佳實踐手段：CI/CD
相信大部分讀者對DevOps和CI/CD經常會弄混淆，那麼如何來了解DevOps和CI/CD之間的關系呢？可以這樣來了解：DevOps是CI/CD思想的延伸，CI/CD則是DevOps的技術核心，如果沒有CI/CD，沒有自動化測試，DevOps是沒有任何意義的。是以說DevOps是以CI/CD為基礎來優化程式的開發、測試、運維等各個不同環節。
9.1 CI：持續內建
持續內建是一種開發實踐，它倡導團隊成員需要頻繁的內建他們的工作，每次內建都通過自動化建構（包括編譯、建構、自動化測試）來驗證，進而盡快地發現內建中的錯誤。讓正在開發的軟體始終處于可工作狀态，讓産品可以快速疊代，同時還能保持高品質。
9.2 什麼是CD？
談到CD，其中是包含了兩層内容：持續傳遞和持續部署。
有時候很多人會把持續傳遞誤認為成持續部署，然而兩者是兩個不同層次的能力。
持續傳遞：
持續傳遞是持續內建的延伸或者看作持續內建的下一步，它将內建後的代碼部署到類生産環境，確定可以以可持續的方式快速向客戶釋出新的更改。如果代碼沒有問題，可以繼續手工部署到生産環境中。它強調的是，不管怎麼更新，軟體是随時随地可以傳遞的。
持續部署：
持續部署是持續傳遞的下一步，在持續傳遞的基礎上，由開發人員或運維人員自助式的定期向生産環境部署穩定的建構版本，持續部署的目标是代碼在任何時刻都是可部署的，并可自動進入到生産環境。
說到這裡，相信大部人已經能清楚明白了，持續傳遞是指團隊確定每個變更可以部署至生産環境，但也許并不需要實際部署，這通常可能是出于業務方面的原因。而持續部署是指每個變更可以自動部署到生産環境。隻有成功實作持續傳遞的前提下，才能進行持續部署。
10.DevOps提倡的原則
DevOps持續傳遞的八大原則對可運維性給出了這樣的定義，在企業中研發和運維體系必然需要互相配合，開發團隊負責功能性需求實作的同時，在架構和編碼上注重非功能性需求的實作，測試團隊與運維團隊将圍繞着各自職能的需求，規劃與建設DevOps流水線中對應的工具系統，加速企業IT價值鍊的流轉，以為企業創造更大的商業價值。
DevOps提倡的原則
- 從瓶頸點着手
- Start Small,從小做起
- 痛苦的事情優先解決
- 工具也是一種文化
- 自動化别人，先自動化自己
- 價值拉動，而非事務驅動
- 建構名額，驅動DevOps落地。
- 建立從開發過程下遊至上遊的回報環。
- 強調全局優化，避免局部優化。
- 持續做試驗和學習的文化，通過反複實踐來達到精通。
希望這篇文章能幫到你！如果喜歡，麻煩幫忙點一下好看或轉發朋友圈，更多幹貨文章請關注我們，最新原創，第一時間發表于公衆号：【測試開發技術】，歡迎關注。
聲明：封面或正文部分圖檔來源于網絡，如有侵權，請聯系删除。