版本管理规范及开发流程

utSmart版本管理规范及开发流程（初稿-2）

版本管理是非常重要的，但很多公司或者程序员根本对这个版本管理毫无概念。在团队中使用的版本管理发布流程。

一、版本号管理

1：版本号命名规范

软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

2：版本号修改规则

1. 主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
2. 子版本号(1)：相对于主版本号而言，子版本号升级对应的是软件功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
3. 阶段版本号(1)：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
4. 日期版本号(051021)：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
5. 希腊字母版本号(beta)：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

3：软件版本阶段说明

1. **Base：**此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
2. **α（Alpha）版：内测版：**软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者 内部交流，或者专业测试人员测试用，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。
3. **β（Beta）版：公测版。**该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI，供专业爱好者大规模测试用。
4. **RC 版：**是 Release Candidate 的缩写，意思是发布倒计时，候选版本，该版本已经相当成熟了，完成全部功能并清除大部分的BUG，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
5. **Release 版：**该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。

4：版本号修改举例说明

比如版本号为：1.0.0.0321_alpha ，此时为内部测试阶段

1. 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为：1.0.0.0321_beta ，如当前日期跟上一个版本号的日期不一样，版本号可改为：1.0.0.0322_beta。
2. 如果修复了一些重大Bug 并按照流程发布到外网时就可发布一个修订版，如1.0.1.0322_beta，日期为发布的当前日期。
3. 如果对软件进行了一些功能上的改进或增强，进行了一些局部变动的时候要修改次版本号，如：1.1.0.0322_beta（上一级有变动时，下级要归零）。
4. 当功能模块有较大变动，增加模块或整体架构发生变化时要修改主版本号，如新增加了退款功能，则版本号要改为：2.0.0.0322_beta 。
5. 紧急情况：如果bug比较紧急可跳过一般流程，由开发人员尽快修复bug，测试确认之后直接发布该版本的beta版。

二、代码库版本管理流程

公司的代码库使用 git 管理版本。

下面描述公司的 git 的 使用规范。

主要分支

代码库中包含两个主要的分钟

1. master
2. develop

origin/master 的最新版本应与生产环境当前版本一致， master 分支上的所有历史版本与线上生产环境的历史版本一一对应。

origin/develop 分支是开发集成的版本。

当 develop 分支的当前版本达到稳定状态，意味着可以向生产环境发布了。

这时 develop 分支需要通过某种方式合并到 master 分支并且打上发布版本号 tag。 后面我们将详细说明这个过程。因此每当有修改合并到 master 分支， 意味着我们产生了一个新的版本号。这个规则必须严格遵守，matser 分支发生改变时将触发持续集成工具和脚本自动打包， 推送到生产环境。

支持分支

除了 master 和 develop 两个主要分支, 我们还使用多种支持分支来协作日常开发。与主要分支不同，这些分支可能生命周期比较短，一个支持分支合并到主要分支后将被移除。支持分支主要分三种：

1. 功能特性的分支
2. 发布分支
3. 紧急修复分支

每种分支都有不同的作用并且遵循不同的 fork 、合并和命名规则。从 git 角度看，各种分支并不存在特殊性， 只是我们依据我们的开发流程需要产生的一种使用规范。

3个流程如下图

1：功能特性分支

起源分支： 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

2：发布分支

起源分支： 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

3：紧急修复分支

起源分支： 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天内，开发者确认并设置修复时间