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的建設是難以短期內完成的，需要進行總體規劃，然後分階段實施。無論是工具的整合，還是度量體系的實施，都需要按部就班、循序漸進，逐步完成建設，最終實現預期目標。