持续交付1-持续交付

Posted 2020-12-17 chengmuyu

持续交付

持续集成:个体不断向主干分支快速迭代的过程,强调开发的及时性,以保障局部和整体开发进度的协调,而不是像瀑布模型那样集中提交,而存在大量冲突的情形;

持续交付:将持续集成的二进制包不断进行测试,优化的过程,使应用保证一种随时可交付使用的状态.

持续部署:构建产品可快速安全交付用户使用的方式,强调快速生产化,包含基础设施的部署能力.

为什么

软件交付是软件需求到产出的最终环节,如何尽快实现交付,是实现软件价值以及企业盈利的关键.

实际软件交付存在很多问题,如:

1. 采用手动发布.从环境部署到软件安装都是手工操作,很容易在发布时出问题
2. 手动部署及测试.由于手动部署是通过文档来进行,但文档常常缺少维护,就造成很容易出问题,同时测试环境也是手动进行,造成部署效率比较差.
3. 开发完成才向预生产环境部署.一般都是快上线时,才部署到预生产环境,很多时候预生产配置和测试环境差异比较大,同时开发还没有对应的权限进行软件安装,造成无法及时修复问题;同时测试,运维都是初接触新功能,都会感觉很棘手.
4. 生产环境手工配置管理.每次部署生产都是一个力气活

生产手工配置的问题:

1. 预生产环境部署正常,但是生产部署就是出问题
2. 集群节点行为有差异,增加了部署复杂性
3. 运维较差时间才能部署服务
4. 系统无法回滚到某个配置.包括操作系统,应用服务器,数据库,web服务器,其他基础设施等
5. 集群基础环境有差异
6. 直接修改生产环境上的配置来改变系统配置

由此可见,如何让软件发布能成为一个低风险,频繁,廉价,迅速且可预见的过程,非常重要.

怎么做

通过部署流水线,将高度自动化的测试和部署以及全面的配置管理结合在一起,实现一键式部署,就是持续交付要做的事情.

持续交付的目标:

1. 强调速度,缩短软件交付周期
2. 快速交付.快速开发和验证
3. 保证质量.软件的可用性是基础.

如何做:

1. 全方面自动化.基础设施,中间件,应用服务的构建,部署,测试,发布都要进行自动化,来达到快速且可控.
2. 频繁做.越是频繁,反馈越快,处理也就相应变快.往往单次异常影响就越小,解决也就越简单.形成一个良性循环.
3. 快速反馈

反馈流程包括:

1. 创建可执行代码流程必须有效
2. 单元测试成功
3. 达到质量标准
4. 功能验收测试成功
5. 非功能测试必须成功.性能,有效性,安全性等方面要求
6. 通过探索性测试.演示环境,满足功能展示需要.

同时还要实现快速反馈:

通过将发布流程拆解为流水线模式,通过区分软件阶段来筛选问题,加速异常反馈速度,同时保障软件的质量,也保证后续流程的验证是满足一定标准的,比如软件都运行不起来,你进行安全性测试是没有意义的.

交付团队必须接收反馈并作出反应,当获取反馈后,必须优先处理反馈异常,才能继续当前工作.

价值

1. 一键式部署.部署流水线让部署更简单,应用版本选择也很简单,很少需要等待可用版本的问题;
2. 减少错误.由于是全方位自动化处理,尽量做到了所有环节可控,就算出问题也可以很快复现(各个环境基础设施相同),快速解决,减少了错误发生率.
3. 缓解发布压力.当你对于环境的越了解,它的不可控因素就越少.
4. 部署更灵活.由于自动化程度高,你可以轻松的构建一个全新的服务.
5. 多加练习,不断完善.通过采用相同的部署流程,需要针对各个环境不断进行部署,来发现问题,优化流程.
6. 每一次提交都可以是候选版本.完备的测试可以让每次提交都可以随时发布.

软件交付原则

1. 为软件发布创建一个可重复可靠的过程.将依赖环境自动化;应用构建,部署,测试,发布所需的东西版本控制管理.流程可控,就可以实现可重复.
2. 将依赖环境自动化.基础设施,中间件,应用服务,数据库,依赖等几乎所有相关服务都可以自动化,当然这不是一次性要求,可以针对自己部署流水线的当前痛点,逐渐进行.
3. 将所有东西纳入版本控制.全面了解,才能确定每次变更集,才容易做构建,测试以及问题追溯.
4. 提前并频繁做让你痛苦的事.问题不会因为你不做而减少,往往还会增多.反而你不断的去面对它,才发现没有想象那么难.
5. 内建质量.越早发现缺陷,修复它们的成本就越低.所以测试要随时进行;每个人都要对质量负责.
6. 交付过程是每个人的责任.强调责任意识,尽快解决问题,而不是等待问题爆发时才解决.
7. 持续改进.团队定期进行:计划-执行-检查-处理.这样也利于解决一些整体规划问题,避免交付时返工.