前言
企業級DevOps的體系化落地中繞不過的一個坎就是如何匹配企業現狀實現交付過程的全覆蓋，特別是在一些金融銀行類的企業，在落實DevOps的過程中還必須滿足業內的一些規範要求，而這些要求往往是一些單獨的工具不會去考慮的，本文便通過整體思路討論一下目前DevOps建設中會遇到的一些流程工藝，如何通過平臺承載。
需求、協同領域
需求管理模型選擇
對於需要嚴管控的企業中，如製造業或傳統IT行業更多的會選擇CMMI的管理模式，此模式更加註重在大批量人員協作的情況下，只要按照流程進行，那至少不會出錯，但是在該模式下我們也不能指望效率能再有什麼提升，畢竟嚴格管控就會有衆多的卡點環節，消耗大量時間。而另一種敏捷模式，相對而言就對人員的要求要高不少，注重輕量化項目團隊，團隊組成更希望有多面手存在，適合需要快速推向市場進行驗證的業務；
但是現在即便是傳統行業中的IT也有很多ToC業務，需要更快的佔領市場份額，因此會做部分項目組的敏捷轉型，那麼這裏就需要優先考量兩個點：一個是項目的風險容忍程度，另一個就是平臺要足夠靈活，支撐多態的場景。
風險容忍度簡單舉例來說，對內提供服務，需要注重穩定性安全性，需求不會經常變更，但是變更會連帶影響衆多依賴系統的，其實也並不一定需要強敏捷的模式。另一方面企業很多的新核心類的系統需要快速迭代滿足市場要求，在這種情況下如果還是採用傳統管理的方式，那就是將市場份額拱手讓人。
目前純粹的需求管理工具有很多，包括很多企業早期也一定建設過許多符合自己管理需要的平臺，這些我們在此不做討論，我們特指在新DevOps體系中，需求的靈活建模、模板沉澱、模塊複用、雙模支持應當在工具層面需要考慮，同時要求所有的業務管理規範都是統一的，在越大體量的企業中就越難實現。
分支策略之如何關聯需求
分支管理策略在企業中也不算陌生，但是在落地DevOps的時候早期往往會疑惑的有幾個點：DevOps的最佳實踐中是否有分支管理建議，需求管理到底在哪個層級和分支關聯最好，關聯代碼分支後有什麼消費場景或意義。
我們首先看第一點，至少目前在企業DevOps的應用場景中，沒有說選用DevOps就連帶選定一個最佳的分支管理模式，模式的選擇更多的還是看企業組織上對於管控和發佈頻率上的要求，因此在不同企業團隊的實際落地中，初期我們可以考慮不改變分支管理模式，建設的中後期可以結合DevOps的轉型諮詢選定更匹配的方式。
有了上述第一點支持，那第二點我們其實也不會那麼疑惑了，那就是分支關聯的層級要根據實際來，由此一來平臺就需要具備一定的靈活性，如在敏捷開發模式下，需求、任務等均有可能關聯分支，平臺需要具備相對靈活的配置方式。
而後的消費場景可以留一點想象力，比較建議至少要做的是代碼的合併、提交在觸發流水線自動構建、測試的同時應當將執行記錄回傳回來，保障基礎的審計要求，另一方面代碼的提交修改需要有詳情記錄，這樣在未來我們可以結合需求關聯和代碼等方面自動梳理出應用之間的依賴情況。
架構設計
架構設計其實在大部分DevOps平臺建設中都不會單獨提出來講，因爲至少在目前的交付過程中它不是一個過程執行項，而更像是一個線下會議評審後的要求項，但是如果將交付過程中所有涉及規範、工藝的項都作爲資產沉澱下來的話，無疑會在人員流動頻繁或知識共享方面更近一步。想象一下，如果在需求評審後的架構設計方面，結合文檔、知識管理中的關聯、分析能力，自動推薦可行的技術架構，那是不是也能節約很多時間。
開發領域
開發過程中的一些好的實踐在今後的文章中我會單獨分享，但是在流程工藝或者叫做流程規範中不得不提的就是對於應用配置的管理。如果是一些熱更新的情況，很多企業會直接選擇帶有一定侵入性的harbor進行管理，這樣如果是要和DevOps平臺集成，最簡單就是界面的統一即可，另外對於傳統虛擬機部署的場景，配置文件的管理就會複雜一些，首先如果現在你還把配置混在源代碼裏，那請先處理文件的分離，如果你本身就是分離的只是管理起來比較困難，那麼一個良好的應用配置管理平臺將大大提升你的效率，應用配置管理平臺應當與CMDB共享結構數據，保證拓撲結構的一致性，另一方面需要文件、參數分離，這樣保障在開發、測試、準生產、生產等環境下可以進行復用。
▲ 示例
測試領域
測試領域之所以分成兩部分說，一方面是目前企業中對於測試的關注程度不一，另一方面測試人員水平以及工具的選擇對於組織測試這件事來說也是影響非常大的，在此，我們不討論人工測試好還是自動化測試好，我們只看如何更好的匹配企業的實際情況。
分層測試
分層測試通常在自動化測試中提及，而另一說法分層測試的配比更是被許多企業質控相關的人員所關注，目前在很多企業中往往會盲目的追求自動化測試覆蓋率，但是發現還是會拖慢交付節奏，這是爲什麼呢？
我們迴歸本質，在測試領域一定是自動化測試與人工測試有效結合的方式更高效，比如冒煙測試我們主要測核心的一些業務邏輯，迴歸測試中我們覆蓋主要業務功能，而在快速迭代更新的非穩定業務功能中，人工測試可能更加高效。
因此在DevOps測試管理方面，一方面可以有效結合測試左移的理念，在需求確認的初期就應當綁定用例，面向於交付場景開發與測試並行，另一方面在測試用例的管理中要有效統一的管理用例、用例集以及任務，這樣在方便測試人員單獨開展日常工作的同時也能夠在DevOps整體交付場景中與開發、運維共同維護好一個良性運轉的交付流水線。
工具選擇
工具選擇方面就五花八門了，市面上做測試相關工具的，開源產品和商用產品百花齊放，選擇上往往企業也會選自己比較順手的，而從覆蓋能力來看，接口測試、UI測試、性能測試、安全測試也是層出不窮，在DevOps平臺的建設上很多產品也會自帶一些自動化測試的工具，但能力上也是層次不齊，那怎麼實踐工具方面的選擇呢？
最好的選擇就是不選擇，我“全都要”，這不是說我要買一堆工具，而是指在建設自動化測試域能力的時候DevOps平臺要具備很強的靈活性，無論是企業已採購的、未來採購的，都可以通過自主接入的方式快速在流程中執行此能力，並且可以通過流程規範進行制約，從而在測試領域落地企業特有的工藝流程。
▲ 共享商店
運維又不僅僅是運維
我們都知道，不管是建設自動化運維還是建設研運一體化的DevOps體系，CMDB都是作爲首要被提到的，之所以被廣泛提及作爲最初的建設要求是因爲它是保障研發側的場景消費以及運維基礎數據準確性的基礎，但是越來越多的企業發現單獨做一個CMDB對於日常工作的支撐是非常有限的，甚至在中小企業中建設後給一線人員直接感覺就是“無感”，爲什麼是這樣呢？
我們回過頭來再看CMDB，保障基礎數據的穩定一致是爲了供場景消費的，而市面上大部分的CMDB建設不管是指基礎CMDB還是應用維度CMDB都只關注數據本身採集的全面性準確性而不太注重後續的消費場景，而作爲研發過程中的支撐就更加有限了。
例如爲了更好做到基於整個交付的版本、基線管理，那麼CMDB中需要存儲的數據就一定不僅僅是服務器、中間件、數據庫、網絡存儲之類，應當將應用或項目維度相關的儘可能全面的數據、版本統一進行納管，這樣我們可以在未來的任意時間點將配置、環境、應用等保持與原基線的一致性，因此不難看出我們可以將需求模型、基礎架構、分支模型、應用配置文件、數據腳本、環境基線等均通過CMDB統一納管，實現更加廣域的CMDB。
▲ 廣域的CMDB示例
總結
企業建設DevOps平臺的時候都想要靈活、可控，但是什麼叫靈活可控，是先開發建煙囪再打通叫靈活可控，還是說就有了全部源碼就算靈活可控呢，我們發現先定義流程再打通的模式很難適應未來快速變化的場景，另外越來越多的企業發現“靈活”的定義應當是指平臺可以在不同企業，不同流程工藝的要求下，依然可以很好的支撐過程，滿足自主能力的擴展，因此無論是端到端的橫向貫通還是縱向的規範落地都應當是企業建設前需要重點考慮的。