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