版本提交测试发布上线流程管理办法Word文档格式.docx

版本提交测试发布上线流程管理办法Word文档格式.docx

《版本提交测试发布上线流程管理办法Word文档格式.docx》由会员分享，可在线阅读，更多相关《版本提交测试发布上线流程管理办法Word文档格式.docx（12页珍藏版）》请在冰点文库上搜索。

3.1.定义

版本上线:

包括新系统初始版本上线及升级版本升级上线两类。

项目负责人:

项目负责人一般为项目经理或项目经理指定的项目负责人员.

3.

3.1.

3.2.流程图

3.2.

3.3.流程说明

流程主要包括提交、测试、发布、上线、确认5大流程，对于存在多次的提交/测试过程不在流程中体现（表单中有允许5次提交，超过5次以退回叠加内容方式进行），同时针对过程中需要进行配合的事项，如人员配合安排、上线&

升级方案审核确认等事宜需线下确认（流程中的虚线部分）。

3.3.1.项目负责人首次提交版本

项目负责人进行版本提交时，在OA工作流中发起版本提交申请，填写完整流程单后主送给下一阶段的测试人员处理；

同时将流程单抄送给项目组相关人员及质量部经理、用服人员。

1）项目负责人发起版本提交申请时，需完整填写提交地址、模块信息、版本特性；

同时检查好版本库中对应的提交文件是否存在、提交内容是否正确无误。

2）对于明确不需要发布的版本，则不需要抄送给用服人员。

3）用服人员根据流程单信息，可提前做好版本提交相关准备，准备上线&

升级方案；

并注意跟进版本的发布情况。

3.3.

3.3.1.

3.3.2.测试人员测试版本

测试人员在收到版本提交的流程单后，根据版本的时间要求安排完成测试工作，并发布测试结果，将填写完整的流程表单提交给项目经理。

1）测试人员在收到提交的版本时，需确认工作流中版本提交信息是否完整无误，如果存在问题需退回给提交者重新填写。

2）测试人员在收到版本后及时完成版本的测试工作；

测试完成后，测试人员在表单中填写版本测试的结果信息，提交流程单给项目经理。

3.3.2.项目负责人提交回归版本

项目负责人在收到测试完成邮件后；

安排进行版本的回归修改，在针对问题单进行了相应的修复或应有处理后，则可以进行回归版本的提交。

1）项目负责人发起版本回归提交前，需检查是否完成了相应BUG单的修复,不进行修改的BUG是否进行了应有的确认，将有效信息传递到下一个环节处理人员。

2）项目负责人需合理控制回归的次数，对BUG是否修改作好风险评估，以避免回归次数过多现象。

3.3.3.测试人员发布（归档）版本

测试人员完成测试回归通过后，则根据实际安排可以发起版本发布或归档流程；

版本发布时，必须提供发布路径、发布版本、发布功能以及注意事项及遗留问题相关信息

1）对于明确不需要发布给用服人员仅本地归档的版本，则提交给项目经理确认环节即可；

2）对于暂时不需要发布（以后需要发布）给用服人员的版本，测试人员正常提交回归结束邮件给项目经理即可；

项目经理在收到发布通知后再提交给测试人员发布版本。

3）对于需要发布给用服人员的版本，测试人员对发布版本的正确性、完整性负责，并确保在版本发布过程中不泄漏源码和设计文档等关键资源。

3.3.4.用服人员执行上线&

升级操作

用服人员根据已制定的上线&

升级方案，执行版本上线&

升级操作，并根据实际执行情况记录上线&

升级结果，撰写相应的升级报告，填写流程表单，将实际情况反馈给项目负责人、用服部经理和测试人员进行确认。

1）用服人员在执行版本提交操作前作好充分的准备工作，包括项目负责人确认配合人员到位情况，局方各接口是否可用等，并按照执行方案中已确定的时间，进行版本上线&

升级操作。

2）用服人员在执行操作过程中，遇到无法解决的问题或无法控制的风险等情况，不能保证版本上线和系统割接成功完成时，应及时与项目负责人、上级领导和客户相关负责人沟通，停止执行版本提交操作并回滚。

3）项目负责人需根据上线&

升级时间安排好支撑人员，确保上线或割接的顺利完成。

3.3.2.

3.3.3.

3.3.4.

3.3.5.

3.3.6.确认结束流程

项目负责人、用服部经理、测试人员收到版本上线&

升级结束通知后，依次根据自身职责进行确认并结束流程。

1）项目负责人和测试人员对版本升级报告进行审核，对升级过程是否存在遗漏和遗留问题隐患等方面确认，并对存在的遗留问题和遗漏等进行相应的处理安排，并跟踪执行。

2）测试人员确认是否在版本上线过程中产生临时版本，并对临时版本进行补测和归档。

3）用服部经理对用服人员涉及的版本上线&

升级执行情况和工作质量等进行必要的检查。

3.4.补充规定

4.

5.

5.1.

5.2.

5.3.

5.4.

3.4.

●发布未经测试的临时版本原则

在项目时间非常紧迫的情况下，有时需要发布未经测试的临时版本必须提交给质量部，由质量部转交给用服人员完成上线&

升级操作，不允许开发人员直接提供版本给用服人员进行版本上线&

升级。

项目负责人应及时安排对临时版本进行补测，用正式版本升级替换临时版本，不允许长期在线上使用未经测试的版本。

●版本上线&

升级割接过程中紧急临时版本的处理原则

对于版本上线&

升级过程中需要发布的临时版本，因测试人员不在场而直接交由用服人员上线时，须在上线结束前对版本进行提交归档，不允许过夜。

●OA流程的补充

由于部分外地用服人员使用OA不够方便，测试人员在OA上走完流程单后，根据需要同时补以外网邮件再进行一次补充发布。

3.4.1.版本变更和取消的处理原则

在版本提交完成后出现版本变更时，项目负责人应要求退回流程单重新修改相关内容后，重新提交表单。

对于版本取消的情况，项目负责人应通知从当前环节处理人开始，将流程步骤依次走完，各环节处理人分别注明确认版本取消的相关信息。

对于已经产生的版本，质量部相关环节责任人应对其进行特殊归档，与正式版本区别，项目负责人负责对归档进行确认。

3.4.2.特殊流程

版本上线和系统割接的处理要严格遵守办公工作流程，对于某些非常特殊或紧急需求，必须要加快流程进展、无法遵守既定流程时，必须及时征得上级领导的许可。

3.5.检查点

对版本上线和系统割接的执行状况的检查点，详细项目如下：

考核人员

考核项目

研发助理

每周进行例行检查，确认流程是否存在异常。

主要版本有否正常流转/结束

3.6.考核原则

各部门相关人员须严格执行及遵守本规范，对于流程各环节相关责任人因未有效履行职责，导致版本提交工作执行不力的情况，相关直接责任人及对应主管，均承担相关责任。

项目负责人作为项目主要负责人，应对版本的全过程组织协调工作负责，对于过程中出现的组织协调问题承担主要责任。

4.附录

表一：

版本提交、测试、发布、上线&

升级流程表

项

目

负

责

人

（第一次版本提交）

项目名称

计划发布时间

版本提交说明

提交人员签字

提交时间

测

试

员

（第一轮测试结束）

测试结果说明

测试人员签字

完成时间

（第二轮版本提交）

（第二轮测试结束）

（第三轮版本提交）

（第三轮测试结束）

:

测试人员签名

（第四轮版本提交）

（第四轮测试结束）

（第五轮版本提交）

（第五轮测试结束）

（版本归档/发布）

归档或发布说明

归档/发布时间

用

服

上线&

升级方案

（附相关附件）

执行时间确认

开始时间

结束时间

执行结果

成功

成功但存在遗留问题

失败

是否产生

临时版本

1、是

2、否

升级报告

确

认

阶

段

是否已归档

1、无临时版本

2、已归档3、未归档

其它补充说明

确认日期

项目负责人

签字

用服部经理