持续交付
持续集成:个体不断向主干分支快速迭代的过程,强调开发的及时性,以保障局部和整体开发进度的协调,使软件随时处于可运行状态.同时避免像瀑布模型那样集中提交,引起大量冲突的情形;这里会执行单元测试.组件测试和功能性验收测试
持续交付:将持续集成的二进制包不断进行非功能性验收测试,人工测试(探索性,易用性测试),优化的过程,使应用保证一种随时可交付使用的状态.
持续部署:将持续交付内容通过自动化部署的方式快速且安全的部署到不同的环境.强调快速生产化,包含基础设施的部署能力.
为什么
软件交付是软件需求到产出的最终环节,如何尽快实现交付,是实现软件价值以及企业盈利的关键.
实际软件交付存在很多问题,如:
- 采用手动发布.从环境部署到软件安装都是手工操作,很容易在发布时出问题
- 手动部署及测试.由于手动部署是通过文档来进行,但文档常常缺少维护,就造成很容易出问题,同时测试环境也是手动进行,造成部署效率比较差.
- 开发完成才向预生产环境部署.一般都是快上线时,才部署到预生产环境,很多时候预生产配置和测试环境差异比较大,同时开发还没有对应的权限进行软件安装,造成无法及时修复问题;同时测试,运维都是初接触新功能,都会感觉很棘手.
- 生产环境手工配置管理.每次部署生产都是一个力气活
生产手工配置的问题:
- 预生产环境部署正常,但是生产部署就是出问题
- 集群节点行为有差异,增加了部署复杂性
- 运维较差时间才能部署服务
- 系统无法回滚到某个配置.包括操作系统,应用服务器,数据库,web服务器,其他基础设施等
- 集群基础环境有差异
- 直接修改生产环境上的配置来改变系统配置
由此可见,如何让软件发布能成为一个低风险,频繁,廉价,迅速且可预见的过程,非常重要.
怎么做
通过部署流水线,将高度自动化的测试和部署以及全面的配置管理结合在一起,实现一键式部署,就是持续交付要做的事情.
持续交付的目标:
- 强调速度,缩短软件交付周期
- 快速交付.快速开发和验证
- 保证质量.软件的可用性是基础.
如何做:
- 全方面自动化.基础设施,中间件,应用服务的构建,部署,测试,发布都要进行自动化,来达到快速且可控.
- 频繁做.越是频繁,反馈越快,处理也就相应变快.往往单次异常影响就越小,解决也就越简单.形成一个良性循环.
- 快速反馈
反馈流程包括:
- 创建可执行代码流程必须有效
- 单元测试成功
- 达到质量标准
- 功能验收测试成功
- 非功能测试必须成功.性能,有效性,安全性等方面要求
- 通过探索性测试.演示环境,满足功能展示需要.
同时还要实现快速反馈:
通过将发布流程拆解为流水线模式,通过区分软件阶段来筛选问题,加速异常反馈速度,同时保障软件的质量,也保证后续流程的验证是满足一定标准的,比如软件都运行不起来,你进行安全性测试是没有意义的.
交付团队必须接收反馈并作出反应,当获取反馈后,必须优先处理反馈异常,才能继续当前工作.
价值
- 一键式部署.部署流水线让部署更简单,应用版本选择也很简单,很少需要等待可用版本的问题;
- 减少错误.由于是全方位自动化处理,尽量做到了所有环节可控,就算出问题也可以很快复现(各个环境基础设施相同),快速解决,减少了错误发生率.
- 缓解发布压力.当你对于环境的越了解,它的不可控因素就越少.
- 部署更灵活.由于自动化程度高,你可以轻松的构建一个全新的服务.
- 多加练习,不断完善.通过采用相同的部署流程,需要针对各个环境不断进行部署,来发现问题,优化流程.
- 每一次提交都可以是候选版本.完备的测试可以让每次提交都可以随时发布.
软件交付原则
- 为软件发布创建一个可重复可靠的过程.将依赖环境自动化;应用构建,部署,测试,发布所需的东西版本控制管理.流程可控,就可以实现可重复.
- 将依赖环境自动化.基础设施,中间件,应用服务,数据库,依赖等几乎所有相关服务都可以自动化,当然这不是一次性要求,可以针对自己部署流水线的当前痛点,逐渐进行.
- 将所有东西纳入版本控制.全面了解,才能确定每次变更集,才容易做构建,测试以及问题追溯.
- 提前并频繁做让你痛苦的事.问题不会因为你不做而减少,往往还会增多.反而你不断的去面对它,才发现没有想象那么难.
- 内建质量.越早发现缺陷,修复它们的成本就越低.所以测试要随时进行;每个人都要对质量负责.
- 交付过程是每个人的责任.强调责任意识,尽快解决问题,而不是等待问题爆发时才解决.
- 持续改进.团队定期进行:计划-执行-检查-处理.这样也利于解决一些整体规划问题,避免交付时返工.