技术部软件版本管理规范.docxVIP

技术部软件版本规范 文档建立 / 修改记录 ： 序号 版本号 建立 /修改 编写人、时间 审核人、时间 审批人、时间 1 V1.0 建立 李洋洋、 2021 年 01 月 29 李洋洋、 2021 年 01 月 29 |精. |品. |可. |编. |辑. |学. |习. |资. |料. * | * | * | * | |欢. |迎. |下. |载.  版本治理规范 【新建项目版本治理部分】 1，项目组接到项目需求， ，开发组出项目设计和开发方案； ，测试在 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 前必需测试，保证代码不能有运行反常，导致无法测试 ， Push 终止后，开发者连续开发下一个功能点； ， 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；测试发邮件给 技术总监，抄送给项目经理、开发组长和运维人员，请批准线上发布，得到确定回复后，运维开头执行发布； 邮件内容：项目软件上线文档 url（存在石墨系统中），请批准线上发布； |精. |品. |可. |编. |辑. |学. |习. |资. |料. * | * | * | * | |欢. |迎. |下. |载. 【master 版本修改版本治理部分】 12，承接上文，发布到线上的软件不排除有时会显现 bug，此时如必需要解决这些 bug，就重复上文的步骤 1~步骤 11，不同的地方在以下几点： ，和上文 1.2 不同，测试人员任务不是在此处新建空项目，而是将 master 版本开分支(V1.0.1), 然后给出 url 给组长； ，此次修改的全部版本号就变为 V1.0.x 形式； ，修改完成后（指的是 bug 俱已修复完成），测试再次封测，将分支权限关闭并且整合到 V1.0.0 版本的 master 中，连续按步骤上线等操作；修复完成； ，上线之后，又发觉了 bug，仍旧需要修复，就再次重复 12.1~12.3 步骤，不过版本号变为 V1.0.2/V1.0.3~~ 形式； 【项目整改版本治理部分】 13，日后，此项目需要整改 (比如：增减模块、转变功能等 )时，基本根据上面的 1~12 步骤执行，不同的地方在以下几点： ，和上文 1.2 不同，测试人员任务不是在此处新建空项目，而是将 master 版本开分支，指定版本号为 V2.0.0(master 版本整改超过 50%)或者 V1.1.0(master 版本整改小功能等 ), 然后给出 url 给组长； ，此次再开发任务的全部版本号就变为 V2.x.x 或者 V1.1.x 形式； ，开发完成后（指的是再开发完成并测试无 bug），测试封测，将分支权限关