# 開發流程與版本管理規範

## 版本號規則

如非特殊說明，所有產品的版本號將遵循 主版本.次版本.BuildNumber 的規則。 
- 主版本號：發布重大更新時增加
- 次版本號：發布新功能點時增加
- build number:  打包的編號， 日常更新，bug 修復， 功能優化

例如 2.1.34， 2 是 主版本號， 1為次版本號， 34 是 build number.   主版本號變化時次版本號清零，但是 build number 不清零，一直累加。2.1.34 的下個版本號是 3.0.35 、 2.2.35 或者 2.1.35 之一。

## 代碼庫版本管理

公司的代碼庫使用 git 管理版本。 不熟悉 git 同事請先閱讀 git 的 相關文檔: https://gitee.com/progit/

下面描述公司的 git 的 使用規範。

![123123](/Users/luoxin/Desktop/123123.png)

### 主要分支

代碼庫中包含兩個主要的分鐘

1. master
2. develop

origin/master 的最新版本應與生產環境當前版本一致， master 分支上的所有歷史版本與線上生產環境的歷史版本一一對應。

origin/develop 分支是開發集成的版本。

當 develop 分支的當前版本達到穩定狀態，意味著可以向生產環境發布了。這時 develop 分支需要通過某種方式合並到 master 分支並且打上發布版本號 tag。 後面我們將詳細說明這個過程。因此**每當有修改合並到 master 分支， 意味著我們產生了一個新的版本號。這個規則必須嚴格遵守，matser 分支發生改變時將觸發持續集成工具和腳本自動打包， 推送到生產環境。**

### 支持分支

除了  master 和 develop 兩個主要分支,  我們還使用多種支持分支來協作日常開發。與主要分支不同，這些分支可能生命周期比較短，一個支持分支合並到主要分支後將被移除。支持分支主要分三種：
1. 功能特性的分支
2. 發布分支
3. 緊急修復分支

每種分支都有不同的作用並且遵循不同的 fork 、合並和命名規則。從 git 角度看，各種分支並不存在特殊性， 只是我們依據我們的開發流程需要產生的一種使用規範。

#### 功能特性分支

**起源分支：**
develop

**合並對象分支:**
develop

**命名規則：**
除了 master, develop, release-\*,  or hotfix-\*  之外沒有特殊限制

功能特性分支用來開發新功能，可能這個功能是下一個版本將要分布的，也可能會在更後期的版本中發布的。當我們開始開發一個新功能時， 這個功能將在哪個版本中發布可能是未知的。這個功能特性開發完成後會合並到 develop 分支然後並刪除分支；或者如果開發到某個階段產品設計上認為這個功能可以被砍掉， 那這個分支將會被丟棄。



```
//開始開發 myFeature 功能時，我們在 develop 分支的基礎上創建一個 myFeature 的新分支
git checkout -b myFeature develop

// 提交代碼, 註意： 提交信息一定要寫清楚
git commit 

// 將分支推送到 git 服務器
git push --set-upstream origin myFeature
```


如上所述， 一個功能特性分支一般經過：創建=>提交=>推送 的過程。
**`註意:` commit 時一定要寫清楚修改了什麽， 測試同事才好針對性的測試，建議每做一個小修改就提交一次，這樣 commit message 才能準確描述所做的修改， 而不是等到整個功能都做完，推送之前再一次性提交。**

push 到服務器後，請到內部的 gitlab 上提交 merge request。收到 merge request 的同事需對代碼進行審查， 確定沒有明顯的 bug 後再合並到 develop 分支。這時這個功能特性分支的生命周期就結束了，可以刪除。


```
// 刪除分支
git branch -d myFeature
```


#### 發布分支
**起源分支：**
develop

**合並對象分支:**
develop 或  master

**命名規則：**
 release-\*

發布分支是為發布到生成環境做準備的。當所有需要發布的功能特性都已合並到develop 分支， 並且經過測試到達相對穩定的狀態後， 我們在 develop 分支的基礎上創建一個新的 release-* 分支。**這個 release-* 分支 不應該包含那些不在此次發布計劃中的功能，因此那些功能相對應的分支必須等 release-* 分支創建之後再合並到 develop.**

release 分支創建時將分配一個版本號（此處應有腳本來管理版本號）， 如 release-1.038,  並且生成版本日誌。 


```
git checkout -b release-1.2.56 develop
```


**`此分支在正式發布到正式環境之前，可能會有一些 bug 修復， 但是新功能的代碼不允許提交到此分支。`**

```
// 在 release 分支基礎上創建用於 bug 修改的分支, 分支的命名規則應該為 release-*_bug*
git checkout -b release-1.2.56_bug1 release-1.2.56

git commit
 
git push --set-upstream origin release-1.2.56_bug1 
```

bug fix 的分支推送到服務器，經審核後合並到 release-\* 分支。直到 bug 修復到了允許發布到生成環境的狀態時需要將此分支分別合並到 master 分支和 develop 分支.

 1. 將 release 分支合並到 master



 ```
 // 切換到 master 分支
 git checkout master
 
 // 將 release 分支合並到 master 分支
 git merge --no-ff release-1.2.56
 
 // master 分支打上 tag
 git tag -a 1.2.56
 ```


 2. 將 release 分支合並到 develop


 ```
  // 切換到 master 分支
 git checkout develop
 
 // 將 release 分支合並到 develop 分支
git merge --no-ff release-1.2.56
 ```

將 release 分支合並到 develop 分支後，  develop 分支也有了bug fix 的代碼。 這時  release-1.2.56 不再需要了，可以被刪除


```
git branch -d  release-1.2.56
```


#### 緊急修復分支

**起源分支：**
master

**合並對象分支:**
develop 和  master

**命名規則：**
 hotfix-\*

 緊急修復分支跟 release 分支類似，都是為發布版本準備的。當線上生成環境有重大的 bug 需要緊急修復，而此時 develop 分支還不穩定，無法發布，我們在 master 分支基礎上創建一個 hotfix 分支， 修復 bug 後合並到 master ，再發布到生成環境。


```
// 命名規則建議為 hotfix-*, * 為當前的 master 的 tag 版本號
git checkout -b hotfix-1.2.35 master

git commit -m "Fixed severe production problem"

git push
```


hotfix 分支提交後，經代碼審核合並到 master 分支,  打上 tag 就可以推送到生成環境了



```
// 切換到 master 分支
git checkout master

// 合並
git merge --no-ff hotfix-1.2.35

// 更新 tag 版本號，準備推送到生成環境
git tag -a hotfix-1.2.36
```


除了合並到 master 分支， 還需要合並到 develop 分支， 這樣 develop 也包含了針對 bug 的修改。` 如果此時存在 release 版本， 應該合並到 release 分支，而不是 develop 分支，這樣下一次發布會包含對 bug  的修改。 release 分支最終也會被合並到 develop 分支。 `


```
git checkout develop
git merge --no-ff hotfix-1.2.35
```


bug 修復了 hotfix 分支就可以刪除了


```
git branch -d hotfix-1.2.35
```


## 如何保障代碼質量

開發過程中我們采用自動化的單元測試與人工代碼審查相結合的方式來保障代碼質量
>目前這兩項工作剛開始實施，需要一段時間磨合團隊。

### 單元測試

編寫單元測試代碼， 利用 Git pre-push hook 在推送前自動運行單元測試。未通過單元測試將會中斷推送。某些情況下可能因為開發人員的 git hooks 配置錯誤，造成代碼未通過單元測試，也被推送到了服務器。 代碼提送到服務器後， 持續集成工具自動拉取最新的代碼，再次運行單元測試，測試失敗的代碼會被標註出來。

### 代碼審查

往代碼庫的 develop,  release,  master 分支合並分支前，必須對修改進行審查。

## 測試發布流程

產品發布分為兩種：
1. Bug 修復或優化
2. 功能特性發布

Bug 修復或者優化發布頻率會很高，1~2 天一次。
測試每次驗證已修復的bug，產品確認修改完成，測試提起發版本請求，記錄修復的bug，存在的問題（不影響本次發布），並確認存在問題的修改意見。請求通過先發布到預生產環境，在預生產環境中再次測試，確認沒有影響版本發布的問題，產品發布到生產環境。如果存在影響發布的問題，立即終止本次發布，修改存在的問題，再次測試，提起發布流程。
這種版本的主版本號和次版本號不會發生變化，只有 build number 會增大。 

功能特性的發布事先制定計劃，有相應的裏程碑管理。測試根據相應的時間點進行功能測試和系統測試，確認沒有影響發布的bug，記錄存在的問題（不影響發布），並確認存在問題的修改意見。測試此時提起發布版本的請求。請求通過先發布到預生產環境，再次進行完整的測試。確認沒有影響版本發布的問題，產品發布到生產環境。如果存在影響發布的問題，立即終止本次發布，修改存在的問題，再次測試，提起發布流程.

### Bug 管理

Bug 按嚴重程度分三個等級

1. 關鍵， 關鍵類 bug 影響線上主體業務流程， 必須當天修復。
2. 重要， 重要類的 bug 必須在提出 bug 當天有開發者確認，並設置修復時間。
3. 一般， 提出bug 2天內，開發者確認並設置修復時間

開發流程與版本管理規範