项目beta环境部署申请

版权声明:知识在分享中升华,思想在交流中沉淀,欢迎大家转载。 https://blog.csdn.net/qwfys200/article/details/83059169

概述

  B对A提交的功能代码做完alpha测试以后,A就可以向运维D提交beta环境部署申请了,审批流程以及审核人关系如下所示:

提交
确认
确认
驳回
驳回
驳回
功能模块开发者 A
功能测试负责人 B
项目组负责人 C
运维负责人 D

  (1)、功能开发人员A基于beta环境部署申请流程创建具体的xxx功能beta环境部署申请,并在申请单附件中详细描述本次部署涉及的功能点、影响范围、数据库变更脚本、部署操作步骤说明。
  (2)、申请单流转给功能测试负责人B,由B确认待部署功能单涉及的功能点已经经过了alpha测试,允许A将功能部署到beta环境。
  (3)、项目负责人C再次确认,可以进行beta环境部署。
  (4)、运维负责人D确认该申请单,并严格按照部署单附件中的说明进行部署。

  该流程涉及项目组、测试组、运维组相关组内的干系人,现对流程中的角色详细解析如下:

管理
管理
管理
项目组负责人C
功能开发者A
测试组负责人B0
测试负责人B
运维组负责人D0
运维负责人D
项目组
通常一个大的互联网软件产品平台会由多个具有特定功能的系统以分布微服务的形式有机结合起来,而每一个微服务系统都由独立的项目组负责开发,项目组由PC Web端、无线APP端、Java服务端三部分人组成。项目负责人负责整个系统的研发人员的组织与协调。而在项目组内部,开发人员又按业务逻辑与职责的不同 ,有不同的侧重点。在一个时间单元内,项目组的开发活动会由于功能点的不同,进而形成功能点研发干人,如登录、注册模块如果涉及PC Web 2人(a1、a2)、无线APP端Android、IOS各一人(a3、a4),Java后端功能开发4人(a5、a6、a7、a8),那么功能点研发干系人会由PC Web前端人员、无线APP人员、Java服务端人员、功能点测试跟进人员、产品功能点跟进人员组成。这里的功能开发者严格来讲,是该功能点干系人员中的研发者的代表。
测试组
通常一个大的互联网软件产品平台会有独立的测试组统一协调各系统项目组的功能测试活动。测试组负责人会派测试人员跟到各项目组的开发活动中,如电商类系统中,商城系统会有4名测试人没(b1、b2、b3、b4)分别跟进到项目组中来,每一个测试负责人一个小范围内的测试,假如注册、登录由测试b1负责测试,那么b1就是流程中的测试负责人。
运维组
通常一个大的互联网软件产品平台会有一个独立的运维组负责相关服务器资源的管控,组内的不同运维人员负责不同的业务范围,假如d1负责电城系统项目组的部署工作,那么d1就是上述情形下的运维负责人。

小结

  项目Beta环境部署申请主要针对功能点内测第二阶段,属于生产环境的一种模拟活动。申请流程主要用于在开发、测试、运维人员之间进行相互确认、告知。
  Beta环境部署成功以后,测试人员进行一轮完整测试,测试没问题后,由产品相关功能点负责人进行预确认,预确认通过以后,就可以走生产部署上线申请流程的申请了。
  之所以将产品预确认添加进来,也是希望将问题尽可能早的暴露出来,让问题及早得以解决,而不是等到上线后发现有问题再做回退。

猜你喜欢

转载自blog.csdn.net/qwfys200/article/details/83059169
今日推荐