01. 需求管理模型和敏穩雙態開發

在研發產品之前，我們都需要先了解客戶的需求。常見的需求理論模型有三種，可基于不同業務和產品復雜度的需求層次結構進行選擇。

• 簡單的業務和產品：拆分成兩層，產品需求?技術任務
• 典型的業務和產品：拆分成三層，業務需求?產品需求?技術任務
• 復雜的業務和產品：拆分成四層，業務需求?產品特性?產品需求?技術任務

那么如何將需求理論模型跟現有的流程結合起來呢？

下圖為某大廠公布的研發效能白皮書中的一張圖，根據需求來源的不同和不同人員所需要具備的能力，把產品管理分成三個層次，通過流程與工具相結合進行描述或使用項目管理工具。

我們對標業界最佳實踐，爭做國內最好的項目管理工具，不僅既支持瀑布開發模式，還支持敏捷開發模式；同時具備存儲文檔、Wiki等功能。也就是說，在項目管理和需求管理方面，我們的平臺能涵蓋95%以上的使用場景（掃描文末海報二維碼，立即申請試用）。軟件開發流程在這兒不過多介紹，業界用的最多的就是瀑布開發模式、敏捷開發模式和DevOps開發模式。盡管常見的開發模式是這些，但是大多數工具只支持敏捷開發模式，很少有工具支持雙態（既支持瀑布，又支持敏捷開發模式）模式。

02. DevOps涵蓋產品全生命周期

有些人可能對敏捷、DevOps等涵蓋的領域有些模糊。一般來講，敏捷解決的是業務部門和研發部門之間的矛盾，DevOps解決的是開發測試運維這一過程中可能遇到的沖突，涵蓋的是整個產品全生命周期。

隨著公司規模的擴大，開發層面常面臨以下問題：

① 研發環境

• 公司需要不斷為企業研發人員配備合適的本地研發工具（如多核高內存的計算機設備、Mac 筆記本電腦），這些設備可能價值不菲，而且需要定期的更新換代。
• 新加入的員工，在正式開始開發前，需要配置復雜的本地開發環境，安裝特定的軟件及插件，并熟悉項目的研發流程及各個線上系統；部分項目因為網絡配置等問題，可能第一時間無法在本地啟動，還會耽誤不少額外的配置及調試時間。
• 公司需要投入較多的資源，才能構建起匹配管理者需求的效能度量系統和安全管控系統，并且因為云端體系天生對開發者本地環境的弱管控性，效果只能差強人意。
• 當產品對保密性要求極高，或者當企業外部成員參與對代碼保密性有要求的項目時，需要確保核心代碼的安全管控。

由此可見，本地開發環境已逐步難適應因公司規模擴大所帶來的問題，云端開發工具（WebIDE）應運而生。盡管云端開發工具有優勢也有劣勢，不同的人對它所持的態度也不同，但云端開發已是不可阻擋的趨勢。

② 代碼倉庫

在研發的過程中，經常會使用到代碼倉庫。代碼倉庫的開發流程通常為：開發人員下載代碼?創建工作分支?提交代碼?創建合作請求?邀請團隊成員?參與代碼評審?倉庫管理員審視后合入代碼。

開源的代碼倉庫通常應用架構集中，一旦待機則全部應用不可用。除此之外，開源代碼倉庫只能使用共享文件系統支撐，如需擴展得采用nfs，ceph等方案。不僅風險高，擴展性能也低，對硬件的要求也高。

③ 代碼管理

為什么做要做靜態代碼檢查？因為代碼交付過程常見的問題和風險有很多，比如：

• 重復代碼過多，造成開發人力的浪費以及后期維護成本增加
• 編碼風格糟糕，代碼凌亂、不可讀，難于維護與開發修改
• 圈復雜度過高，造成代碼可維護性、可繼承性降低，問題定位難度加大
• 編碼安全風險，使用具有安全風險的函數，導致系統的安全性層級降低，加大系統的安全風險

那么，需要檢查代碼的什么方面呢？以下列舉幾種常見的代碼靜態檢查關注點：

A：重復率：表示一段源代碼在一個程序，或者一個團體所維護的不同程序中重復出現

B：代碼風格：程序開發人員所編寫源代碼的書寫風格，良好代碼風格的特點是使代碼易讀

C：圈復雜度：衡量一個模塊判定結構的復雜程度，數量上表現為獨立線性路徑條數，圈復雜度大說明程序代碼可能質量低且難于測試和維護

D：代碼安全：編碼過程中，常見的安全問題包括（但不限于）：緩沖區溢出/跨站腳本攻擊(XSS)/SQL注入/XML 注入/LDAP 注入

藍鯨DevOps平臺代碼掃描工具CCheck當下所具備的能力項，不僅內置了檢查規則，并對相關規則做了簡化，便于團隊人員使用，能夠在較短的時間內逐步提高代碼質量。

④ 測試場景

在測試領域，一直爭論不休的話題有：關于單元測試到底是由開發人員來做還是測試人員來做？針對當下常用的微服務架構，契約測試和Mock測試又該如何去做？以及如果有在線測試系統的話，又該如何把在線測試系統與本地的測試工具做聯動？

盡管微服務架構已十分普遍，但其存在著的分布式、最終一致性和管理復雜性等特性，也讓過去的測試理念及工具略有些“束手無策”。微服務是一種架構風格，它將單個的應用設計成一組服務的集合。微服務架構由于自身的高度模塊化、可獨立部署和技術多樣性優勢，在當前開發系統或業務系統廣泛應用。

PS. 契約測試和Mock測試

微服務架構下，當一個服務已經同時被多個使用者調用的時候，怎么保證整體服務不會對其他使用者造成影響呢？契約測試，能很好的避免這類問題。

契約測試定義了一套數據標準，既包含了請求也包含返回的數據項，通過對這些數據項事先做好了相關的定義，無論是消費方還是生產者，只要遵循了契約測試的內容，就可以保證服務實時暢通的進行調用。契約測試通過驗證Provider（生產者）是否按照期望的方式與Consumer（消費方）進行交互。

以下圖為例，假設現在不同的服務提供方對同一個請求提供了不同的數據形式，這三個服務都有"id"。但第二種微服務比第一種微服務多了"age"字段，而第三個微服務和第一個微服務相比，雖然都包含"name"字段，但"name"字段里的數據是不一樣的。此時如果是用接口測試來做的話，需要提供3個不同的請求來測試；但如果用契約測試來做的話，契約測試就相當于是這三個的全集，只需要定義一種契約即可。

下圖是藍鯨DevOps平臺提供的測試工具CTest產品功能架構圖，從中可以看出無論是對于支撐不同的測試模式，還是測試報告應該具備的功能項，都已經有了相關的能力，是個較為成熟的產品。在微服務測試時，想要實現環境無依賴，服務間無依賴？或者想要實現快速測試，支撐服務快速上線？這些都可以通過Mock測試來搞定，它就是在測試過程中，對于某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創建以便測試的測試方法。

⑤ 編譯構建

編譯構建是指把軟件的源代碼編譯成目標文件，并把配置文件和資源文件等打包的過程。

當前，業界最流行的編程語言還是Java，不同的編程語言都有不同的構建工具。對于流水線上的構建工具來講，到底一款工具能支撐多少語言類型，也能考驗一款編譯構建工具的能力。

藍鯨DevOps流水線效能實踐工具，可以通過拖拽的形式構建流水線，不像一些開源工具，必須要會寫腳本和手工配置。而藍鯨DevOps流水線效能實踐工具，已經把上述模塊和組件內置了，降低了使用難度。

⑥ 軟件制品

軟件研發過程中的“源碼”和“軟件制品包”（通常被通俗稱為“二進制包”）都是很關鍵的資產。軟件制品包通常是源碼文件的集合或者編譯后的產物，因此主要有二進制包和壓縮包兩種形式，軟件制品包的管理和復用在發布管理有著關鍵的作用。

不同的編程語言，同樣會對應不同的制品形式。現在之所以容器特別流行，就是因為它屏蔽了語言帶來的限制，將包打成統一的格式，放到集群里邊進行部署。

本地倉庫是指開發者個人PC中包文件的存儲包文件通常不放在源碼庫中管理，而是使用專門的包文件倉庫進行存儲并配合包文件依賴管理工具（Maven、NPM、Ivy等）進行使用。包文件倉庫可以大致分為本地倉庫、私服倉庫、中央倉庫三種。

• 私服倉庫通常是企業為了提升包文件使用性能搭建的局域網內共用的包文件倉庫，通常使用開源的Nexus、Artifactory等工具搭建
• 中央倉庫是指開源包文件的共享社區

私服倉庫把源碼倉庫拉下來，通過持續構成的工具打包并存在私服倉庫中。對依賴管理這塊，比如項目和工程依賴一些開源的相關組件，那么私服就會把這些開源組件從互聯網中央倉庫拉下來，放到私服倉庫上。開發人員在內網就可以根據需要，拉取代碼或依賴包在本地做功能開發，做完后再提交到源碼庫，最終打成二進制介質放到私有倉庫里。

PS. 什么是軟件制品庫？

軟件制品庫指能夠統一管理各種類型的二進制制品，同時無縫對接現有的標準化構建和發布工具的軟件平臺。也就說制品庫既能夠存儲中間產物，也能存儲結果產物。“軟件包”及其屬性的管理是發布過程管理的基礎，也是軟件開發過程中的重要資產。

軟件制品庫在DevOps工具鏈中的開發集成、測試、生產等階段都有作用，相關人員可在不同階段把制品打完后放到制品庫。一旦流程走到下一個環節，比如走到開發、測試，走到整個上線管理，制品也會做相應的晉級。

作為DevOps的重要樞紐，如果沒有統一可信制品庫，DevOps和CI/CD運轉起來，就像流水線沒了軸承，研發規模越大，問題和隱患就越多。雖然源碼都是同一套，但是開發環境和測試環境的不同，會導致代碼運行不起來。但如果能夠保證在不同的環境下，用的都是同一個制品，那就能盡量少的屏蔽環境不同帶來的影響。

比如經常聽到“誒這個代碼在我這里運行可以啊，怎么在你哪里運行不了？那肯定是你本地服務器的毛病。”因此，通過制品庫的使用，能逐步避免這類現象的產生。

該客戶是內外網隔離的，私服負責從外網的中央倉庫下載依賴包，內網的依賴庫和外網的私服庫進行打通，以便于數據同步。所有內網的研發團隊，都是從依賴庫下載所需資源包，并做一些安全掃描等管理工作。由于該團隊是分布式的開發團隊，在全國各地都有相應的團隊，每個城市都有自己的制品倉庫作為本地的倉庫節點，在開發中心有一個主節點，這樣就把制品庫做了一個主從的模式，以便制品的同步和晉級。

03. DevOps實現自動化部署

自動化部署可以減少人肉運維和手工運維的工作量，也能盡量避免人工操作所帶來的的錯誤和風險。自動化部署是指將可交付產品，快速且安全地交付用戶使用的一套系統和工具。系統會自動構建、測試并準備代碼變更，以便將其發布到指定環境的過程，包括開發環境、預發布環境、生產環境等。

系統模板是自動化部署服務的關鍵特性。通過使用系統模板快速創建部署任務，然后將組合的部署步驟保存為自定義模板，這樣在下一次部署任務來臨時，就可以直接使用該模板。

我們把不同系統的發布策略做了一個整理匯總（見下圖），如果實際應用場景具備這些能力項，就可以跟其他的組件相結合，對外提供不同的發布策略。

04. 企業文化推廣

有了前面的方法論，又該怎么開始準備和實施呢？

準備階段1：選擇合適的試點項目

從最有同理心和最樂于創新的團隊開始，擴大DevOps的范圍。在逐步擴大的過程中，發現創新者和早期采用者，贏得沉默的大多數，并識別意愿較低的“釘子戶”。最后，盡早展示成果并積極宣傳，將大目標分解成漸進式的小步驟。

Tips: 改進試點項目時，不但要努力降低復雜性，提高可靠性和穩定性，而且還應該更快、更安全、更容易變更，團隊才可能更愿意嘗試。

準備階段2：組建全功能團隊

軟件開發團隊的結構對軟件產品的架構和成果有巨大的影響，利用康威定律組織團隊，減少工作交接次數，提升交付速度和成功率。小團隊獨立運作，彼此充分解耦，避免過多的溝通與協調。牢記兩個比薩原則，保持小規模。

準備階段3：團隊成熟度評估

在對團隊進行成熟度評估時，可從價值、能力、角色三個方面進行考慮，參考業界端新型的研發能力框架對團隊進行成熟度評估。

準備階段4：價值流分析實例

• 召集所有關鍵成員，繪制價值流圖。
• 記錄主要的步驟和細節，讓相關干系人員擁有同樣的視圖。
• 重點分析和優化，識別阻礙：需要等待數周甚至數月的工作；引發或處理重大返工的工作。
• 確定想要改進的度量指標，通過探索各種假設，然后分析結果，不斷迭代和重復，將獲得的經驗用于下一次實驗。

團隊敏捷：敏捷意識強化、知識點與工具使用培訓、敏捷會議的觀察及引導、測試前移、團隊質量監控、SoS敏捷管理方法在實施階段，確定實施的優先級，按優先級逐一推進。

• 業務敏捷：探求運用用戶故事地圖、實例化需求與用戶故事、進行需求條目化、利用需求條目需求及任務分拆、形成統一的產品需求列表、探求估算與與迭代計劃、探求需求溝通與反饋方式
• 工程敏捷：自動化單元測試、自動化代碼掃描、自動化集成測試、自動化功能/流程測試、持續集成、持續交付、部署流水線、主干開發
• 管理工具：電子看板/物理看板、任務列表、項目狀態 - 燃盡圖、增值流圖

DevOps是數字化轉型成功的關鍵之一，雖然DevOps建設非一日之功，但是建成之后的價值不只能提升企業IT研發效能、交付質量和靈活應對業務需求的變化，對提升企業內部團隊的協作和敏捷能力都有著顯著變化。