DevOps落地實踐分享

轉載本文需註明出處：EAWorld，違者必究。

引言：

DevOps的理念已經說了不少年，其帶來的價值逐漸被接受，不少企業也逐漸引入了DevOps。目前普元DevOps平臺發佈到5.2版本，這期間爲多個客戶實施了DevOps平臺。那麼，實施的主要過程是怎樣的，在實施過程當中會遇到哪些問題又是如何解決的，本文將和你們一塊兒探討這些問題。

目錄：

1、DevOps平臺簡介
2、DevOps平臺實施過程
3、問題和解決方案
4、實施效果

1、DevOps平臺簡介

首先簡單介紹一下DevOps平臺，看下能力矩陣和整合的工具鏈，對DevOps平臺有一個大體的瞭解。

DevOps的能力矩陣

DevOps整合工具

2、DevOps平臺實施過程

調研和評估

調研和評估過程主要爲了瞭解客戶的管理成熟度和重要流程，以此爲依據制定提高目標及改進方案，爲遷移到DevOps平臺作準備。爲此，咱們整理了調研問卷，涉及項目研發的整個過程。

在實施初期，咱們通常會選擇比較有表明性的項目，進行調研和分析。咱們會從需求管理、開發、代碼管理、構建、測試、部署、發佈這幾個方面進行調研和分析，判斷項目是否適合遷移到DevOps平臺，項目研發過程的某些環節是否須要進行改進和完善。

根據調研問卷，各方面的具體關注點以下：
 

• 需求管理：需求管理工具、用戶故事、任務、迭代等
• 開發：開發語言、開發工具、技術框架、運行環境、組件劃分及依賴關係等
• 代碼管理：代碼及文檔管理工具、代碼庫分支及用途、分支策略、代碼質量檢測工具及質量指標等
• 構建：構建工具、構建過程及構建策略、構建介質策略、中間介質及最終介質管理等
• 測試：用例和Bug管理、自動化測試工具、驗收標準等
• 部署：環境規劃、環境配置、部署方式、依賴的中間件和公共組件等
• 發佈：上線交付物、發佈流程、應用及數據備份方式、回滾方式等

本階段產出文檔：調研問卷、提高建議和改進方案。

制定規範

通過對典型項目的調研和分析，結合客戶的實際關切點，根據最佳實踐制定相關規範，爲後續項目遷移到DevOps平臺提供條件。

這裏主要介紹兩個規範：
 

• 代碼庫規範：包括分支和標籤命名規範、分支管理規範（管理流程、hotfix流程、分支策略）、代碼提交規範。

以分支開發、主幹發佈爲例，管理流程規範中會涉及代碼庫準備、開發集成、驗收測試、發佈環節，每一個環節中涉及的角色，角色的操做流程都有詳細規範。
 

• CICD流程規範：命名規範：組件、介質倉庫、構建定義、構建產物別名、發佈定義。流水線規範：開發流水線、用戶驗收測試流水線及回滾流水線、發佈流水線及回滾流水線、hotfix流水線。

經過制定流水線的規範，造成不一樣類型項目的CICD流程模版，能夠做爲組織級規範進行審計。

對於流水線的定義和設計，須要考慮客戶的環境規劃和網絡策略。通常狀況下，會設計和定義開發測試流水線、用戶驗收測試流水線、發佈流水線這些常規流水線，對應開發測試環境、用戶驗收環境、生產環境。開發測試流水線通過屢次執行，業務系統造成穩定版本，交付到用戶驗收測試流水線，經過用戶驗收測試以後，再轉到發佈流水線進行發佈上線；這個過程也設計到代碼分支和標籤的維護。

有的客戶，階段交付物是某個版本的工件介質，而且介質庫能夠多環境共享或者同步，這種狀況下須要在開發測試流水線中設計構建環節和部署環節，在用戶驗收流水線和發佈流水線不須要構建環節，由於交付介質像下一個環境同步便可。

流水線設計以下：


有的客戶階段交付物是代碼，且各個環境有網絡策略限制。這種類型的流水線，不一樣環境須要根據對應的代碼分支或標籤將介質構建出來，而後再進行部署。

流水線設計以下：



產出文檔：代碼庫規範文檔、CICD流程規範、流程配置規範、度量指標等。

培訓

主要是對DevOps平臺和相關的規範的培訓。DevOps平臺的培訓，主要是爲了讓用戶熟悉DevOps的能力。規範培訓，主要結合具體的使用場景和最佳實踐讓用戶瞭解和熟悉代碼庫、CICD流程等規範。

項目試點及推廣

項目試點是很是重要的環節，也是後續可否進行推廣的重要評判依據。通過前期的項目改進，以及流程規範的普及推廣，試點項目做出適當調整，試點項目的遷移是對以前全部工做的一個重要檢驗。

在試點階段，一方面是要經過試點項目的規範化改造，打造同類項目的流程規範，造成可複製的流水線模式；另外一方面看遷移先後給試點項目帶來哪些好的效果，是否符合預期，是否還有須要改進的空間，平臺能力是否須要提高等等。項目試點階段產出的文檔和手冊是後續推廣的重要資源。

當試點項目的遷移達到預期效果，就能夠進行DevOps平臺的普及推廣。

3、常見問題和解決方案

工具整合

在DevOps實施過程當中，工具鏈的打通必然涉及各類工具的整合。除了DevOps平臺自己已經集成的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具，比較常見的是對客戶已有工具等集成，如客戶自建的項目管理平臺、CMDB平臺、自動化測試平臺等等。

對於用戶自建工具的整合，首先須要去理清整合的真正目的是什麼，能爲用戶帶來哪些價值。好比，對項目管理平臺的整合，DevOps平臺能夠對項目等迭代、需求、任務等信息進行收集和彙總，最終項目的進度、成本一目瞭然。再好比，對CMDB的集成，對於CD過程當中使用的資源（主機、容器），直接從CMDB拉取數據便可，無需在DevOps平臺中從新配置一遍。

這裏建議，對已有工具的整合，整合的是數據，目的是讓數據流轉和彙總起來，而非作功能的整合。

環境

不一樣的客戶對環境的規劃每每也不一樣，好比有的客戶規劃爲開發環境、集成測試環境、用戶驗收環境、生產環境，也有客戶在生產環境前還有預發環境；對於不一樣環境的隔離，不一樣客戶的作法也不盡相同。

某電信客戶的部署架構，經過防火牆策略+Nginx管控環境間的網絡通訊



某銀行客戶的部署架構，經過防火牆策略管控環境間的網絡通訊，可是要經過堡壘機鏈接部署機



對環境和網絡的管控，通常都是硬性要求，須要符合客戶的管理規範。這就須要根據實際的環境和網絡要求，調整DevOps平臺的部署架構，並按照客戶的規範開通相關策略，這裏會有必定的溝通成本和實施成本。

任務類型支持

DevOps平臺中的構建和部署流程通常由若干個可編排和可配置化的任務組成，平臺中內置了經常使用的構建和發佈相關的任務，能知足絕大部份構建和部署場景。

構建相關任務



發佈相關任務



若是內置的任務中沒法知足使用需求，還能夠根據DevOps平臺提供的擴展手冊進行任務擴展。

4、實施效果

規範化、統一化

項目遷移到DevOps平臺，各個項目能夠在一個統一的DevOps平臺進行CICD，無需各自搭建持續集成平臺。經過制定合理的規範，不一樣的項目遵照一致的規範，避免了代碼庫、CICD流程的管理混亂和不規範。制定度量指標和規範，對軟件開發成果和開發過程的測量和分析，幫助對軟件開發過程持續進行改進，有效提升軟件交付質量和效率。

研發效能提高

可視化和可編排，無需編寫pipeline腳本，一次配置，屢次執行。提交或合併代碼出發、定時觸發或手動一鍵執行構建和部署，提升研發人員效率。有效減小系統變動部署上線的時間，快速響應業務變化。

報表展現、可度量

從效率、質量、進度三個維度展現任務、代碼、構建、部署相關數據，結合項目看板、報表和度量指標，各環節干係人能夠對進度、質量等進行判斷和干預。

總結：

DevOps的建設是難以短時間內完成的，須要進行整體規劃，而後分階段實施。不管是工具的整合，仍是度量體系的實施，都須要循序漸進、按部就班，逐步完成建設，最終實現預期目標。


關於做者：田新會，普元雲計算&SOA產品部高級軟件工程師，曾參與銀聯、神華集團等雲平臺項目的設計與研發，後參與DevOps項目的研發工做，並負責多個客戶的DevOps平臺實施工做。


關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享。長按二維碼關注！