为什么要做持续部署?

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

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

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

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

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

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

Continue reading

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

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

——持续交付与跨功能团队

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

Continue reading

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

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

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

Continue reading

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

用veewee创建vagrant的虚拟机

感谢larrycai的投稿。
原文链接:https://github.com/larrycai/blog/blob/master/cn/veewee_create_vm.mkd

简介

虚拟机有很多好处,不仅仅节省硬件资源,而且还可以快速切换系统环境,会在软件开发中起到极大作用。

上一篇vagrant和jenkins的文章中我们说到了vagrant这个工具,你必须要先有一个盒子:vagrant box,它是vagrant对virtualbox虚拟机的进一步封装。将virtualbox虚拟机转变成vagrant的盒子有点麻烦,可以参见vagrant的说明,所以,大家都是找一个现成的盒子来用。

但是,没有更好的办法了吗?现在网络的开放精神真是强大,你能想到的一般都存在了,它就是我要介绍的veewee,它的功能就是从你的ISO光盘开始,准备好你需要的vagrant虚拟机(盒子)。

Continue reading

Posted in Tools | Tagged , , , | 1 Comment

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

不知道有多少人把《持续交付》一书的前言看全了。最后一部分讲的是福斯铁路桥(本站Logo上的这座美丽的桥),并把它和软件做类比。现摘录如下:

福斯铁路桥是英国第一座使用钢铁建造的大桥。其钢铁使用最新的西门子马丁平炉工艺制造,并由在苏格兰的两个钢铁厂和威尔士的一个钢铁厂交付。钢铁是以管状桁架的形式运送的,这是英国首次使用大规模生产的零部件组装桥梁。与早期的桥梁不同,设计师John Fowler爵士,Benjamin Baker爵士和Allan Stewart计算了建筑压发生率,以便减少后续的维护成本,并计算了风压和温度对结构的影响,而这很像软件开发中的功能需求和非功能需求。他们还监督了桥梁建设,以确保这些要求都能得到满足。

当时有4600名工人参与建造该桥,其中不幸死亡约一百人,致残数百人。然而它仍是工业革命的一个奇迹,因为1890年建成时,它是世界上最长的桥,而到了21世纪初,它仍是世界第二长的悬臂大桥。就像长生命周期的软件项目一样,这座桥需要持续维护。这已在设计时考虑到了,大桥配套工程中不但有一个维护车间和场地,而且在Dalmeny车站还有一个50个房间的铁路“聚居点”。据估计,该桥的使用寿命还有一百多年。

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

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

感谢larrycai投稿

简介

虚拟机有很多好处,不仅仅节省硬件资源,而且还可以快速切换系统环境,显然会在软件开发中起到极大作用。

在《持续交付》第十一章(11.7.1)中就提到了虚拟机环境的管理。如下图
持续交付 虚拟机创建环境它描述的是在你的持续集成的Jenkins CI服务器(以下简称jenkins)中,需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中,启动需要的各种类型虚拟机,而不是每个都重新安装(省时),完成测试,产生报告后,也快速消失(省钱)。

让我们一起来看看一种漂亮的实现方案vagrant+jenkins实现技巧。

Continue reading

Posted in Tools | Tagged , , , | 2 Comments

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

持续交付, continuous delivery《持续交付》中文版已于2011年10月17日上架销售。

该书由Jez Humble 和 Dave Farley历时三年完成,

Martin Fowler为该书作序,并称其为“2010年最重要的持续书籍”,

同时,在2011年8月获得 “Jolt 杰出奖”。

从下面网站均可购得:

如果您在书中发现有些地方翻译欠妥,您有多种渠道反馈建议。

  1. 请在下面直接回复即可。内容包括:问题所在页号、原文句子,以及您的建议。
  2. 点击这里,进入图灵社区的《持续交付》专栏勘误。
  3. 直接邮件给译者,邮箱是: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. 构建过程冗长,而且其中的主要步骤常常出错。

二级:可重复级(Repeatable)

1. 在开发人员的代码上进行定期的自动化构建和单元测试。
2. 利用自动化过程,能够从源控制中重新生成任意一个构建版本。
3. 开发人员的提交频率是不定的。

三级:已定义级

1. 每次提交都会触发构建和各类测试。
2. 公共工具集中的脚本或工件得到重用。

四级:可定量级(Quantitatively managed)

1. 构建数据度量项被收集,高度可视化,并执行相应的改进活动。
2. 构建失败不会没人管。所有团队成员至少每天提交一次。
3. 尽可能在最后时刻(即将发布时)才拉发布分支。

五级:优化级(Optimizing)

1. 随时可以从主干上拿到已全面集成且生产环境可部署的构建版本。
2. 关注点是:随着对代码质量信心不断提交,能够进行更加频繁的提交。

环境与部署的五个级别分别是:

一级:阻碍级(Regressive)

1. 手工准备环境,无适当方法管理环境冲突。
2. 手工部署软件。

二级:可重复级(Repeatable)

1. 环境已被定义,并可自动化地准备和控制。
2. 部署操作是手工和自动化相结合才能完成。

三级:可定义级

1. 开发和测试环境是全面自动化且自服务的。
2. 已具备 “点击按钮即可向任意环境进行部署”的能力。
3. 为了完成自己的工作,每个人都有相应权限访问并操作相应的环境。

四级:可定量级(Quantitatively managed)

1. 协调的部署管理。
2. 发布计划自动产生。
3. 对所有的失败进行根因分析。
4. 回滚流程被脚本化,并被管理起来。
5. 建立了环境和系统健康状态指示板(Dashboard),其上显示的数据被监控和报告。

五级:优化级(Optimizing)

1. 环境的准备是全自动化的。
2. 已具备根据需求快速重建完整环境和基础设施的能力。
3. 端到端的业务度量项被监控。

这里可以下载全部

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

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

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