开发流程与版本管理规范

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

## 版本号规则

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

  

原文地址:https://www.cnblogs.com/lianruihong/p/9367512.html

时间: 2024-10-11 04:40:07

开发流程与版本管理规范的相关文章

外包项目开发流程规范(ODC)

    忙碌时候时间过得很快,没时间记录下工作的一些东西,以下记录外包项目开发的一些流程规范: ODC软件系统开发流程: 例行版本:1.需求分析(用户.ODC) 1)找用户谈需求 2)确定系统上线时间.移交用户测试时间2.工作量的估算(ODC) 1)各个功能点需要的人天(初步估算,后续需求有改动,需要重新更新)3.工作计划安排(ODC) 1)开发计划-指定哪个功能由哪个开发人员进行开发,什么时候开发完成(移交系统测试) 2)测试计划-几时移交系统测试.几时移交用户测试4.系统开发及自测(ODC)

智能合约从入门到精通:Solidity语言的开发规范和开发流程

简介:上面介绍的在Solidity中嵌入的内联汇编语言也可以单独使用.实际上,它是被计划用来作为编译器的一种中间语言.本文我们将介绍开发智能合约过程中Solidity语言的开发规范和开发流程. Solidity作为编译器的一种中间语言.在开发智能合约时需要遵守相应的开发规范和开发流程. 开发规范 命名规范 目录和文件 目录使用小写,请勿使用特殊符号: 库文件和合约文件统一以.sol为后缀: 合约文件名保持与合约名一致: 文件名采用驼峰命名(首字母大写): 合约.库文件命名 合约名采用驼峰命名(首

搭建前端的开发环境和前端开发流程总结

一.搭建前端的开发环境 1.代码编辑工具:sublime/WebStorm/HBuilder. 2.断点调试工具:Firebug. 3.版本管理工具:Git(本人建议使用git,至于原因大家可以看看相关blog),安装完成后我们就可以从github上clone一些项目. 4.代码合并和混淆工具:webpack (Webpack具有Grunt.Gulp对于静态资源自动化构建的能力,同时兼容AMD与CMD的模块加载规范). 4.开发调试工具:NodeJs.很多非常有用的工具都是基于NodeJs的,我

智能家居项目(1):软件开发流程

结合公司开发过的产品以及对自学知识的总结,整理出此系列文章  .侧重点还是在软件部分. 公司开发某个项目,肯定是为了盈利赚钱.开发的项目无非就是自己的产品或者承接甲方的开发任务. 大体的流程可以分为几个部分或阶段: 1.需求说明书 预期想要一个什么功能,达到什么样的效果.有的客户也说不明白具体的东西,描述不清.需要加强沟通交流,确定最终的模型.一般情况下是甲方就提供好了的.关键部分大致如下: 监控功能 监控室内温度,监控红外传感器,以阻塞或异步的方式对红外传感器进行检测,如果红外传感器探测到有不

EAM系统开发流程

EAM系统开发流程主要包括三个阶段: EAM系统分析 主要是通过规范EAM系统内的信息,进一步把它们整合成一个完整的EAM原型.具体的工作是定义EAM系统中的词汇和建立一组用来生成具有可重用和可配置的概念模型的规范.这些对实施具体系统有指导作用,并且是其基础,类似施工手册.例如,对于资产可以定义为一个能跟踪.修复后可重复使用的.唯一具有独立名称的实体.  EAM系统设计 主要是开发一个高度灵活的通用架构,并且提供一个生产规范.软件构架为组件或对象的重组和配置提供了技术保证,为实现系统的灵活通用提

互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?

作者:暗灭 第一   为什么需要敏捷开发. 在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多.总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求. 怎么办?继续改.这一改又是半年多的时间过去了.马丹用户的需求还再改,怎么办? 这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大.文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多.

20个可以帮你简化iOS app开发流程的工具

这里推荐20个可以帮你简化iOS app开发流程的工具.很多开发者都使用过这些工具,涉及原型和设计.编程.测试以及最后的营销,基本上涵盖了整个开发过程. 原型和设计 有了一个很好的创意后,你要做的不是立刻编程,而是设计UI和创建原型,这样你才能知道app如何运行,根据用户体验需要做哪些调整. App Cooker AppCooker 不仅是一个创建原型的优秀工具,它提供的许多功能还可以帮助你将程序发布到App store中.它集成了Dropbox,Box.net和photo roll,你可以直接

《白帽子讲WEB安全》学习笔记之第17章 安全开发流程(SDL)

第17章 安全开发流程(SDL) 17.1 SDL简介 安全开发是从根源有效地解决安全漏洞问题,而已在软件的生命周期内,这样的开发模式成本更低. SDL过程: q  培训 所有的开发人员必须接收适当的安全培训,了解相关的安全知识. q  安全要求 明确项目的安全要求. q  质量门/bug栏 质量门和bug栏相当于确定安全和隐私质量的最低可接受级别. q  安全和隐私风险评估 评估项目中的安全现状和威胁模型 q  设计要求 在产品设计初期考虑安全问题 q  减小攻击面 减小攻击面通过减少攻击者利

微信小程序开发流程

2017年1月9日,张小龙在2017微信公开课Pro上发布的小程序正式上线,一夜之间,小程序可谓家喻户晓,但通过接下来的几个月的观察,微信小程序并没有想象中的那么火爆.进入4月以来,微信小程序团队进行了多次发文调整,并放开了个人公众号快速注册小程序能力.不管未来如何,微信小程序已经在发力了,作为一名码农,咱还是先了解下小程序的开发流程及规范,以备不时之需! 按照惯例,学习一门新技术或者新框架,咱们还是从官方提供的文档开始,于是找到微信小程序官方教程(https://mp.weixin.qq.co