Etsy(一个手工制品交易平台)的持续部署

  • Etsy每天向生产环境部署25到50次;
  • 他们为其支付系统构建一个符合PCI-DSS(支付卡行业数据信息安全标准)的环境;
  • 责任分离并不是指:大家互相之间不能交流。事实上,协作是有效风险管理的最关键元素之一。所以在PCI环境中,每个人仍要遵循devops原则——团队并没有物理分隔;
  • 在支付环境中,他们要遵守规则:“开发人员不能接触生产环境的数据库”。但,DBA就坐在旁边,可以及时帮助他们,并可以通过图形方式展示一些数据库中的度量项;
  • 在PCI环境中,他们使用与非non-PCI环境相似的部署过程。不过,会加入更多的日志信息,来记录谁在什么时间做了什么,并且有专门的角色做QA环境和生产环境的发布人;
  • 在PCI环境上,开发人员可以运行大部分的测试框架,并且可以通过Splunk以只读方式查看生产系统的日志;
  • 他们有一个ticketing系统,所有的变更都需要经过这个系统。然而,因业务需要,他们从开发环境到生产环境的变更部署过程只需要不到一个小时,但所走的流程是与非紧急变更管理流程一样的;
  • 最后的建议:“确保找到合适的团队人选,并意识到,在现实中的确有一些约束条件”。然而,只要积极地合作,即便在一个对安全性有非常严格要求的环境中,仍旧可以持续交付产品。
Posted in 持续交付 | Tagged , , | Leave a comment

IMVU如何在实施持续部署的同时确保软件质量

本文是IMVU(一个社交网络公司)在32个月之前发表在他们的技术博客上。你可能会羡慕这种发布状态(每次代码修改在20分钟内就可以部署到生产线,而每天部署50次),以及他们如此强大的工具和基础设施。然而,你看到的只是结果,而背后却是他们坚持的理念——“持续交付、持续学习”的精益创业开发理念;以及在这一理念支持下,大量艰苦的工作。那么,这些工作都包括哪些内容呢?详情如下。

---------------------------------------

我们公司有时也会由于某个特性抢速度上线而对顾客造成一些负面影响,但是这些负面影响也是我们得到教训的一个来源。有时,我们做的特性对于顾客没有什么价值,有时也会在生产环境中引入一些回归问题或是新的缺陷。

然而,有的时候,对于我们小心翼翼做出来的一些特性,客户也并不买账——可这的确消耗了我们很多精力,因为我们要花了更多的时间来研究、学习和调整方向。举一个例子吧:我们曾用 一个月的时间开发完了一个叫做“更新”的特性——有点像Facebook的“Friend feed”(朋友新鲜事),而用户对这个特性的反应和我们预想的完全不同。这表明,我们花了很长时间却交付了一个没人要的功能,而导致的结果就是:这延迟了另一个更加重要的特性(群组特性)的交付。

Continue reading

Posted in 公司案例 | Tagged , , , | 1 Comment

为什么软件开发方法论让你觉得糟糕?

围绕软件开发实践和方法论,总有很多教条式的口水仗。阶段式(phase-gate)方法能够有效管理软件开发过程的风险,还是说只是风险管理中的花哨噱 头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说,虽然缺乏证据判断这些论调的谬处,但有两条常用的法则能够帮助我们选择好的实践,同时,提升我们所提供软件的价值:划小开发周期以及提升反馈效率

Michael Feathers给出了以下观点:

我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实并非如些。

问题是,我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭,这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁钝,并导致低质量软件出 现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式,招聘好的人才,是一门(招聘)艺术,而非(招聘)工程。 Continue reading

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

利用“抽象分支”做增量式大规模软件改造

很多开发团队通常严重依赖于版本控制系统的分支功能。分布式版本控制系统让分支操作更加方便。然而,在《持续交付》一书中描述的很多非常规言论中,就有一条是:“使用分支,你就无法做持续集成”。根据定义,如果你有代码在某个分支上,那就没有集成。有一种很常见的情况,会让人很自然地想到利用版本控制工具的分支功能:那就是“对应用程序进行大规模改造时”。然而,还有一种替代这种真实分支的做法,技术上叫做“抽象分支(Branch by Abstraction)”。

抽象分支:在主干上进行以增量方式对软件进行大规模改造的一种模式。

Paul Hammant在2007年就提到过用这种方式把OR mapping的方案从Hibernate切换到iBatis(详见这里)。同样,我曾经工作的一款商业产品(持续集成与敏捷发布管理平台 Go)则从iBatis改到了Hibernate,这已经是两年前做的事情了。我们也把产品的UI层慢慢地从“使用Velocity和JsTemplate”转移到了“JRuby on Rails”上。

这两种变化都是慢慢地增量式地完成的,在改变的同时,也做新功能的开发,但这并不妨碍我们每天向Mercurail的版本库主干上提交数次代码,甚至在切换过程中做了数次正式发布。我们是如何做到的呢? Continue reading

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

IMVU持续监控:数千台服务器上应用系统的实时分析

IMVU是国外一家游戏社交网络公司,《精益创业》作者是其创建者之一。我在2011年由InfoQ组织的QCon大会上分享的《持续交付》相关话题中介绍过该公司的情况。那时该公司只有不到40名工程师,每天部署50次。在部署前需要运行一个很大的单元测试集合,总运行时间为15~20分钟(当然是分布式执行,而不是在一台机器上啦)。一旦通过,即可部署到生产环境中。当然,这么做有一个前提是有一个强大的监控系统,他们把它叫做“免疫系统”。下面就是这个免疫系统的升级过程介绍,以及他们开源出来的监控工具istatd

Continue reading

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

苹果的持续交付

最近,在持续交付和精益创业的相关讨论中,经常提到苹果公司的例子。比如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电脑的发布那样, 成为广告史上最壮观的场面之一。

’1984′ commercial for the launch of the Macintosh


1 有一个更现实的例子,看一下惠普激光打印机的firmware团队如何转到持续交付模式的,包括提交到主干进行持续集成,使用真正的逻辑板来运行自动化功能测试,以验证算法和时间计算。

 

原文来自这里

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

持续交付:价值主张​

过去十年中,一个划时代的改变就是:基于Web的业务模式对传统企业业务模式的冲击。亚马逊就是历史最长,也最明显的例子之一,而越来越多的公司(从航空到金融服务)开始依赖软件打造其竞争优势了。

​依靠软件来运行的业务有两个关键组件:一是你想如何改变世界的愿景,二是尽早收集用户的反馈。精益创业运动特别强调反馈的重要性,这不仅仅体现在创业公司。像亚马逊、NetFlix、和脸谱这样的公司也持续不断地对其网站进行小步改进,从而增加收入,并改善网站用户的体验。

​什么是持续交付?

想在用户与项目团队(包括客户或者Product Owner)之间建立紧密的反馈环,依赖于你是否有这样的能力,即:通过持续交付新的软件版本,验证新的想法和软件的改动,并能衡量这些改动对收入的影响。

对于很多需要几个月时间才能发布新版本的公司来说,在一天之内发布数次似乎是天方夜谭。然而,遵循《持续交付》一书中的原则与实践,一些原来一年才能发布几次新版本的公司,也已经能在一个月内发布数次,或者更频繁了。这是一种巨大的竞争优势,而且意味着,在时间和精力方面减少了大量的浪费。

实际上,持续交付有两个至关重要的业务收益:

  • 第一,它让你能更快地验证新业务方案的结果,并根据真实的用户反馈进行调整。尤其是当业务方案有根本性缺陷时,你一定希望能尽早地发现,而不是花数月或数年的时间和大量的金钱来实施计划后,才知道存在问题。
  • 第二,与项目结束后的一次性大版本发布相比,它能提供一种大幅降低交付风险的交付流程,而且成本的投入也更加具有可预见性。

另外,对于IT管理来说,它还提供另外两种好处:

  • 第一,项目经理们能看到项目的真实进度,因为,此时的“完成”是指:运行于真实生产环境中的可工作的软件已经为用户带来价值。
  • 第二,通过规律性增量发布,大大减少了每次发布的风险。

实现持续交付

为了能够成功实现持续交付,需要依赖于两个基础,一是技术基础,二是组织基础。而这两个基础有三大支柱:(1)全面的配置管理;(2)敏捷测试;(3)部署流水线。

配置管理:

就配置管理而言,为了实现持续交付,有四个关键点:

  • 第一,要能以全自动化的方式,构建、测试并部署你的应用。为了做到这一点,源代码、测试脚本、构建与部署脚本、数据库迁移脚本等统统要纳入到版本管理。
  • 第二,应用程序的部署时及运行时配置项需要以某种统一且集中地方式管理起来。
  • 第三,要能用全自动化的流程在每种环境上创建或者进行配置变更。
  • 第四,所有的开发工作必须在主干上完成,而且,能够对较大的特性或重构做增量实现,以便应用程序一直保持在可工作状态。如果必要的话,没有开发完的特性可以利用配置开关,使用户无法通过界面或公共接口使用它。

同时,有效的配置及发布管理也依赖于整个交付过程中开发团队与运维团队(包括DBA)之间的紧密合作。为了确保运维需求被纳入项目考虑范围,并让应用程序在开发初期就能部署到类生产环境中进行单一功能或跨功能测试,运维人员应在项目开始阶段就成为交付团队的一员。这种协作也正是DevOps运动所倡导的重要的文化转变之一。

敏捷测试

持续交付依赖的第二个支柱是敏捷测试方式。当然,它也同样包含技术和组织两方面。从工程角度来看,各个层次上的自动化测试是必不可少的,包括单元级别、组件级别,系统级别(功能与非功能测试)。要确保做到:如果自动化组合套件全部成功通过了,那软件本身就达到了可发布质量,即:在生产环境中没有回归缺陷,满足业务需要——包括容量和可用性方面的要求。

敏捷测试要求在整个交付过程中的质量内嵌。也就是说,测试不再是一个“阶段”,而应该是在整个交付过程中持续发生的一种活动。同样,软件的质量不再只是测试人 员或QA的责任,而是整个交付团队的责任。测试人员与分析人员应该在一起,共同创建可测试的验收条件。作为开发过程的一部分,测试人员与开发人员应该合作创建自动化的验收测试,用于验证所开发的内容满足验证标准,这叫做“验证测试驱动的开发(acceptance test-driven development)。开发人员要负责维护验收测试,并确保它们一直可以成功通过。

部署流水线

持续交付的第三个支柱是部署流水线。从本质上讲,部署流水线是现有交付过程的一个模型,是整个价值流的一部分,即从提交到发布的那一段价值流。可以用像Go这 样的工具对其进行建模。对于应用程序的任何修改(包括配置)都要从头到尾通过这个部署流水线,即先对系统进行构建,并基于该构建产物运行自动化测试,然后放到某处,以便后续部署到测试环境和生产环境。可以把部署流水线看做是持续集成的一个延伸,即:它将持续集成从开发团队扩展到了测试和运维团队。

用来建模和管理部署流水线的工具会记录每一次构建历史,它会记录每个构建所对应的版本控制库中的版本号,谁把它部署到了哪个环境,什么时候部署的,部署的结果是“成功”,还是“失败”。这个部署流水线应该强制你的部署工作流(包括认证和授权),并能对整个交付流程进行审计。由于这个流水线是对你的开发及部署过程进行建模,所以,它为发现流程瓶颈,持续改进交付过程提供了丰富的数据支持。

通过持续交付来管理项目

毫无疑问,对于刚刚接触持续交付的团队来说,对其所要求的纪律性会感到吃惊。很多直觉上应该如何管理项目的方式(包括团队成员之间如何互动)都需要改变。对团队来说,当实施持续交付时,和所有的敏捷方法一样,最重要的事情是通过回顾,持续反省他们正在做的事情,并对工作方式和过程做增量式的改变,并不断地改进它。

重新调整你的直觉

每个项目天生都有一种节奏和风格。传统的交付项目在项目开始和中期,总会有一个漂亮而体面的进度报告。然而,当到了某个时间点后,客户和管理层常常会有一些令其不悦的发现:尽管大部分内容都“开发完成”了,但在集成阶段,部署到具有现实负载的类生产环境中的应用程序总是不能工作得很好。

此时,这个项目就进行了所谓的“两难境地”,或叫“死亡行军”,人们在很大的压力上加班工作,试图修复整个系统。这令每个人都极不满意,而事实上, 在某些领域,这种失控模式已经成为一种家常便饭。

在那些实践持续交付的项目中,开始时进展可能比较慢。因为项目一开始要建立基础设施,对构建、测试和部署做自动化,并在得到成功构建的产品后,在类生产环境中执行验收测试。这让团队成员,尤其是刚接触它的管理者,感到不舒服。然而,这正说明它起作用了。持续交付的影响表现在它把痛苦提前了,从而让交付过程更加平稳、真实且可度量。

你原来体会到的是“开发完成“,与“真正完成”不一样。现实中,真正的“完成”是指发布给用户,或者至少在集成环境上严格地进行验收和回归测试后,在类生产环境中向客户演示。在新功能开发完后,其实还有很多工作要做:交付过程中的这部分被叫做最后一哩。持续交付坚持认为:“只有过了这一哩”,工作才算完成,根本就没有“完成了百分之五十”这个说法,所以,这让整个交付进度看上去比较慢。​

然 而,通过持续交付,你能得到可持续性。首先,因为持续交付意味着软件一直处于可发布状态,所以可以把原来的测试与集成阶段移掉,这就会大大降低项目风险。在这两个阶段,经常会发现严重问题,甚至是整个架构的缺陷。而修复这些问题的时间则很难预期。通过持续交付,这些问题在交付过程的早期就会被发现,些修复成本往往比较低。

​其次,对于新开发的特性来说,能更快地从客户和用户那里得到反馈。通过增量开发和持续发布给用户,你能在特性创作过程中就得到早期反馈,并不断调整。这样,软件的演进可以更快速地满足用户的需求。

设法进行增量开发

在主干上增量开发时,为了能够将大的特性拆分成小的、有价值的、可测试且相对独立的用户故事,需要分析人员、测试人员及开发团队的紧密合作。这么做,有几个好处。

可能最重要的好处就是,它促使团队将一个功能里,关键的部分和非关键部分区分开来,这让客户能在更小的粒度上做决策。将一个“必须做”的特性分解成多个小的、可增量开发的小需求,能更有效地区分出哪些是该功能的核心,哪些是外围需求。

然后,你可以将功能的核心部分(最初的最直接的实现)给用户进行测试,并找出用户接下来想做什么。这样可以给客户一些具体的数据,让他们更好地对该功能的剩余工作进行优先级的排序。当然,也很可能在他们看过以后,客户希望将后续的时间花在其它功能上了。而且,假如客户看过以后。认为这个特性没有什么价值,你可以马上停下来,不再浪费精力在这上面了。

增量开发依赖于每个人每天都能够提交一次,这样,应用程序才可以持续集成。对于那些习惯于在长生命周期分支上开发新特性或每个分支对应一类客户的团队来说,这看上去是不可能的。好消息是,在主干上开发是可行的,对于很大的团队也是可行的。坏消息是,它要求应用程序由松耦合的组件构成,并有良好的架构。它还要求,可以通过配置项在UI上能控制特性的开与关,这样,你才能可以灵活地控制,当功能准备好后,再打开开关。即使一些新功能只开发到一半,你也能持续地发布你的软件。

然而,这样做的收益也很大:你能持续不断地把已经做好的功能交付给客户,而不用绞尽脑汁地猜测哪个功能有价值。频繁地发布有价值的新功能是提高收入的 最好方式。

我怎么知道我是不是真的在持续交付?

持续交付是否需要一个像“Nokia 测试”那样的checklist呢?实际上,没有那个必要,因为有一个非常简单的方法来验证,你是不是真的在持续交付:你的软件是不是一直处于产品可发布状态。你只要按个回车键就可以把 它发布给用户。如果你的发布过程很痛苦,而且不太频繁,并且在发布之前还有一个充满风险的集成阶段,那么你就没有在做持续交付。

持续交付中最重要的度量是周期时间(cycle time):从决定实现某个想法开始,到将其发布给用户为止这段时间长度。有几个原因让它成为一个很重要的度量:

  • 第一,这是一个全局度量指标,用于度量整个过程的有效性。
  • 第二,这是一个团队度量指标,而不是一个个人度量指标——只整个团队关注于改进交付过程,才有可能改变周期时间。

部署流水线提供了部分答案:部署流水线的实现会给你提供一些你需要的数据,主要是从提交到发布这段时间的。那么,只要你有一种方式将提交与特性关联起来,你就可以看到某个特性的周期时间。如果现在的工具不能让你收集这些数据,那就找一个去吧。

这样,你就可以制定一个持续改进流程,应用约束理念 ,或者使用看板,在交付过程中找到瓶颈,并想办法移除它们。持续交付可以也应该同样使用持续改进的方式减少成本,提高收入的增量地方式实现。

 

原文刊登于InfoIT

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

剖析“持续交付”:五个核心实践

原文发表于 InformIT

持续交付 是一种软件开发策略,用于优化软件交付流程,以尽快得到高质量、有价值的软件。这种方法让你能更快地验证业务想法,通过直接在用户那里进行试验,做到快速迭代。 尽管《持续交付》一书主要讲的是工程实践,但持续交付的概念对整个产品交付过程都有重大意义,包括对特性的”fuzzy front end”、设计和分析的意义。

持续交付的一般性原则如下:

与其设计一大堆特性,再策划一个持续数月的版本发布,不如持续不断地尝试新想法,并独立发布给用户。通过充分思考,即便很大的特性或者大范围的变更,也能够通过一系列小步骤得到更快反馈,而且一旦你认为有必要停下来的话,可以随时停下来。利用 跨功能团队 在几小时或几天内交付这些小且增量式的功能,就能比竞争者有更多的创新,将投资回报最大化。

持续交付五个关键实践,为你建立一个从猜测到持续反馈的最有效途径,它们就是:

  • 从最小可行产品(MVP)开始——Start with a minimum viable product
  • 衡量新特性的价值——Measure the value of your features.
  • 做恰好充分的预先分析——Perform just enough analysis up front.
  • 少做——Do less.
  • 用户故事中要包括特性开关——Include feature toggles in your stories.

Continue reading

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

为什么要做持续部署?

本文是《Lean Startup》一书的作者Eric 在2009年发表的一篇博文,他是IMVU的创始人之一。文中没有讨论如何做持续部署,而是讨论了一个更关键的问题:“IMVU为什么要做持续部署?”这也充分地表达了他关于“Learning from production and customer”的观点。

----------------------------------------

在我所倡导的Lean Startup所有实践中,没有哪个实践比持续部署更有争议(持续部署是指:让公司在几分钟内发布软件的过程,而不是几天或几个月才发布一次)。我之前所在的一个创业公司IMVU使用这个流程,平均每天部署50次。这也引发了一些争论,有些人说:这种快速发布流程会导致低质量的软件,或者阻碍公司的创新。假如我们能够接受由客户来评判,而不是专家的判定,那么,我想这些说法就很容易消散了。一个更为常见,且更为困难的问题是:如何回答那些只想知道这种持续部署是否可以用于他们自己的业务、行业或团队的人们。 Continue reading

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

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

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

Continue reading

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