闲亭信步（KISS）

持续集成是敏捷最佳实践之一，但并不是只有使用敏捷方法的团队才能够采纳。但如果你能够采纳敏捷方法，那么它会发挥更大的作用。“什么是持续集成”在前面的文章中已谈过了，这里只把其中的一部分：持续集成的六个基本自动化再细说一下。这六个基本自动化是：自动运行测试、自动产生可部署的二进制文件，把它部署到类似生产环境中，自动标识你的代码基线，自动运行回归测试以及自动产生度量。一、运行测试 　　这本来是不必说的事

This manual deployment process was as follows.1. Logon to the ‘build box’2. Get latest3. Open visual studio and compile the application4. FTP the resulting app to a staging area on our product

自从去年开始，Cruise团队就坚持一周至少更新自己使用的Cruise服务器一次，更新其它团队使用的Cruise服务器一次。四个月前，我们又建了一个Personal build CI server，而这个server的部署频率更高，只要每次提交到团队持续集成服务器上后单元测试通过，Cruise就会将其自动部署到这个Server上。效果非常不错，因为这个持续集成服务器是每个开发人员做pre-comm

Martin Fowler 最近在用分布式版本控制工具（mercurial/GIT），并写了一篇博文，名为《特性分支》，主要讨论了使用分布式版本控制工具以后，可能的三种工作方式。（非常佩服Martin Fowler的总结能力。） 1. 堆积变更，推迟合并       在我看来，这种方式的确充分利用了DVCS的灵活性，但显然，不爱频繁提交的开发人员很可能一直发扬这个坏

前些日子写了关于小规模产品团队的持续集成实践，之后就一直就忙于项目，今天终于有时间完成这一篇关于大规模项目的持续集成相关问题了。 一、持续集成基础在典型的软件项目中，集成阶段一般都是在最后，因此也是出现问题最多，而且最有可能导致不能按时交付。而持续集成（XP十二实践之一）可以用来解决这个问题。既然大家都认为“频繁地使软件在某一代码基线构建并通过测试”是个不错的做法，那么

 在去年的AgileChina大会中，Jez Humble(Cruise的产品经理)提到了持续集成的成熟模型， 从低到高为：  1 自动化构建并持续编译(Automated build / continuous compilation)2 让单元测试自动化(Automated unit tests)3

一个多月前，收到一封来信，咨询一个持续集成的问题。内容是这样的：“我们目前的项目，用Selenium Grid跑一遍完整的测试，用10台服务器分布式跑，已经需要超过1个小时，本地根本无法跑过。这样的话，让开发人员在本地run完所有的test再提交，已经不可能了。你们是否碰到过类似的情况？是如何解决的？”很多人可能都在团队中实践了敏捷方法或精益方法，尽管有些团队会感到一些收效，但是达

持续集成已经是一个古老的话题了。有的公司跃跃欲试，有的公司浅尝则止，有的公司半路放弃，而有的公司去能持之以恒。这是什么原因呢？既然是一个古老的话题，那与它刚出现的时候相比，现在是否有了新的变化呢？受优快云之邀，本人将在软件开发2.0(SD2.0) 软件工程专场（本月23日上午9:00）和对此话题有兴趣的朋友一起探讨这一主题，题目

<!-- /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; m

 测试持续集成一直同自动化测试相关联。这在马丁福勒的文章或更早期Steven McConnell对日构建和冒烟测试的相关实践描述中都有提及。而且在企业持续集成的领域中，我们会考虑很多种类型的自动化测试和手工测试。尽管如些，很多团队在测试方面还是比较弱。很常见的一个版本发布场景就是：某个团队完成一个版本后，手工测试一下基本功能就发布了。而其中的某一部分总是出错，而新功能也只做了少量测

 报告——企业持续集成成熟度模型简介之四持续集成工具一直以来就负责报告最近一次构建的状态。报告是持续集成的一个至关重要的元素。在企业持续集成中，报告应包含所做软件的相关质量和内容方面的信息，以及与企业持续集成过程有关的度量信息。没有报告的团队就象一个没有雷达的飞机在飞行。如果没有人看测试结果的话，所有的测试都是无用的。同样，很多数据如果没有被提取成可消化利用的信息的话，

所有团队在四个维度都达到统一的企业持续集成成熟度是很困难的。企业持续集成在不同的条件和状态下，应该考虑选择不同的方向来实现或加强。为了表明这一点，下面是一个企业的例子，提供了企业持续集成混合成熟度的解决方法。Emeno 投资公司：平衡敏捷与控制现状分析： Emeno的团队为安全交易者提供在线交易系统。能够让新功能快速上线可以很大的提高他们的竞争力。然

1. Your Single Path to Production:From Point-and-Click Package Promotion to Integrity Assurance to Package Deployment and Redeployment to History and Traceability, you will find that once you us

有位童鞋问了这样一个问题："我现在的团队也面临这样的问题，更糟糕的是我们还没有测试套件。目前只是面临企业内网，马上也面临外网的应用了。痛苦。。。那个大侠给个好建议！"其实，文章中已经给出了答案，即一直保持“主干开发为主的短周期分支策略”。当然，很多团队无法达到这种境界。原因可能非常简单。比如，无法拒绝客户要求，否则就有可能失去重要客户。开发时的代码质量太差，当需要发布时，在分支上修复Bug的时间需要很长，而在主干上开发新功能时仍旧不注重质量。传统的瀑布开发方式使两次发布之间的时间间隔太长（每次发布都需要三个

为了吸引大家的注意力，我想说：“特性分支是邪恶的化身”。自2008年起，Mercurial (最近是Git)就成了我日常工作的工具，而且我喜欢使用分布式版本控制系统。正如《持续交付》一书中讨论的那样(英文版第393页和394页)，有很多理由说明，与之前已存在的同类工具相比，D

详见这里。

现在，服务器集群已经是司空见惯的事情了。随便一个小的互联网应用程序都需要用集群来支撑。而当采纳“持续集成”，尤其是“持续交付”实践时，在各种环境上的部署让你发疯。这些环境包括开发环境、测试环境（包括功能测试和非功能测试）、试运行环境和生产环境。而且，每种环境可能会有多套实例，而不

持续交付成熟度模型更新，新版本v1.2发布《持续交付》一书中提供的“持续交付成熟度模型”是1.0版本。这是经过再次调整的改进版，更具有指导性和可操作性。使用说明：建议使用该模型进行现状分析，发现改进点，不建议将其作为绩效衡量的标准。共有七个维度，它们分别是：

<!--v/:* {behavior:url(#default#VML);}o/:* {behavior:url(#default#VML);}w/:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}--> Normal 0 fal

什么是个人预提交（Personal build）?Personal build简单来说，就是开发人员在代码提交之前，先要自己在本地运行一次构建和测试代码，保证本地没有测试失败后，再将其提交到中央代码仓库。Personal build的痛处在哪里？“提交代码之前，必须在本地运行并通过单元测试”是敏捷团队的原则之一。而随着新功能的增加，我们的单元测试越来越多，运行时间当然也就越来越

以前没使用Nant和Nunit建立过C#代码的自动化构建，今天自己写了一个C#程序，想用Nant和Nunit构建C#代码。可写好build文件后运行UnitTest时遇到了麻烦。命令行提示如下：Could not load file or assembly nunit.framework, Version=2.4.3.0, Culture=neutral, PublicKeyToken=

Cruise是Thoughtworks即将发布的又一款产品，其适用领域为持续集成，是新一代的持续集成＆发布管理系统。具有以下特性：零配置的构建网格——安装Agent后，它们会自行更新和获取配置，然后自动检出所需构建的源代码进行构建。 集中管理工件——将应用软件包、测试结果和日志文件集中存放，你可以在同一处得到你所需要的信息和数据。端到端的安全性——Cruise支持LADP和活动目录，Agent与S

最近，优快云对Cruise（一款新的持续集成和部署管理系统）的产品经理Jez Humble进行了采访。其中提到了如下内容： 即将发布的Cruise 1.0版主要面向中小企业用户及大企业中的中小型团队。 引入“构建管道（pipeline）"的概念，使该工具覆盖了软件开发、构建和部署的全过程。 引入”构建网格（build grid）“的概念，使其具有很强的可伸缩性，

Cruise终于在今天(2008年7月28日)正式发布了。上星期六在Beijing OpenParty上讲了一个关于持续集成的Session，主要内容是持续集成在软件开发生命周期中的作用，同时谈到一个软件从测试完成到正式上线还有多少工作要做。应在座同学的要求，谈了一些Cruise的新特性。还是言归正传吧。一、Pipeline（构建管道）众所周知，Cruise引入了Pipeline的概念，但它到底是

概念篇已经介绍了Cruise中出现的新名词，今天就说一说Cruise的配置问题。由于Cruise几乎提供了所有平台的安装包，所以只要您了解各平台上安装软件的方法，您就可以轻而易举地完成Cruise的安装。现在，Cruise1.0的配置秉承开源项目CruiseControl的单一配置文件风格，但比CruiseControl要简单的多。而且在Cruise1.0中提供了简单的WEB界面编辑功能，尽管看上

优快云终于可以访问了。今天说说Cruise的安装与数据备份吧。你从这里注册一下，就可以下载Cruise，并会得到为期一个月的试用版License（最多6个Agents有效），一个月后，你可以申请有效期是一年的免费License（最多两个Agents有效）。Cruise可以安装在很多种操作系统上，而且Server和Agent可以安装在不同的操作系统上。Cruise官方提供了windows安装包(.

自动化测试是持续集成的前提毋庸置疑，自动化测试是持续集成的前提。如果您的项目还没有单元测试或功能测试代码，那么持续集成的意义就不那么重要了。只有随着项目的进行，不断增多的自动化测试，才能突显持续集成的重大意义。持续集成是代码健康状况的指示器或风向标。通过持续集成，可以尽早发现问题，提醒团队成员尽早修复问题，得到更健康的代码。持续集成有很多实践，通过实际项目的经历，总结三个基本实践：一、尽早开始持续

软件从需求到发布是一个漫长的过程。而持续集成关注于软件开发，即开发人员的每次代码提交都会由持续集成工具进行构建。但到这个构建版本后，到将其真正部署上线还要走多远呢？从持续集成那里拿到好的Build以后， 作为测试人员，部署到探索性测试（Exploratory Test）环境。 进行探索性测试。 根据具体的软件特性，部署到其它测试环境， 进行其它的

Cuise提供了一些Restful Url，方便用户来使用Cruise。目前这些Restful Url覆盖三个方面（一）关于Artifacts的操作　　例如查看某个job有哪些Artifacts，以及通过API下载这些Artifacts，向某个已完成的Job上传某些文件。（二）关于Properties的操作　　例如查看某个job有哪些属性，它们的值是什么，以及为某个job增加一个属

自2008年7月28日Thoughtworks公司推出Cruise1.0以后，收到了良好的用户反馈，并得到了很多的建设性的意见和建议。根据这些反馈和建议，在Cruise团队的努力下，Cruise1.1即将在2008年10月中下旬发布。新增加的特性包括：一、增加对两种SCM的支持　　　分别是Perforce和GIT(一种分布式SCM)。二、基于角色的安全机制　　　可以定义角色列表。三、对Stage的

今天花了很长时间才在Ubuntu7.10上安装好GIT 1.6.0.2。－－－最开始本不需要1.6，所以只用 sudo apt-get install git-core就把GIT1.5安装好。可以使用GIT://，SSH等方式。但后来需要HTTP的支持，1.5版本中不包含这个，所以开始漫长的升级之路。由于还没有哪个repository中有最新的1.6的package，所以只好用源文件来装了。1 在

Mercurial是一种开源的分布式版本控制工具，目前的最高版本是1.6.0.2。一、什么是分布式版本控制工具传 统的版本控制工具（如SVN，CVS，CleanCase等）因其将Code Repository的所有历史信息全部保存在同一台服务器上，而称为集中式版本控制工具。而在分布式版本控制系统（如Mercurial、GIT）中， Code Repository的历史信息的复本被保存在多台机器中，

Mercurial是什么？Mercurial是与GIT相似的一个分布式版本控制系统，但使用方法上与Subversion（一个比较流行的集中式版本控制系统）相似．如果你使用过Subversion，很容易迁移到Mercurial．如何在Ubuntu上安装Mercurial？sudo apt-get install python2.5sudo apt-get inst

Cruise提供将任何HTML文件作为一个子表单显示到Web页面上．我们每次在Build结束后就将EMMA的report放回到Cruise Server上，并将其作为WEB页面显示出来．如下图所示：在Cruise中的配置也很简单，如下如示：job>  ....  artifacts>        artifact src="target/emma" dest="analysis" />    a

Cruise是什么？为什么要构建Cruise？自Thoughtworks创建了CruiseControl(第一个开源持续集成服务器)近十年以来，我们的咨询师一直在帮助我们的客户进行持续集成的实践。经过十余年的积累，在构建及部署管理以及快速、高质量且低风险的交付与发布管理方面，我们积累并总结了很多理论原则与实践，而我们将这些理论原则与最佳实践溶为了一体，研发了Cruise（持续集成和发布管理

农历年前，李剑（InfoQ中文站的敏捷社区主编，就是小刀）提议写一些在实际的敏捷软件开发项目中的使用的实践及范例，于是决定将个人的实际项目和咨询经历总结一下。既然现在一直在做“持续集成与发布管理”这一领域的事情，就不再花时间去想题目啦，仅以持续集成为题，将自己在咨询过程中遇到的项目及情况加以总结。 信手拈来的当然就是自己所在的项目“Cruise”了。于是《“持续集成”也需要重构——持续集成

目前IT行业中，似乎“要不要做持续集成？”已经不再是讨论的焦点，取而代之的是“如何进行持续集成？”。在前一篇文章中，我介绍了Cruise团队持续集成的演进过程。在最后，还曾提及Cruise团队的持续部署。本文将结合团队的实际情况，与大家分享持续部署的实践心得。 “最后一哩”问题 持续集成解决了软件开发中的部分问题，但还有更为重要的一部分有待解决，即“通过什么样的方法，

本文已发表在 InfoQ中文站的《持续集成》专栏，关于“持续集成”和“持续交付”更多的文章、视频资源请访问“持续交付中文站”,http://www.continuousdelivery.info/index.php/resources/。在前文《软件自我识别》中，我们讨论了如果使软件做到自我识别，以促进自动化部署和版本检测等工作。 随着互联网的飞速发展，以及基础设施的改进，越来越多