【SOP】迭代管理-checkList模版
迭代负责人：XXX
各应用可以结合自身应用特点，修改完善checkList模版。
每个迭代的checkList要确认主要负责人，去把控审查和跟进。
在迭代提测前后（1～2天内）写完checkList，保证脑子里的逻辑清晰，代码稳定时写。
相关依赖
排期时确认上下游发版日期，发版前两到三天内二次确认，发版当天上午再次确认（存在依赖方临时变更，不通知上下游的情况，强依赖请多次确认）
确认相关依赖方的发布日期，发布顺序可考虑如下：
- 添加配置，可自行切换发布功能
- 等强依赖方发布完成后，再发布
| 依赖方名称 | 负责人 | 真线支持日期或状态 | 依赖 |
后端应用配置
应用配置，可以和技术方案一起写，或者提测前后写，逻辑最清晰的时候写，避免提测后，做其他事情后产生误差：
- 配置列可根据自己的应用自行添加，目的是让配置不丢失
- 可能不同环境配置不同，相同配置可以标明同上或者同下
- 各配置添加注释，标识 增/删/改 操作
| 配置项 | 注意点 | 备注 |
|---|---|---|
| 数据库脚本 | ||
| MQ | ||
| 菜单和权限 | ||
| ES | ||
| CANAL | ||
| 定时任务 | ||
| 转发 | ||
| 审批 |
| 配置项 | 环境 分支： |
| 数据库脚本 | 变更类型： 工单一： -- 注释 SQL |
| MQ | N/A |
| 菜单和权限 | |
| ES | |
| CANAL | |
| 定时任务 | |
| 转发 | |
| 审批 |
版本发布流程
编写到可以无脑执行下游步骤，从用户使用角度出发，包含整个链路需求完整性和上下游执行流程
- 此迭代发布后，用户感知强，需在发版前几天，提前发布邮件通知并且交底告知
- 产品功能，产品经理发邮件
- 技术优化，强技术相关，可以技术PM发邮件
- 每个步骤标明执行人，发版时，严格按照执行人去执行
- 严格按照应用发布时间去进行配置同步
- 如果提前同步了配置，请评估是否需要完善发布流程，比如：提前同步ZMQ的消费者，导致消息堆积，大量请求打到下游
- 标识清晰可以同时执行的步骤和必须严格按照顺序执行的步骤
- 复杂迭代写完checkList，需和所有人对称（包括但不限于产品、前后端、测试、需要感知的依赖方）
- 此迭代负责人，确认各执行人执行进度，通知测试真线验证
| 执行步骤 | 执行内容简介 | 执行时间 | 具体内容 | 执行人 |
| 1 | ||||
| 2 |
版本回滚流程
- 复杂迭代必须写版本回滚流程，避免发生问题时脑子当机
- 技术方案时，可考虑部分功能回滚
| 回滚内容 | 具体内容 | 执行人 |
生产回归验证
- 需要依赖方提供账号或其他数据，请提前准备，不要阻塞测试回归进度
| 验证场景 | 物料内容 | 备注 |