近年來，伴隨着國內數字化轉型的逐漸深入，DevOps的熱度不斷攀升，各行各業都在進行DevOps轉型建設，其在提升業務價值交付能力及推進企業從內至外的數字化進程上有着重要意義。因此，瞭解DevOps方法論和它的實際落地案例，便顯得尤爲重要。
往期DevOps乾貨內容請戳：
本次直播我們邀請到DevOps諮詢顧問王英偉老師，爲大家講述DevOps方法論和實踐指導。王英偉老師曾任職於電信、自媒體、電子商務、互聯網等領域的科技公司，有着豐富的開發、項目管理、DevOps實施經驗。同時，老師還是中國DevOps社區核心組織者，曾參與《京東敏捷實踐指南》、《敏捷無敵之DevOps時代》、《DevOps悖論》等書的翻譯、審校工作。
英偉老師認爲，DevOps的建設是一個長期的、持續改進的過程，需要結合企業自身實際建設平臺及自動化工具，同時也要提升內部人員理論、實踐能力。
一、需求管理模型和敏穩雙態開發
在研發產品之前，我們都需要先了解客戶的需求。常見的需求理論模型有三種，可基於不同業務和產品複雜度的需求層次結構進行選擇。
- 簡單的業務和產品：拆分成兩層，產品需求➡技術任務
- 典型的業務和產品：拆分成三層，業務需求➡產品需求➡技術任務
- 複雜的業務和產品：拆分成四層，業務需求➡產品特性➡產品需求➡技術任務
那麼如何將需求理論模型跟現有的流程結合起來呢？
下圖爲某大廠公佈的研發效能白皮書中的一張圖，根據需求來源的不同和不同人員所需要具備的能力，把產品管理分成三個層次，通過流程與工具相結合進行描述或使用項目管理工具。
▲ 圖片來源網絡，如有侵權請聯繫刪除
軟件開發流程在這兒不過多介紹，業界用的最多的就是瀑布開發模式、敏捷開發模式和DevOps開發模式。儘管常見的開發模式是這些，但是大多數工具只支持敏捷開發模式，很少有工具支持雙態（既支持瀑布，又支持敏捷開發模式）模式。
我們對標業界最佳實踐，爭做國內最好的項目管理工具，不僅既支持瀑布開發模式，還支持敏捷開發模式；同時具備存儲文檔、Wiki等功能。也就是說，在項目管理和需求管理方面，我們的平臺能涵蓋95%以上的使用場景。
項目管理組件能力全景圖
產品界面展示
二、DevOps涵蓋產品全生命週期
有些人可能對敏捷、DevOps等涵蓋的領域有些模糊。一般來講，敏捷解決的是業務部門和研發部門之間的矛盾，DevOps解決的是開發測試運維這一過程中可能遇到的衝突，涵蓋的是整個產品全生命週期。
▲ 圖片來源網絡，如有侵權請聯繫刪除
1. 研發環境
隨着公司規模的擴大，開發層面常面臨以下問題：
- 公司需要不斷爲企業研發人員配備合適的本地研發工具（如多核高內存的計算機設備、Mac 筆記本電腦），這些設備可能價值不菲，而且需要定期的更新換代。
- 新加入的員工，在正式開始開發前，需要配置複雜的本地開發環境，安裝特定的軟件及插件，並熟悉項目的研發流程及各個線上系統；部分項目因爲網絡配置等問題，可能第一時間無法在本地啓動，還會耽誤不少額外的配置及調試時間。
- 公司需要投入較多的資源，才能構建起匹配管理者需求的效能度量系統和安全管控系統，並且因爲雲端體系天生對開發者本地環境的弱管控性，效果只能差強人意。
- 當產品對保密性要求極高，或者當企業外部成員參與對代碼保密性有要求的項目時，需要確保核心代碼的安全管控。
由此可見，本地開發環境已逐步難適應因公司規模擴大所帶來的問題，雲端開發工具（WebIDE）應運而生。儘管雲端開發工具有優勢也有劣勢，不同的人對它所持的態度也不同，但云端開發已是不可阻擋的趨勢。
▲ 本地開發環境Vs雲端開發環境（如有侵權請聯繫刪除）
2. 代碼倉庫
在研發的過程中，經常會使用到代碼倉庫。代碼倉庫的開發流程通常爲：開發人員下載代碼➡創建工作分支➡提交代碼➡創建合作請求➡邀請團隊成員➡參與代碼評審➡倉庫管理員審視後合入代碼。
▲ 圖片來源網絡，如有侵權請聯繫刪除
開源的代碼倉庫通常應用架構集中，一旦待機則全部應用不可用。除此之外，開源代碼倉庫只能使用共享文件系統支撐，如需擴展得采用nfs，ceph等方案。不僅風險高，擴展性能也低，對硬件的要求也高。
3. 代碼管理
爲什麼做要做靜態代碼檢查？因爲代碼交付過程常見的問題和風險有很多，比如：
- 重複代碼過多，造成開發人力的浪費以及後期維護成本增加
- 編碼風格糟糕，代碼凌亂、不可讀，難於維護與開發修改
- 圈複雜度過高，造成代碼可維護性、可繼承性降低，問題定位難度加大
- 編碼安全風險，使用具有安全風險的函數，導致系統的安全性層級降低，加大系統的安全風險
那麼，需要檢查代碼的什麼方面呢？以下列舉幾種常見的代碼靜態檢查關注點：
重複率：表示一段源代碼在一個程序，或者一個團體所維護的不同程序中重複出現
代碼風格：程序開發人員所編寫源代碼的書寫風格，良好代碼風格的特點是使代碼易讀
圈複雜度：衡量一個模塊判定結構的複雜程度，數量上表現爲獨立線性路徑條數，圈複雜度大說明程序代碼可能質量低且難於測試和維護
代碼安全：編碼過程中，常見的安全問題包括（但不限於）：緩衝區溢出/跨站腳本攻擊(XSS)/SQL注入/XML 注入/LDAP 注入
點擊閱讀原文，可下載PPT查閱靜態代碼檢查常用分析技術和代碼檢查的常用工具介紹
藍鯨DevOps平臺代碼掃描工具CCheck當下所具備的能力項，不僅內置了檢查規則，並對相關規則做了簡化，便於團隊人員使用，能夠在較短的時間內逐步提高代碼質量。
4. 測試場景
在測試領域，一直爭論不休的話題有：關於單元測試到底是由開發人員來做還是測試人員來做？針對當下常用的微服務架構，契約測試和Mock測試又該如何去做？以及如果有在線測試系統的話，又該如何把在線測試系統與本地的測試工具做聯動？
微服務是一種架構風格，它將單個的應用設計成一組服務的集合。微服務架構由於自身的高度模塊化、可獨立部署和技術多樣性優勢，在當前開發系統或業務系統廣泛應用。
儘管微服務架構已十分普遍，但其存在着的分佈式、最終一致性和管理複雜性等特性，也讓過去的測試理念及工具略有些“束手無策”。
契約測試和Mock測試
微服務架構下，當一個服務已經同時被多個使用者調用的時候，怎麼保證整體服務不會對其他使用者造成影響呢？契約測試，能很好的避免這類問題。
契約測試定義了一套數據標準，既包含了請求也包含返回的數據項，通過對這些數據項事先做好了相關的定義，無論是消費方還是生產者，只要遵循了契約測試的內容，就可以保證服務實時暢通的進行調用。契約測試通過驗證Provider（生產者）是否按照期望的方式與Consumer（消費方）進行交互。
以下圖爲例，假設現在不同的服務提供方對同一個請求提供了不同的數據形式，這三個服務都有"id"。但第二種微服務比第一種微服務多了"age"字段，而第三個微服務和第一個微服務相比，雖然都包含"name"字段，但"name"字段裏的數據是不一樣的。此時如果是用接口測試來做的話，需要提供3個不同的請求來測試；但如果用契約測試來做的話，契約測試就相當於是這三個的全集，只需要定義一種契約即可。
▲ 圖片來源網絡，如有侵權請聯繫刪除
在微服務測試時，想要實現環境無依賴，服務間無依賴？或者想要實現快速測試，支撐服務快速上線？這些都可以通過Mock測試來搞定，它就是在測試過程中，對於某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創建以便測試的測試方法。
下圖是藍鯨DevOps平臺提供的測試工具CTest產品功能架構圖，從中可以看出無論是對於支撐不同的測試模式，還是測試報告應該具備的功能項，都已經有了相關的能力，是個較爲成熟的產品。
5.編譯構建
編譯構建是指把軟件的源代碼編譯成目標文件，並把配置文件和資源文件等打包的過程。
當前，業界最流行的編程語言還是Java，不同的編程語言都有不同的構建工具。對於流水線上的構建工具來講，到底一款工具能支撐多少語言類型，也能考驗一款編譯構建工具的能力。
藍鯨DevOps流水線效能實踐工具，可以通過拖拽的形式構建流水線，不像一些開源工具，必須要會寫腳本和手工配置。而藍鯨DevOps流水線效能實踐工具，已經把上述模塊和組件內置了，降低了使用難度。
6.軟件製品
軟件研發過程中的“源碼”和“軟件製品包”（通常被通俗稱爲“二進制包”）都是很關鍵的資產。軟件製品包通常是源碼文件的集合或者編譯後的產物，因此主要有二進制包和壓縮包兩種形式，軟件製品包的管理和複用在發佈管理有着關鍵的作用。
不同的編程語言，同樣會對應不同的製品形式。現在之所以容器特別流行，就是因爲它屏蔽了語言帶來的限制，將包打成統一的格式，放到集羣裏邊進行部署。
包文件通常不放在源碼庫中管理，而是使用專門的包文件倉庫進行存儲並配合包文件依賴管理工具（Maven、NPM、Ivy等）進行使用。包文件倉庫可以大致分爲本地倉庫、私服倉庫、中央倉庫三種。
- 本地倉庫是指開發者個人PC中包文件的存儲
- 私服倉庫通常是企業爲了提升包文件使用性能搭建的局域網內共用的包文件倉庫，通常使用開源的Nexus、Artifactory等工具搭建
- 中央倉庫是指開源包文件的共享社區
私服倉庫把源碼倉庫拉下來，通過持續構成的工具打包並存在私服倉庫中。對依賴管理這塊，比如項目和工程依賴一些開源的相關組件，那麼私服就會把這些開源組件從互聯網中央倉庫拉下來，放到私服倉庫上。開發人員在內網就可以根據需要，拉取代碼或依賴包在本地做功能開發，做完後再提交到源碼庫，最終打成二進制介質放到私有倉庫裏。
▲ 圖片來源網絡，如有侵權請聯繫刪除
什麼是軟件製品庫？
軟件製品庫指能夠統一管理各種類型的二進制製品，同時無縫對接現有的標準化構建和發佈工具的軟件平臺。也就說製品庫既能夠存儲中間產物，也能存儲結果產物。“軟件包”及其屬性的管理是發佈過程管理的基礎，也是軟件開發過程中的重要資產。
軟件製品庫在DevOps工具鏈中的開發集成、測試、生產等階段都有作用，相關人員可在不同階段把製品打完後放到製品庫。一旦流程走到下一個環節，比如走到開發、測試，走到整個上線管理，製品也會做相應的晉級。
軟件製品有多種格式，如Maven、Pypi、NPM等。
作爲DevOps的重要樞紐，如果沒有統一可信製品庫，DevOps和CI/CD運轉起來，就像流水線沒了軸承，研發規模越大，問題和隱患就越多。雖然源碼都是同一套，但是開發環境和測試環境的不同，會導致代碼運行不起來。但如果能夠保證在不同的環境下，用的都是同一個製品，那就能儘量少的屏蔽環境不同帶來的影響。
比如經常聽到“誒這個代碼在我這裏運行可以啊，怎麼在你哪裏運行不了？那肯定是你本地服務器的毛病。”因此，通過製品庫的使用，能逐步避免這類現象的產生。
這個是我們在某客戶那裏的製品庫落地案例。該客戶是內外網隔離的，私服負責從外網的中央倉庫下載依賴包，內網的依賴庫和外網的私服庫進行打通，以便於數據同步。所有內網的研發團隊，都是從依賴庫下載所需資源包，並做一些安全掃描等管理工作。由於該團隊是分佈式的開發團隊，在全國各地都有相應的團隊，每個城市都有自己的製品倉庫作爲本地的倉庫節點，在開發中心有一個主節點，這樣就把製品庫做了一個主從的模式，以便製品的同步和晉級。
三、DevOps實現自動化部署
自動化部署可以減少人肉運維和手工運維的工作量，也能儘量避免人工操作所帶來的的錯誤和風險。自動化部署是指將可交付產品，快速且安全地交付用戶使用的一套系統和工具。系統會自動構建、測試並準備代碼變更，以便將其發佈到指定環境的過程，包括開發環境、預發佈環境、生產環境等。
系統模板是自動化部署服務的關鍵特性。通過使用系統模板快速創建部署任務，然後將組合的部署步驟保存爲自定義模板，這樣在下一次部署任務來臨時，就可以直接使用該模板。
我們把不同系統的發佈策略做了一個整理彙總（見下圖），如果實際應用場景具備這些能力項，就可以跟其他的組件相結合，對外提供不同的發佈策略。
四、企業文化推廣
有了前面的方法論，又該怎麼開始準備和實施呢？
準備階段1：選擇合適的試點項目
從最有同理心和最樂於創新的團隊開始，擴大DevOps的範圍。在逐步擴大的過程中，發現創新者和早期採用者，贏得沉默的大多數，並識別意願較低的“釘子戶”。最後，儘早展示成果並積極宣傳，將大目標分解成漸進式的小步驟。
Tips: 改進試點項目時，不但要努力降低複雜性，提高可靠性和穩定性，而且還應該更快、更安全、更容易變更，團隊纔可能更願意嘗試。
準備階段2：組建全功能團隊
軟件開發團隊的結構對軟件產品的架構和成果有巨大的影響，利用康威定律組織團隊，減少工作交接次數，提升交付速度和成功率。小團隊獨立運作，彼此充分解耦，避免過多的溝通與協調。牢記兩個比薩原則，保持小規模。
準備階段3：團隊成熟度評估
在對團隊進行成熟度評估時，可從價值、能力、角色三個方面進行考慮，參考業界端新型的研發能力框架對團隊進行成熟度評估。
準備階段4：價值流分析實例
- 召集所有關鍵成員，繪製價值流圖。
- 記錄主要的步驟和細節，讓相關干係人員擁有同樣的視圖。
- 重點分析和優化，識別阻礙：需要等待數週甚至數月的工作；引發或處理重大返工的工作。
- 確定想要改進的度量指標，通過探索各種假設，然後分析結果，不斷迭代和重複，將獲得的經驗用於下一次實驗。
在實施階段，確定實施的優先級，按優先級逐一推進。
- 團隊敏捷：敏捷意識強化、知識點與工具使用培訓、敏捷會議的觀察及引導、測試前移、團隊質量監控、SoS敏捷管理方法
- 業務敏捷：探求運用用戶故事地圖、實例化需求與用戶故事、進行需求條目化、利用需求條目需求及任務分拆、形成統一的產品需求列表、探求估算與與迭代計劃、探求需求溝通與反饋方式
- 工程敏捷：自動化單元測試、自動化代碼掃描、自動化集成測試、自動化功能/流程測試、持續集成、持續交付、部署流水線、主幹開發
- 管理工具：電子看板/物理看板、任務列表、項目狀態 - 燃盡圖、增值流圖
DevOps是數字化轉型成功的關鍵之一，雖然DevOps建設非一日之功，但是建成之後的價值不只能提升企業IT研發效能、交付質量和靈活應對業務需求的變化，對提升企業內部團隊的協作和敏捷能力都有着顯著變化。精彩未完待續，接下來我們還會邀請更多DevOps領域的專家爲大家帶來分享，請持續關注我們。如您有更多想探討交流的話題，歡迎留言~