持续交付

持续交付是一种可以帮助团队以更短的周期交付软件的方法,该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。

通过对生产环境中的应用程序进行更高频次的增量更新,这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。

注意:持续交付 ≠ 持续部署 - 有时候很多人会把持续交付误认为成持续部署。持续部署是指每个变更可以自动部署到生产环境。持续交付是指团队确保每个变更可以部署至生产环境,但也许并不需要实际部署,这通常可能是出于业务方面的原因。只有成功实现持续交付的前提下,才能进行持续部署。

持续交付的主要想法在于:

  • 部署越频繁,对部署流程就会越熟悉,自动化机制就能获得更好的结果。如果同一件事每天需要执行3次,很快你将变的无比娴熟,但很快也会因为日复一日解决同样的问题而感到厌烦。
  • 部署越频繁,所部属的变更集就越微不足道,而这些微不足道的内容最有可能出错,甚至可能导致丢失对整个变更集的控制力。
  • 部署越频繁,TTR(修复/解决所需时间)指标就会越出色,从业务用户处获得有关功能的各类反馈的速度越快,作出改进以便完美满足对方需求的过程也会越简单(这方面TTR与TTM其实非常相似)。

(来源:Ops Meta-Metrics: The Currency You Pay For Change )

但持续交付并不仅仅是尽可能频繁地构建可发布、生产就绪版本的软件产品那么简单。持续交付包含3个关键实践:

  • 从实践中学习
  • 自动化
  • 更频繁的部署

3.1 从实践中学习

持续交付的关键在于要能从实践中学习。真理并不存在于开发团队中,而在于业务用户中。然而无论花多长时间,没人能真正清楚地表达自己的想法,或者将自己的想法用清晰的文档概括出来。也正是因此,敏捷方法论强调将功能提供给用户,并不惜一切代价从用户处获得尽可能多的反馈。

持续交付与持续部署类似,需要尽可能减少前置时间,这也是尽快从用户处获得“真理”的关键。

但真理绝对不会来自正规形式的用户反馈。我们绝不能尽信自己的用户或寄希望于通过正规形式的反馈了解用户。我们只能相信自己的度量。

痴迷于度量是精益创业(Lean Startup)活动中一个重要的概念,但这一概念对DevOps同样重要。我们应该度量一切!确定最恰当的度量指标可以让团队了解某种方法最终能否成功或失败,了解怎样做可以获得更好的结果,以及哪些最成功的做法同时也蕴含着一定的风险。为了帮助团队做出更明智的决策,在确定要衡量的指标时,一定要抱着“宁多勿少”的原则。

不需要“考虑”,只需要“知道”!“知道”的唯一方法就是度量,度量一切:响应时间、用户思考时间、展示次数、API调用次数、点击率等,但这些并非需要度量的全部。找出所有能让你更进一步了解用户对功能看法的度量指标,对所有这些指标进行度量!

这种方法可以表示为如下形式:

3.2 自动化

自动化已经在上文2. 基础架构即代码一节进行了讨论。

在这里我想强调的是,在没有将与基础架构有关的所有供应和任务实现妥善、全面的自动化之前,持续交付根本无从谈起。

这一点很重要,因此有必要再重复一遍:环境的搭建和生产就绪版本软件的部署只需要一键点击,只需要运行一条命令,整个过程应该自动完成。否则根本无法设想能一天多次部署同一个软件。

在下文的3.5 零停机部署一节中,还将介绍有助于自动化交付的其他重要技术。

3.3 更频繁的部署

DevOps的信条在于:

“越是困难的事,需要更频繁地进行!”

敏捷思维中,困难任务更要迎难而上,更频繁地去做,这中想法非常重要。

自动化测试、重构、数据库迁移、面向客户的产品规格、规划、发布 - 所有这些活动都要尽可能频繁地进行。

原因主要有三点:

  1. 首先,随着要做的工作量逐渐增加,这些任务也会变的愈加困难,但如果能拆解为小块,则会变的相对容易些。

    以数据库迁移为例:一些涉及大量表的大规模数据库迁移工作很麻烦,容易出错。但如果一次只迁移一部分,则可以相对较容易地成功完成整个迁移任务。此外还可以轻松地将多个小规模的迁移任务安排成一定的序列,在将一个艰难的大任务拆解为一系列容易实现的小目标后,处理起来就简单多了。(这也是数据库重构的本质)

  2. 第二个原因在于反馈。大部分敏捷思维关注的是设置反馈环路,借此让我们更快速地学习了解。反馈已经是极限编程(Extreme Programming)中一个非常重要,蕴含巨大价值的概念。在诸如软件开发等复杂流程中,我们需要更频繁地检查自己的最新进展,并进行必要的纠正。为此我们必须尽一切可能创建反馈环路,并提高反馈的频率,这样才能更快速地酌情做出调整。
  3. 第三个原因是实践。对于任何活动,越频繁地从事就越能获得完善。实践可以帮助我们理清整个流程,让我们更熟悉代表有事情出错的征兆。只要认真琢磨自己从事的工作,就能提炼出近一步完善所需的实践。

    对于软件开发,也有可能实现一定程度的自动化。一旦有人将某件事做了多次,就可以更容易地确定该如何进行自动化,更重要的是,这样的人在对这些事情实现自动化方面将有更大的动机。此时自动化尤为重要,因为可以加快速度并降低出错的概率。

那么这就产生了一个问题:使用DevOps方法时,该选择怎样的交付频率?

这个问题没有标准答案,而是取决于产品、团队、市场、公司、用户、运维需求等各种因素。

我认为最佳答案应该是:如果不能实现至少每两周一次交付,或在冲刺阶段结束时交付,那么连敏捷都谈不上,DevOps又从何谈起呢?

DevOps鼓励我们尽可能频繁的交付。在我看来,你需要对团队进行培训,让他们能够做到尽可能频繁的交付。我在我的团队中使用的一种较为可行的方法是在QA环境中每天交付两次。交付过程是完全自动化的:每天两次,中午和午夜各一次,计算机启动起来,构建软件组件,运行集成测试,构建并启动虚拟机,部署软件组件,对其进行配置,运行功能测试等。

3.4 持续交付的前提需求

在改为使用持续交付方式之前,需要满足哪些要求?

我草拟的需求清单如下:

  • 对软件组件的开发和平台的供应和设置进行持续集成。
  • TDD - 测试驱动的开发。这一点还有待商榷……但始终还是需要面对:TDD是目前唯一能通过单元测试对代码和分支进行可接受程度覆盖的方法(单元测试使得问题的修复过程比集成测试或功能测试容易很多)。
  • 代码审阅!至少要进行代码审阅……如果能进行结对编程(Pair programming)当然就更好了。
  • 软件的持续审计 - 例如使用Sonar。
  • 在生产级环境实现功能测试的自动化。
  • 更强大的非功能测试自动化(性能、可用性等)。
  • 独立于目标环境的自动化打包和部署。

另外在管理重大功能和演进时,还需要具备健全的软件开发实践,例如零停机部署技术。

DevOps之持续交付的更多相关文章

  1. [转载]持续交付和DevOps的前世今生

    作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人. 这是一个新 ...

  2. [转]DevOps实战:百度持续交付体系与最佳实践大解密!

    本文转自:http://dbaplus.cn/news-21-471-1.html “互联网+”时代,软件产品要想满足快速增长的用户需求,高效.快速的迭代转型必不可少,面对时刻发生改变的互联网及业务模 ...

  3. 产品经理人的持续交付和DevOps实践

    如果你正处于下列情形中 ,那这篇文章是为你准备的: 你目前身处技术行业,你是产品经理,并且,你明白特性分支是什么,CD代表什么,DevOps文化是什么样子的. 或者,你已经在实施敏捷,团队每周都会与您 ...

  4. 测试需要了解的技术之基础篇三__持续集成持续交付DevOps

    持续集成.持续交付.DevOps 1.容器技术Docker:容器技术介绍.Docker安装与加速配置.Docker基础命令.Docker搭建selenium.Docker搭建持续集成平台Jenkins ...

  5. CODING DevOps 系列第一课:基于开源工具链打造持续交付平台

    当下软件发展趋势 当今 IT 行业发展中比较流行的几个技术,首先是微服务化,将原有的一个系统拆分成多个,意味着有多个系统需要构建.测试.部署和运维. 第二个是敏捷开发模式,需求粒度更细化,要求一个可独 ...

  6. 什么是以特性为核心的持续交付|阿里巴巴DevOps实践指南

    编者按:本文源自阿里云云效团队出品的<阿里巴巴DevOps实践指南>,扫描上方二维码或前往:https://developer.aliyun.com/topic/devops,下载完整版电 ...

  7. [转载]"百度方法+"案例—从持续集成到持续交付

    前言 百度开放云(https://bce.baidu.com)是百度基于十五年基础架构核心技术积累推出的云服务,目前推出了14个云计算产品和9个大数据产品,并提供数字营销云.在线教育.物联网等10种解 ...

  8. CI Weekly #14 | 如何搭建合适的持续交付开发流程?

    时隔 10 个月,flow.ci 开始正式收费上线.为感谢对我们的内测支持,所有内测用户可继续免费使用基础版 30 天,截止至 3 月 15 日失效.欢迎随时告诉我们你对收费版 flow.ci 的反馈 ...

  9. 基于微服务的DevOps落地指南 交付效率提升40%

    基于微服务的DevOps落地指南 交付效率提升40% 2015-2016年,珍爱线下门店已新增覆盖城市9个,与此同时,CRM系统大小故障却发生了数十起... ... 珍爱网是以“网络征选+人工红娘”模 ...

随机推荐

  1. Linux less 常用导航命令

    linux中经常用less来查看文件,文件较短的时候用pgup(pageup), pgdn(pagedown),↑,↓几个键够,但是当文件比较长的时候用一些快捷键就能很方便实现快速导航. 1. 按匹配 ...

  2. python中的字符串常量,是否支持通过下标的方式赋值

    说明: 今天在看python,通过下标获取字符串常量的字符,在想是否可以通过下标的方式赋值. 操作: 1.对字符串下标赋值 >>> text='python' >>> ...

  3. 搭建项目Maven+springMVC+hibernate时,JUnit測试出现报ClassNotFoundException错误的解决

    近期在搭建Maven+springMVC+hibernate项目,正常启动项目时一切正常.但JUNIT測试时出现报ClassNotFoundException错误,经过细致排查发现没有生成class文 ...

  4. 【Ubuntu】Windows 远程桌面连接ubuntu及xrdp的一些小问题(远程桌面闪退、连接失败、tab补全功能,无菜单栏,error - problem connecting )【转】

    转:https://blog.csdn.net/u014447845/article/details/80291678 1.远程桌面闪退,shell可以用的问题:(1)需要在该用户目录创建一个.xse ...

  5. Java调用MQ队列

    IBM MQ 6.0中设置两个队列,(远程队列.通道之类都不设置). 队列管理器是XIR_QM_1502 队列名称是ESBREQ IP地址是10.23.117.134(远程的一台电脑,跟我的电脑不在一 ...

  6. Apache Kafka 1.0.0正式发布!

    千呼万唤始出来,经过7年的发展与完善,Apache Kafka 1.0.0正式发布!在笔者看来,比起1.0.0引入的新功能,此版本最大的意义在于标识Kafka各种组件功能的稳定性.不过我们还是来看下1 ...

  7. android新建的项目界面上没有显示怎么办?

    看log也没有说明具体情况? 一翻折腾在清单文件里加了权限就好了!!!

  8. Python中定义函数时参数有默认值的小陷阱

    在定义函数的时候,如果函数的参数有默认值,有两种类型的参数,一种是整数,字符串这种不可变类型,另一种是列表这种可变类型,对于第一种情况没有什么特殊的地方,但是对于可变类型,有一个微妙的小陷阱. 可变类 ...

  9. iOS 9: UIStackView入门

    本文转自http://www.cocoachina.com/ios/20150623/12233.html 本文由CocoaChina译者candeladiao翻译,欢迎参加我们的翻译活动.原文:iO ...

  10. 执行automake时报错 error while making link: Operation not supported

    执行automake时报错: [root@localhost project]# automake --add-missingconfigure.in: installing `./install-s ...