持续集成和交付规范v2.0（敏捷）

以下规范适合敏捷开发
持续集成和交付规范v2.0
一、持续集成和交付

持续集成：开发过程中，开发成员需经常集成他们的工作，即代码的更改需定期合并到代码库，并进行测试。

持续交付：在持续集成的基础上，将集成后的代码部署到更贴近真实运行的环境中。

持续集成和交付的工作流程：编码->构建->集成->测试->交付。

新功能工作流程的具体步骤如下：

1、开发人员拉取线上代码(master分支)，基于master在本地创建功能分支feature/sp编写代码，定时提交到功能开发分支（feature/sp分支），开发完成后对代码进行单元测试；

（sp代表一个sprint，sp12代表第12个sprint）

2、单元测试完成且准备提测前，开发人员将代码与release分支合并，release基于master创建的；

3、运维人员将（release分支）代码部署到测试环境，由测试人员进行集成测试；如果需要更改代码，需从第一步重新开始流程；

4、测试完成后，开发人员将代码合并至master分支，并打相关tag，运维人员根据tag把代码部署到线上环境。

（tag的规则: v1.2.1,主版本.springt版本.hotfix次数）

线上BUG修复流程具体步骤如下：

1、开发人员拉取线上代码(master分支)，基于master在本地创建BUG修复分支（hotfix/sp*-次数） 编写代码，开发完成后进行自测；

2、运维人员将（hotfix分支）代码部署到测试环境，由测试人员进行集成测试；

4、测试完成后，将开发人员把代码合并至master分支，并打相关tag，运维人员根据tag把代码部署到线上环境。

二、代码分支、版本管理

1、分支管理

1.1 master 主分支

对应线上（正式环境）的代码，版本上线由测试人员确认，通知开发人员将对应上线版本合并至master分支并打tag，由运维更新至线上环境。

1.2 feature/sp* 功能分支

从 master 拉取，用于新需求（版本）开发。

命名规则：feature/sprint版本号

1.3 hotfix/* 热修复分支

从 master 拉取，用于快速修复线上Bug，修复后需合并回master。

命名规则：hotfix/sp*-次数

1.4 release/* 测试分支

从 master拉取，合并需要测试的feature分支代码，用于新功能测试，确保当前版本是基于线上最新版本迭代，可处理与线上代码存在的冲突。

命名规则：release/sprint版本号

2、TAG管理

Tag命名规则：v+主版本号+sprint版本号+hotfix修复次数。主版本号为一位，只有当系统在结构和功能上有重大变化时改变；sprint版本号根据排期走。

如v1.12.1 表示第一个主版本，spring第12个排期，hotfix修复次数为1