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

技术部软件版本规范 文档建立/修改记录： 序号 版本号 建立/修改 编写人、时间 审核人、时间 审批人、时间 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。测试发邮件给技术总监，抄送给项目经理、开发组长和运维人员，请批准线上发布，得到肯定回复后，运维开始执行发布。 邮件内容：项目软件上线文档url（存在石墨系统中），请批准线上发布。 【master版本修改版本管理部分】 12，承接上文，发布到线上的软件不排除有时会出现bug，此时如必须要解决这些bug，则重复上文的步骤1~步骤11，不同的地方在以下几点： 12.1，和上文1.2不同，测试人员任务不是在此处新建空项目，而是将master版本开分支 V1.0.1 ,然后给出url给组长； 12.2，此次修改的所有版本号则变为V1.0.x形式； 12.3，修改完成后（指的是bug俱已修复完成），测试再次封测，将分支权限关闭并且整合到V1.0.0版本的master中，继续按步骤上线等操作。修复完成。 12.4，上线之后，又发现了bug，仍然需要修复，则再次重复12.1~12.3步骤，不过版本号变为V1.0.2/V1.0.3~~形式。 【项目整改版本管理部分】 13，日后，此项目需要整改 比如：增减模块、改变功能等 时，基本按照上面的1~12步骤执行，不同的地方在以下几点： 13.1，和上文1.2不同，测试人员任务不是在此处新建空项目，而是将master版本开分支，指定版本号为V2.0.0 master版本整改超过50% 或者V1.1.0 master版本整改小功能等 ,然后给出url给组长； 13.2，此次再开发任务的所有版本号则变为V2.x.x或者V1.1.x形式； 13.3，开发完成后（指的是再开发完成并测试无bug），测试封测，将分支权限关闭并且整合到现有的master版本中 V1.x.x ，继续按步骤上线等操作。再开发完成。 版本管理规范流程图