持续交付的8条原则

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

原文:http://www.dzone.com/links/r/the_8_principles_of_continuous_delivery.html

选择持续集成工具需要考虑的几个因素

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

根据目前软件发展的特点,在选择持续集成工具时需要考虑如下几个方面(不包括金钱投入):

  1. 版本控制工具的支持。在你的企业中,使用哪种版本控制工具(Git, Hg,SVN,ClearCase等等)。
  2. 每个构建是否可以支持指定多个代码源URLs。
  3. 是否支持构建产物管理库。
  4. 是否支持部署流水线,类似于一个或多个构建完成后触发另一个构建。
  5. 是否支持并行构建。
  6. 是否支持构建网格,以及对网格内机器管理的能力。即,能否将多个构建同时分配到多个构建机器上执行,以提高执行速度。
  7. 是否有良好的开放API,比如触发构建API、结果查询API、标准的Report接口等等。
  8. 对于安全性来说,是否支持企业所用的安全机制,如LDAP等等。
  9. 是否有良好的Dashboard。
  10. 与构建工具(如Maven,Make,Rake,Nant等)和测试工具的集成。

另外,“有良好的开放API”是任何工具选择的重要标准。因为,自动化是持续集成的关键。如果一个工具只能通过一个Web界面来操作的话,那简直就是一个噩梦。

详细的工具及特性列表见这里

 

配置与发布管理成熟度模型1.0版

在过去多年的持续集成咨询经历中,最常听到的一个问题是:如何来评估企业在配置与发布管理方面做得到底怎么样?还需要在哪些地方进行改进或提高?

两年前,CITCON的几个参与者给出了一个持续集成成熟度模型,聚焦于“持续集成实践”,而在《持续交付》一书中,Jez与Farley也结合ThoughtWorks在这方面的实践经验,总结了“配置与发布管理成熟度模型”,并在多个项目中进行了实际应用,效果不错。

由于这是通用模型,所以各等级中多为定性描述,在拿到具体企业使用时,可以根据实际情况,对其中一些定性描述进行量化,比如“提交不频繁”“定期沟通”等。

如何使用这个成熟度模型呢?

  1. 找出你所在团队在各维度上所处的级别。
  2. 找出你所在团队需要改进的维度,以及在该维度上的改进目标。
  3. 根据目标与现状,制定改进行动计划并实施。
  4. 重新评估,再制定下一个目标。

任何流程都是可以改进的,所以没有最好,只有更好。所以最高一级是“持续优化”。

模型内容可从以下地址下载:

http://download.csdn.net/source/3454593

持续交付-追求软件卓越的必读书目

持续交付,Jez Humble著,乔梁译

被Martin Fowler誉为2010年软件业最重要的一本技术书籍《持续交付:Continuous Delievery》于去年10月份在发布第一版。该书由ThoughtWorks公司的资深咨询师Jez Humble与David Fawley所著,可以说是该领域数年的经验总结。

自2007年开始,与Jez Humble一起,和来自四个国家的同事开发了Cruise(ThoughtWorks Studios 开发的一款持续集成与发布管理工具,现在改名为Go)。我们在两年内发布了8个版本,而且在V1.0中就引入了Pipeline的概念,而这正是本书的核心。本书是对持续集成、持续发布方面的多年经验做的精妙总结,而Cruise这款产品本身也是这些原则与实践的产物。如果你想真正了解持续集成是如何在真实项目中成功应用的,那么请一定不要错过这本书!

经过10个月的奋战,终于将第一稿译文完成,正在进行Review,希望能够尽快与读者见面。现附上前五章的中文目录。

Continue reading 持续交付-追求软件卓越的必读书目