部署与发布
部署和发布的主要区别是回滚能力.发布是可获取新版本,部署是部署新版本且要具备回滚的能力.
解决什么问题
自动化部署软件.避免人工操作引起部署异常.
怎么做
创建发布策略
- 项目启动时应确定的发布相关内容.这个需要项目启动时就要内部协商好,具体协商内容如下:
- 每个环境的部署和发布由谁负责
- 创建资产和配置管理策略.环境配置相关
- 部署技术达成共识
- 实现部署流水线计划
- 列举所有环境及依赖关系.包括验收测试,容量测试,集成测试,用户验收测试等环境
- 部署流程.申请方式和权限管理
- 程序监控.服务状态通知接口
- 部署和运行时的配置管理,如何将配置和自动化流程集合
- 程序和外部服务集成.哪个阶段集成,怎么测试,出问题找谁(对接方)
- 日志管理
- 灾备计划
- 故障转移,高可用计划
- 容量规划
- 归档策略
- 生产环境首次部署流程
- 生产环境缺陷修复流程
- 生产环境升降级数据迁移
- 如何做应用程序的生产服务和技术支持
- 发布计划.第一次发布风险最高,需要细致地做个计划:
- 第一次部署应用程序时所需的步骤
- 如果进行程序和依赖服务的冒烟测试
- 问题时撤销步骤
- 应用程序状态备份和恢复步骤
- 不破坏应用程序状态的前提下,程序升级步骤
- 发布失败,重启或重新部署步骤
- 日志存放及其记录了哪些信息
- 服务监控
- 数据迁移步骤
- 前次部署的问题记录及解决方案
- 发布产品.商业软件还需考虑内容:
- 收费模式
- 许可策略
- 依赖第三方技术版权问题
- 打包
- 市场活动所需要的材料(印刷材料,网站,播客,博客,新闻发布会等)
- 产品文档
- 安装包
- 销售和售后支持团队准备
程序部署和升级
应用程序部署要以一致且可靠的方式进行,这样来统一不同环境的流程,避免部署复杂化.首次部署就应该自动化部署,通过脚本自动执行,而不是手工.
- 首次部署.应该在项目进行一两周后进行,可以通过一些客户演示等原因着手,以便在类生产环境部署应用.当首次部署后你会得到:
- 部署流水线提交阶段
- 一个部署的类生产环境.具体类生产环境的规模不用跟生产完全一致,可以进行比例缩小,达到可验证环境又便于自动化测试.
- 自动化部署流程.
- 一个简单的冒烟测试.验证部署正确性
- 发布过程建模与晋级.建模内容:
- 为了达到发布质量,构建版本需要经过的测试
- 晋级条件
- 晋级条件决策人
- 配置晋级.因为不同阶段需要不同的配置,二进制晋级时,配置也需要进行晋级.这就需要晋级的程序进行冒烟测试检查配置信息,中间件的配置可以通过nagios等工具判断.组件化应用应该整体晋级,避免版本问题
- 联合环境.共享服务环境时,修改环境配置要避免影响其他应用;互相依赖服务,要进行集成测试,通过冒烟测试来验证互相依赖的服务最新版本是否可以使用;
- 部署到试运行环境.试运行环境这里进行了单独抽取,实际上类生产环境就应该时试运行环境,但是这里环境分类更细致.它是生产前的最终准备,所有测试都应该在这个环境及之前得到验证.项目开始时的环境准备:
- 准备好生产环境,容量测试环境和试运行环境.
- 准备好自动化过程,对环境进行配置,包括网络配置,外部服务和基础设施
- 确保部署流程经过充分的冒烟测试
- 程序预热,尤其时需要缓存时
- 外部系统测试集成
- 将每次通过验收测试的版本部署到试运行环境
部署回滚和零停机发布
这个问题的难点有两个:1数据2需要与其他系统集成,即联合环境发布.这都有可能造成部分成功的情况,容易引起数据不一致.
解决方式:1发布前系统状态备份.2发布前进行计划练习.
-
回滚方案:
通过重新部署原有版本进行回滚.因为有自动化部署流程,重新部署原有版本时间可控,风险较低;已部署版本基本问题都已经解决,回滚错误率更低;但是也有问题:- 需要耗费一定时间,可能需要停机
- 更难做调试,因为环境被覆盖
- 存在一定的数据丢失
-
零停机发布.关键是将发布流程中的不同部分解耦,尽量使它们能独立发生.其中共享资源新版本的要单独处理,如数据库和静态资源.静态资源处理比较简单,因为它的变化不大.但是数据库它就存在部署时的新增数据.实际数据库版本管理见持续交付8-数据管理.常用部署方式如下:
- 蓝绿发布.当前环境为绿环境.新版本是蓝环境.同时运行蓝环境,通过路由切换将绿环境的访问引导到蓝环境中,实现无中断访问服务.蓝绿发布的难点在于数据库,因为切换存在一段时间数据不一致的情况.解决方式就是进行数据拷贝,此时绿环境只读,数据库准备好后,进行环境切换,把用户路由到蓝环境,如果一切正常,就进入读写模式.如果出问题,就切回绿环境.这时就要注意蓝环境是否写入数据,如果写入需要将这部分数据同步到绿环境.
- 金丝雀发布.通过直接将新版本部署到生产环境中,验证功能和进行非功能性验证.实现快速反馈的效果.实际操作是通过服务访问分流来实现.优点:1非常容易回滚.只要关闭路由即可.便于问题分析和定位;2作为A/B测试,通过使用率来判断新版本使用情况.3通过逐渐向新版本增加负载,来进行非功能性测试.缺点:需要约束数据库升级和共享资源.1需要进行版本兼容.2减少共享资源
紧急修复
紧急修复:让每个紧急修复都走完标准的部署流水线.避免修复引起连锁反应;避免造成环境版本不一致;还有如果短时间内无法完成修复就直接将版本回退,来快速解决问题.
持续部署
持续部署:就是将每个通过自动化测试的版本都部署到生产环境.这要你对自动化测试相当自信同时也要求公司对于新产品更迫切.如果是客户端,用户的升级就成为了你持续部署的阻碍.实际升级方式有:1软件进行版本检查,提示用户升级;2后台下载,提醒用户安装;3后台下载悄悄升级.实际3对于版本要更自信,但是会给用户一种强制的感觉,用户体验不好;1,2相对保守一些,也是使用最多的方式.升级问题需要采集用户反馈,获取崩溃报告;
部署建议
- 真正执行部署操作的人应该参与部署过程的创建.
- 记录部署过程.如果没有完全的自动化,需要记录配置信息路径,日志,二进制包,修改记录;
- 不要删除旧文件,而是移到别处.UNIX环境中一个最佳实践:应用程序的每个版本部署在也给单独的目录中,通过符号链接指向当前版本,版本切换只要更改符号链接即可.
- 部署是整个团队的责任.
- 服务器应用不应该有GUI.
- 为新部署留预热期.
- 快速失败.对部署脚本进行测试
- 不要直接对生产环境进行修改.自动化修改,所有修改要被记录,便于排查问题.