一、普元 DevOps 平臺建設歷程  

普元從 2008 年開始研發持續整合平臺（CIP）、自動化測試平臺（UTP），2009 年內部的所有產品都實現了持續整合、自動化測試、自動化部署。

隨著 DevOps 理念的興起，企業的數字化轉型的需求也愈發強烈，於是開始著手研發 DevOps 平臺，並在這個過程中不斷探索微服務、DevOps、容器雲、ChatOps 等的關係和最佳實踐。DevOps 先後歷經 4 個大版本，目前已經完成了落地的實踐。

2015.7~2016.4：為支撐企業數字化轉型，普元開始研發數字化企業雲平臺（ThePlatform），於 2016 年 4 月完成 1.0 版本並進行內部上線。1.0 版本主要提供了持續整合和持續部署的能力，同時還包含了自己的容器雲平臺，與容器雲平臺對接，貫穿設計、開發、測試、上線、維護五大軟體研發生命週期，打通程式碼提交、觸發整合、自動部署到容器雲的快速鏈路。

2016.5~2016.9：基於自己吃自己狗糧的思想，通過 1.0 版本研發了 2.0 版本，考慮到產品的發展，將數字化企業雲平臺中的產品各自獨立拆分出來，包括 DevOps、容器雲。每個產品都有著獨立團隊，持續發展。DevOps2.0 在 1.0 版本的基礎上，打通規劃、需求等環節，將產品管理、專案任務管理等能力納入進來。

做了 2.0 版本，大家反倒有些困惑了，DevOps 平臺真的就只是簡單的通過和某些工具（如 Jenkins）整合，然後一鍵編譯、部署到容器雲上就可以了嗎。我們開始借鑑很多國外的優秀產品，同時也開始和更多的其他公司進行深度交流。慢慢地發現，真正實現一個企業級的 DevOps 平臺，遠不止和 Jenkins 做整合、一鍵部署到容器雲這麼簡單。以持續整合為例，一個企業要支援的整合環境肯定不止一種，包括 maven 編譯、ant 編譯、android 編譯、ios 編譯、前端應用編譯（nodejs），在整合時還要考慮和程式碼質量分析，單元測試、單元測試覆蓋率檢查、介質上傳等能力的結合，其實整合也是一個工作流。

最典型的一個流程如：maven 編譯 (包含單元測試)–》程式碼質量分析 –》交付物上傳到二方庫。在構建後還應該看到詳細結果：構建詳情、日誌、單元測試報告、程式碼質量分析報告、介質檢視與下載等能力。想想，這樣的一個過程是不是才能基本滿足了企業的正常使用方式？

以部署而言，企業的真實環境又豈會是隻有容器雲。對於大部分企業而言，物理機是必須的，有的企業甚至物理機、虛擬機器、容器雲三種環境並存，那麼在部署的能力上，只支撐容器雲環境的部署顯然是遠遠不夠的，至於企業實際的部署能力，自然又更加的複雜：應用部署（springboot 應用，傳統 war 包、純前端應用）、中介軟體部署（資料庫部署、分散式快取、分散式訊息佇列）等都要一一考慮。所以在 2016.7~2016.8，我們開始研發 3.0 版本中，在持續整合和自動化部署的能力上，參考 tfs 和 oneops 的優秀設計，結合企業實際的使用場景，用了兩個月的時間細化打磨持續交付的能力。

2016 年 10 月份開始，我們重新梳理了整個 DevOps 平臺的需求，將整個平臺劃分成了三大領域：敏捷過程、持續交付、持續改進。

• 敏捷過程：包含產品管理、專案管理、任務管理、進度管理、計劃管理等，覆蓋產品、專案的全生命週期。
• 持續交付：包含程式碼庫的管理、持續整合、部署、交付流水線等能力，意在打通從程式碼提交到部署上線的全流程。持續整合支援編譯、打包、測試、工具四類構建任務，支援程式碼提交時觸發構建、定時構建、手動構建三種構建觸發策略。在部署方面，支援 springboot 應用、傳統 war 包、html 站點、mysql 等部署，支援灰度釋出、滾動升級、藍綠髮布等多種部署策略。
• 持續改進：包含質量標準、質量監控、以及產品專案全生命週期過程中的各種度量報表。支撐企業的精益度量。

2017 年 6 月份會發布 5.0 版本。

二、如何建設企業級的 DevOps 平臺  

這裡為什麼要強調“企業級”呢？一個小團隊如果想要實現 DevOps 能力其實可以很簡單，因為團隊規模不大，比較容易管理，同時負責的應用也不會特別多，通過整合一些開源的工具完全可以做到持續整合、持續部署、持續交付，同樣可以帶來極大的效率提升，這其實也是一些網際網路企業內部小團隊的特色。但是當這一切放大到一個數百人，數千人甚至數萬人的企業時，就會發現遇到的問題、阻礙呈幾何級的上漲。一個企業要考慮的因素太多，歷史越悠久的企業，內部的文化、流程越是根深蒂固，而當一個平臺需要打通整個 IT 生命週期時，現有的文化、流程，現有的組織結構都不得不慎重推敲下是否能夠滿足。所以，如何建設適合自己企業的 DevOps 平臺，即使現有市場的 DevOps 理念已經基本普及開了，但是到落地的時候，卻總會發現困難重重。到底該怎麼去落地呢？

明確定位：DevOps 是覆蓋 IT 全生命週期的生產線

對於 DevOps 平臺的定位還是要再明確下，DevOps 代表的含義早已不僅僅是簡單的開發運維一體化，而是在此基礎上，打通產品、專案的軟體研發全生命週期，覆蓋持續交付、持續改進等能力，在縱向打通應用的全生命週期（需求、設計、開發、編譯、構建、測試、部署、運維等），橫向打通架構、開發、測試、質量、運維、運營等部門。

我們把 DevOps 分為三大領域，敏捷過程、持續交付、持續改進，三者相互獨立卻又相輔相成。通過 DevOps 平臺將企業軟體研發的全生命週期管理起來，在保證質量、安全的前提下，通過一些自動化的手段不斷提升軟體交付的效率，通過不斷精益度量對過程、對技術持續改進，最終支撐起企業的 IT 精益運營。

理清思維：DevOps 思維和網際網路思維的區別

可能很多人對於 DevOps 的理念還存在這樣的誤解：DevOps 來源於網際網路，也只適合網際網路企業。但 DevOps 思維和網際網路思維還是有著一定的區別的，不能簡單的認為只有網際網路公司才適合 DevOps。恰恰相反，其實 DevOps 理念的提出以及最初的發展並非是網際網路公司而是傳統企業。網際網路公司強調的是快速、使用者口碑，效能，並且對於上線的大部分應用具有一定的容錯性，嚴重的錯誤可以快速的修改和再上線。而 DevOps 追求的是質量、效率、精益、價值、穩定，企業尤其是金融類的企業對於線上應用的問題容忍度其實很很低的，很難想象如果一個交易業務出現問題後，會給企業帶來多大的損失。

所以，DevOps 絕不只是網際網路企業可以實行，對於傳統企業而言，更加適合。通過建設 DevOps 平臺來大幅提升軟體研發效率，提升對市場的響應速度，支撐企業的數字化轉型，也許對於傳統企業而言，DevOps 平臺帶來的價值才是更大的。

認清價值：DevOps 給你帶來怎樣的業務價值

清楚了 DevOps 平臺的定位，也明白了 DevOps 平臺對於任何企業都是可以實現的，那麼還是迴歸到自身上，需要結合企業自身的現狀思考下：到底 DevOps 能給自己的企業帶來什麼樣的業務價值呢？DevOps 平臺的理念固然是將軟體研發的全生命週期管理起來，但是並不意味著一定要做到全生命週期的管理，落實到企業內部，終究還是要結合企業的現狀和實際的需求，有選擇性有目標的去建設。比如某企業由於組織的問題無法打通整個生命週期，那麼通過持續整合、自動化測試、自動化部署等能力，提升軟體交付的效率也是極好的。

對於企業而言，不管是提升 IT 的運營效率 70%，還是做到開發測試環境的持續整合、自動化測試、自動化部署，亦或是一天部署 10 次這種 DevOps最初的目標，最重要的還是要結合現狀，先認清 DevOps 能給企業帶來什麼樣的業務價值。

 建設步驟：DevOps 平臺建設步驟

Step 1 梳理企業的流程和規範：

梳理企業的流程和規範是企業建設 DevOps 的前提，甚至即使不建設 DevOps 平臺，這也是一個必不可少的行為。只有統一了企業的流程和規範，才能建設出一個適用於企業的 DevOps 平臺，否則到最後，有可能會讓 DevOps 平臺脫離實際，導致沒有人會去使用。那麼有哪些流程和規範是要提前梳理和統一呢？這裡列舉幾個如下：

• 產品（應用）管理規範：包括版本管理、需求管理的規範等
• 專案管理規範：包括團隊的角色構成、過程工作流模板（Agile,CMMI,Scrum）、計劃 / 任務管理規範等
• 開發和編譯規範：包括程式碼開發規範（分支主幹的使用）、程式碼提交規範、構建規範（觸發策略，是否需要程式碼提交時構建等）、介質管理規範等
• 部署相關的流程和規範：比如部署架構的規範，環境的管理規範、軟硬體資產管理規範等…

Step 2 總結自身的痛點和需求，規劃建設路線圖（MVP）

完整的 DevOps 平臺是個很龐大的體系，如果全都靠自己建設的話，很顯然不可能短時間建設完成，那麼就要結合自身的痛點，從痛點入手，認清自己最迫切的需求，規劃出 DevOps 平臺的建設路線圖。基於 MVP（ ）的理念，一步步有序的推 Minimum Viable Product進整個平臺建設。假如自己的企業目前主要的瓶頸在於如何提升研發效率，那麼就可以從統一開發平臺、打通持續整合作為切入點。如果目前的主要問題是軟體交付速度太慢，那麼可以優先考慮持續整合、自動化部署、自動化測試、交付流水線的建設。

Step 3 從組織、技術、流程、文化四個維度持續優化與改進

DevOps 的實施和企業的組織、技術、流程、文化緊密結合，根據我們的經驗，在企業中，技術方面的實踐最容易在團隊中實踐，流程次之，組織的優化與變革則是最為困難的。很多時候，不是技術上打不通整個生命週期，而是一些客觀的因素導致無法打通各個部門。

我們建議，在實踐的過程中，由易入難，持續優化和改進。

細節至上：DevOps 平臺建設關鍵點

在建設 DevOps 平臺中，有一些關鍵點是不得不注意的，簡單列舉幾點：

• 如何支援異構環境、異構應用自動化部署？企業的應用型別多樣，純前端應用（通過 nginx 等執行），傳統 war 包（通過 tomcat 等應用伺服器執行），springboot 應用（fatjar 包直接執行）、android 應用、IOS 應用等等，執行環境複雜的要同時支援物理機、虛擬機器、容器雲。如何做到異構環境、異構應用的部署支撐，並且考慮到後續的可擴充套件性，對於平臺架構的設計是有一定要求的，這個會在後面的部署架構的章節中詳細介紹。
• 如何打通工具鏈的整合？其實大部分企業，現狀都是在軟體研發生命週期各個環節，已經有了一批的工具，只是這些沒有串聯起來，如果是小工具隨便用用還好，但是如果是一些用的比較根深蒂固的，可能就不是那麼好替換了，方案會更加傾向於整合。整合除了技術因素外，還必須要想清楚哪些工具去整合，哪些不整合。整合到什麼程度，比如針對於底層的 IaaS 平臺或者容器雲平臺，我們就只是進行介面呼叫，而並非功能的接管。對於 Jenkins 這種敏感資源，更傾向於把整個 Jenkins 封裝起來，不對外進行暴露。
• 如何與現有的企業流程緊密結合？不同企業有著不同的流程和規範，以持續交付流水線為例，可以是構建、SIT 部署、SIT 測試、提測、UAT 部署、UAT 測試、LAB 部署、LAB 測試、預發演練、生產部署等環節構成的一個大流程，也有會拆分成集測流程（開發過程中不斷執行）、釋出流程（從提測開始，UAT 和 LAB 可以是並行的）兩個流程，當然也有可能流程和這完全不一樣。這也就對 DevOps 平臺的建設提出了要求，如何和現有的實際流程緊密結合。

  除此之外，還有一些問題也是要考慮進去的，如何快速支援流程使用過程中的一些微調（如環節的配置欄位屬性等）？如何做到流程手工和自動執行的自定義？如何讓 buildNumber 貫穿整個流程，讓後續環境部署的介質對應的是哪個 buildNumber 有跡可循？如何直觀的檢視交付？當做到這些的時候，才能讓整個交付 流程目前到了哪個環節、每個環節的狀態是什麼樣的？如何以環境為視角，看到該環境下正在執行哪些應用流水線真正的實現價值。關於這一部分我們的設計同樣在後面的持續交付流水線架構章節中進行詳細介紹。

• 如何支撐企業 IT 精益運營？精益運營的基礎是度量，度量的三大維度：指標、執行監控 、預測。首先是明確指標和執行監控，基於軟體全生命週期的度量過程中企 執行監控業遇到的最大困難莫過於拿不到完整的資料，各個部門、各個流程、各個系統之間資料相互隔閡，資訊很難流通，導致無法從整體的角度對軟體過程進行度量。當 DevOps 平臺能打通企業的軟體生產全生命週期時，資料的割裂性問題自然也就不存在。當然，度量不僅僅是事後的統計分析，更應該提供過程監控的能力，在過程中，通過一些看板（比如任務看板、需求看板、釋出看板）、趨勢圖（比如任務燃盡圖、bug 燃盡圖）等，提前預知風險，規避風險，持續把控專案質量和產品質量。

  我們目前主要從質量、效率、進度三個維度，普通員工、團隊負責人、部門領導等角色視角出發，提供如下能力：

三、DevOps 平臺架構剖析

1.總體架構解析

先看看 DevOps 的整體架構，正如最一開始所說，我們把 DevOps 平臺劃分為三大模組：敏捷過程、持續交付、持續改進。平臺的概念模型如圖所示，劃分為 5 大領域：產品域、組織機構與許可權域，專案域、部署域、持續整合域。

平臺的邏輯架構如下：

DevOps 平臺劃分為領域層、基礎服務層、工具層三層。領域層和概念模型的 5 大領域基本一一對應，包括專案管理、產品管理、交付中心、組織機構等。服務層則是封裝的一些基礎能力，如編譯、部署、程式碼管理等。底層執行環境支撐傳統主機、PaaS 平臺、容器雲平臺。同時平臺機制支援靈活的的擴充套件（如工具整合擴充套件、部署能力擴充套件等），面對複雜的場景或者特殊的需求時，平臺也可以提供更加靈活地能力。

2. 敏捷過程

敏捷過程的架構核心在於工作項（WorkItem）的設計，工作項涵蓋了需求（長篇故事、特性、使用者故事）、開發（任務、缺陷）、測試（測試用例、測試計劃）等。可以說，在整個專案週期中，將所有的工作項統一管理起來，工作流和工作項關聯，不同的過程對應不同的工作項，比如 Agile 對應的需求相關工作項是 Feature/Story。Scrum 過程體系對應的需求工作項則是 Epic/Feature/UserStory。

通過對工作項的設計，可能支撐多種工作流的差異化，便於設計和擴充套件，同時，可以從統一的視角檢視所有的工作項，更加便於統一管理、統計分析。其實 jira、tfs 也是類似的設計思路，只不過 jira 把一切看成是“issue”，tfs 則是把一切看成“工作項”。

以需求為例說明，需求分 Epic/Feature/UserStory 三層，每一層都是一種工作項，工作項有哪些屬性，屬性對應的值型別，控制元件型別都會在資料中定義，頁面上表單頁面通過資料庫中定義的屬性和控制元件資料動態生成表單。使用者可以自定義專案中需求屬性和狀態。

3.持續整合

持續整合模組功能主要有程式碼庫管理、構建定義管理以及構建例項管理等。在構建定義管理模組中，DevOps 平臺將構建任務分成了四種類型：

• 編譯類任務：Maven、Ant、Gradle、純前端構建等
• 測試類任務：Sonarqube、Jmeter、Selenium 等
• 打包類任務：Npm、Archive、Docker 等
• 其他工具類任務：Copyfile、Shell、介質提交到 Nexus 倉庫、介質上傳二方庫等。

在每個構建定義上可以選擇若干個需要的構建任務，通過原子步驟編排，組裝成一個完整構建流程。程式碼提交時觸發構建（支援 gitlab、github、svn 等常用程式碼庫版本管理工具）、日構建等不同的構建觸發策略等支撐了持續整合的完整鏈路打通。

在持續整合的領域，絕大多數企業應該都會選擇 Jenkins 吧，我們也不例外。持續整合模組的核心框架就是 Jenkins。每個構建任務對應 Jenkins 的一個 pipeline stage。在執行時，將所有構建任務結合構建定義的一些基礎資訊，建立 Jenkins 的 pipeline 進行執行。

Jenkins 的搭建採用 master/slave 叢集模式，面對大量應用的編譯壓力時可以更好的分散壓力，保證編譯速度。如果想更靈活的話，可以考慮 Jenkins 叢集部署在容器中，通過容器雲的動態伸縮能力，可以更靈活的去使用資源。這裡要提到一個關於異構環境的編譯，如 ios 應用的編譯，就必須在 mac os 系統中進行。這就要求編譯機和其他的機器有所區別。我們是採用 Jenkins 的節點標籤能力，如果是要進行 ios 編譯任務的話，就會通過標籤到 ios 的工作節點中執行任務。

4. 自動化部署

在自動化部署模組中，為了更好的與實際結合，我們將部署分為三個階段：設計、轉換、運維。

設計階段：將部署架構分為三層：部署裝配（Assembly）、部署容器（Platform）、部署元件 (Component)。部署裝配是對部署架構的描述，由多個部署容器組成，每個部署容器由若干個部署元件組成。

操作流程：

1. 建立 Assembly
   • 通過選擇可用的系統模版 (Platform Template)，新增一個新的 Platform。
   • 每一個 Platform 都對應一種應用（如 mysql，tomcat，springboot，nginx）。
   • 每一個 Platform 都是有一組元件（Component）組成的，並且已定義好了元件之間的依賴關係。
2. 管理 ComponentComponent 是最底層的部署（或者配置）單元，如 springboot 中的 secgroup, compute, os, jdk, fatjar, lb 都是一個元件每一個 Component 都有相應的配置模版。
3. 提交設計提交的過程是將已經完成的設計做一次 Commit，做一次歸檔。

轉換階段：轉換（Transition），是在 Assembly 內對應用 / 系統在某一具體部署環境內的部署過程。部署環境是配置、架構設計、執行資源、部署策略的結合。

操作流程：

1. 建立部署環境（Deploy Environment）根據環境型別 (如 dev, test, prod 等)，新增屬於某個 Assembly 的部署環境。部署之前，部署環境是應用 / 系統用於部署的配置的抽象。

   部署之後，部署環境就是管理和監控應用 / 系統的具體例項的集合。

2. 配置部署環境設定每個 Platform 關聯的資源（vm/container）、部署模式（單點，高可用）
3. 選擇 Assembly 內的一個或多個 Platform 生成並提交執行計劃根據部署策略不同，一個 Platform 的執行計劃可能包含幾個子計劃
4. 執行部署每個 Assembly/Environment/Platform 下面的每個 Component 都有一個部署例項，這些例項可以進行單獨操作

運維階段：對於已部署的例項進行運維管理，包括啟動、停止、重啟、修復、狀態檢查等等

考慮到驅動的統一性以及 Jenkins2 外掛的豐富性，DevOps 自動化部署框架底層同樣使用了 Jenkins。採用 DevOps 平臺（設計）＋Jenkins（執行）的方式完成。

DevOps 的職責：

• 完成部署架構設計；
• 根據部署架構設計和部署環境的配置建立生成相應的執行計劃及子執行計劃，每一個子計劃對應一個 Jenkins pipelinejob 配置檔案 (config.xml)；
• 查詢 Jenkins 執行 job 的實時進度與結果。

Jenkins 的職責：

• 根據 config.xml 建立 Jenkins Pipeline Job；
• 執行 pipeline job；
• Jenkins job 通過 pipeline script 中 ansible／openshift 命令進行相應的部署等執行操作；
• 提供查詢 job 執行情況的 Rest API。

DevOps 平臺中的部署架構設計和 Jenkins pipeline 的對映關係如下圖所示：

可以看到每個元件都會對應 Jenkins 的一個 stage。所有的 stage 組裝成一個完整的 pipeline 在通過 Jenkins 執行。

為什麼選擇 Jenkins pipeline? 主要是結合以下幾點進行考慮的

• durable 永續性：在 Jenkins 的 master 按計劃和非計劃的重啟後，pipeline 的 job 仍然能夠工作，不受影響。
• 可暫停性：pipeline 基於 groovy 可以實現 job 的暫停和等待使用者的輸入或批准然後繼續執行。
• 更靈活的並行執行，更強的依賴控制，通過 groovy 指令碼可以實現 step，stage 間的並行執行，和更復雜的相互依賴關係。
• 可擴充套件性：通過 groovy 的程式設計更容易的擴充套件外掛。
• 豐富外掛：Jenkins 已經支援通過 groovy 命令呼叫 git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes 等外掛，不需要我們再單獨實現整合。
• Rest API：Jenkins 提供通過 Rest API 的方式獲取每一個 stage 的執行情況。

5. 持續交付流水線

有了持續整合、部署、測試的能力是否就足夠了呢？其實還是不夠，DevOps 的本質是 IT 生產線，交付流水線是持續交付的核心能力，它可以把分散的能力如構建、部署、測試等串聯在一起，形成一個從程式碼提交到釋出上線的流水線，通過流水線可以很直觀的看到當前某個具體構建版本已經到了哪一個環節，從整體上對於軟體交付進行更好的把控。

在設計流水線能力時，我們主要考慮到幾點：

• 結合企業的不同交付流程，要能支援自定義的流程配置，要能支援多套流程配置
• 流程的每一個環節都要支援自動執行的配置
• 流程中每個環節的屬性和配置資訊可以自定義，靈活擴充套件
• 流程以構建開始，讓 buildNumber 貫穿整個流程，方便追根溯源
• 要有一個看板，直觀的看到整個產品的版本目前到了流程的哪個環節，是 SIT 還是 UAT，結果如何
• 要有一個看板，直觀的看到每個環境下，有哪些介質在執行

以這些為基礎準則，我們底層基於了普元的 BPS 流程引擎，支撐流程的自定義和擴充套件。並且，針對於每個環節，都可以配置前置後置事件、人工執行還是自動執行，責任人等。整個流水線從構建開始，以程式碼的 buildNumber 貫穿全流程。便於問題、進度的追溯。看板的設計如下：

QA環節

Q1 ：實施DevOps過程中，持續整合上線有沒有引入A/B測試？DevOps 如何開展主流程壓力測試的？

A1：  A/B測試現階段我們還沒有引進，壓力測試我們是通過整合JMeter實現的，部署到LAB環境，呼叫JMeter實現壓力測試。

Q2： 2009年就實現了CI CD和自動化測試，那DevOps和他們比起來最大的優勢是？

A2：  最早之前都是自己內部的，主要做到了日編譯。應用型別比較少，沒有考慮移動應用、純前端應用、中介軟體的部署。測試倒是涵蓋了IDE測試以及WEB的自動化測試。並且沒有真正的把持續整合、自動化部署、自動化測試徹底打通，很多資料都沒有收集起來。DevOps的真正價值，除了更全面的交付能力，提升軟體交付速度外，很大一方面在於打通了軟體生產的全生命週期。從而對整個軟體過程進行度量和管理，提升軟體交付的質量。

Q3：我們公司現在的業務需求完全hold住，IT不是主要部門，我在思考是不是不需要DevOps?畢竟DevOps改造的過程成本很大吧？

A3：  是否要實施確實要結合企業實際情況的，如果業務或者應用不多，就幾個應用，並且短時間看不到擴大的話，實施DevOps確實意義不大，反之則可以考慮下。並且實施DevOps並非要一口氣就打通整個生命週期，可以有選擇的一步步建設。比如可以先從持續交付開始實施，至少提升IT的交付效率也是一件很好的事情。以後有機會可以再考慮擴大到整個生命週期。

Q4：請問怎麼通知到下一環節呢？通過什麼樣的方式

A4： 我們採用了我們自己的BPS流程引擎，在流程中進行環節的流轉的。通知的方式可以結合企業不同的需求，比如整合郵件、內部通訊工具、OA系統等。

Q5：那傳統的運維人員不轉型DevOps是不是要失業了？

A5：呵呵，其實現在隨著IaaS/CaaS/DevOps等理念的盛行和落地，並不是說傳統運維人員要面臨淘汰，而是傳統運維的工作新挑戰。壓力更大，比如基礎環境的維護，比如部署指令碼的管理。運維依舊是很關鍵的一環。

Q6：普元公司都涉及到哪些業務啊？

A6：普元為金融、通訊、企業和政府使用者提供軟體平臺產品和解決方案，產品包括 SOA、雲端計算、大資料 三方面，幫助使用者實現數字化轉型。

Q7：請問Jenkins是自動一鍵構建到開發、測試各個不通的環境嗎？如果不是如何保證程式碼唯一性？

A7： 是的，正如文章裡分享的一樣，在整個釋出流水線中，構建是第一步，後面到各個環境的部署，除了生產環境的部署外，其他都是用的同一份介質。生產部署前會將介質提交到release庫中。

Q8：想請問王老師，devops和微服務之間是一個什麼樣的關係，或者說是如何結合在一起的，我們公司的業務大都使用PHP做主要開發語言，近期打算往服務化這方面去轉變，但現在網上能找到的大多數微服務相關的資料都是基於Java，想請問王老師對於PHP有沒有好的微服務框架或者書籍資料的推薦，謝謝！

A8：微服務其實和容器雲結合的很好，但是二者結合，傳統的單個應用，拆分成了N個微服務，跑在N個容器中，很難管理和運維。DevOps平臺和微服務、容器雲平臺的關係，我認為是DevOps提供了一個平臺，將微服務和容器雲從很散、很裸的狀態有效的管理起來，即使應用拆分的很散，依舊可以很方便的進行運維管理。對於PHP我確實也不是特別瞭解，不好意思~

Q9：DevOps一定是指完全打通嗎？那就是開發運維職責有交疊了？

A9：DevOps的完整場景是打通軟體生產的全生命週期，但是由於企業的現實情況，往往確實很難打通。可以考慮先有選擇的部分建設DevOps，等到有機會了再整體打通。開發和運維的職責還是會切分開的，只是他們共同在平臺上協作。包括測試和QA等角色。比如運維需要去管理和開通機器。如果是虛擬機器和容器雲的話，運維則只需要提供好相關的介面和保證資源充足，開發測試環境完全可以讓開發和測試人員直接在平臺去部署。平臺會呼叫底層介面建立虛擬機器和容器。

作者介紹

王海龍，普元資訊雲端計算架構師，畢業於華東師範大學，曾參與和負責銀聯 Paas 雲平臺專案、興業銀行 CAP4J 專案、交通銀行信用卡中心統一監控平臺專案、神華災備雲平臺、萬達 DevOps 平臺等專案。

文章來自微信公眾號：高效開發運維