Tag Archives: 交付原则

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

本文是IMVU(一个社交网络公司)在32个月之前发表在他们的技术博客上。你可能会羡慕这种发布状态(每次代码修改在20分钟内就可以部署到生产线,而每天部署50次),以及他们如此强大的工具和基础设施。然而,你看到的只是结果,而背后却是他们坚持的理念——“持续交付、持续学习”的精益创业开发理念;以及在这一理念支持下,大量艰苦的工作。那么,这些工作都包括哪些内容呢?详情如下。 --------------------------------------- 我们公司有时也会由于某个特性抢速度上线而对顾客造成一些负面影响,但是这些负面影响也是我们得到教训的一个来源。有时,我们做的特性对于顾客没有什么价值,有时也会在生产环境中引入一些回归问题或是新的缺陷。 然而,有的时候,对于我们小心翼翼做出来的一些特性,客户也并不买账——可这的确消耗了我们很多精力,因为我们要花了更多的时间来研究、学习和调整方向。举一个例子吧:我们曾用 一个月的时间开发完了一个叫做“更新”的特性——有点像Facebook的“Friend feed”(朋友新鲜事),而用户对这个特性的反应和我们预想的完全不同。这表明,我们花了很长时间却交付了一个没人要的功能,而导致的结果就是:这延迟了另一个更加重要的特性(群组特性)的交付。

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

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

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

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

持续集成案例分析系列(1)——大规模项目团队持续集成历程

这篇文章是我在两年前写的,记录了一个150+人的软件团队(最多时近200人)如何在一个庞大的遗留系统上,通过逐步建立一个持续交付部署流水线,从而达到频繁发布的状态。最终在该团队的持续交付基础设施中,共有260台服务器用于构建、测试和部署(几乎全部是虚拟机)。而这个产品也可以每六周发布一次。

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

持续交付的8条原则

软件的发布或部署过程必须是可重复且可靠的。这就引出了下一条… 所有操作的自动化!我很难相信“手工操作是可重复且可靠的”这种说法。所以一定要将所有重复性的操作变成自动化的,从而变得可靠。 如果某件事情做起来很困难或者让你觉得很痛苦,那么就尽早且尽可能频繁地去做。乍一看上去,这么做太蠢了,因为人的直觉反应是:应该推迟这件事。然而,实际上,这句话是说:如果做某件事很痛苦,一旦要求自己更频繁地做,你就会有动力想出各种办法,来解决这个痛苦,很可能把它变成了自动化的,最终会把它变成一件简单容易的事情。就拿更新数据库结构来说吧。一般来说,没人想频繁地修改它,所以就会尽可能推迟或少做,比如一个月做一次更新,或者更长。然而,你真正需要做的却是改进数据库结构调整的流程,让它变成更容易,更频繁。甚至如果必要的话,可以一天做一次。 对所有内容进行版本控制。当今软件行业还在强调这种要求,你可能会觉得奇怪,谁现在还没有用版本控制呢?但是,我指的不仅仅是源代码哟,还包括环境、配置、数据等等。 完成意味着“已发布”。也就是说,项目的“完成”是指把它交到用户手中,并且可以正常工作。而不是“我已经提交了,后面的我不管了”,或者“我已经提测啦”,或者“我测试完了,没有问题。” 内建质量。在质量度量方面花一点儿精力。从长期维护的角度来讲,具有良好质量度量目标的项目(如单元测试覆盖、代码风格、复杂度等等) 要比没有这些度量的项目更容易一些。 每个人都要对交付过程负责。在开发人员机器上运行的程序不会为公司带来收益。没有部署的项目也一样。开发人员也应该时刻想着如何部署手中的软件。项目经理也应该关注什么时间部署。测试人员也应该进行部署测试。 持续改进。软件开发如“逆水行舟”,不进则退。持续改进意味着,你的系统需要一直改进,这样当需要时,才能很容易修改。 原文:http://www.dzone.com/links/r/the_8_principles_of_continuous_delivery.html

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