Tag Archives: 最佳实践

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

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

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

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

围绕软件开发实践和方法论,总有很多教条式的口水仗。阶段式(phase-gate)方法能够有效管理软件开发过程的风险,还是说只是风险管理中的花哨噱 头?TDD真的能够促生出高品质软件?结对编程是代码评审的有效替代抑或只是增加了商议沟通代价?我想说,虽然缺乏证据判断这些论调的谬处,但有两条常用的法则能够帮助我们选择好的实践,同时,提升我们所提供软件的价值:划小开发周期以及提升反馈效率。 Michael Feathers给出了以下观点: 我认为,我们最终还是得倚重开发者的能力,这才是个更重要的考量因素,而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说,我们都清楚这点,但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申,要是人人都可以替代(随便找个人都能顶上),那该有多好呀?但事实并非如些。 问题是,我们怎样才能找到有(合适)技能的开发者?IT界从未很好地定义个体生产率,从这点来看,那么,要找到合适技能的开发者就是个很难解决的问题。代码行数(Lines of code) – 在现在仍然是一个主流的度量方法 – 深陷“一行代码一个责任”泥潭,这并不是一个好的方法。而度量工作小时数则是鼓励(个人)英雄式举动 – 经验表明,“英雄们”通常就是导致项目延期的人,依赖“英雄”往往是一开始就采取的不该采取的冒险行动,长时间工作导致人变得鲁钝,并导致低质量软件出 现。目前还没有被普遍接受的针对IT专业人才的专业要求系列标准和雇用范式,招聘好的人才,是一门(招聘)艺术,而非(招聘)工程。

Posted in 持续交付 | Tagged , , | 1 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.

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

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

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

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

使用vagrant+jenkins来管理虚拟机的技巧

感谢larrycai的投稿。 简介 虚拟机有很多好处,不仅仅节省硬件资源,而且还可以快速切换系统环境,显然会在软件开发中起到极大作用。 在《持续交付》第十一章(11.7.1)中就提到了虚拟机环境的管理。如下图 它描述的是在你的持续集成的Jenkins CI服务器(以下简称jenkins)中,需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中,启动需要的各种类型虚拟机,而不是每个都重新安装(省时),完成测试,产生报告后,也快速消失(省钱)。 让我们一起来看看一种漂亮的实现方案vagrant+jenkins实现技巧。

Posted in Tools | Tagged , , , | 2 Comments

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

《持续交付》中文版已于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

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

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

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

持续交付的8条原则

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

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

百度技术沙龙第16期演讲稿《持续交付的魅力》

持续交付的魅力  View more presentations from Tony Qiao.

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