DEVOPS落地實踐分享
轉載本文需注明出處：微信公眾號EAWorld，違者必究。
引言：
DevOps的理念已經說了很多年，其帶來的價值逐漸被接受，很多企業也逐漸引入了DevOps。目前普元DevOps平台發布到5.2版本，這期間為多個客戶實施了DevOps平台。那么，實施的主要過程是怎樣的，在實施過程中會遇到哪些問題又是如何解決的，本文將和大家一起探討這些問題。
目錄：
一、DevOps平台簡介
二、DevOps平台實施過程
三、問題和解決方案
四、實施效果
一、DevOps平台簡介
首先簡單介紹一下DevOps平台，看下能力矩陣和整合的工具鏈，對DevOps平台有一個大致的了解。
DevOps的能力矩陣
DevOps整合工具
二、DevOps平台實施過程
調研和評估
調研和評估過程主要為了了解客戶的管理成熟度和重要流程，以此為依據制定提升目標及改進方案，為遷移到DevOps平台做准備。為此，我們整理了調研問卷，涉及項目研發的整個過程。
在實施初期，我們一般會選擇比較有代表性的項目，進行調研和分析。我們會從需求管理、開發、代碼管理、構建、測試、部署、發布這幾個方面進行調研和分析，判斷項目是否適合遷移到DevOps平台，項目研發過程的某些環節是否需要進行改進和完善。
根據調研問卷，各方面的具體關注點如下：
需求管理：需求管理工具、用戶故事、任務、迭代等 開發：開發語言、開發工具、技術框架、運行環境、組件划分及依賴關系等 代碼管理：代碼及文檔管理工具、代碼庫分支及用途、分支策略、代碼質量檢測工具及質量指標等 構建：構建工具、構建過程及構建策略、構建介質策略、中間介質及最終介質管理等 測試：用例和Bug管理、自動化測試工具、驗收標准等 部署：環境規划、環境配置、部署方式、依賴的中間件和公共組件等 發布：上線交付物、發布流程、應用及數據備份方式、回滾方式等
本階段產出文檔：調研問卷、提升建議和改進方案。
制定規范
經過對典型項目的調研和分析，結合客戶的實際關切點，根據最佳實踐制定相關規范，為后續項目遷移到DevOps平台提供條件。
這里主要介紹兩個規范：
代碼庫規范：包括分支和標簽命名規范、分支管理規范（管理流程、hotfix流程、分支策略）、代碼提交規范。
以分支開發、主干發布為例，管理流程規范中會涉及代碼庫准備、開發集成、驗收測試、發布環節，每個環節中涉及的角色，角色的操作流程都有詳細規范。
CICD流程規范：命名規范：組件、介質倉庫、構建定義、構建產物別名、發布定義。流水線規范：開發流水線、用戶驗收測試流水線及回滾流水線、發布流水線及回滾流水線、hotfix流水線。
通過制定流水線的規范，形成不同類型項目的CICD流程模版，可以作為組織級規范進行審計。
對於流水線的定義和設計，需要考慮客戶的環境規划和網絡策略。一般情況下，會設計和定義開發測試流水線、用戶驗收測試流水線、發布流水線這些常規流水線，對應開發測試環境、用戶驗收環境、生產環境。開發測試流水線經過多次執行，業務系統形成穩定版本，交付到用戶驗收測試流水線，通過用戶驗收測試之后，再轉到發布流水線進行發布上線；這個過程也設計到代碼分支和標簽的維護。
有的客戶，階段交付物是某個版本的工件介質，並且介質庫可以多環境共享或者同步，這種情況下需要在開發測試流水線中設計構建環節和部署環節，在用戶驗收流水線和發布流水線不需要構建環節，因為交付介質像下一個環境同步即可。
流水線設計如下：
有的客戶階段交付物是代碼，且各個環境有網絡策略限制。這種類型的流水線，不同環境需要根據對應的代碼分支或標簽將介質構建出來，然后再進行部署。
流水線設計如下：
產出文檔：代碼庫規范文檔、CICD流程規范、流程配置規范、度量指標等。
培訓
主要是對DevOps平台和相關的規范的培訓。DevOps平台的培訓，主要是為了讓用戶熟悉DevOps的能力。規范培訓，主要結合具體的使用場景和最佳實踐讓用戶了解和熟悉代碼庫、CICD流程等規范。
項目試點及推廣
項目試點是非常重要的環節，也是后續能否進行推廣的重要評判依據。經過前期的項目改進，以及流程規范的普及推廣，試點項目作出適當調整，試點項目的遷移是對之前所有工作的一個重要檢驗。
在試點階段，一方面是要通過試點項目的規范化改造，打造同類項目的流程規范，形成可復制的流水線模式；另一方面看遷移前后給試點項目帶來哪些好的效果，是否符合預期，是否還有需要改進的空間，平台能力是否需要提升等等。項目試點階段產出的文檔和手冊是后續推廣的重要資源。
當試點項目的遷移達到預期效果，就可以進行DevOps平台的普及推廣。
三、常見問題和解決方案
工具整合
在DevOps實施過程中，工具鏈的打通必然涉及各種工具的整合。除了DevOps平台本身已經集成的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具，比較常見的是對客戶已有工具等集成，如客戶自建的項目管理平台、CMDB平台、自動化測試平台等等。
對於用戶自建工具的整合，首先需要去理清整合的真正目的是什么，能為用戶帶來哪些價值。比如，對項目管理平台的整合，DevOps平台可以對項目等迭代、需求、任務等信息進行收集和匯總，最終項目的進度、成本一目了然。再比如，對CMDB的集成，對於CD過程中使用的資源（主機、容器），直接從CMDB拉取數據即可，無需在DevOps平台中重新配置一遍。
這里建議，對已有工具的整合，整合的是數據，目的是讓數據流轉和匯總起來，而非做功能的整合。
環境
不同的客戶對環境的規划往往也不同，比如有的客戶規划為開發環境、集成測試環境、用戶驗收環境、生產環境，也有客戶在生產環境前還有預發環境；對於不同環境的隔離，不同客戶的做法也不盡相同。
某電信客戶的部署架構，通過防火牆策略+Nginx管控環境間的網絡通信
某銀行客戶的部署架構，通過防火牆策略管控環境間的網絡通信，但是要通過堡壘機連接部署機
對環境和網絡的管控，一般都是硬性要求，需要符合客戶的管理規范。這就需要根據實際的環境和網絡要求，調整DevOps平台的部署架構，並按照客戶的規范開通相關策略，這里會有一定的溝通成本和實施成本。
任務類型支持
DevOps平台中的構建和部署流程一般由若干個可編排和可配置化的任務組成，平台中內置了常用的構建和發布相關的任務，能滿足絕大部份構建和部署場景。
構建相關任務
發布相關任務
如果內置的任務中無法滿足使用需求，還可以根據DevOps平台提供的擴展手冊進行任務擴展。
四、實施效果
規范化、統一化
項目遷移到DevOps平台，各個項目可以在一個統一的DevOps平台進行CICD，無需各自搭建持續集成平台。通過制定合理的規范，不同的項目遵守一致的規范，避免了代碼庫、CICD流程的管理混亂和不規范。制定度量指標和規范，對軟件開發成果和開發過程的測量和分析，幫助對軟件開發過程持續進行改進，有效提高軟件交付質量和效率。
研發效能提升
可視化和可編排，無需編寫pipeline腳本，一次配置，多次執行。提交或合並代碼出發、定時觸發或手動一鍵執行構建和部署，提高研發人員效率。有效減少系統變更部署上線的時間，快速響應業務變化。
報表展示、可度量
從效率、質量、進度三個維度展示任務、代碼、構建、部署相關數據，結合項目看板、報表和度量指標，各環節干系人可以對進度、質量等進行判斷和干預。
總結：
DevOps的建設是難以短期內完成的，需要進行總體規划，然后分階段實施。無論是工具的整合，還是度量體系的實施，都需要按部就班、循序漸進，逐步完成建設，最終實現預期目標。