开发流程与版本管理规范

Posted 2020-12-25 lianruihong

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

## 版本号规则

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