【SOP】迭代管理-checkList模版

迭代负责人：XXX

各应用可以结合自身应用特点，修改完善checkList模版。

每个迭代的checkList要确认主要负责人，去把控审查和跟进。

在迭代提测前后（1～2天内）写完checkList，保证脑子里的逻辑清晰，代码稳定时写。

相关依赖

排期时确认上下游发版日期，发版前两到三天内二次确认，发版当天上午再次确认（存在依赖方临时变更，不通知上下游的情况，强依赖请多次确认）

确认相关依赖方的发布日期，发布顺序可考虑如下：

• 添加配置，可自行切换发布功能
• 等强依赖方发布完成后，再发布

依赖方名称	负责人	真线支持日期或状态	依赖

后端应用配置

应用配置，可以和技术方案一起写，或者提测前后写，逻辑最清晰的时候写，避免提测后，做其他事情后产生误差：

• 配置列可根据自己的应用自行添加，目的是让配置不丢失
• 可能不同环境配置不同，相同配置可以标明同上或者同下
• 各配置添加注释，标识 增/删/改 操作

配置项	注意点	备注
数据库脚本
MQ
菜单和权限
ES
CANAL
定时任务
转发
审批

配置项	环境 分支：
数据库脚本	变更类型： 工单一： -- 注释 SQL
MQ	N/A
菜单和权限
ES
CANAL
定时任务
转发
审批

版本发布流程

编写到可以无脑执行下游步骤，从用户使用角度出发，包含整个链路需求完整性和上下游执行流程

• 此迭代发布后，用户感知强，需在发版前几天，提前发布邮件通知并且交底告知
  • 产品功能，产品经理发邮件
  • 技术优化，强技术相关，可以技术PM发邮件
• 每个步骤标明执行人，发版时，严格按照执行人去执行
• 严格按照应用发布时间去进行配置同步
  • 如果提前同步了配置，请评估是否需要完善发布流程，比如：提前同步ZMQ的消费者，导致消息堆积，大量请求打到下游
• 标识清晰可以同时执行的步骤和必须严格按照顺序执行的步骤
• 复杂迭代写完checkList，需和所有人对称（包括但不限于产品、前后端、测试、需要感知的依赖方）
• 此迭代负责人，确认各执行人执行进度，通知测试真线验证

执行步骤	执行内容简介	执行时间	具体内容	执行人
1
2

版本回滚流程

• 复杂迭代必须写版本回滚流程，避免发生问题时脑子当机
• 技术方案时，可考虑部分功能回滚

回滚内容	具体内容	执行人

生产回归验证

• 需要依赖方提供账号或其他数据，请提前准备，不要阻塞测试回归进度

验证场景	物料内容	备注