git开发流程 公司项目开发流程

1、分支介绍:

永久分支:
master:主分支。用于存放经过测试,完全稳定的代码。
dev:开发分支。一开始从master分离而来,用于存放基本稳定的代码。
testing:测试分支。从dev分离而来,用于生成测试产品和修改bug。
临时分支:

feature:特性分支。 从dev分支分离而来,用于开发项目功能。
hotfixes:紧急分支。当产品已经发布,发现紧急bug,创建hotfixes分支进行紧急修复,完成后合并到master和dev。
release:预发布分支。每次发布有一个分支。从testing分离而来,用于生成预发布产品和回归测试。

2、工作流程:

每个spring 和 项目创建不同的feature分支。
开发人员基于feature分支进行开发。
开发人员完成功能开发及单元测试后,提交pull request请求。
技术组长审核pull request并进行code review。 
技术组长进行拒绝或者合并到dev分支。
jenkins自动更新dev代码,自动进行sonar检测,自动构建,将成功或者是失败信息通过邮件反馈给开发人员和技术组长。
技术组长将dev合并到testing分支。
jenkins自动更新testing代码,自动构建并部署到测试环境,将成功或者是失败信息通过邮件反馈给开发人员和技术组长。
jenkins自动进行单元测试,集成测试,系统测试,生成测试报告。
测试人员在测试环境进行手动测试。发现bug及时反馈给开发人员。
开发人员在dev分支及时进行修复。
开发人员修复完成后,提交pull request请求合并到dev。
技术组长审核pull request并进行code review。 
技术组长进行拒绝或者合并到dev分支。
技术组长将dev合并到testing分支。
测试人员测试通过后,技术组长合并testing到新的release分支。

3. pull request格式要求
pull request的格式要求如下:
标题:【jira任务号】feature或bugfix分支名称
同一个任务、bug的所有pull request标题要一致。
说明:本次提交的一则说明,包括,但不限于:
本次合并涉及哪些端的pr
本次合并和是否有依赖于别的合并
本次合并是否涉及脚本审核
本次合并的功能说明

jenkins自动更新release代码,自动构建并部署到预发布环境,将成功或者是失败信息通过邮件反馈给开发人员和技术组长
jenkins自动进行单元测试,集成测试,系统测试,生成测试报告。
测试人员在预发布环境进行回归测试。
测试完成后,技术组长合并release分支到dev分支以及master 分支并在master 分支打上Tag标签。

运维负责人部署升级数据库
1.运维负责人拉生产环境新建实例执行SQL脚本,验证实例环境网络连接及访问正常、确认有效升级数据库,将成功或者是失败信息通过微信群QQ群等实时反馈给开发人员和技术组长。
2.技术组长和开发人员验证SQL脚本无误,以及新额数据库脚本可以兼容旧的程序代码无误,将成功或修正信息反馈运维负责人。
3.运维负责人执行升级生产环境数据库SQL脚本,验证生产环境网络连接及访问正常、确认有效升级数据库,将成功或者是失败信息通过微信群QQ群等实时反馈给开发人员和技术组长。

运维负责人拉取release分支,打包,并部署到生产环境,验证生产环境网络连接及访问正常、确认有效升级程序,将成功或者是失败信息通过微信群QQ群等实时反馈给开发人员和技术组长
测试人员在发布环境进行冒烟测试。
产品负责人在生产环境进行验证。
测试完成后,运维负责人发布版本发布信息。
技术组长合并release分支到dev分支以及master 分支并在master 分支打上Tag标签。

Git工作流指南:Gitflow工作流:http://blog.jobbole.com/76867/
Git工作流指南:Pull Request工作流:http://blog.jobbole.com/76854/

猜你喜欢

转载自blog.csdn.net/nikita1995/article/details/81084863