技术部软件版本管理规范

1、技术部软件版本规范文档建立 / 修改记录 ：序号版本号建立 /修改编写人、时间审核人、时间审批人、时间1V1.0建立李洋洋、 2016年李洋洋、 2016年01月2901月29版本管理规范【新建项目版本管理部分】1，项目组接到项目需求，1.1，开发组出项目设计和开发计划；1.2，测试在 Git 中建立空项目 (项目名称开会时候会有， 没有需要问 )，形成 master 版本，版本设定为。2，组长发邮件给技术总监，并且抄送给项目经理和测试。邮件内容：开发计划文档url 和开发版本号，请批准第一阶段(开发计划中会包含)开发。3，得到批准开发回复后，测试从 建立分支版本，打开版本参与人员的更新权限，

2、并且将url 给组长。4，组长 download 项目， 上传项目可运行框架，并且更新GIT 中的 readme 文档并通知开发；5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到 GIT 中，并且push 前必须测试，保证代码不能有运行异常，导致无法测试5.1， Push 结束后，开发者继续开发下一个功能点。5.2， push 结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，测试人员需先关闭版本参与人员的更新权限，再按功能点来测试bug，然后更新bug 文档和测试用例文档的内容(有无 bug 都需要更新 )，随即打开更新权限并通知组长。6，开发者下一个功能点提交时

3、，同上要求。7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版本建分支版本并且给出版本url 给组长，继续进行测试最后一个功能点bug。8，组长通知组员进行bug（ bug 一般会比较少，bug 很多只能说明开发者开发质量有问题）修改，给出修改版本地址。9，修改完毕后提交，测试人员再次关权限且测试，如仍然有相关修改支版本(这里是中再次建立修改版本(此时是bug 存在，更新相应文档并在，随即给出版本url 给组长。 ps：提交版本如有冲突找组长调节。10，第一阶段开发完全完成后开始开发第二阶段任务，重复 29 步骤，相应的版本号会变为从开始，同里修改版本号则是11，

4、当全部阶段任务完成(指的是开发完成并测试无bug)，测试将最新的修改完成的版本(应该是，x 为任意数字 )合并到 master 版本中，此时版本号设定为。测试发邮件给技术总监，抄送给项目经理、开发组长和运维人员，请批准线上发布，得到肯定回复后，运维开始执行发布。邮件内容：项目软件上线文档url（存在石墨系统中），请批准线上发布。【master 版本修改版本管理部分】12，承接上文，发布到线上的软件不排除有时会出现bug，此时如必须要解决这些bug，则重复上文的步骤 1步骤 11，不同的地方在以下几点：12.1，和上文 1.2 不同，测试人员任务不是在此处新建空项目，而是将master 版本开分

5、支(V1.0.1),然后给出 url 给组长；12.2，此次修改的所有版本号则变为V1.0.x 形式；12.3，修改完成后（指的是bug 俱已修复完成），测试再次封测，将分支权限关闭并且整合到 V1.0.0 版本的 master 中，继续按步骤上线等操作。修复完成。12.4，上线之后，又发现了bug，仍然需要修复，则再次重复12.112.3 步骤，不过版本号变为V1.0.2/V1.0.3 形式。【项目整改版本管理部分】13，日后，此项目需要整改 (比如：增减模块、改变功能等)时，基本按照上面的112 步骤执行，不同的地方在以下几点：13.1，和上文 1.2 不同，测试人员任务不是在此处新建空项

6、目，而是将master 版本开分支，指定版本号为 V2.0.0(master 版本整改超过50%)或者 V1.1.0(master版本整改小功能等 ),然后给出 url 给组长；13.2，此次再开发任务的所有版本号则变为V2.x.x 或者 V1.1.x 形式；13.3，开发完成后（指的是再开发完成并测试无bug），测试封测，将分支权限关闭并且整合到现有的master 版本中，继续按步骤上线等操作。再开发完成。版本管理规范流程图版本管理规范流程图2016 年1 月29 日项目新建流程2016/1/29组长接到项目开发组：1，项目设计2，开发计划开发计划完成后组长：测试者：建立空项目，形成mast

7、er版本等待邮件通知发邮件，获批第一阶段开发组长：1， download项目，上传项目框架，更新 GIT 中 readme文档2 ，通知开发者开发开发者：1，按时按功能点提交代码到 GIT 中，需保证可测试2，继续开发下一个功能点测试者：测试时关闭 GIT 中版本参与开发人员更新权限，测试完成打开权限并更新相关文档和通知组长组长：1，通知开发者修复 bug并给出修改版本 url测试者：发邮件给技术总监，抄送给项目经理、开发组长和运维人员，请批准线上发布，得到肯定回复后，运维开始执行发布。等待邮件通知阶段任务完成Bug再修复Bug全部修改完毕获得批准测试者：1，从 master建分支版本2，打开分支参与开发人员的更新权限3，将分支 url 给组长测试者：1，关闭当前版本更新权限，从版本建立分支并将此版本 url给组长2，继续测试本阶段最后一个功能点测试者：1，关闭更新权限并测试，更新相关文档2，如仍有 Bug(Bug再修复流程 )，则继续在上一个版本上建立分支版本并将此版本 url 给组长3，如无 Bug测出