- 包括所有应该发布的内容，包括代码、配置及数据。如果配置涉及多个区域，需要每个区域分别检查。
- 不包括非预期的其它变更，包括：
- 一键或复制粘贴。整个发版过程，应该是一键完成或是通过复制粘贴事先准备（并测试）过的脚本完成。
- 所发布的变更，已经在dev集成环境完成测试。
- 对生产与测试环境之间的差异进行评估与预判。对于不确定的，需要在开发环境验证可行性。比如：
- 通过Flyway做DML时，不同环境的执行时间不同，可能在生产环境会超时失败。（Flyway不应当用于DML。）
- 如果变更中包括API的结构或行为变更。需要与产品及技术支持团队做好沟通。
- 对于不是随时可以发布的服务，需要在发版前确认当前是否适合发版。
- 对于需要审批的发版，应该提前至少一天拿到发版的所有批准。
* 对于所有有输出的执行过程，需要将所有的执行过程保存，以备复盘及数据核对等。
- 验证新增功能（如有）是否能正常工作。验证的结果，应当截图保存。截图中的信息应当完整。
- 验证原业务是否能正常工作。方式包括：
- 实时业务，而且日志完备的，可以通过日志确认工作没有异常。
- 对于非实时业务，需要在生产环境手工验证。
- 通过Sentry、SignalFX、NewRelic等实时监控系统，查看确认系统状态。
对于复杂的发布（非一键完成的，都是复杂发布），需要编写相应的发布计划。比如：
- 数据库结构变更或数据迁移。
- 环境变量的配置
- 对服务器发送请求。
- （非系统化地）手工触发作业。