持续发布15-部署与发布

部署与发布

部署和发布的主要区别是回滚能力.发布是可获取新版本,部署是部署新版本且要具备回滚的能力.

解决什么问题

自动化部署软件.避免人工操作引起部署异常.

怎么做

创建发布策略

1. 项目启动时应确定的发布相关内容.这个需要项目启动时就要内部协商好,具体协商内容如下:
   1. 每个环境的部署和发布由谁负责
   2. 创建资产和配置管理策略.环境配置相关
   3. 部署技术达成共识
   4. 实现部署流水线计划
   5. 列举所有环境及依赖关系.包括验收测试,容量测试,集成测试,用户验收测试等环境
   6. 部署流程.申请方式和权限管理
   7. 程序监控.服务状态通知接口
   8. 部署和运行时的配置管理,如何将配置和自动化流程集合
   9. 程序和外部服务集成.哪个阶段集成,怎么测试,出问题找谁(对接方)
   10. 日志管理
   11. 灾备计划
   12. 故障转移,高可用计划
   13. 容量规划
   14. 归档策略
   15. 生产环境首次部署流程
   16. 生产环境缺陷修复流程
   17. 生产环境升降级数据迁移
   18. 如何做应用程序的生产服务和技术支持
2. 发布计划.第一次发布风险最高,需要细致地做个计划:
   1. 第一次部署应用程序时所需的步骤
   2. 如果进行程序和依赖服务的冒烟测试
   3. 问题时撤销步骤
   4. 应用程序状态备份和恢复步骤
   5. 不破坏应用程序状态的前提下,程序升级步骤
   6. 发布失败,重启或重新部署步骤
   7. 日志存放及其记录了哪些信息
   8. 服务监控
   9. 数据迁移步骤
   10. 前次部署的问题记录及解决方案
3. 发布产品.商业软件还需考虑内容:
   1. 收费模式
   2. 许可策略
   3. 依赖第三方技术版权问题
   4. 打包
   5. 市场活动所需要的材料(印刷材料,网站,播客,博客,新闻发布会等)
   6. 产品文档
   7. 安装包
   8. 销售和售后支持团队准备

程序部署和升级

应用程序部署要以一致且可靠的方式进行,这样来统一不同环境的流程,避免部署复杂化.首次部署就应该自动化部署,通过脚本自动执行,而不是手工.

1. 首次部署.应该在项目进行一两周后进行,可以通过一些客户演示等原因着手,以便在类生产环境部署应用.当首次部署后你会得到:
   1. 部署流水线提交阶段
   2. 一个部署的类生产环境.具体类生产环境的规模不用跟生产完全一致,可以进行比例缩小,达到可验证环境又便于自动化测试.
   3. 自动化部署流程.
   4. 一个简单的冒烟测试.验证部署正确性
2. 发布过程建模与晋级.建模内容:
   1. 为了达到发布质量,构建版本需要经过的测试
   2. 晋级条件
   3. 晋级条件决策人
3. 配置晋级.因为不同阶段需要不同的配置,二进制晋级时,配置也需要进行晋级.这就需要晋级的程序进行冒烟测试检查配置信息,中间件的配置可以通过nagios等工具判断.组件化应用应该整体晋级,避免版本问题
4. 联合环境.共享服务环境时,修改环境配置要避免影响其他应用;互相依赖服务,要进行集成测试,通过冒烟测试来验证互相依赖的服务最新版本是否可以使用;
5. 部署到试运行环境.试运行环境这里进行了单独抽取,实际上类生产环境就应该时试运行环境,但是这里环境分类更细致.它是生产前的最终准备,所有测试都应该在这个环境及之前得到验证.项目开始时的环境准备:
   1. 准备好生产环境,容量测试环境和试运行环境.
   2. 准备好自动化过程,对环境进行配置,包括网络配置,外部服务和基础设施
   3. 确保部署流程经过充分的冒烟测试
   4. 程序预热,尤其时需要缓存时
   5. 外部系统测试集成
   6. 将每次通过验收测试的版本部署到试运行环境

部署回滚和零停机发布

这个问题的难点有两个:1数据2需要与其他系统集成,即联合环境发布.这都有可能造成部分成功的情况,容易引起数据不一致.
解决方式:1发布前系统状态备份.2发布前进行计划练习.

1. 回滚方案:
   通过重新部署原有版本进行回滚.因为有自动化部署流程,重新部署原有版本时间可控,风险较低;已部署版本基本问题都已经解决,回滚错误率更低;但是也有问题:

   1. 需要耗费一定时间,可能需要停机
   2. 更难做调试,因为环境被覆盖
   3. 存在一定的数据丢失

2. 零停机发布.关键是将发布流程中的不同部分解耦,尽量使它们能独立发生.其中共享资源新版本的要单独处理,如数据库和静态资源.静态资源处理比较简单,因为它的变化不大.但是数据库它就存在部署时的新增数据.实际数据库版本管理见持续交付8-数据管理.常用部署方式如下:

   1. 蓝绿发布.当前环境为绿环境.新版本是蓝环境.同时运行蓝环境,通过路由切换将绿环境的访问引导到蓝环境中,实现无中断访问服务.蓝绿发布的难点在于数据库,因为切换存在一段时间数据不一致的情况.解决方式就是进行数据拷贝,此时绿环境只读,数据库准备好后,进行环境切换,把用户路由到蓝环境,如果一切正常,就进入读写模式.如果出问题,就切回绿环境.这时就要注意蓝环境是否写入数据,如果写入需要将这部分数据同步到绿环境.
   2. 金丝雀发布.通过直接将新版本部署到生产环境中,验证功能和进行非功能性验证.实现快速反馈的效果.实际操作是通过服务访问分流来实现.优点:1非常容易回滚.只要关闭路由即可.便于问题分析和定位;2作为A/B测试,通过使用率来判断新版本使用情况.3通过逐渐向新版本增加负载,来进行非功能性测试.缺点:需要约束数据库升级和共享资源.1需要进行版本兼容.2减少共享资源

紧急修复

紧急修复:让每个紧急修复都走完标准的部署流水线.避免修复引起连锁反应;避免造成环境版本不一致;还有如果短时间内无法完成修复就直接将版本回退,来快速解决问题.

持续部署

持续部署:就是将每个通过自动化测试的版本都部署到生产环境.这要你对自动化测试相当自信同时也要求公司对于新产品更迫切.如果是客户端,用户的升级就成为了你持续部署的阻碍.实际升级方式有:1软件进行版本检查,提示用户升级;2后台下载,提醒用户安装;3后台下载悄悄升级.实际3对于版本要更自信,但是会给用户一种强制的感觉,用户体验不好;1,2相对保守一些,也是使用最多的方式.升级问题需要采集用户反馈,获取崩溃报告;

部署建议

1. 真正执行部署操作的人应该参与部署过程的创建.
2. 记录部署过程.如果没有完全的自动化,需要记录配置信息路径,日志,二进制包,修改记录;
3. 不要删除旧文件,而是移到别处.UNIX环境中一个最佳实践:应用程序的每个版本部署在也给单独的目录中,通过符号链接指向当前版本,版本切换只要更改符号链接即可.
4. 部署是整个团队的责任.
5. 服务器应用不应该有GUI.
6. 为新部署留预热期.
7. 快速失败.对部署脚本进行测试
8. 不要直接对生产环境进行修改.自动化修改,所有修改要被记录,便于排查问题.