技术部软件版本管理规范.pdf
版权申诉
100 浏览量
2023-04-20
23:05:44
上传
评论
收藏 285KB PDF 举报
技术部软件版本规范
文档建立/修改记录：
序号
1
版本号
V1.0
建立/修改
建立
编写人、时间
李洋洋、2016 年
01 月 29
审核人、时间
李洋洋、2016 年
01 月 29
审批人、时间
版本管理规范
【新建项目版本管理部分】
1，项目组接到项目需求，
1.1，开发组出项目设计和开发计划；
1.2，测试在 Git 中建立空项目(项目名称开会时候会有，没有需要问)，形成 master 版本，
版本设定为 V0.0.0。
2，组长发邮件给技术总监，并且抄送给项目经理和测试。
邮件内容：开发计划文档 url 和开发版本号(V0.1.0)，请批准第一阶段(开发计划中会包
含)开发。
3，得到批准开发回复后，测试从 master(V0.0.0)建立分支版本(V0.1.0)，打开版本参与人员的
更新权限，并且将 url 给组长。
4，组长 download 项目，上传项目可运行框架，并且更新 GIT 中的 readme 文档并通知开发；
5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到 GIT 中，并且 push 前必须
测试，保证代码不能有运行异常，导致无法测试
5.1，Push 结束后，开发者继续开发下一个功能点。
5.2，push 结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，
测试人员需先关闭版本参与人员的更新权限，再按功能点来测试 bug，然后更新 bug 文档和
测试用例文档的内容(有无 bug 都需要更新)，随即打开更新权限并通知组长。
6，开发者下一个功能点提交时，同上要求。
7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版
本(V0.1.0)建分支版本(V0.1.1)并且给出版本 url 给组长，继续进行测试最后一个功能点 bug。
8，组长通知组员进行 bug（bug 一般会比较少，bug 很多只能说明开发者开发质量有问题）
修改，给出修改版本地址。
9，修改完毕后提交，测试人员再次关权限且测试，如仍然有 bug 存在，更新相应文档并在
相关修改支版本(这里是 V0.1.1)中再次建立修改版本(此时是 V0.1.2)，随即给出版本 url 给组
长。ps：提交版本如有冲突找组长调节。
10，第一阶段开发完全完成后开始开发第二阶段任务，重复 2~9 步骤，相应的版本号会变为
从 V0.2.0 开始，同里修改版本号则是 V0.2.1/V0.2.2/V0.2.3......
11，当全部阶段任务完成(指的是开发完成并测试无 bug)，测试将最新的修改完成的版本(应
该是 V0.x.x，x 为任意数字)合并到 master 版本中，此时版本号设定为V1.0.0。测试发邮件给
资源评论
hhappy0123456789
- 粉丝: 58
- 资源: 5万+
