- 每个环境部署和发布的责任制。
- 资产和配置管理策略。
- 部署时所用技术达成共识。
- 实现部署流水线的计划。
- 枚举所有的环境
- 部署时应该遵循的流程
- 对应用程序的监控需求，通知API或服务。
- 配置方法如何管理
- 外部系统集成策略。
- 记录日志详情
- 制定灾难恢复计划
- 生产环境的数量大小及容量计划
- 制订一个归档策略
- 如何修复生产环境中出现的缺陷，并为其打补丁。
- 如何升级生产环境中的应用程序以及迁移数据。
- 如何做应用程序的生产服务和技术支持。
- 每次部署时使用相同的流程和使用同样的方法，向每个环境部署。在首次向测试环境部署时就应该使用自动化部署。
- 首次部署MVP，让流水线运行起来
- 部署流水线提交阶段
- 类生产环境
- 将提交阶段中生成的二进制包，部署到这个类生产环境（UAT）中，做一个简单的冒烟测试，用于验证本次部署的正确性
- 一个版本要通过哪些测试阶段
- 每个阶段需要设置怎样的质量门禁
- 谁有权批准让该构建版本通过该阶段
- 比如用冒烟测试来验证配置信息的正确性。
- 发布前的一段时间就准备好生产环境，并把它作为部署流水线的一部 分向其进行部署。
- 准备好一个自动化过程，对环境进行配置，包括网络配置、外部服务和基础 设施。
- 确保部署流程是经过充分冒烟测试的。
- 与外部系统进行测试集成。
- 发布之前就把应用程序放在生产环境上部署好，蓝绿部署
- 试着把它发布给一小撮用户群。这种技术叫做金丝雀发布。
- 将每次已通过验收测试的变更版本部署在试运行环境中（尽管不必部署到生产环境）。
-
两个原则：
- 发布前，确保生产系统的状态已备份
- 每次发布之前都练习一下回滚计划
-
通过重新部署历史版本进行回滚
- 将新版本部署在蓝环境，在蓝环境下测试后，将路由配置到蓝环境。
- 蓝绿部署要小心管理数据库
- 金丝雀发布：把应用程序新版本部署到生产环境中的部分服务器中，让部分用户使用。
- 原则：紧急修复版本也需要走构建、部署、测试和发布的标准流水线。
- 让部署到生产发布也自动化。理想情况下，如果某次提交通过了所有的测试环节，就直接部署到生产环境中。可以与金丝雀发布结合。
- 不要直接对生产环境进行修改
- 移动文件，而不是删除