----

**引言：伴隨著基礎設施技術升級，應用研發環境也從最初的傳統 IT 架構、虛擬化 & 容器化架構演變到現在的雲原生多雲架構。“應用研發新模式”本身就是一個比較大的話題，我們也不敢說一個人或者一個團隊就能把這個話題聊透徹。但隨著應用研發基礎架構環境的演進，應用研發模式一定是在不斷地調整和創新。**

----

今天我們大膽把話題丟擲來，聊聊自己的一些想法，和大家一起探討、共創雲原生時代應用研發模式後續的演進路線。

# DevOps 平臺現狀和痛點

![image.png](https://ucc.alicdn.com/pic/developer-ecology/a3c257d6510249d6b4a50b8564197112.png)
（應用研發架構演進路線）

本文暫將應用研發架構的演進路線歸納為四個階段（如上圖），傳統 IT 架構和虛擬架構下的應用研發，相信大家都比較熟悉，DevOps 的概念在這兩個階段幾乎沒有激起什麼水花，所以這兩個階段我們就不展開闡述了。

伴隨容器技術的出現（特別是 Docker 和 Kubernetes，後續簡稱 K8s），讓 DevOps 概念火了一把，也在實踐中開始快速落地和普及。容器能夠封裝微服務整個執行時環境的特性，天然就適用於微服務構建、釋出和執行，讓原本緩慢前進的 DevOps 得到飛速發展，開源社群也湧現了很多優秀的開源產品（比如 Jenkins、GitLab 等），大家透過這些開源產品能夠快速搭建自己應用的持續整合環境，因此市場上也如雨後春筍般冒出許多 DevOps 相關的產品。

現階段中的 DevOps 產品透過 Docker 和 K8s 確實幫助使用者解決了資源管理、微服務環境構建和持續整合的複雜、效率低等問題，但是伴隨公有云等 Infra 基礎設施持續高速發展，人們對於應用研發的效率追求也會有更高的要求，對於 DevOps 產品也不會滿足停留在當前階段（微服務應用的持續構建部署），那麼如何在 DevOps 現階段的版本基礎上進一步提高研發效率和質量呢？我們還是一起透過梳理當前研發過程中面臨的痛點出發吧！

![image.png](https://ucc.alicdn.com/pic/developer-ecology/5e92c5e8ead34cae9c955a741818b16f.png)

**痛點 1：多雲資源如何統一管理，解綁雲廠商？**

在公有云、私有云等多元化的雲環境下，大家手頭往往都有兩套或者多套雲資源，如何讓這些割裂的雲資源統一進行管理？如何基於一個平臺讓應用快速進行跨雲遷移、釋出？比如：開發在私有云，生產在公有云等這些問題伴隨資源環境多元化問題會越來越突出。

**痛點 2：複雜微服務組合如何快速進行環境構建、持續整合？**

當前 DevOps 對於單個微服務的環境構建和持續整合問題已經基本解決。但對於企業級軟體研發交付團隊來說，錯綜複雜的微服務組合而成的專案如何進行統一的環境構建、部署和交付，目前仍解決得不太徹底，只能讓各應用的研發成員都參與到構建、部署的整個階段。以上覆雜的過程容易引起問題不說，效率成本上也是個大問題。

**痛點 3：研發效能如何進一步提升？**

在當前主流的 DevOps 產品中，程式碼、構建、部署全流程自動化觸發執行的特性基本都是得到了比較好的解決，但是隨著研發管理的深度、精細度要求越來越高，需要研發同學維護的資料也隨之不斷增多，管理維護專案資料的專案管理工作量也在不斷增大，效率和成本這組矛盾如何得到妥善處理？

新一代 DevOps 不僅應有效解決上述痛點，還應具有測試安全的左移、研發效能度量等更多開放效能力，這個全新的時代需要有更全面、更創新的特性。

# 新一代 DevOps 的特性

## 多雲管理

多雲管理並不是簡單指透過 K8s 叢集來實現資源的排程管理，如果僅僅是統一資源排程那本身是 K8s 叢集的特性。

透過應用部署環境配置去關聯叢集，確實可以實現環境之間的隔離、環境之間快速遷移的能力，就如上面提到的：開發測試在本地私有云環境，生產可以透過同一套程式碼能夠快速釋出到公有云；還有就是業務在一個叢集，資料處理可以在另外一個叢集，實現業務和資料分離，兩者互不影響，這些都可以透過叢集管理來實現。

![image.png](https://ucc.alicdn.com/pic/developer-ecology/96d9266ed608438880e71fc01e9a3482.png)

既然說了這麼多都是和叢集相關的，那麼和多雲管理有什麼關係呢？

首先，我們對 K8s 叢集的節點管理，希望可以一個平臺上統一便捷購買/釋放主流公有云廠商的資源節點。

其次，現在公有云上都有容器相關的服務提供，平臺只需要排程管理這些容器服務即可，所有容器服務的對接管理（包含但不僅限於容器服務的購買、釋放、擴縮容等）都需要在平臺完成。

再者，公有云上其他的雲服務都可以透過平臺進行購買直接使用，無需使用者不斷切換登陸到各公有云的控制檯，最後進行雲資源的統計分析、資源成本的運營分析，幫助企業在資源方面進行降本增效。這些都是多雲管理的範疇之內。

Erda 目前在 K8s 叢集管理、公有云服務對接管理方面都是做得比較好的，大家可以體驗使用，對這部分內容感興趣的同學歡迎聯絡我們，一起溝通、碰撞想法。

## 專案級持續整合

目前，對於單應用的持續構建部署，DevOps 的業界產品基本都是達成共識的，對於單個微服務應用構建部署的自動化完善程度較好。

但是對於企業級專案研發過程，我們一起來回想看看，比如：單應用內不同任務需要拉多分支來進行開發（基於主幹開發的模式可能沒有這個問題），受開發環境資源的限制，不同任務開發同學要不斷進行線下溝通合併程式碼釋出開發環境（或者測試環境）進行測試，過程中可能存在誰的程式碼分支有問題導致整個環境不可用的現象，oh my god！

專案級的聯調部署就更復雜了，首先需要配置專案環境，其中包含了專案級的引數配置以及大家公用的專案級中介軟體準備部署；其次是複雜的微服務編排資訊維護，這些繁瑣的專案級維護管理動作，往往會導致專案部署過程中出現各種阻塞，比如專案共同的中介軟體準備阻塞，上游服務的部署和健康度也會影響或阻塞下游服務部署和測試等，這些問題會讓專案部署更加困難化。

![專案級持續整合-1.gif](https://ucc.alicdn.com/pic/developer-ecology/55b399a0f665423793985c53e688aac8.gif)

既然已經分析出問題的所在，那麼我們一起來看下 Erda 的解決之道。

Erda 堅持以應用為中心，在單應用的研發過程中，基於任務分支開發的模式下（這裡說明一下，Erda 產品本身的研發團隊是基於主幹開發來實現每日整合的），研發同學只要保證自己分支質量的基礎上，隨時可以釋出到開發環境進行測試和驗證。

那麼細心的同學肯定會發現如果開發環境只有一套，相同應用下有其他研發任務分支的同學該怎麼辦？這裡就先透露一下 Erda 接下來即將規劃的功能：大家只管發自己的分支部署，分支之間的臨時合併後部署的事情，就交給 Erda 平臺來完成吧?。

![專案級持續整合-2.gif](https://ucc.alicdn.com/pic/developer-ecology/8d0ccf128383486b976a659be75b3cc4.gif)

專案級構建部署的問題，Erda 透過**專案級流水線**、**製品**、**環境部署**（其實是環境準備和部署兩個環節）三個重要特性來解決的。

首先，在應用透過程式碼持續構建部署到開發/測試環境，實現了程式碼到服務的全流程自動化。

其次，專案共用的中介軟體進行了統一管理。這裡的中介軟體不僅覆蓋了平臺內建豐富的中介軟體服務，還提供了公有云上的儲存類中介軟體，甚至還支援透過自定義中介軟體的方式來管理對接使用者自己部署維護的中介軟體。這些中介軟體在 Dice.yml 中可以一鍵部署，實現真正專案級的中介軟體管理，徹底解決使用者依賴中介軟體的煩惱。

前面提到了程式碼到服務的全流程自動化，其實製品到服務也是這個全流程中的一個環節。應用研發同學在開發環境冒煙測試透過後，測試同學可以基於應用製品可以組合成專案製品，透過專案製品 + 環境配置，可以快速在測試環境上部署測試（基於主幹開發的話，這些步驟都是可以全自動化完成），測試同學透過自動化測試和手動測試確保專案質量達標後，就可以一鍵釋出專案製品，後期專案交付實施同學可以基於此製品到客戶環境上進行快速交付或升級應用。

![專案級持續整合-3.gif](https://ucc.alicdn.com/pic/developer-ecology/0495944a10db48cf99aba9fca8bee3ae.gif)

## 研發流程的自動化

上述的程式碼到服務、製品到服務的全流程當然是在研發全流程自動化中進行的。除此之外，在優雅解決研發效能度量資料採集的同時，還要讓我們的研發同學儘量少做一些維護工作，比如：需求任務拆解後，任務的狀態、備註是否能夠自動流轉，不需要刻意地登陸到平臺去進行維護就能完成。研發同學在進行沉浸式本地開發的同時，就能完成相關工作。

這個也是 Erda 當前重點在解決的事情，研發角色在統一平臺進行高效協同的認知角度可能也會適當調整一下。不同研發角色的協同資料在統一平臺，具體的協同可以由多元化的端能力來完成，讓使用者在不感知平臺的情況下，無時無刻不在使用平臺的能力，比如：透過 ChatOps，讓資訊及時觸達到使用者後，使用者可以在實時通訊 APP 中快速處理，處理後的資料會返回平臺進行統一計算分析，伴隨使用者在實時通訊 APP 的處理，相關 Issue 事項的備註、截止日期、狀態等屬性資訊也在同步進行自動化流轉處理。

[影片內容見文章內 Erda 產品全景圖](https://mp.weixin.qq.com/s?__biz=Mzg2MDYzNTAxMw==&mid=2247490910&idx=1&sn=e85331e5fd91a29fdedaa485204a892c&chksm=ce2237b4f955bea2f10c7c527f8d6362b6723cf59969b84ffc5dbf4f7842d801af40d069f0ad&token=1306388647&lang=zh_CN#rd)

研發流程自動化還可以體現在 Issue、程式碼、測試、環境例項之前的全方位自動化，透過 Issue 和程式碼分支的繫結，研發同學本地提交/合併程式碼後就會自動觸發相關 Issue 狀態流轉、程式碼自動化構建部署、自動化測試、專案製品合成、製品 Changelog 的自動生成等全鏈路的自動化。

![image.png](https://ucc.alicdn.com/pic/developer-ecology/93e7487f676f4b62afe3c3b4a2db45b0.png)

以上僅僅羅列了新一代 DevOps 的部分特性，對於其他特性，都應該圍繞效率、成本和質量這個鐵三角展開，去創造更多有意義、有價值的新特性。

本文只發表了一些個人對於 DevOps 演進的部分觀點，相信其他小夥伴肯定有更好的的想法，如果大家對於本話題感興趣，歡迎聯絡我們一起深入探討。我們將定期組織小夥伴圍繞相關話題進行持續討論推進，期待更多小夥伴的加入！

----

我們致力於決社群使用者在實際生產環境中反饋的問題和需求，如果您有任何疑問或建議，歡迎關注**【爾達Erda】公眾號**給我們留言，加入 Erda 使用者群參與交流或在 Github 上與我們討論！

[Erda Github 地址](https://github.com/erda-project/erda)
[Erda Cloud 官網](https://www.erda.cloud/)

深度好文｜探尋雲原生時代應用研發新模式

相關文章