闲亭信步（KISS）

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

目前，持续集成工具多达30种，每种工具都有自己的特点。在国内，软件企业很少为这类产品付费，所以国个目前最流行的包括Hudson（开源），CruiseControl（开源），TeamCity（商业版，买了IntellJ的License就能免费使用）。而在国外，还有两个比较流行的工具

百度技术沙龙演讲主题：持续交付的魅力——百度持续集成实践经验分享 演讲简介：百度从2009年引入敏捷，并结合自身情况，从项目管理、需求管理为起点。随着业务的发展，对研发效率的更高要求，自2010年起，在各产品线引入持续集成实践。众所周知，在引入敏捷的过

在过去多年的持续集成咨询经历中，最常听到的一个问题是：如何来评估企业在配置与发布管理方面做得到底怎么样？还需要在哪些地方进行改进或提高？两年前，CITCON的几个参与者给出了一个成熟度模型，主要关注于“持续集成实践”，而在《持续交付》一书中，Jez与Farley也结合Thou

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

详见这里。

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

软件开发中，“配置开关”根本算不上是一个“新”概念。无论是通过启动时加载配置，还是应用程序运行时动态刷新配置，都可以用来决定或改变应用程序的某种具体行为。比如：通过配置文件，使用应用程序连接不同的数据库通过模板配置，达到应用程序“换肤”的目的通过系统管理员的配置，使不同的

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

简介虚拟机有很多好处，不仅仅节省硬件资源，而且还可以快速切换系统环境，显然会在软件开发中起到极大作用。在《持续交付》第十一章（11.7.1）中就提到了虚拟机环境的管理。如下图它描述的是在你的持续集成的Jenkins CI服务器（以下简称jenkins）中，需要各种服务器来测试一个应用。我们可以快速的从虚拟机的VMM模板库中，启动需要的各种类型虚拟机，而不是每个都重新安装（省时），完成测

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

本文是《Lean Startup》一书的作者Eric 在2009年发表的一篇博文，他是IMVU的创始人之一。文中并没有讨论如何做持续部署，而是讨论了一个更关键的问题：“IMVU为什么要做持续部署？”这也充分地表达了他关于“Learning from production and customer”的观点。在我所倡导的Lean Startup所有实践中，没有哪个实践比持续部署更有争议（持续部署是

自2007年开始，我与Jez Humble一起，和来自四个国家的同事们开发了Cruise（ThoughtWorks Studios 开发的一款持续集成与发布管理工具，现在改名为Go）。该产品在两年内发布了8个版本，而且在V1.0中就引入了Pipeline的概念，而这正是《持续交付

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

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

前些日子写了关于小规模产品团队的持续集成实践，之后就一直就忙于项目，今天终于有时间完成这一篇关于大规模项目的持续集成相关问题了。 一、持续集成基础在典型的软件项目中，集成阶段一般都是在最后，因此也是出现问题最多，而且最有可能导致不能按时交付。而持续集成（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的团队为安全交易者提供在线交易系统。能够让新功能快速上线可以很大的提高他们的竞争力。然

 出差在外，没有及时更新Blog。继“构建”之后，今天再说一下企业持续集成成熟度模型的另一个维度“部署”。在正文之前，还想再强调一点，即“这个模型本身是是工具箱里的一件工具，并不一称个斤两的量器。”  部署 部署是指将软件移动到它被测试的地方，或用户指定的某个位置，准备送给客户。对于web应用来说，这可能意味着将软件安装到某个web服务器上，并更新数据库或静

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

今天收到yahoo group中极限编程组（extremeprogramming@yahoogroups.com）的一封求助信，大意是：“需要自动化构建和持续集成的收益数字，好让他们的VP能让他花上一段时间专门优化他们的构建脚本，以便将时间从3、4天缩短到12个小时。因为他们的单元测试运行时间太长，而且构建经常因为单元测试的失败而失败。”这也没什么可笑的，因为这种事在很多公司都常见，但是，当这