Tag Archives: casestudy

苹果的持续交付

最近,在持续交付和精益创业的相关讨论中,经常提到苹果公司的例子。比如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

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

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

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

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

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

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