Tag Archives: 持续交付

苹果的持续交付

最近,在持续交付和精益创业的相关讨论中,经常提到苹果公司的例子。比如Richard Durnall(精益思想和系统管理的倡导者,第三届敏捷中国大会的演讲者,《将精益思考的方法引入技术实践》)在Twitter上描述了苹果的策略 : 几个不寻常的家伙对其杰出的产品愿景坚信不移,并以盛大的庆典来做为其产品的发布仪式,而且,更重要的是,这种产品发布并不频繁。 这看上去恰好与精益创业或持续交付所倡导的方法背道而驰。由于苹果对其内部开发过程有严格的规定,禁止外泄,我们很难知道在苹果内部到底是怎么做的。而且, 也没有办法知道我们手中所了解的信息是否与他们的实际工作情况相吻合。但是,如果我们看一看苹果的发展历史,有些例子强烈表明,持续交付和精益创业的原则在苹果的早期工作过程中就体现出来了。 一个例子就是 Apple I。它在Steve Wozniak父母的车库中诞生,而且销售时根本没有键盘、显示器、电源转换器,甚至没有外壳儿,这正是Eric Ries所指的MVP(minimum viable product)。 Apple I on display at the Smithsonian, taken by Ed Uthman 另外一个例子是 “The Macintosh Spirit”,(参见 folklore.org), 来自Mac原始版本的创作团队成员写的一篇文章。 这篇文章认为,正是“团队的态度与价值观打造出了Macintosh精神”。这篇文章不长,值得通读一遍。(如果你有时间的话,整个网站都值得读一下,其中很多内容也在《Mac是如何炼成的》 这本书中)。下面这段文字描述了Macintosh团队的生产开发过程: 在苹果公司的其它团队使用详尽且正式的产品开发过程(在开始实现之前,要有长篇的产品需求文档和工程规格说明书)时,Mac团队喜欢一种更有创造性、更灵活的增量方法来不断地重构产品原型。Burrell Smith基于可编辑逻辑阵列芯片开发了一种独创的硬件设计方式,几乎在其他工程师修改​软件的同时,他就能够进行硬件设计的修改,这比传统开发方式快得多。与其在那里争论新的软件想法,不如真正通过快速原型来验证想法,保留那些最好的可工作的想法,而抛弃其它的(参见Busy Being Born)。我们一直让它可以运行,用于体现我们当时的最佳想法。 既然我们说的是二十年前的事情,就很难让人信服,然而还有一个例子说明在嵌入式系统上实现持续交付1。这个例子也解决了一个常见的错误认识,即:尽管你不需要“频繁地交付”,也并不意味着你不能持续交付(这就是为什么要把 持续交付和持续部署区分开,并且区分“部署”和 “发布”)。更进一步讲,持续交付是使成功的盛大庆典成为可能的武器之一。如果你正确地持续交付,在产品发布之前,很早就会做高风险的技术工作,而产品发布只是一个纯粹的市场运作—— 正如Mac电脑的发布那样, … Continue reading

Posted in 持续交付 | Tagged , , | 1 Comment

持续交付:价值主张​

过去十年中,一个划时代的改变就是:基于Web的业务模式对传统企业业务模式的冲击。亚马逊就是历史最长,也最明显的例子之一,而越来越多的公司(从航空到金融服务)开始依赖软件打造其竞争优势了。 ​依靠软件来运行的业务有两个关键组件:一是你想如何改变世界的愿景,二是尽早收集用户的反馈。精益创业运动特别强调反馈的重要性,这不仅仅体现在创业公司。像亚马逊、NetFlix、和脸谱这样的公司也持续不断地对其网站进行小步改进,从而增加收入,并改善网站用户的体验。 ​什么是持续交付? 想在用户与项目团队(包括客户或者Product Owner)之间建立紧密的反馈环,依赖于你是否有这样的能力,即:通过持续交付新的软件版本,验证新的想法和软件的改动,并能衡量这些改动对收入的影响。 对于很多需要几个月时间才能发布新版本的公司来说,在一天之内发布数次似乎是天方夜谭。然而,遵循《持续交付》一书中的原则与实践,一些原来一年才能发布几次新版本的公司,也已经能在一个月内发布数次,或者更频繁了。这是一种巨大的竞争优势,而且意味着,在时间和精力方面减少了大量的浪费。 实际上,持续交付有两个至关重要的业务收益: 第一,它让你能更快地验证新业务方案的结果,并根据真实的用户反馈进行调整。尤其是当业务方案有根本性缺陷时,你一定希望能尽早地发现,而不是花数月或数年的时间和大量的金钱来实施计划后,才知道存在问题。 第二,与项目结束后的一次性大版本发布相比,它能提供一种大幅降低交付风险的交付流程,而且成本的投入也更加具有可预见性。 另外,对于IT管理来说,它还提供另外两种好处: 第一,项目经理们能看到项目的真实进度,因为,此时的“完成”是指:运行于真实生产环境中的可工作的软件已经为用户带来价值。 第二,通过规律性增量发布,大大减少了每次发布的风险。 实现持续交付 为了能够成功实现持续交付,需要依赖于两个基础,一是技术基础,二是组织基础。而这两个基础有三大支柱:(1)全面的配置管理;(2)敏捷测试;(3)部署流水线。 配置管理: 就配置管理而言,为了实现持续交付,有四个关键点: 第一,要能以全自动化的方式,构建、测试并部署你的应用。为了做到这一点,源代码、测试脚本、构建与部署脚本、数据库迁移脚本等统统要纳入到版本管理。 第二,应用程序的部署时及运行时配置项需要以某种统一且集中地方式管理起来。 第三,要能用全自动化的流程在每种环境上创建或者进行配置变更。 第四,所有的开发工作必须在主干上完成,而且,能够对较大的特性或重构做增量实现,以便应用程序一直保持在可工作状态。如果必要的话,没有开发完的特性可以利用配置开关,使用户无法通过界面或公共接口使用它。 同时,有效的配置及发布管理也依赖于整个交付过程中开发团队与运维团队(包括DBA)之间的紧密合作。为了确保运维需求被纳入项目考虑范围,并让应用程序在开发初期就能部署到类生产环境中进行单一功能或跨功能测试,运维人员应在项目开始阶段就成为交付团队的一员。这种协作也正是DevOps运动所倡导的重要的文化转变之一。 敏捷测试 持续交付依赖的第二个支柱是敏捷测试方式。当然,它也同样包含技术和组织两方面。从工程角度来看,各个层次上的自动化测试是必不可少的,包括单元级别、组件级别,系统级别(功能与非功能测试)。要确保做到:如果自动化组合套件全部成功通过了,那软件本身就达到了可发布质量,即:在生产环境中没有回归缺陷,满足业务需要——包括容量和可用性方面的要求。 敏捷测试要求在整个交付过程中的质量内嵌。也就是说,测试不再是一个“阶段”,而应该是在整个交付过程中持续发生的一种活动。同样,软件的质量不再只是测试人 员或QA的责任,而是整个交付团队的责任。测试人员与分析人员应该在一起,共同创建可测试的验收条件。作为开发过程的一部分,测试人员与开发人员应该合作创建自动化的验收测试,用于验证所开发的内容满足验证标准,这叫做“验证测试驱动的开发(acceptance test-driven development)。开发人员要负责维护验收测试,并确保它们一直可以成功通过。 部署流水线 持续交付的第三个支柱是部署流水线。从本质上讲,部署流水线是现有交付过程的一个模型,是整个价值流的一部分,即从提交到发布的那一段价值流。可以用像Go这 样的工具对其进行建模。对于应用程序的任何修改(包括配置)都要从头到尾通过这个部署流水线,即先对系统进行构建,并基于该构建产物运行自动化测试,然后放到某处,以便后续部署到测试环境和生产环境。可以把部署流水线看做是持续集成的一个延伸,即:它将持续集成从开发团队扩展到了测试和运维团队。 用来建模和管理部署流水线的工具会记录每一次构建历史,它会记录每个构建所对应的版本控制库中的版本号,谁把它部署到了哪个环境,什么时候部署的,部署的结果是“成功”,还是“失败”。这个部署流水线应该强制你的部署工作流(包括认证和授权),并能对整个交付流程进行审计。由于这个流水线是对你的开发及部署过程进行建模,所以,它为发现流程瓶颈,持续改进交付过程提供了丰富的数据支持。 通过持续交付来管理项目 毫无疑问,对于刚刚接触持续交付的团队来说,对其所要求的纪律性会感到吃惊。很多直觉上应该如何管理项目的方式(包括团队成员之间如何互动)都需要改变。对团队来说,当实施持续交付时,和所有的敏捷方法一样,最重要的事情是通过回顾,持续反省他们正在做的事情,并对工作方式和过程做增量式的改变,并不断地改进它。 重新调整你的直觉 每个项目天生都有一种节奏和风格。传统的交付项目在项目开始和中期,总会有一个漂亮而体面的进度报告。然而,当到了某个时间点后,客户和管理层常常会有一些令其不悦的发现:尽管大部分内容都“开发完成”了,但在集成阶段,部署到具有现实负载的类生产环境中的应用程序总是不能工作得很好。 此时,这个项目就进行了所谓的“两难境地”,或叫“死亡行军”,人们在很大的压力上加班工作,试图修复整个系统。这令每个人都极不满意,而事实上, 在某些领域,这种失控模式已经成为一种家常便饭。 在那些实践持续交付的项目中,开始时进展可能比较慢。因为项目一开始要建立基础设施,对构建、测试和部署做自动化,并在得到成功构建的产品后,在类生产环境中执行验收测试。这让团队成员,尤其是刚接触它的管理者,感到不舒服。然而,这正说明它起作用了。持续交付的影响表现在它把痛苦提前了,从而让交付过程更加平稳、真实且可度量。 你原来体会到的是“开发完成“,与“真正完成”不一样。现实中,真正的“完成”是指发布给用户,或者至少在集成环境上严格地进行验收和回归测试后,在类生产环境中向客户演示。在新功能开发完后,其实还有很多工作要做:交付过程中的这部分被叫做最后一哩。持续交付坚持认为:“只有过了这一哩”,工作才算完成,根本就没有“完成了百分之五十”这个说法,所以,这让整个交付进度看上去比较慢。​ 然 … Continue reading

Posted in 持续交付 | Tagged , , , , | 1 Comment

LinkedIn:移动APP开发中的自动化测试与持续部署流水线

最近,有很多人问我关于“移动应用开发中的自动化测试如何做?持续集成和部署流水线从哪里开始?”的问题,觉得有必要写一写。恰好这个周末在家无意间看到Linkedin的做法,觉得非常有意思,尤其是截屏做对比测试的做法,在移动应用中比较少见, 在这里与大家分享。原文地址在这里。

Posted in 持续交付 | Tagged , , , , , , | 1 Comment

围绕最终交付物,而不是角色来组织软件交付活动

——持续交付与跨功能团队 在实施持续交付的过程中,我们很容易聚焦于自动化和工具,因为作为起点,它们通常是最容易做的。然而,持续交付的成功实现,还依赖于根据最终交付物而对组织结构所做的优化。对于持续交付来说,最大的障碍是依据角色和分层结构来组织团队,而非业务上的最终交付物(即产品或服务)。

Posted in 持续交付 | Tagged , , , | 2 Comments

《持续交付》封面上的故事——福斯铁路桥

不知道有多少人把《持续交付》一书的前言看全了。最后一部分讲的是福斯铁路桥(本站Logo上的这座美丽的桥),并把它和软件做类比。现摘录如下: 福斯铁路桥是英国第一座使用钢铁建造的大桥。其钢铁使用最新的西门子马丁平炉工艺制造,并由在苏格兰的两个钢铁厂和威尔士的一个钢铁厂交付。钢铁是以管状桁架的形式运送的,这是英国首次使用大规模生产的零部件组装桥梁。与早期的桥梁不同,设计师John Fowler爵士,Benjamin Baker爵士和Allan Stewart计算了建筑压发生率,以便减少后续的维护成本,并计算了风压和温度对结构的影响,而这很像软件开发中的功能需求和非功能需求。他们还监督了桥梁建设,以确保这些要求都能得到满足。 当时有4600名工人参与建造该桥,其中不幸死亡约一百人,致残数百人。然而它仍是工业革命的一个奇迹,因为1890年建成时,它是世界上最长的桥,而到了21世纪初,它仍是世界第二长的悬臂大桥。就像长生命周期的软件项目一样,这座桥需要持续维护。这已在设计时考虑到了,大桥配套工程中不但有一个维护车间和场地,而且在Dalmeny车站还有一个50个房间的铁路“聚居点”。据估计,该桥的使用寿命还有一百多年。

Posted in 持续交付 | Tagged , | Leave a comment

《持续交付》中文版已上架销售,欢迎对译文进行意见反馈。

《持续交付》中文版已于2011年10月17日上架销售。 该书由Jez Humble 和 Dave Farley历时三年完成, Martin Fowler为该书作序,并称其为“2010年最重要的持续书籍”, 同时,在2011年8月获得 “Jolt 杰出奖”。 从下面网站均可购得: 中国互动出版网 当当网 卓越亚马逊 如果您在书中发现有些地方翻译欠妥,您有多种渠道反馈建议。 请在下面直接回复即可。内容包括:问题所在页号、原文句子,以及您的建议。 点击这里,进入图灵社区的《持续交付》专栏勘误。 直接邮件给译者,邮箱是:qiaoliang.email@gmail.com 谢谢!  

Posted in 持续交付 | Tagged , , | 2 Comments

持续交付成熟度模型更新,新版本v1.2发布

《持续交付》一书中提供的“持续交付成熟度模型”是1.0版本。 这是经过再次调整的改进版,更具有指导性和可操作性。 使用说明: 建议使用该模型进行现状分析,发现改进点,不建议将其作为绩效衡量的标准。 一、七个维度 它们分别是: 1. 持续集成(Continuous Integration) 2. 环境与部署(Environments and Deployments) 3. 可视化与可追踪性(Visibility and Traceability) 4. 测试(Testing) 5. 数据管理(Data Management) 6. 配置管理(Configuration Management) 7. 组织协调性(Organisational Alignment) 二、每个维度又分成五个级别,它们分别是: 一级:阻碍级(Regressive) 二级:可重复级(Repeatable) 三级:可定义级 四级:可定量级(Quantitatively managed) 五级:优化级(Optimizing) 其中,持续集成维度的五个级别分别是: 一级:阻碍级(Regressive) 1. 软件的构建过程是手工的。 2. … Continue reading

Posted in 持续交付 | Tagged , , , , , | 2 Comments

《走向持续交付》,AgileChina2011上的演讲

The way to continuous delivery View more presentations from Tony Qiao

Posted in 持续交付 | Tagged , , , | 1 Comment

主干开发,“关上”未完成的功能

软件开发中,“配置开关”根本算不上是一个“新”概念。无论是通过启动时加载配置,还是应用程序运行时动态刷新配置,都可以用来决定或改变应用程序的某种具体行为。比如: 通过配置文件,使用应用程序连接不同的数据库 通过模板配置,达到应用程序“换肤”的目的 通过系统管理员的配置,使不同的用户具有不同的权限 所有这些“开关”都被认为是理所当然的,因为用户的需求就是这样的,“我需要通过xx开关来控制yy”。因此,做为交付团队,也会老老实实地把这些需求实现了。 然而,现在的很多团队,为了能够尽早发布软件,使用主干开发方式,并在程序中加入了另外一种“对用户透明”的开关。这种开关通常有两种使用场景是: 某些高级(或创新)的特性已经开发完毕,但业务人员根据市场情况,认为不需要投放市场。 市场需要某些已开发完成的特性,但还有一些特性尚未完成,仍旧处于开发中。 无论哪种情况,都是要求将某些特性进行隐藏后再发布。这种开关常常被认为是不可取的,但现在很多需要“持续交付”的公司都在使用。 (有的同学会说:“这完全可以通过按特性拉分支的方式来解决”。关于这个问题,我会在下一篇中讨论,本次仅限于讨论在使用“主干开发”的情况下,如何正确使用开关。) 开关最容易的地方就是应用程序的用户界面。当为已上线的应用程序重新设计了全新交互界面后,团队无法在一次性在同一发布周期中将其修改完成时,可以 先保留原有页面不变,同时每次仅替换少数的新页面。令所有未开发完成的页面对用户不可见,例如:原有页面的URL是 http://xx.xx.xx.xx/create_user,那么对应的新页面使用http://xx.xx.xx.xx/new_UI /create_user(要对后台逻辑的修改应能够同时响应新旧两个页面的请求)。当新页面完成后,将原来创建用户的页面链接重新指向新页面就可以了。 这样,就能在不破坏原有功能的前提下,做到持续发布。 开关实现形式 另外,对于那些无法在一个发布周期内实现的新功能,我们可以使用下面形式的“开关”: 配置文件,通常在启动时加载 <features> <feature name=”hq.remote_panel_load” /> <feature name=”el.enable_asset_library” /> …etc… </features> 在代码中实现 public function isFeatureOn(featureName:String):Boolean { var nodes:XMLList = xml.features.feature. (@name==featureName); return null != … Continue reading

Posted in 持续交付 | Tagged , | Leave a comment

ControlTier,基于命令的自动化部署工具

现在,服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”,尤其是“持续交付”实践时,在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境(包括功能测试和非功能测试)、试运行环境和生产环境。而且,每种环境可能会有多套实例,而不只是一套实例。 曾经接触过的一个团队,其持续集成环境中就有260+台服务器,随着开发人员的提交,不同版本的应用程序在这些服务器上一遍又一遍地被部署、测试、卸载。而且,这些服务器的作用各不相同,有的是web服务器,有的是应用服务器,还有数据库服务器,也许还有消息服务器等等。想象一下,如果由你来管理这样一个团队中的服务器集群的部署,你的状态会是什么样子? 其实,当面对这么庞大的集群时,关键问题不仅在于知道每一步怎么做,而是:如何能够在所有的服务器上能够让所有的步骤都能够正确地被执行,而且要按照你期望的顺序,不至于各节点的执行步骤间互相受到影响。 其实,已经有很多工具解决这类问题了,ControlTier就是其中之一。它是一个跨平台软件系统,用于在多个服务节点中管理应用程序的相关操作。 它既有命令行工具,又有Web管理界面。用户可以自定义命令组,并重用它们。它与Puppet的一个区别在于:ControlTier是基于“对目标进行操作(Activity)”的工具,而Puppet则是基于“定义目标状态”的工具。所以,Puppet的“部署幂等性”在ControlTier里是很难办到的。它们在这一点上的区别也决定了它们使用层次上的不同。在《持续交付》的“环境管理”章节中,说环境配置管理的层次如下图所示: 而它们所服务的位置如下: 当然,你完全可以在系统层使用ControlTier,也完全可以在应用层使用Puppet,但是它们有各自的专长,在其它层次上使用意味着需要的定制工作量稍多一些而已。 你还等什么,赶快使用这些工具,去打造你的完美“持续交付”环境吧!   本文版权归作者乔梁所有,转载请包含作者签名和出处,不得用于商业用途,作者将保留“追究法律责任”的权利!

Posted in 持续交付 | Tagged , , , , | Leave a comment