普元DevOps5.2版本新特性發布

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

做者自白：

伴隨新版本的發佈，咱們團隊也對此次迭代作了些回顧，有值得分享的新特性與設計，也有一些需增強的能力，藉此與你們分享。

主題大綱：

1、新特性部分

一、安全提高，更細粒度的流程與權限控制
二、企業級中間件支持，更匹配普元現有客戶需求
三、全新看板，更精益的度量並指導優化
四、UI大升級，提供To C的互聯網體驗
五、監控加強，圍繞應用視角的運行監測
六、流水線與工單結合，向一體化工做臺演進

2、待提高部分

一、自動化測試體系的完善
二、預警能力的建設
三、流水線任務的持續豐富

新特性

DevOps產品，從定位上來看，仍舊保持初衷不變，要創建一條從業務需求到最終線上運營的IT生產線。



以前的版本其實已經造成了從項目管理->組件設計->代碼管理->持續集成->自動部署->度量優化的能力，因此在5.2版本需求範圍定義時，更多的是從流水線豐富、實施模板、API擴展、安全可靠幾個方面着手的，在此分享如下6個特性：

特性一：安全提高，更細粒度的流程與權限控制

DevOps平臺相對特殊的定位（跨部門、跨環境、長週期）使得平臺在安全上須要更加去關注，這個版本從如下三個方面進行了增強。



一、圍繞功能碼的菜單、操做（API）、環境的三類受權

第一個方面：仍舊是從RBAC着手，考慮到DevOps至少是有兩層權限的：



而且在第二層權限中，會隨着項目類型的不一樣，擁有的菜單集、功能集範圍也不相同。因此須要在兩級都提供面向菜單、功能碼、環境的細粒度權限配置能力，才能保證知足各種客戶要求。

 

2. 充分考慮安全隔離、單向通訊的部署架構

第二個方面則是部署架構的安全，參考下圖：



好比通常企業，開發測試區和生產區都是徹底隔離的，介質共享傳遞更可能是拷貝或者堡壘機完成，在DevOps平臺上，要注意的就是如何能在最小開放的狀況下，完成上述不一樣環境的完整流水線。

通常來說咱們在客戶那邊是經過部署多套任務引擎來解決這類問題的，devops門戶只與各環境中的任務引擎打交道（至關於拿任務引擎做爲agent入口），而不去和各個環境中的其餘任何機器交互。

但到了有些客戶那邊，多部署引擎是容許的，可是必須只是單向通訊。考慮到devops通常都會集成很多中間件或開源工具，好比爲了實時看到部署的執行狀態，須要經過回調接口造成與任務引擎的雙向通訊，這個就會受到限制，因此又須要其餘的部署架構或技術方案來解決，這裏就不一一贅述。

3. 其餘安全示意

第三個方面，更多的是一些瑣碎的安全控制（由於安全這個領域，原本就是瑣碎的，要持續修補的，最明顯的就是殺毒軟件的病毒庫）。因此咱們平臺還作了以下的一些事情，像密碼強度、定時備份、審計日誌明細化等：

特性二：企業級中間件支持，更匹配普元現有客戶需求

第二個特性則是後續的每一個版本都會作的，針對不一樣中間件的集成能力，任務化封裝。

畢竟咱們主要關注的仍是企業市場，企業市場裏不可能徹底拋棄傳統的應用服務器、數據庫等。



因此在這個版本里，增長了像ear、數據腳本等CI的能力，同時也補充了weblogic、websphere、oracle存儲過程，以及普元自有產品上的發佈回退等能力。

不只僅CICD，產品裏還作了傳統中間件自己的安裝部署運維等能力。



特性三：全新看板，更精益的度量並指導優化

第三個特性是重構了原有項目Issue看板的能力，以前咱們更多的是純粹的集成，好比集成jira、禪道都徹底是API導向，在DevOps產品裏並無一套本身的清晰模型，這就使得每次使用標準的變動，都須要對產品進行深度代碼定製，很是不友好。

在這個版本里，咱們新抽象了模型，抽象的要點包括：

如何保證看板適應不一樣客戶、項目的要求？



將不一樣的幾種項目Issue模型進行抽象，包括看板泳道、issue流轉flow、issue的一些狀態數據集等。



因此上面這張圖不管是泳道、仍是具體的story、bug、task的流轉與關聯，均可以經過模板來進行客戶化配置。

看板這塊還解決了需求與後續代碼、介質的信息斷層問題 ：



如今能夠經過需求追溯代碼提交歷史，自動統計一個需求所花的代碼行等，並與後續的工件造成關聯，爲度量提供更多原始數據。

特性四：UI大升級，提供To C的互聯網體驗

第四個特性則是UI的升級，這裏要感謝兩位前端同事在短短一個多月，將整個技術棧從NUI（一套基於jquery的UI）完全升級爲基於Vue.js的全新門戶。

同時前端提供的很好的動態表單能力，使得之後擴展一個流水線上的任務（包括任務對應的表單、控件、驗證、級聯等），只要經過配置就可直接展現。





如今增長一個流水線上的任務，前端要作的就是提交圖片資源、部分表單控件之間的特殊事件聯動處理、再從新打包就足夠了。

特性五：監控加強，圍繞應用視角的運行監測

第五個特性則是發佈後的監控能力，藉助咱們的微服務、容器雲等其餘平臺，此版本能夠看到以下一些監控視圖：



這是針對應用產生日誌的滾屏展現與檢索。

這是對於應用運維的timeline圖，以及每次運維操做的具體執行信息。



還有像上圖這種，與咱們其餘平臺集成的系統調用拓撲、業務請求鏈路、進程資源信息、長sql語句等。

特性六：流水線與工單結合，向一體化工做臺演進

第六個特性則是一直猶豫要不要作的工單能力，由於在之前的項目實施中，不少企業客戶是要求與其ITIL進行集成。可是在最近的幾個實施項目裏，你們都但願把devops向真正的一體化工做臺演進，因此在這個版本中提供了獨立的流程任務與工單管理能力。



舉個例子，如上圖，經過設置流水線上某個環境的審批人（支持多人，好比通常生產環境都要有發佈評審與執行審批），最終在執行過程當中，會產生相關的工單並通知到干係人，由相關人進行線上審批，觸發流水線的繼續執行。

目前平臺提供的工單包括：項目立項單、代碼merge單、環境部署前審批單、環境部署後確認單、人工任務單（用於更細粒度的一些確認事宜）等，且此模塊可支持快速歸入新流程與工單類型。

待提高部分



自動化測試：雖然如今平臺作過了jmeter、以及咱們公司的自動化測試產品（UTP）的集成，可是在一些具體細節上打磨的不夠，須要好好考慮測試能力集成的正確模式。

預警能力：平臺如今的度量更可能是給出結果統計，並無創建完善的指標預警策略，這塊須要造成對應能力（固然，具體指標值是要通過長期運營才能定，咱們也只能給出咱們公司的參考值）。

流水線任務的持續豐富：每一個版本都要持續作的，流水線上任務的豐富，如今雖然各種構建、部署任務都不少了，可是一些細節還不夠，就好比應用數據備份、滾動升級過程的流量切換，這些都是要去補充的。

本文分享的相對簡單，沒有作技術實現的深刻，須要瞭解產品具體能力、功能實現細節的，可經過其餘渠道與咱們團隊創建長期溝通機制。


關於做者：顧偉，現任普元信息主任架構師，長期致力於IT技術研究、產品設計與開發、架構諮詢等工做，擅長Web、OSGI、CI/CD、服務治理、雲計算等領域技術；對DevOps、自動化運維、微服務架構有着濃厚的興趣。





關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享