**前言：**在產研全鏈路流程上，協同最大的目標就是團隊資訊的透明化，即在清晰目標的指引下進行團隊資訊透明的日常研發工作，助力專案/產品成功釋出。基於此，研發過程是否行之有效就成為我們關注的另一重點要素。通常「研發過程」是指：程式碼到製品再到部署上線的全鏈路，這個過程是持續整合的重中之重。

----

本期主要圍繞「研發過程」展開探討，在具體分享實踐之前，筆者想先和大家暢想討論下，在軟體研發全流程中，我們需要怎樣的**產品**和**特性**來支撐我們持續去追求高效研發（本期主要圍繞成本、效能，質量這塊後續單獨再做分析）的目標，個人思考了幾點內容（部分內容會在正文的實踐分享中詳細說明），在此拋個磚讓歡迎大家一起探討。

**思考一** **支援團隊把實踐和文化透過自定義配置方式沉澱。**

![](http://img.blog.itpub.net/blog/2022/07/25/c494c753c3dfe67e.png?x-oss-process=style/bb)

所有團隊成員在使用產品功能的過程中，會潛移默化按照團隊希望的實踐路線進行。一方面，團隊的研發是按既定路線進行的，研發效能是可預期的；另一方面，團隊新人也能快速融入到團隊開發模式中，快速融入團隊文化。

**思考二** **在軟體研發全鏈路中，應該具備高度自動化的能力。**

研發全鏈路工作流中的各節點，透過高度自動化的能力，能實現以下目標：

- 除程式碼開發和專案管理事項資訊錄入外，儘量減少登入平臺的手動操作；
- 自動精準訊息的推送，藉助端的能力，讓使用者本地非同步訂閱檢視研發和專案管理資訊。

**思考三** **強大且豐富的端能力。**

讓研發成員能夠在本地沉浸式開發，目標要做到不感知 DevOps 平臺存在的情況下，無時無刻不在使用平臺能力。

**思考四** **產品能力和形態應該能夠高度自定義化。**

想透過一種產品形態去支撐覆蓋所有的行業是不現實的，一個 DevOps 平臺研發團隊，不可能深入瞭解熟悉各行各業的研發模式，更不可能去定義實踐去引領所有行業的研發提效。平臺能做和需要做的是：把平臺底層基礎能力做強、做靈活，讓不同業領導者，在高效持續交付的理論引導下，利用平臺豐富的基礎能力和高度自定義配置能力，去構建屬於自己行業的研發實踐模式，最終透過行業研發實踐模式沉澱模版的可複製化，助力該行業整體研發效能的提升。

**思考五** **平臺需要深度結合低程式碼開發平臺，讓應用研發變得更簡單。**

**思考六** **藉助 AI 的能力，輔助提升使用者程式碼開發、質量、安全、問題定位等應用研發過程效能。**

**思考七** **結合大資料、AI、函式計算等技術特性，讓研發效能度量、運維監控等觀測能力變得更強大。**

- 透過公有云或者企業級大資料、AI 和底層雲端計算能力的對接，讓研發效能度量、監控資料統計的成本變得更低；
- 透過函式計算以低成本的方式滿足使用者對研發效能和監控資料的靈活統計訴求；
- 透過低程式碼開發平臺 + DevOps 平臺底層 Tracing、Logs、Metrics + 函式計算 + 資料視覺化，讓使用者能夠快速構建行業最佳實踐的監控運維繫統，透過模版可以複製到其他行業使用者。
-

言歸正傳，接下來我將主要從「研發全鏈路」出發，分享一下 Erda 團隊具體的實踐過程，希望能給大家帶來新的思考。

# 基於主幹的開發模式

在研發模式方面，Erda 團隊採用的是基於主幹開發模式（Trunk Based Development），相對於主幹開發模式還有特性分支開發模式（Feature Branch Development），其典型的代表就是 gitflow 模式。兩者都是軟體屆常用的軟體分支模式，各自有著各自的優缺點，選擇適合自己的才是最重要的。Erda 團隊選擇基於主幹開發模式的初衷，是想以持續整合的方式儘快釋出版本，以及希望透過主幹開發模式促成團隊成為精英績效團隊。

![](http://img.blog.itpub.net/blog/2022/07/25/9b9b91047112fc49.png?x-oss-process=style/bb)

**Erda 團隊基於主幹開發的目標：**

- 每日有新程式碼合入主幹，每日完成持續整合、持續測試
- 隨時隨刻能夠提供可釋出的版本，特性可以按需緊急釋出上線
- 產品特性快速實現驗證，減少試錯成本

為了讓團隊透過主幹開發模式來實現上述的目標，有**兩個實踐要點**非常重要：

1. 專案協同的高要求：任務拆分（參考迭代事項協同中的任務顆粒度建議，儘量拆分到 1-2 天）需要足夠小驅動 mr 變小，從而能從專案管理上支援產品特性快速實現驗證和試錯；
2. 研發質量的高要求：特性開發的快，不能是犧牲質量的快，所以在這個快的前提下，對於合入的特性程式碼要求就會變的更高，這裡的關鍵就是開發需要確保程式碼質量，不要想著把質量交給測試團隊來保障 (建設自動化流程對規則、標準、規範進行自動檢查；單元測試；資料庫規範等等）。

實踐要點分析後，接下來一起看看具體的實踐步驟以及需要怎樣的 DevOps 平臺工具來支撐。
 
## 基於主幹分支的程式碼研發

透過專案協同把需求進行任務拆分，研發同學認領任務後即進入開發工作，開發的首要工作就是建立一個**特性分支**（Feature/ 任務 ID）用於該特性的程式碼託管。OK，對於團隊新成員來說可能開工第一步問題就來了 ?

### Feature 的源分支是誰？

團隊採用的是主幹分支的開發模式，自然就是從主幹分支（Master）來拉取了，對於熟悉團隊開發模式的同學來說，根本就不是問題，新同學只要透過培訓或者自己去 google 學習一下也就明白了。

團隊的實踐和文化固然可以透過管理規範來進行約束來實現，不過古人也雲“堵不如疏”，是否能夠把這些實踐規範約束在產品中定義？透過產品功能互動，引導使用者按團隊的預定的實踐路線進行。Erda 團隊就是這樣實踐的，效果還不錯！

### 程式碼開發到提測的整體流程

![](http://img.blog.itpub.net/blog/2022/07/25/f0abfa6f50449437.png?x-oss-process=style/bb)

### 基於主幹分支開發的規範配置

Erda 團隊的研發規範是在產品的研發工作流中進行定義配置，內容涉及分支清單、分支策略和工作流配置，具體示意圖如下：

![](http://img.blog.itpub.net/blog/2022/07/25/ccebc8fecc9fadc6.png?x-oss-process=style/bb)
Erda 產品-研發工作流配置示意圖
具體以產品實際互動為主

工作流具體配置內容：

![](http://img.blog.itpub.net/blog/2022/07/25/5f0a7b9864c28eb0.png?x-oss-process=style/bb)

分支策略具體配置內容：

### 具體過程

1. 研發同學在任務詳情中，選擇應用一鍵選擇建立工作流。工作流建立後就會自動建立對應的開發分支（如feature/XXXX，其中 XXXX 代表特性 ID）；
2. 相同應用相同環境不同特性進行系統臨時合併部署自測。透過 Erda 平臺提供開發環境下相同應用不同特性分支的系統臨時合併的功能，讓所有特性研發同學可以一起部署和冒煙測試，在不影響效率的情況下大幅減少環境資源的壓力；
3. 透過研發自測後，工作流中可以一鍵發起 MR 合併請求，研發 TL 對合並請求相關分支 Code Review 後（因為任務工作流中事項和分支的關係繫結，Code Review 的時候可以清晰知道本次合併請求的具體任務內容），特性分支自動合入主幹分支，主幹分支透過定時/程式碼變更的觸發器進行整合部署+測試，至此研發同學的特性任務狀態也會自動完成。（上述特性正在開發中，目前以手動發起 MR 請求為主）。

## 基於主幹分支的每日整合部署

透過 Erda 平臺來支撐專案級每日持續整合部署。透過專案流水線，構建各應用最新制品（基於各應用主幹最新程式碼）並整合為專案整體制品進行自動化的部署到統一的主幹測試環境（Erda 叫整合環境）。

部署的策略為每日 23 時，定時觸發流水線執行構建、整合、部署 (其他專案也可以根據實際情況設定其他的部署策略)。

## 基於主幹分支的每日持續測試

### 自動化測試

- **用例管理**

根據需求的 deadline ，測試同學會基於研發同學的特性完成時間，去安排自動化測試用例（主要是是基於 API 介面的測試）和功能測試用例的作成。在研發同學特性分支合併到主幹分支後，測試同學會在原有的測試計劃上追加新特性的自動化測試用例，已有的自動化測試用例迴歸確保之前特性的可用性。

![](http://img.blog.itpub.net/blog/2022/07/25/b53cf7683e4adb9f.png?x-oss-process=style/bb)

- **自動化測試執行**

那麼每日持續測試如何觸發？
即透過部署測試流水線中的 action，觸發自動化測試計劃的執行。

- **自動化測試結果通知**

自動化測試結果透過釘釘同步給研發團隊。

![](http://img.blog.itpub.net/blog/2022/07/25/81a371a21dc5b20f.png?x-oss-process=style/bb)

### 手動功能測試

自動化測試並不能百分之百覆蓋所有的產品特性，而對於自動化無法覆蓋的特性，就需要手動完成。功能性測試是需要實打實投入測試同學人力去一遍遍手動覆蓋的，且不說必要性，人力成本可能就是敏捷團隊所不能容忍的。對於這樣的場景，Erda 團隊在手動功能性測試方面主要採用以下策略：

- 針對迭代新功能需要手動功能測試覆蓋，主要是測試團隊對當前迭代的需求內容進行針對性的測試；
- 測試團隊基於需求、任務的狀態來判斷每日新增的大概內容 (erda 測試團隊甚至被要求關注開發提交的 MR/PR，對測試團隊的要求是更高的）。

## 基於主幹分支的製品管理策略

通常意義上的「軟體製品」主要是原始碼檔案的集合或者編譯後的產物，主要包括**二進位制包**和**壓縮包**兩種形式。如果基於 Erda 平臺，製品的概念上稍微有點難以區別，我們主要定義為包含部署一個應用所需的全部內容，包括映象、依賴的 Addon 以及各類配置資訊，最終的目的就是透過製品能夠在任何一套 Erda 上進行環境級別的部署。

這裡暫時不去分析和討論製品的定義和具體的功能點（如對產品製品管理功能有興趣的同學可以聯絡我們繼續討論），還是迴歸到主題，以分享 Erda 團隊對於製品管理的實踐為主。

### 語義化版本管理

首先在製品版本和型別的管理上，團隊主要採用的是「語義化版本」管理規範，主要涉及以下幾種版本型別：

- alpha：僅僅是研發自測透過，未經過測試的版本，不穩定的版本
- beta：階段性測試透過，相對穩定的版本
- stable：經過系統性測試，穩定的釋出版本

### 版本和分支的關係

其次，製品版本和分支上做了強實踐的繫結（主要透過研發工作流配置完成）。不管制品如何定義，肯定是基於程式碼或者編譯產物的基礎，也就是說製品肯定是從程式碼來的。所以 Erda 團隊在實踐中是把分支和製品型別進行繫結關聯的，並且把這個以最佳實踐沉澱到 Erda 產品中，當然產品支援研發工作流的自定義配置來滿足其他特性分支和製品版本型別的關聯。

Erda 團隊的研發模式是基於主幹研發的模式，所以分支和版本型別的關係如下：

![](http://img.blog.itpub.net/blog/2022/07/25/420113df816f510e.png?x-oss-process=style/bb)

如果採用 Gitflow 可以參考如下：

![](http://img.blog.itpub.net/blog/2022/07/25/6357773e18d0abdf.png?x-oss-process=style/bb)

### 版本和分支的配置

分支和製品版本的配置：在研發工作流中配置

主要過程說明：

- 研發同學在 feature 分支上開發完成後，並在開發環境上完成自測，程式碼合入到主幹分支（Master）；
- 主幹分支（Master）透過每日定時觸發器執行流水線，會自動構建生成【版本號 + alpha +時間戳】的製品；
- 迭代版本所有的特性程式碼都合入到主幹分支（Master），並且透過自動化測試用例及測試同學手動功能階段性測試後，測試同學會從主幹分支（Master）上切出迭代版本的 Release 分支（分支名：Release/版本號-beta+遞增數字），時間頻率取決於團隊的釋出頻率（Erda 團隊的釋出頻率是每週，所以這邊的時間頻率就是每週）；
- 當迭代版本進行到一定週期後，產品一般會對外釋出一個正式的版本（這個版本可以是上面一個迭代版本，也可以由多個迭代版本組成，這個取決於產品的版本釋出計劃，Erda 產品的一個大的 Rc 版本由 4 個迭代 beta 版本的特性組成），測試同學會從主幹分支（Master）切出Release 分支（分支名：Release/版本號）進行全面測試；
- 測試同學透過 Release/版本號分支流水線構建部署該分支的 beta 製品，在透過測試驗證後，測試同學會手動把該 beta 版本製品切換為 stable 版本，並且在製品中維護好製品的 ChangeLog 和製品標籤，最終釋出到 Gallery 提供的交付團隊下載使用。

![](http://img.blog.itpub.net/blog/2022/07/25/603dcfdd9ec19748.png?x-oss-process=style/bb)

# 釋出火車

## 概念和規則

釋出火車，通常是指設定固定的釋出視窗，具體可以按周或者按月固定一個時間，在這個時間進行定時釋出，產品特效能夠趕上這趟火車就釋出，否則就需要等下趟火車。

釋出火車的規則看似非常簡單，只要固定時間釋出即可，其實不然，團隊並不能透過一個釋出火車的概念就能讓釋出變得高效，真正能驅動團隊高效釋出的還需從建立團隊的釋出文化開始，文化又依託於釋出規則的沉澱：

- 定時定點發車。火車不等特性，拒絕未經測試的新特性上車；
- 只發布高質量的特性。只有測試透過的特性才允許上車，即使研發已經完成相關特性並且要求上線的時候，也要堅決拒絕；
- 頻繁釋出火車，特性拆分的足夠小。更快更小的釋出能夠讓產品的質量更高、成本更低，頻繁釋出使每次釋出的特性變小，出現問題的時候定位和解決也會變得更明確和高效，當然釋出的頻率需要根據團隊的研發和管理整體質量決定，不是一味地追求快；
- 世界沒有完美的釋出，需要有明確的關鍵效能指標來決策爭議特性的釋出。
 
## Erda 團隊實踐

基於以上的規則，Erda 團隊的實踐如下：

![](http://img.blog.itpub.net/blog/2022/07/25/b554438018316916.png?x-oss-process=style/bb)

# 小結

不管從專案協同、研發全流程以及到最後的釋出火車，其本質目標還是希望能夠以高效的方式去支撐應用軟體持續快速、高質量的更新發布，為了這個目標，每家公司都有自己的實踐和見解，沒有對和錯之說，只要符合企業當下利益最大化，能夠佈局企業的未來即可。本文只是以 Erda 一個團隊視角進行了分享，歡迎大家可以一起參與分享討論研發提效的實踐，共同促進整個行業效能的提升，謝謝！

----

更多技術乾貨請關注【爾達 Erda】公眾號，與眾多開源愛好者共同成長～

8 年產品經驗，我總結了這些持續高效研發實踐經驗 · 研發篇

相關文章