DevOps 實踐分享：4 個實施步驟與 6 個關鍵設計
本文介紹了普元 DevOps 平臺在金融行業實施落地的常用方法，以及在項目管理，代碼管理，構建管理，製品管理，部署管理等模塊針對一些典型客戶場景的關鍵設計。
01 平臺簡介
1. 普元 DevOps 定位
普元 DevOps 平臺以質量和安全爲基礎支撐保障，通過工程化的手段，打造一條覆蓋從需求到研發、測試、部署、運維的軟件生產全週期的 IT 生產線，幫助企業提升 IT 系統研發效率，快速響應業務需求，並通過度量分析、風險預判，持續提升 IT 運營能力。
2. 普元 DevOps 集成
既然要實現軟件研發的全生命週期的管理，自然不可避免需要對企業軟件研發交付的各個階段進行一些集成方面的工作。這裏從縱向和橫向兩個維度來看。
橫向的話實際上是從全生命週期過程中，整個軟件從需求提出，到研發測試，到最終上線，它涉及到了不同部門和角色，不同人員之間的一些協作。橫向主要是爲了打通跨部門，不同職責的人員之間的壁壘，通過流程驅動的方式，讓各部門能高效的協同合作。
縱向維度主要是從軟件需求的管理，項目過程的管理，開發代碼的管理，測試過程的管理，到後續持續集成和持續發佈，再到驗證及最終上線，會涉及到不同的工具鏈。縱向主要是爲了打通了工具鏈的串聯，以實現數據和流程的打通。
3. 普元 DevOps 價值
在通過集成過程打通各部門壁壘，打通工具鏈串聯之後，最終實現數據和管理流程的打通。同時通過度量的方式幫助管理者進行過程的優化，這是我們的一個最終目標。
我們在 DevOps 在實施過程中通過解決如下問題以創造客戶價值。
管理前移： 通過流程數據的打通，可以提前感知項目存在的風險，項目進度是否有延遲，質量與預期的目標是否有偏差，幫助管理者能更早的發現問題並介入處理，以便能更早的規避風險。
全鏈路追溯： 通過數據流程的打通建立從工作項 - 代碼 - 構建 - 製品 - 發佈 - 實例運維的一整條鏈路信息。以便發現問題時能很方便的進行鏈路追溯和問題排查。
量化評估： 打通流程和數據之後，可以基於報表相關數據對各個階段的工程效率進行度量，也能更好進行資源分配。同時可以更準確評估完成需求需要的時間，以便合理的制定開發計劃。
自主掌控： 對代碼源頭，編譯過程，發佈過程進行管控。
多架構適配： 支持各種技術棧應用的編譯，編譯環境管理，支持不同的中間件應用發佈。在一個統一的平臺上形成完整的資產和信息鏈。屏蔽一些差異化，通過相對標準的配置就能進行管理。
驅動協同： 這裏不僅僅是開發和運維了，它是完整的，從需求，開發，測試，運維。並涵蓋質量與安全。這也就是之前提到的橫向打通部門之間的壁壘，實現高效的驅動協同。
02 實施方法
1. 實施過程總覽
通常，會將 DevOps 實施過程分成如下四個步驟。
調研分析：
1) 組織級現狀調研
基於需求範圍對企業 IT 管理流程和規範進行調研，如項目管理，需求任務拆分，缺陷管理，應用提測及投產流程，代碼庫分支管理策略等。同時，需要對企業的網絡架構及管理規範進行調研，結合企業已有平臺（代碼庫，製品庫等）部署情況，合理的設計 DevOps 平臺的部署架構。
2) 試點選擇與調研
試點項目選擇需要基於企業應用特點，選擇最具有代表性的項目（應用架構具有普遍性，如微服務項目等）。根據試點項目應用類型梳理接入 DevOps 關鍵問題點並進行調研。
3) 範圍梳理
根據上述調研的情況編制調研分析報告，結合需求範圍與調研的結果合理的規劃後續的實施範圍及方案。
制定方案：
1）平臺部署方案
根據之前的調研情況以及與運維的溝通，制定平臺的部署架構。梳理需要部署的應用以及資源信息（主機資源或雲上資源信息，高可用，存儲，CPU，內存等），以及應用之間的交互方式及端口，以便開通網絡策略。
2）技術驗證
搭建完平臺環境之後可以進行試點項目應用的驗證，試點項目工程的 CI，CD 驗證等。
3）平臺建設方案
在技術驗證的過程中，同步梳理項目的建設目標，集成方案（單點登錄，應用服務器，容器雲等）。
實施落地：
1）建立規範
根據試點項目的應用類型，梳理對應該類型應用的 CI，CD 相關規範，結合代碼庫管理規範與製品管理規範等配置對應的流水線模板，建立對應的最佳實踐。
2）平臺定製
在驗證過程中，根據情況擴展工具集。基於需求範圍同步完成其他如單點登錄，容器雲等平臺的集成開發。
3）試點接入
在建立對應應用類型的最佳實踐之後開始對同類型項目試點進行宣貫和培訓，以便能夠快速接入。
運營推廣：
1) 實施推廣
建設推廣運營團隊，制定平臺運營推廣指南，建立標準規範體系，提供技術支撐，加強項目組的能力建設。
2）持續優化
在推廣過程中持續與項目組溝通，獲取反饋信息，持續優化 DevOps 平臺。
2. 落地方法與策略
迭代演進
DevOps 建設不可能一蹴而就，需要結合平臺特點、項目需要、以及企業自身的組織能力，形成階段性目標，採用迭代演進的方式，有重點分步驟的建設。每次迭代必須有明確目標、工作清單、交付物。
自主掌控
在 DevOps 建設過程中，需要重視企業自身 IT 隊伍的培養，確保自主掌控，實現人員能力和組織能力的雙落地。IT 部門應該深度參與項目實施過程，與 DevOps 實施人員共同組成團隊，承擔具體的實施任務以及後續的運營推廣。
03 關鍵設計
1. 項目管理
工作項概念模型
我們將不同的項目管理模式定義成不同的項目模板。項目模板包含人員角色模板，菜單模板和工作項方案等。
Ø 角色模板
人員角色模板定義了一類項目管理模式中涉及到的人員角色。不同的人員角色有不同的權限配置。如項目中有項目經理和需求分析員等人員角色。系統中有系統開發負責人，開發人員，測試人員，配置管理員，運維人員等角色。
Ø 菜單模板
菜單模板定義了一類項目管理模式中涉及的功能菜單。如系統下對應用程序做構建和部署，生產上線也是以系統爲單元。在項目下不進行構建和部署則不需要對應功能菜單。
Ø 工作項方案
工作項方案定義了一類項目管理模式中涉及到的工作項管理。如項目中需要對業務需求拆分的需求條目進行管理，系統下需要對條目拆分的系統需求，開發任務，缺陷等工作項進行管理。不同工作項對應的頁面及屬性也不同，工作項狀態流轉過程也不同。
項目模板的能力用以應對企業項目管理的差異化需求。同時藉助項目之間關聯的能力實現項目與系統的關聯以及跨項目的工作項拆分。
2. 代碼庫管理
通常，代碼庫按系統分組，系統下的每一個工程都有一個或多個獨立的代碼庫，它們通常獨立的進行編譯和部署。
如 scm 系統下的 lmp 工程前後端獨立開發部署：scm/lmp-portal.git，scm/lmp-server.git。
代碼分支策略 - 多分支並行
這是一個代碼分支管理策略的示例（系統存在多個項目的需求並行開發，測試，上線）：
客戶需求：
Ø 既希望版本可控，又希望簡化項目組工作量。
Ø 單項目多批次上線：同一個項目可能分多個批次上線。
Ø 系統下多項目並行開發：開發、測試和投產都是按項目管理，但爲了簡化運維工作，希望在同一天上線的多個項目合併投產一次。
Ø 計劃調整：計劃上線的特性可能臨時調整，不上線的代碼不投產。
大家也能看出如上第四點中計劃上線的範圍變更所帶來的問提，系統下工程存在多個項目的需求並行開發，同時規劃好要投產的代碼要提前進行合併測試。
但臨上線之前的範圍變更，並沒有足夠的時間進行重新合版測試。最後的結果只能是投產的版本與測試的版本不能完全一致。
在面對這種問題我們都會解釋這種臨時的變更是不合理的，是不符合管理規範的。但這麼顯而易見的問題，客戶又怎麼會不知道。只是日積月累，有些問題很難一下子就改變，但在當下要做的是結合已有的能力盡可能的去規範化，去簡化這些流程。
代碼提交規範
通過代碼提交和任務關聯的方式，可以解決代碼庫策略中的部分問題，如基於系統需求去篩選代碼進行 cherry-pick。
我們提供了 Eclipse 和 IDEA 的插件，開發人員可以在開發工具上就能處理自己的開發任務。同時提交代碼時可以選中代碼對應的開發任務，這樣會自動生成代碼提交的信息，並將代碼提交記錄與工作項任務關聯。這樣在系統需求和任務中就能看到提交代碼的記錄。
3. 構建管理
最佳實踐 - 應用構建模板
DevOps 提供了涵蓋代碼，工具，構建，部署，測試等類型共計 80 + 個原子任務，同時提供了動態表單加靜態腳本擴展原子任務的框架以滿足企業持續集成和持續部署的需求。
針對企業不同的應用類型，我們通過原子任務的編排配置及參數抽離建立了不同的應用構建模板，以供同類型應用可以導入執行，以達到統一規範，建立應用構建最佳實踐的目的。
最佳實踐 - 雲上構建
雲下構建過程中，如果存在系統公用引擎的情況，可能會產生一些問題。如一些構建工具的多版本及全局配置問題（編譯環境隔離）。
DevOps 平臺提供了構建引擎節點在雲上動態擴展的能力，可以實現節點按需擴展（一個構建任務對應一個 pod）。
我們根據微服務應用編譯用到的原子任務，去配置 pod template，pod template 中包含了微服務應用所用到工具的容器，同時包含一個額外與 jenkins master 交互的 jnlp 容器。在微服務應用執行構建時，會自動調用雲環境，用 pod template 中定義的容器配置去創建對應的 pod 來執行整個構建過程。
4. 製品管理
製品庫管理
除了製品庫管理需求，企業本身還有自己的三方庫管理，通常會使用代理外網或離線同步的方式管理第三方依賴。同時會使用獨立的庫管理企業自身產出的一些依賴。
製品庫一般按系統和環境劃分，不同的環境使用不同的庫，通常區分開發，測試，投產庫。開發，測試庫製品通過編譯產生，生產庫製品通過測試庫中測試通過的製品晉級獲取。
製品目錄結構
除了按環境分庫管理，對製品目錄也會建立規範要求。如在測試環境和生產環境使用基線（投產窗口）作爲一級目錄（測試環境可以加上提測次數標記）。
基線下可以按應用模塊劃分，每個應用模塊都應該是一個獨立部署的單元。
config 目錄存放變更的配置，app 目錄存放變更的應用程序包，data 目錄存放變更的數據包（如升級 sql，回滾 sql 等）。
製品元數據
通過關聯對象的打通我們基於製品彙總了關聯信息，同時我們在多個功能模塊中都可以對全鏈路信息進行追溯。
Ø 工作項：可以查看製品中新增部分所對應的需求，任務以及修復的缺陷等。
Ø 代碼庫：可以查看製品對應的代碼庫，分支，commit 等信息。
Ø 構建：可以查看製品是從那個構建定義的那一次執行產生的。
Ø 發佈：可以查看製品是否已經被部署到具體的環境。
Ø 質量：可以查看製品的代碼掃描的結果信息。
Ø 依賴：可以查看製品的第三方依賴及其 license 信息。
Ø 安全合規：可以查看製品中依賴的漏洞信息和 license 合規（不允許商用等）信息。
製品晉級
質量和安全在整個軟件研發全生命週期中是無處不在的。 因此對於檢測的執行過程是可以分散在不同的功能模塊中，但管控不應該是分散的，我們應該基於特定的管理流程對我們需要執行的檢查結果進行統一管控。
Ø 質量配置：
指標管理： 對不同工具的檢查結果指標要求進行定義。
策略管理： 檢查結果校驗的後處理邏輯，如郵件通知，自動創建缺陷，工單審覈等。
清單管理： 彙總指標和策略配置並與具體的系統進行關聯。
Ø 數據關聯（建立檢查結果數據與製品關聯）：
代碼掃描： 代碼檢查的結果信息。
製品掃描： 製品依賴的漏洞和 license 合規的信息。
容器掃描： 容器掃描的漏洞信息。
自動化測試： 測試環境自動化測試的結果信息。
Ø 統一管控（在製品晉級流程中基於質量和安全檢查結果信息進行管控）：
晉級申請： 測試通過的測試製品庫基線目錄發起晉級到生產庫的流程。
晉級審批： 基於質量配置指標自動檢測製品關聯的結果信息，也可觸發人工檢查流程。
5. 部署管理
部署流水線配置
同構建一樣，部署也是採用的原子任務編排的方式實現，如一個發佈流水線用到數據庫備份，數據庫腳本執行，websphere 應用部署等原子任務來實現應用及其數據的備份和部署。
應用部署原子任務示例
這是一個 websphere 應用部署原子任務的例子。主要想說明的是部署不單單只是一個部署腳本的執行，我們會有針對應用發佈的一些流程進行管控，如全量部署，增量部署，應用備份，應用回滾等。
應用部署規範
基於平臺提供的能力，根據應用部署的規範要求，通過流水線配置將同一類應用的部署過程模板化，並保證不同環境基礎設施的一致，這樣才能保證同一條流水線在不同環境中都能正常使用。
6. 生產發佈
平臺部署方案
一套平臺的部署方案相對簡單，通常會將平臺部署到生產，然後打通到開發測試點對點的網絡即可。
但部分企業對生產環境的網絡打通有嚴格的管控，同時運維人員使用的平臺需放到獨立的環境中。上圖就是兩套 DevOps 環境，使用單向數據同步的部署方案。打通生產 DevOps 單向訪問測試區 DevOps 的網絡，用以同步所需的關鍵數據，如項目，系統，流水線等。打通生產製品庫單向訪問測試區 DevOps 的網絡，用以同步生產發佈所需的製品。
投產管理
同開發測試環境部署不同，生產發佈通常是在固定投產日對當天上線的系統進行統一的生產環境部署。DevOps 平臺提供了獨立的投產管理的功能。
投產管理功能包含投產窗口管理，投產系統管理，投產系統部署執行及跟蹤的能力。
Ø 投產窗口： 對提前規劃投產窗口進行批量導入，同時支持添加臨時投產創建。
Ø 投產系統： 系統投產計劃關聯投產窗口，支持查看系統的投產責任人，迭代或版本信息，投產時間等，支持維護系統的投產狀態。支持查看投產日投產進度。
Ø 投產發佈： 支持查看製品基線，投產清單，流水線等信息，支持手動或定時執行發佈流水線，支持對執行過程進行跟蹤。
關於作者： 子康，普元數智研究院資深顧問。曾參與多個 DevOps 項目，主要負責項目實施工作。開源技術愛好者，擅長雲計算，容器，DevOps 等相關領域技術。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/YlHEHRc-5FjCyv7VSf5GmQ