开发流程与版本管理规范

# 开发流程与版本管理规范

## 版本号规则

如非特殊说明，全部产品的版本号将遵循 主版本.次版本.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天内，开发者确认并设置修复时间