開發流程與版本管理規範

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

## 版本號規則

如非特殊說明，全部產品的版本號將遵循 主版本.次版本.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天內，開發者確認並設置修復時間