# 发布规范

# 提交发布任务

# 请求形式

发布任务需要在数字化团队项目发布上新建发布任务，添加并完善请求内容，确认后把任务指派给相应的运维人员

# 请求内容

产品和开发/测试确定：发布范围和测试结果（测试环境结果决定是否可以发布）。

1. 发布范围：

• 代码/分支确认；
• 数据库（描述文字以及脚本附件）；
• 影响业务清单（在测试环境上就需清楚，并在测试时追踪并更新）；

2. 测试描述：

• 发布内容清单：修复问题，新增特性；
• 可接受问题清单；
• 发布后测试范围和测试方案

3. 发布步骤：具体的前后端发布流程明细；

# 发布审核

# 审核任务

接到发布任务，验证请求内容是否正确，如果不正确不予发布，并将任务返回给请求人。

1. 请求所需信息是否完整；
2. 确定发布时间/发布规则；
3. 发布结果确认时间/发布错误回退方案；

# 发布预生产环境

审核通过后按照发布请求发布步骤进行发布，发布后将任务指派给相应的测试人员。
如果在发布过程中很多问题，可指回任务，让修改梳理后重新提交发布申请。

# 预生产测试

测试人员按预定的测试范围和测试方案进行确认，返回发布测试结果。

# 测试成功

返回结果给运维进行预生产到生产的发布。

# 测试失败

根据发布预期决策进行处理。

# 发布结果与记录

•发布成功：发布成功日志并邮件通知； •发布失败：发布失败日志和处理细节；

# 常见问题

# 运维怎么确定发布信息是否正确？

运维只能确定提供信息是否完整，是否正确应由提供方自己确认是否正确。

# 任务基本信息

# 发布主题

# 发布时间

明确此次发布具体的操作时间，让运维可以安排好可操作时间。

格式：YYYY-MM-DD
示例：2019-06-01

# 参与人员

必须包含以下角色：产品，设计，前端，后端，测试，运维。

# Bug总数

本次发版所包含的特性和解决的问题总数，简明涵盖本次发版工作量（并不做其他评估参考）。

# 发布版本

按照正常的项目开发流程，这里应该填写具体的系统版本号或对应的Sprint 值。具体版本号，应在前后端代码信息中具体说明。

例如：Sprint01 或 v1.2.0

# 确认人

基本信息确认人。可能信息所有人和信息填写人不一致，需要记录信息具体来源。

# 任务技术信息

# 发布步骤

说明具体的发布步骤，或重点说需要注意重点发布步骤。可能需要根据前后端分别说明。
例如：在发布版本后注意更新数据库 sys_version 表中对应的版本号 app_version字段，值为基本信息版本号。

# 代码仓库

按前后端分别说明：

• 代码仓库地址
• 需发布分支名
• 发布版本号

# 数据库脚本

• 备注关于此事发布的数据库变动信息，需要很具体；
• 附上确认后的数据库脚本文件，并说明具体的使用步骤；

# 回退方案

说明如果发布未成功的情况下，具体的处理方案和步骤。可能有不同情况，例如：

• 主要功能发布成功，部分细节有问题但不影响主业务；
• 新功能不能使用，但是修复的BUG正常上线；
• 发布失败； 可按项目实际情况和历史处理方法，列举出处理方案

# 确认人

技术信息确认人，需要项目相关的技术负责人角色确认，因为此处信息需要专业的评估和技术进行处理。