对于小型项目来讲，发布申请清单由项目经理填写并审核，然后交付部署人员直接发布了。但在严谨的项目规范里，这种方法并不可行，尤其是大型项目，如果是涉及到外部客户的项目，发布申请清单更是需要经过层层审核，通过后方可执行发布动作。
发布申请清单
首先，我们先了解下项目中发布的整个流程，很多传统的测试人员一般只跟踪到测试交付，或是产品验收结束阶段。对于发布流程不清晰 ，或是等到发布后会由项目经理通知需要线上测试。以此类推，测试人员一直处于被动的工作阶段。对于项目的整体规范，发布流程如下：测试团队系统测试交付通过->UAT测试团队预发布测试通过->产品经理验收通过->研发经理填写发布申请清单->交由所属项目经理&QA经理签字确认->研发经理发送申请发布邮件->职能部门负责人同意后方可执行发布动作，否则会给出拒绝发布的原因。
一般情况下，发布申请清单主要包含以下内容：
- 项目名称
- 当前版本
- 发布版本
- 申请人
- 申请日期
- 版本描述
- 测试情况
- 回退机制
- 备注
- 相关审核人员
当前版本填写当前的应用版本号，申请人为申请发布的第一责任人，也是填写发布清单的人员，版本描述即目前即将要上线的内容，可以分为新增和删除，优化功能；测试情况填写申请发布版本的测试结果 ，如SIT/UAT测试通过，XXX产品团队验收通过等；备注与相关审核人员可根据公司需要配置；一般由项目经理及QA经理、职能部门负责人审核；回退机制根据项目性质及公司要求来，回退机制与风险识别同等重要，一旦发布异常，需要做好容灾测试的建议方案。以下举个例子：试运行：2天；试运行期间，内部用户进行系统功能验收及测试团队线上常规测试；若发现问题且问题数量较多（超过XX个）或出现严重程度高的问题则进行回退，回退版本至上一个版本；回退需要在XX确认前进行并马上进行问题修复；若发现问题数量较少且严重级别较低，则后续安排逐步修复。
即使我们现在工作中并不需要测试人员去接触到发布相关的工作，也需要主动学习以使我们融入进整个项目中，而非单纯地“执行测试”。