博客园_kivenhou's bookmark

最奇特的编程语言的特征

2011-12-26T12:33:00Z

目前为止，据我个人观察，从语法角度上讲，最被人诟病的一种语言应该是 LISP 语言了。打开这种语言的代码，一眼望去，满目全是括弧，一层套一层。这种语言特征最大的问题是，它不符合人们通常的思维习惯。LISP 语言的这个特点是个整体的语言现象，而任何一种语言其实也都有一些个别的很奇特的东西，其中有些会奇怪的让你摸不着头脑。有一个好事者在一个帖子上征集各种语言里不合常理的地方，结果收集到了 320 多条，问题最大最多的语言算是 Javascript 了，另外还有C，Java，Python，PHP 等等。下面列出的是其中最有趣的几条。

1、在C语言里，数组可以这样索引取值：

a[10]

这种写法相当常见。

然而，还有一种很少见的写法(绝对可用！)是这样的：

10[a]

这两种写法的效果是一样的。

2、在 JavaScript 里：

'5' + 3 结果是 '53'

而

'5' - 3 结果是 2

3、在 JavaScript 里，下面的语法结构

return
{
id : 1234,
title : 'Tony the Pony'
};

会提示语法错误:”缺少分号”。而下面的写法却能按你预想的结果运行：

return {
id : 1234,
title : 'Tony the Pony'
};

更让人郁闷的是下面的写法竟然可以(至少在谷歌浏览器里是这样的)：

return /*
*/{
id : 1234,
title : 'Tony the Pony'
};

下面的例子也是同样的问题引起的，但不会报错，而你却得不到想要的结果：

return
2 + 2;

4、JavaScript 的等式对照表：

'' == '0' // false

0 == '' // true

0 == '0' // true

false == 'false' // false

false == '0' // true

false == undefined // false

false == null // false

null == undefined // true

" \t\r\n" == 0 // true

Java 里有趣的自动打包(auto boxing)和 IntegerCache：

Integer foo = 1000;

Integer bar = 1000;

foo = bar; // true

foo == bar; // false

//然而，如果 foo 和 bar 的值介于 127 和 -128 之间，

//情况会发生变化：

Integer foo = 42;

Integer bar = 42;

foo = bar; // true

foo == bar; // true

解释

在 Java 源代码里你很快能翻出下面的内容：

/**

* Returns a Integer instance representing the specified

* int value.

* If a new Integer instance is not required, this method

* should generally be used in preference to the constructor

* {@link #Integer (int)}， as this method is likely to yield

* significantly better space and time performance by caching

* frequently requested values.

*

* @param i an int value.

* @return a Integer instance representing i.

* @since 1.5

*/

public static Integer valueOf (int i) {

if (i >= -128 && i

注意：IntegerCache.high 的值，如果你不设置它，缺省是 127。

自动打包(auto boxing)过程中发生的事情是：除非显式的创建：比如 foo = new Integer (42) ，否则 foo 和 bar 都是从缓存中取出的整数，当比较值时，它们会返回 true。正确的比较 Integer 的方式是使用 .equals 。

6、在 Java 里：

try {
return true;
} finally {
return false;
}

在 Python 和 JavaScript 也可以这样写。这样写的结果是什么？当作一个保留的问题考考大家吧。

7、C++的模板可以做很多奇怪的事情，最好的例证是 “多维模拟排版”，你可以用模板来计算“画出的”形状。下面是一段计算一个3×3矩形的有效的 C++ 代码：

#include"analogliterals.hpp"
using namespace analog_literals::symbols;

unsigned int c = ( o-----o
| !
! !
! !
o-----o ) .area;

这还有一个 3D 立方体的例子：

assert ( ( o-------------o
|L \
| L \
| L \
| o-------------o
| ! !
! ! !
o | !
L | !
L | !
L| !
o-------------o ) .volume == ( o-------------o
| !
! !
! !
o-------------o ) .area * int(I-------------I) );

8、PHP 处理数字字符

"01a4" != "001a4"

如果两个字符串来的字符数不相等，它们不可能相等。前面的零非常重要，因为他们是字符而不是数字。

"01e4" == "001e4"

PHP 不太喜欢字符，它会寻找任何的借口来把你提供的值当作数字。把这些十六进制的字符串稍微做些改动，PHP 马上认为它们不再是字符，而是数字。它们是按科学计数法写的数字(PHP 并不在意你是否用了引号)，它们是相等的，因为对于数字来说，前面的零是可以忽略的。更强化这个事实的例子是，你会发现 PHP 认为 “01e4″ == “10000″ 是正确的，因为作为数字，它们的值是相当的。这是一个被特别提醒的语言特征，原因就是它不太合理。

在一些没有保留字、关键字的语言里，例如 PL/I，你可以写出这样有趣而且合法的代码语句：

IF IF THEN THEN = ELSE ELSE ELSE = THEN

(IF, THEN, ELSE 都是变量名)，或

IF IF THEN THEN ELSE ELSE

(IF 是变量，THEN 和 ELSE 都是函数)

10、JavaScript 里八进制的转换：

parseInt ('06') // 6
parseInt ('07') // 7
parseInt ('08') // 0
parseInt ('09') // 0
parseInt ('10') // 10

11、在C语言里，你可以把 do/while 语句和 switch 交织在一起，下面就是一个使用这种方法的内存拷贝的例子：

void duff_memcpy ( char* to, char* from, size_t count ) {
size_t n = (count+7)/8;
switch( count%8 ) {
case 0: do{ *to++ = *from++;
case 7: *to++ = *from++;
case 6: *to++ = *from++;
case 5: *to++ = *from++;
case 4: *to++ = *from++;
case 3: *to++ = *from++;
case 2: *to++ = *from++;
case 1: *to++ = *from++;
}while(--n>0);
}
}

在 Python 中：

>>> x=5
>>> 1>> 1

在 Java 中：

int[] numbers () {
return null;
}

可以被写成：

int numbers () [] {
return null;
}

如果你觉得还没看够，请到这里，还有更多。

本文链接

HTTPS和HTTP的区别

2011-11-02T09:21:00Z

HTTPS（Secure Hypertext Transfer Protocol）安全超文本传输协议
它是一个安全通信通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版。
它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安全全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。
HTTPS和HTTP的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
http的连接很简单,是无状态的
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议要比http协议安全
HTTPS解决的问题：
1 . 信任主机的问题. 采用https 的server 必须从CA 申请一个用于证明服务器用途类型的证书. 改证书只有用于对应的server 的时候,客户度才信任次主机. 所以目前所有的银行系统网站,关键部分应用都是https 的. 客户通过信任该证书,从而信任了该主机. 其实这样做效率很低,但是银行更侧重安全. 这一点对我们没有任何意义,我们的server ,采用的证书不管自己issue 还是从公众的地方issue, 客户端都是自己人,所以我们也就肯定信任该server.
2 . 通讯过程中的数据的泄密和被窜改
1. 一般意义上的https, 就是 server 有一个证书.
a) 主要目的是保证server 就是他声称的server. 这个跟第一点一样.
b) 服务端和客户端之间的所有通讯,都是加密的.
i. 具体讲,是客户端产生一个对称的密钥,通过server 的证书来交换密钥. 一般意义上的握手过程.
ii. 加下来所有的信息往来就都是加密的. 第三方即使截获,也没有任何意义.因为他没有密钥. 当然窜改也就没有什么意义了.
2. 少许对客户端有要求的情况下,会要求客户端也必须有一个证书.
a) 这里客户端证书,其实就类似表示个人信息的时候,除了用户名/密码, 还有一个CA 认证过的身份. 应为个人证书一般来说上别人无法模拟的,所有这样能够更深的确认自己的身份.
b) 目前少数个人银行的专业版是这种做法,具体证书可能是拿U盘作为一个备份的载体.
HTTPS 一定是繁琐的.
a) 本来简单的http协议,一个get一个response. 由于https 要还密钥和确认加密算法的需要.单握手就需要6/7 个往返.
i. 任何应用中,过多的round trip 肯定影响性能.
b) 接下来才是具体的http协议,每一次响应或者请求, 都要求客户端和服务端对会话的内容做加密/解密.
i. 尽管对称加密/解密效率比较高,可是仍然要消耗过多的CPU,为此有专门的SSL 芯片. 如果CPU 信能比较低的话,肯定会降低性能,从而不能serve 更多的请求.
ii. 加密后数据量的影响. 所以，才会出现那么多的安全认证提示。

转自：http://liuwei1981.iteye.com/blog/364180

本文链接

持续集成相关总结(五)

2011-10-31T04:19:00Z

（五）持续集成的深层理解与相关问题研究

1.持续集成与敏捷编程
在敏捷领域中，测试驱动和持续集成被称为敏捷编程的两大基石，于是乎，很多人的概念里就是持续集成是为了实现敏捷编程的。这是一个错误的认识。实际上，早于敏捷编程概念的提出，持续集成作为一个best practice就已经被很多公司采用了，只不过作为一个概念，则是由Martin为了推进敏捷所倡导并由此风靡起来。持续集成本身只是一种 practice，并不被什么开发模型所限制，在任何一种开发模型中都可以采用，也可以运行得非常理想。

2.持续集成还是阶段集成
有很多人说，我不做持续集成，照样工作的很好。因为我们一个（小）阶段出一个版本，照样控制得非常好。我得恭喜你，首先持续集成也好，阶段集成也罢，你做了，做了就好，比没有做要好很多，也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。

那么究竟那种方式更加理想，更加符合项目的开发和管理呢？其实这个问题Steve McConnell在他那本获得Jolt大奖的书《Code Complete》(代码大全）里有过回答了。他说：对于一个微型程序来说，阶段式的集成或许是最佳方法。何谓微型程序，他说就是那种两三个类的程序，而你又很走运的话，那么阶段式集成就可以是你的最佳方法了。当然，这位老兄是个老美，我们也都知道老外嘛，都比较笨一点，不会转弯一点，所以呢，他说微型程序，对于我们拥有5000年文明的中国人说，可以再扩大点吧，对于一个小型项目，就是那种二三十个类的项目，也许使用阶段集成也不会出啥子问题吧。

3.对持续集成好处的理解
很多人肯定非常不苟同我的看法，他们认为即使没有做持续集成，甚至没有做阶段集成，但是项目一样按时的完成，甚至提前完成，而且照样完成的非常理想，老板满意，客户满意，夫复何求？而做持续集成，无非就是动不动收到一封邮件，说这个build成功了，那个build失败了，不过就是持续编译罢了，我自己打个命令编译一下，不就知道了吗？要做个daily build，我还要颠颠的去set up，还要花力气去配置，效果也不见得好到什么地方去。

    对于这样一些问题，我想首先我们还得搞清楚，究竟为什么我们要去做持续集成，持续集成究竟可以给我们带来什么好处。同样在《Code Complete》里提到了，对于持续集成（在书中，Steve McConnell使用Incremental Integration的术语）有以下几点好处：

易于定位错误   也就是当你的持续集成失败了，说明你新加的代码或者修改的代码引起了错误，这样你很容易的就可以知道到底是谁犯了错误，可以找谁来讨论。
及早在项目里取得系统级的成果   因为代码已经被集成起来了，所以即使整个系统还不是那么可用，但至少你和你的团队都已经可以看到它已经在那了。
改善对进度的控制，改善客户关系   这点非常明显，如果每天都在集成，当然每天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你是程序员，你不用在汇报任务的时候说我完成了多少百分比而烦恼，而如果你是项目经理的话，那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。
更加充分地测试系统中的各个单元   这也是我们常讲的Daily Build与Smoke Test相结合带来的绝大好处。
能在更短的时间里建造整个系统   这点恐怕要你实施以后才能得出结论。就我们而言，持续集成并没有为每个项目都缩短时间，但却比没有实施时，项目更加可控，也更加有保证。

随着时间的推移，持续集成带来的更多好处，也逐渐被认识到了，比如说：
有助于项目的开发数据的收集   比如说，项目代码量的变化，经常出错的Tests，经常出错的source code，等等。
与其它工具结合的持续代码质量改进   如与CheckStyle, PMD, FindBugs, Fxcop等等等等的结合。
与测试工具或者框架结合的持续测试   如与xUnit，SilkTest, LoadRunner等等的结合。
便于Code Review   在每个build里，我们都可以知道与前一个build之间有什么改动，然后针对这些改动，我们就可以实施Code Review了。
便于开发流程的管理   比如说，要把一个开发的build提交给测试组作测试，测完满意了，再提交到发布组去发布。

4.持续集成应该自动化什么
我们要以尽可能少的成本来获得尽可能多的价值。这就要考虑哪些自动化是必要的。Jez Humble提到至少有六点要做到自动化，它们分别是(1)自动化的运行测试；(2) 自动产生可部署的二进制成品；(3) 自动将成品自动部署到近似生产环境；(4) 自动为CodeBase打上标签；(5) 自动运行回归测试；(6)自动生成度量报告。

5.只有持续集成服务器是远远不够的
正如Jez Humble所说，CruiseControl和其它的CI工具本质上只不过是一个定时器，时间一到，做你让它做的事情。所以，必然要有其它工具与其结合，方显持续集成的本色。这些工具又是什么呢？想测试的话，你就要用一些测试工具，如JUnit，JWebUnit，Selenium等等；想检查代码标准的话，你就要用checkstyle等代码规范检查工具；想要了解测试覆盖率的话，你可能就要用到JCoverage啦。当然，想得到二进制文件，就要用到Ant，Make之类的工具啦。

6.最重要的事：实践与反思
也许这些东西大家都知道，而且有些人可能已经实践过。无论这些实践的结果是怎样的，一定不要忘记总结和反思。如果这些实践成功了，不要把它归功于这个工具，而是要总结一下为什么会成功，如果你愿意的话，还可以和大家分享一下。如果这些实践失败了，也不要把它归功于这个工具，而是要反思一下，是否正确地使用了这个工具，团队成员是否都喜欢这个工具，为什么？

7.跌跌撞撞的持续集成之路（分享持续集成经验）
网站链接：http://cd.qq.com/a/20090910/000715.htm
本文链接

持续集成学习总结(四)

2011-10-31T04:17:00Z

（四）基于 Ant 搭建敏捷开发过程中的持续集成环境

持续集成（CI）是敏捷开发过程中至为关键的一个环节，在每个迭代开发周期中，合理地对软件产品进行持续集成，将有效协调软件编码，测试以及版本发布各个团队的工作进程，降低软件开发风险，对客户需求做出最及时有效的反馈。Apache Ant 提供了丰富的核心任务以及扩展任务来完成持续集成过程中的各项工作，同时开源社区 Ant-Contrib提供的 Ant 任务更是大大增强了 Ant 的可编程性，使得 Ant 有能力完成更为复杂的逻辑操作。本文中将展示一个典型的 Web 2.0 应用在敏捷开发过程中的持续集成环境，并展示每个部分如何由 Ant 来具体实现。

1.基本的持续集成环境

一个持续、稳定的构建是整个持续集成过程中的关键。在每个迭代周期的开发过程中，软件开发团队应当及时将最新的功能代码进行提交和构建，以便使软件测试团队能够进行功能或系统测试，及早发现缺陷并尽快解决。同时，在相应迭代周期的后期，版本发布团队应该能够获取经过验证后的最新的产品构建，并将其打包成可交付产品或进行线上产品的更新，交由产品的项目关系人或最终客户进行使用，确保客户需求与软件产品一致。目前在 Web 2.0 应用的敏捷开发过程中多采用这样一种集成环境，以满足 Web 2.0 应用最为典型的“Always Beta”特性。

下图展示了一种基本的持续集成环境的拓扑结构。

图 1. 持续集成环境的拓扑结构

持续构建服务器上的 Ant 脚本首先从源代码管理库获取最新的代码，并按照特定的构建策略执行构建，比如在固定时间触发每日构建，而后将构建结果自动上传至 FTP 服务器用以保存和分发；功能测试 (FVT) 或系统测试 (SVT) 环境则包括了测试服务器和测试数据等信息，其上的 Ant 脚本则负责从 FTP 服务器获取最新的构建，提取更新所需的产品代码（如果需要，还要提取必要的数据库更新脚本，完成数据库架构的重构）来完成测试环境的更新，而后调用测试脚本进行测试并产生测试报告；产品环境则是面向终端用户的产品运行环境，其上的 Ant 脚本可以将通过测试的构建生成可交付的产品或线上产品更新包，这一过程常伴随产品版权信息验证、产品包压缩以及产品部署等动作。

2.Ant 如何帮助持续集成

Ant 作为 Java 开发领域应用最为广泛的自动构建工具，不仅可以帮助开发团队实施每日构建生成构建包，更支持在此构建包基础之上，生成测试团队和版本发布团队所需要的构建包以完成后续的产品测试与发布工作，最终使得整个迭代周期过程的产品集成实现自动化。本文不会对 Ant 的基本概念和所有任务进行逐一介绍，而是将作者在实践过程中认为对持续集成有所帮助的概念和任务加以解释阐明，以期读者更好地了解 Ant 的能力，并加以灵活的运用。

3.<Ant> 与 <Antcall>（<AntFetch> 与 <AntCallback>）

<ant> 任务提供了在一个构建脚本内调用外部脚本特定目标（target）的能力，这种能力可以很好的帮助我们管理整个持续集成过程。特别是在有多个项目构建需求的情况时，设计一个独立的控制脚本，借助 <ant> 任务使其通过调用不同的项目构建脚本完成整体项目的集成，这样做的一个最明显好处是使我们可以快速的适应项目变动，符合随需应变（On Demand）的开发模式。

<antcall> 任务区别于 <ant> 任务之处在于，其只能调用同一个构建脚本之内的构建目标，他所提供的是对一个构建脚本自身的清晰管理。以往依赖于 depends 属性的方式使得我们很容易迷失在复杂的目标依赖关系中，而使用 <antcall> 则能够将每个构建脚本的任务以显式的、易修改的方式呈现给项目构建者。

<antfetch> 和 <antcallback> 是 ant-contrib 开源项目提供的扩展任务，是增强版本的 <ant> 和 <antcall> 任务，他们不仅具备前二者的基本能力，还可以返回外部脚本或同脚本其他目标中的属性，可类比编程语言中带返回值的方法调用。

4.Available 与 Condition

在构建过程中，构建脚本不可避免地会对许多外部资源（文件，目录，URL 等）进行访问甚至修改，而为了能够有效的对这些资源进行操作，所需做的第一步通常是验证资源的可用性。<available> 任务可以帮助我们对各种外部资源进行判断，通过设置相应的属性来表明判断结果，进而引导后续的构建操作。

另外，在某些情况下，构建脚本或许需要对多个资源同时进行判断而不仅仅是单个资源。<condition> 任务通过支持丰富的内嵌标记（nested element），如 <and>/<or>/<xor> 等，具备了对资源进行更加复杂的逻辑判断能力。

5.For 与 If

当我们使用 Ant 脚本编写一些较为复杂的逻辑功能，比如循环和流程判断时，自然希望 Ant 能支持这种编程能力。然而 Ant 核心任务中并没有提供 <if> 任务，只是在 <target> 任务的属性中支持 if 属性，比如 <target name="build-module-A" if="module-A-present"/>，即表示只有 module-A-present 属性存在才执行 build-module-A 目标。但是，必须注意的一点是，这里的 if 并不是判断 module-A-present 属性是否设置为特定值，而仅仅是检查该属性是否被设置了，因而其可编程性并不是很强。

Ant-contrib 为 Ant 提供了与通常所使用的编程语言功能相同的 <if> 和 <for> 任务，在构建过程中灵活运用这两个任务，将大大增强 Ant 对逻辑操作的控制能力，这其实就是一种基于 XML 脚本的编程。

在具体的实践过程，有一点需要特别注意：在使用 <for> 任务的过程中，如果我们期望在循环体内使用一个变量，而非 Ant 的 property，则需借助由 ant-contrib 提供的 <variable> 任务（ant-contrib 任务）来实现。尽管这与 property 的值一经设置便无法改变的设计原则相抵，但有时能够给构建脚本很大程度上的灵活性。

6.Replace 与 ReplaceRegExp

在由开发构建包向产品构建包转变的过程中，替换与开发环境相关的属性值是主要工作之一 , 比如我们不能假设用户会将 JDK 安装在与开发环境相同的路径下，这时便可以使用 ant 的 <replace> 任务，<replace> 任务可以针对特定的字符串的执行替换操作。不仅如此，利用 Ant 扩展任务所提供的 <replaceRegExp> 任务，还可以实现基于正则表达式的替换。

例如，要将 test.bat 文件中的行首“java”字符串替换为“../../java/bin/java”而不影响其他“java”字符串，可以使用如下 ant 脚本：

<replaceregexp

file="test.bat"

byline="true"

match="^java "

replace="http://www.cnblogs.com/ java/bin/java "

7.Filterchain 与 Mapper

Filterchain 和 Mapper 是在集成脚本中经常用到的 ant 概念。Filterchain 增强了面向数据传输的 ant 任务的能力，如 Concat，Copy，Loadproperties 和 Move，借助于各种不同功能的 filter，使得这些任务具备了数据筛选和处理的能力，非常类似于 Unix 系统中的管道的概念。

例如，要实现将 A 文件夹复制到 B 文件夹，同时对 B 文件夹中所有 jsp 文件的文件头添加 copyright.txt 文件内容的任务，可以使用如下 ant 脚本。

</filterchain>

</copy>

Mapper 则常出现于 Copy，Move 或 Unzip 任务中，它的作用在于为这些任务增加指定输出文件的能力，使得我们不仅可以通过 <fileset> 来指定源文件集，更可以通过各种不同功能的 mapper，来实现重新命名输出文件文件名或更改输出文件目录结构的能力，这在构建持续集成环境中起到了极为灵活的作用，很好的理解这两个概念有助于写出简单而功能全面的 ant 脚本。

8.Taskdef

另外，在一个复杂的持续集成环境中，我们不可避免地会涉及一些商业产品或者开源项目来搭建整个环境，比如使用 CVS，SVN 或 IBM ClearCase 作为项目源代码库，使用 Apache Tomcat，IBM WebSphere Application 作为测试或产品环境的部署服务器，使用 LiquiBase，DBdeploy 作为产品数据库的持续重构工具等。而 Ant 借助其易扩展的特性，对所有这些工具提供了很好的支持，外部工具的提供者只要实现特定的 Ant 任务接口，就可以提供自定义的 Ant 任务，我们只需要通过 <taskdef> 任务引入这些特定的 Ant 任务，便可以实现与这些工具的连接，实现通过 Ant 脚本来管理整个集成环境的目的。

9.实现一个基本的持续集成环境

在一个典型的线上 Web 2.0 应用的迭代开发周期中，持续集成通常涉及构建、部署、测试和上线等一系列动作，而这些动作能够自动运行的前提是获取各自需要的产品包（比如基于 Java EE 的产品都须提供的 WAR 或 EAR 文件）。因此，在构建服务器上调用一个综合性的 Ant 构建脚本（清单 1），产生其它动作所需要的产品包，则成为整个持续集成过程中最为核心的一步。

清单 1. 产生其它动作所需要的产品包

<?xml version="1.0" encoding="UTF-8"?>

</target>

</target>

<antFetch dir="${basedir}" antfile="checkLicense.xml" target="checkLicense"

return="reportFile" />

<fail message="Unlicensed file found, please check ${reportFile}"

if="${reportFile_exist}"/>

</target>

<teamAccept repositoryAddress="${repositoryAddress}" userId="${userId}"

password="${password}" workspaceName="${workspaceName}" verbose="true" />

<teamFetch repositoryAddress="${repositoryAddress}" userId="${userId}"

password="${password}" workspaceName="${workspaceName}"

destination="${destination}"

verbose="true" />

</target>

<ant dir="${SampleApp1.dir}" antfile="build.xml" target="war"

inheritAll="false" />

</target>

<ant dir="${SampleApp1.dir}" antfile="build.xml" target="ear_FVT"

inheritAll="false" />

</target>

<ant dir="${SampleApp1.dir}" antfile="build.xml" target="product"

inheritAll="false" />

</target>

<ftp action="mkdir" server="${FTPAddress}" userid="${FTPUserName}"

password="${FTPPassword}" remotedir="${FTPSharedFolder}/${build.time}"/>

<ftp server="${FTPAddress}" userid="${FTPUserName}" password="${FTPPassword}"

remotedir="${FTPSharedFolder}/${build.time}">

</ftp>

</target>

<mail mailhost="${MailServer}" mailport="${MailServerPort}"

subject="Build Report Mail" tolist="${MailList}" messagemimetype="text/html"

messagefile="mailcontent.html">

</mail>

</target>

</project>

不难看出，<antcall> 任务通过调用不同的任务组合达到了为不同构建目的提供不同构建动作的目的，其中包括对“冒烟”测试，功能测试以及产品环境安装的特定支持，而各个环境所需要的产品包也因 <ant> 任务目标的不同而不同，这种松散组合的方式为今后脚本的维护和更新提供了良好的基础。

在为产品环境提供产品包（perform_productBuild）的目标中，<antFetch> 扩展任务通过调用外部的 checkLicese.xml 脚本来对产品进行版权核查，任何没有版权信息的文本文件都将被记录到 reportFile 中。虽然类似的这种功能可以使用多种脚本语言来方便的实现，比如 Python 和 Ruby 等，但这里给出了基于 Ant 的实现，以更好的展示 Ant 脚本的灵活性和可编程性。清单 2 是使用 Ant 实现版权信息检查的部分脚本。

清单 2. 使用 Ant 实现版权信息检查的部分脚本

<path>

<not>

</not>

</fileset>

</path>

<echo file="${reportFile}" message="@{file},${line.separator}"

append="true" encoding="UTF-8"/>

</sequential>

</for>

</sequential>

</for>

</sequential>

</for>

</target>

对于测试环境和产品环境而言，获取产品包并自动的进行产品部署是两者共同的首要工作，而这个过程中所面临的主要问题通常涉及不同操作系统的脚本移植性问题。幸好，Ant 具备了良好的跨平台能力，我们不必为不同的部署环境（Windows 或 Linux）去编写不同的部署脚本，只需将精力集中于产品包的获取和针对不同应用服务器的部署即可，清单 3 展示了如何从 FTP 服务器获取产品包，并自动发布于 IBM WebSphere 应用服务器的过程。

清单 3. 获取产品包并自动部署

<?xml version="1.0" encoding="UTF-8"?>

<taskdef name="wsStartServer"

classname="com.ibm.websphere.ant.tasks.StartServer"/>

<ftp action="get" server="${FTPAddr}" userid="${FTPUsr}" password="${FTPPasswd}"

remotedir="${product_FTP}">

</fileset>

</ftp>

</target>

<unzip src="${basedir}/FTPDownload/Production.zip"

dest="${basedir}/Production">

</unzip>

</target>

<wsadmin script="${basedir}/updateApp1.py" user="${MMC_user_name}"

password="${MMC_user_password}" conntype="NONE" failonerror="yes">

</wsadmin>

</fileset>

</copy>

</target>

<wsStartServer server="server1" noWait="false" trace="true"

username="${MMC_user_name}" password="${MMC_user_password}" failonerror="yes">

</wsStartServer>

</target>

<wsStopServer server="server1" noWait="false" trace="true"

username="${MMC_user_name}" password="${MMC_user_password}" failonerror="yes">

</wsStopServer>

</target>

</project>

10.结束语

本文首先介绍了一种在敏捷开发环境中最基本的持续集成环境，然后结合作者自身实践，讲述了几种能够为持续集成提供重要支持和能力的 Ant 任务及概念，最后通过示例性 Ant 脚本片段展示如何使用 Ant 脚本来快速地搭建这样一种环境。

11.参考资料

学习

Apache Ant 用户手册，从这里可以了解到 Ant 相关的详细内容。
Ant-Contrib Task, 从这里了解更多 Ant-contrib 任务。
查看敏捷专区，了解更多有关敏捷开发相关知识。
查看 IBM WebSphere Application Server 信息中心，获取更多对 WAS 对 Ant 所提供的支持。
“敏捷软件开发基础：持续集成环境的构建”（developerWorks，2005 年 6 月）：本文中，作者将介绍如何构建持续集成所需要的环境。
“实现持续集成”（developerWorks，2005 年 12 月）：本文是对持续集成的概念和实践的一个介绍。
developerWorks Java 技术专区：查找数百篇有关Java 编程各方面的文章。

获得产品和技术

下载 IBM 软件试用版，体验强大的 DB2®，Lotus®，Rational®，Tivoli®和 WebSphere®软件。

讨论

查看 developerWorks 博客的最新信息。

本文链接

持续集成学习总结(三)

2011-10-31T04:15:00Z

（三）持续集成的具体实施经验举例

持续集成有很多很多的好处。可是持续集成要做好的话，本身就有很多的讲究。从持续集成工具的选择到持续集成具体实施，每一点都可能影响到你使用持续集成的效果。持续集成不是持续编译，也不是仅仅用来发发邮件的工具而已。
    首先选择一个好的工具很重要，可能会觉得QuickBuild这个工具真得很不错。工具选好了，具体怎么做呢？这个没有什么标准可以遵循，每个项目都是不一样的，我谈谈我们这里的具体过程吧。
    首先，我们对编码有一些规范需要遵从，所以我们制定了一系列的FindBugs和PMD的规则用于检查代码。
    其次，我们使用Cobertura作为我们的代码覆盖（code coverage）工具。
    再次，我们使用JUnit作为我们的unit test工具
    基于上述几点，我们编写了我们的Ant脚本，这个脚本有一系列的task，基本上就是:
compile, source code analytics, unit test, generate reports, generate javadoc, package artifacts
这个，也是Java领域中经常使用的一个完整的过程。
    有了这样一个脚本以后，我们开始配置我们的项目到QuickBuild中去，在QuickBuild中，我们配置一个configuration，然后设定我们的SCM repository，对应于我们的ant task，我们配置了一系列的step，用于完成整个过程。由于我们的测试需要跨平台，所以对应与同一个unit test的task，我们使用QuickBuild的分布式的step功能，使之在不同平台上可以进行测试，这一点也是使用CI Server的一个好处吧。
    对应于这个configuration，我们配置了四个子configuration，分布是 Development Configuration, QA Configuration，Integration Configuration和Release Configuration。这几个configuration分别对应于我们开发过程的四个阶段，我们的每日构建都是在Development configuration上的，所以我们配置为每日一次，而对于其它三个则不做自动的构建。因为我们是通过Promote来做的。对于 Development Configuration，我们没有对SCM自动打Label，而对于其它的，我们则对每一个Build自动对SCM进行打Label。
    有了这些以后，开发工作开始了，我们每天的代码在下班前都提交到subversion里去，第二天，Development Configuration就自动的编译完成了，并且发送通知给我们。我们通常会会开一个Morning Meeting，首先我们会到在QuickBuild的页面上，看到昨天有哪些个改动，测试的状况，比如说哪些测试修正了，哪些测试还没有被修正，哪些 source code没有通过代码检查。然后我们会点到具体的报告中去分析，这些报告都可以很容易的打开source code，我们可以直接在上面对各个改动做code review。通常这个工程耗时约30分钟结束。
经过这样开发之后一段时间，我们的功能很多已经就绪，就可以提交给QA作test了，由于当日的构建可能失败，或者不是我们特别想给QA的，那么我们会选择之前几日的一个好的build做 Promote，这个promote就会自动触发QA Configuration去做build，QA Configuration的build做完以后，就会发送一个邮件通知QA Lead，这封邮件里QuickBuild会把所有与上一个QA build的changes都列出来，这样他就知道我们这个版本里增加了什么功能，修正了什么bug。
    再如此经过几个迭代后，我们开发组和QA组一致认为功能基本实现了，bug也不多了，于是就由QA的Lead做一个Promote，触发Integration Configuration不build一个大版本交给客户，做VOC (Voice of Customer)，听却客户的意见，如果客户没有什么易见的话，那么就会在Integration Configuration上做一个Promote到Release Configuration上去。
    通过这样做，我们基本上可以很容易的知道每一个版本之间有什么变化，甚至我们可以很容易的重新build出任何一个时间点上的版本。而且，我们基本上无需操心什么时候给SCM打什么样的Label，因为对于我们而言，我们需要看到的只是每一个版本的build。而如果用subversion来管理的话，也许你也可以通过命令来列出在SCM中各个版本的变化，但是如果有一天，你头昏忘记打label的话，或者打错label的话，也许要找到这个问题就不是那么容易了。又也许，你可以通过一系列的命令来完成这里提到的所有功能，但是我是懒惰的，而且很容易做错事情，所以我觉得如果机器可以完成的话，就让机器去做吧。

本文链接

持续集成学习总结(二)

2011-10-31T04:14:00Z

安装CI

安装是我们开始的第一步，同时也对各个CI server都有了初步的印象。按照各自的手册，很快就装好了，我基本上选择的是Standalone的版本，就是不配置数据库，使用自带的，也不deploy到Tomcat或者其它容器，这点，基本上每个CI Server都非常简单。

AntHill要download还得提交一个request，然后才能下载，安装。

配置项目
在大多数的CI Server中，绝大部分都是以Project或者Project Group来进行管理，只有LuntBuild和QuickBuild比较另类，它们使用了Configuration这个术语，意即一个配置。在配置一个典型的项目的时候，即只处理基本的一个流程：CheckOut, Build, Publish Artifacts，这些工具都完成的非常好，也非常简单。
TeamCity的导航最方便，一目了然。
而LuntBuild和QuickBuild在这方面稍显人性化不足，这两个工具都没有使用wizard的模式。
下面，我接着实验配置50个测试项目，这也就开始考验一个CI Server的管理能力了。
QuickBuild最实用，因为它使用Configuration而不是Project，并且它是这些CI Server中唯一支持树状结构配置的。我可以把Configuration配置成Team A, Team B ...，然后根据实际情况，对每个Team配置任意多个子节点，孙节点（注意，Configuration的数目在QuickBuild的Community Edition里是要限制的，好像是最多16个）。QuickBuild的继承关系使用起来也非常方便，如果要管理一个大型的CI Server，没有这种继承简直是一种折磨。比如说用hudson来配置50个项目，要需要大半天，而用QuickBuild来，只需大约一个小时，我实际配置的Configuration（含有实际step定义的）只有3个，其它的都是继承下来，然后修改了一下参数而已，而如果我们需要批量修改一系列的configurations的时候，则由于有继承关系，通常我们只要去修改一下父节点的设置就可以了。
TeamCity支持Project Group的概念，类似于一种树形，但是还不完备，它只能分成两级关系，即Project Group和Project。另外QuickBuild所拥有的继承的功能，在别的CI里没有看到过，有的只是象TeamCity类似的copy project的功能。而QuickBuild在复制的能力上远远胜过其它的CI Server，它可以整个子树拷贝，这也就意味着，我可以配置一个公司用的template configuration树，然后复制出A部门，B部门，C部门，等等等等。对于不同项目之间的区别则通过变量来控制，赞一个！TeamCity在配置的方便上真得是没话说，非常直观，最酷的是象JUnit，NUnit这样的Tests，连Ant脚本都不需要写了，它直接就可以找出项目里的unit tests，这个在其它的工具里也没有看到过。
至于CruiseControl，Hudson，Bamboo等则是中规中矩，无甚亮点。
另外配置一个项目要配的就是项目持续集成的流程管理，在我们这里，基本上是这样一个流程: Daily Build -> QA Build -> Integration Build -> Release Build。所谓Daily Build，顾名思义，就是每天一次的，由development team管理以保证项目的顺畅执行，然后经过一段时间后，development team要提交到QA那边进行测试，通常是2个星期到一个月左右，随项目大小不等，QA测试结束之后，如果没有重大的问题，则提交作Integration Test，以保证在模拟的实际环境中能正常工作，最后，如果没有什么问题的话则作Release Build以形成发布版本。对于公司里有一些Team使用敏捷编程的，则需要增加所谓的Commit Test Build，也就是developer在作每一个check in的时候自动触发一个build，以保证build不会被这个check in破坏（包括不会破坏unit tests和code quality)。这也是所谓的要作continuous testing和continuous code quality analysis，这些都是通过利用JUnit, NUnit，CheckStyle, PMD，Cobertura，FxCop等工具来实现的。
这个环节里，个人比较喜欢AntHill Pro和QuickBuild，这两个工具都是比较强调流程的，尤其是AntHill Pro更是将其作为卖点。AntHill Pro以工作流的模式来定义这个流程，一个项目可以定义多个的workflow，对应于我们的case，就是定义Daily Build的workflow，定义QA Build的workflow，等等，然后在作promote的时候，通过选择不同的workflow来达到目的。
QuickBuild则是利用已有的configuration的概念，定义不同的Configuration，然后在Configuration的setting里定义一个或多个要promote的configurations。要作promote的时候，则通过点击某个build的promote按钮将其promote到指定的configuration上去，也很方便。使用AntHill的模式，概念上很清晰，因为我们要作的是流程管理嘛，所以workflow会听起来比较容易接受。而QuickBuild则是把它绑定在Configuration上，使用起来比较简单，但是找起来要费点事，至少对于我而言是这样。Hudson也有类似的流程管理，但是它是自动的，而promote在我们这里是需要人来作review的，也就是说要人去参与，判断究竟使用哪个版本来promote，所以在我们这里，不是很合适。
在配置项目这个环节里，个人感觉QuickBuild比较灵活，既可以做到很简单的配置，也可以做到非常复杂的配置，而且配置起来方便性非常好。只是术语与其它的CI Server有些不同，需要熟悉一下。
Build功能：CI Server最重要的就是Build本身的功能，包括SCM的连接，用户的权限管理，Build工具的支持。首先我们来看看SCM的支持。

SCM支持
在这些CI Server中，AntHill Pro和Hudson支持的种类最多，尤其是Hudson，基本上市面上的SCM都有所支持。对于象比较常见的Subversion，CVS，ClearCase，StarTeam，SourceSafe等，各家都已经支持了。
而QuickBuild，则属于在SCM里支持最少的一家，它还不支持git，Team Foundation Server，这个目前已经很流行的两种SCM，QuickBuild在支持SCM的时候，由于使用变量的支持，却是多家CI Server中最灵活的一家，它可以使用变量来配置SCM的URL，而其它的，则是通过定义一个基本的URL，然后针对不同项目来定义各自的SCM repository。而QuickBuild还有一个它自有的QuickBuild Repository，用于在不同的Configuration中传递artifacts，实际用起来也很方便，比如说我们在一个项目里要用到别的项目的artifacts，那么就可以定义一下这个repository。当然，这个功能也可以通过Maven的repository来完成来达到相同的目的。TeamCity也提供了类似的机制，只不过TeamCity的Repository其实就是一个Ivy的扩展。
SCM的数据在这些CI Server中都有体现，从每一个Build的change sets到历史统计。说明现在大家都很重视对于这些数据的收集和分析。其中TeamCity能直接从Web页面上直接调用IDE来打开这些改动的文件是一大亮点，毕竟是做IntelliJ的公司！

用户管理
这个基本上是每个CI Server的必备功能了，基本上都是既可以用内置的数据库管理（Hudson好像没用数据库），又可以连接LDAP服务器。

Build的Dependencies管理 (Dependent Builds)
在实际的项目中，我们常常会出现项目之间的依赖关系，比如说A项目依赖于B项目，B项目依赖于C项目。所以当我们要编译A项目的时候，我们需要先编译C项目，然后编译B项目，最后再来编译A项目，这样做的好处显而易见，就是保证我们总是使用最新开发的code来编译一个版本，如果发生了什么问题，我们也可以很容易的知道究竟是哪个项目break了整个build的流程。这个功能基本上所有的这些CI Server都有提供，而能力各有千秋。
TeamCity在这里属于最弱的一个，它只能通过定义Ivy来达到Artifacts在不同项目中的依赖管理。
而AntHill Pro，Bamboo和QuickBuild则都有提供两种类型的dependency管理，即artifacts和项目本身的依赖管理。
不过TeamCity却有另外的杀手锏，就是导入项目的功能，它支持从IntelliJ的项目，Maven的项目中直接导入创建这种依赖关系。

分布式Build Pool
由于公司的项目繁多，平台繁多，对于一个项目需要分布到不同的平台去编译，测试，这时候就需要建立一个Build Pool了，基本上述各家的CI Server都已经支持了这种分布式的build pool，其实质是利用了grid computing技术来进行管理。也就是一个build server带上一群的build agent，然后把build的任务分布到不同的agent上去执行。
在这里不得不再赞一个QuickBuild了，其实QuickBuild的agent与其它家的倒没什么不同，只不过就是一个computing unit，关键在于QuickBuild里配置一个configuration，它使用了step的概念，这个step在AntHill Pro里也存在，关键在于这个step是可以分布的，也就是说，我配置一个项目的时候，可以定义一系列并行的分布式的step，这样对于管理和收集artifacts非常方便，我们可以定义Test On Windows, Test On Mac, Test On Linux，然后设置一下运行这些step的时候需要什么类型的agent，QuickBuild就可以把这些任务分布到这些平台的agents上去运行了。
而其它家的可能是因为收费的方式，象TeamCity，一个build只能在一个agent上运行，我如果要做到同样的效果，就需要定义出三个项目，然后让这三个项目在不同的agents上运行，最后，还要再定义一个项目，让这个项目去收集它们的artifacts，非常麻烦。
Bamboo和AntHill也类似于TeamCity。
而Hudson在这块的能力很弱，个人感觉不如其它的产品强大，而且使用起来也更复杂一些。

Report功能和统计
上述各家CI SERVER都提供了Report的功能和统计的功能。
Hudson是支持报告类型最多，最全的，因为是OpenSource的，有太多人开发。
Bamboo属于支持报告类型最少的，不过也有很多第三方的plugin（插入式的）供选择。
我们所关心的几个reports都有被各家支持；
QuickBuild的report给我的感觉最华丽，不过好像是参考google analytics来的，从界面上看和analytics简直就是一个翻版。
在使用上，QuickBuild和TeamCity的最方便，直接点报告中的链接就可以作一些过滤。
在统计信息方面，各家对tests的统计都非常完备，这也从一个侧面反应出test driven现在已深入人心。
在支持Test Driven方面，TeamCity是力拔头筹，得益于开发IntelliJ的经验，TeamCity不仅可以自动寻找出项目中的unit tests（你不用在Ant脚本里调用junit task，或者在Maven里调用surefire），而且对于上次运行失败的test cases，它可以在下次build中自动先运行，这样就可以避免一个build运行了很久才发现上次失败的test还没有被更正过来呢。
另外，要提一下，QuickBuild中那个Build的Dashboard我非常喜欢，对于一个项目当前的状况可以一目了然，有多少个tests成功了，多少失败了，多少被fix了，多少还没有fix，总之，信息很丰富，不过就是配置起来有点复杂，需要我去一个报告一个报告去加step，如果能做到TeamCity的程度，简直就是完美了。
对于其它的CI Server则是亮点不多。其实也很强，只不过是对比而言，我觉得TeamCity和QuickBuild更强，更好。

与第三方工具的集成
在与第三方工具的集成中，Hudson遥遥领先，是所有CI Server里Plugin最多的。可以和FaceBook，Google Calendar，Twitter，反正基本上你能想到的，它都有。不过对于我们而言，好多Plugin没有太大的价值。Bamboo在与它自己的几个产品中集成度也非常好，比如说Jira，Wiki，Clover等。这几个我们公司都有用到，在这点上非常理想。

价格
考虑一下价格的因素，记得有人说过，Price is nothing, but price is everything，尤其在这个金融危机的年代里。OpenSource永远是最好的。而在商用的这几个里QuickBuild最便宜，它使用的是Site License，一个Site收$2999，AntHill最贵，随便搞搞就要$10000了，TeamCity的入门也很便宜，$1999带3个agents，它是按agent收费的，Bamboo也很贵，按照它的功能而言，性价比不是很好。

总结
综合各方面因素,基于原笔者的考虑，最后得出结论比较倾向于QuickBuild，虽然这个产品名声不是很大，不过在它的客户中，不乏象Cisco，HP这样级别的公司，应该还是可以值得信赖的。另外就是我们使用下来觉得它还是拥有诸多亮点，对于统一管理来说，可谓是方便至极。另外价格方面考虑也很不错。当然如果你的团队不是很大，那么选择QuickBuild的Community Edition和TeamCity的Professional Edition都是非常值得，这两者都是免费的，而且QuickBuild的Community Edition功能没有任何裁剪，只是限制了一下configuration的数目，非常适合要求比较高而项目不是很多的团队。
本文链接

持续集成学习总结(一)

2011-10-31T04:13:00Z

Ⅲ.Hudson，目前使用最广的持续集成工具.（http://hudson-ci.org/）
厂商
Java.net
支持的编程语言
Java
是否开源
是
价格
免费
主流 SCM 支持程度
Clear Case ， VSS, CVS, Subversion ， PVCS 等， SCM 支持最为完善
构建管理
并行构建，分布式构建，增量构建，人工强制构建， SCM 触发构建等都有支持
消息通知机制
Email ， Run executable ， FTP ， IRC ， Jabber ， Lotus Sametime ， RSS,SCP,Windows System Tray,Formatted Logging

构建工具支持
Shell 脚本与命令行， Ant, Groovy, OpenMake Meister, Maven, Maven2 ， MSbuild ， NAnt ， Rake (Ruby)
项目管理工具集成
无
测试工具集成
CppUnit result rendering ， JUnit result rendering ， NUnit result rendering ， Selenium result rendering ， PHPUnit result rendering ， MSTest result rendering ， SilkCentral ， Clover result rendering ， PMD result rendering
安装与配置
有 windows 安装程序， Self contained distribution (except SCM clients) ， N 无需修改构建脚本，支持多个项目，自动配置构建脚本
IDE 集成
Eclipse Plug-in ， IntelliJ Plugin

Ⅳ.持续集成流行工具的初步分析与建议
持续集成(continuous integration)作为敏捷编程的基石现在已经被绝大多数的开发团队所广泛采用。而持续集成的工具现如今也是百花齐放，各有千秋，在此主要对比了在Java领域中比较常见的几种CI server（因为公司要求统一整个公司的CI server）。如果想了解更多的工具，可以看这里：
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
在此主要针对以下几种CI Server作对比，版本有点多，国内的多选用了一些open source的，而老外那边用得比较多的是商用版本；
CruiseControl (http://cruisecontrol.sourceforge.net/)
Hudson (https://hudson.dev.java.net/)
LuntBuild (http://luntbuild.javaforge.com/)
TeamCity (http://www.jetbrains.com/teamcity/)
AntHill Pro (http://www.anthillpro.com/)
Bamboo (http://www.atlassian.com/software/bamboo/)
QuickBuild (http://www.pmease.com/)
在持续集成领域，OpenSource的CruiseControl和LuntBuild可谓老牌了，尤其是CruiseControl，出自thoughtworks，这可是Martin Fowler的老巢啊。Hudson作为OpenSource里持续集成的后起之秀，现在已经赶超了这两个前辈，目前恐怕是使用最多的一个CI Server了。而后面4个是商用的CI Server，其中TeamCity是来自jetbrains的，jetbrains是开发著名的IDE IntelliJ的公司。Bamboo则是开发著名的Bug Tracking工具Jira和Wiki Confluence的公司atlassian公司出品的。AntHill也属于Continuous Integration界的元老，QuickBuild则是LuntBuild的商业版本，我在下面重点考量的是QuickBuild，因为LuntBuild好像现在更新较慢了，而且QuickBuild现在好像也有了免费的所谓的Community Edition，功能齐全，只是配置数有所限制。在这些商业版本中，TeamCity应该是目前市场占有率最高的。由于公司里比较倾向使用商业版本的服务器，所以我重点比较的是后4种，捎带比较了一下CruiseControl和Hudson。TeamCity和QuickBuild都有各自的免费版本，有兴趣的也可以去看看。
CI Server在本质上就是一个定时调度器。我们配置一系列的项目，然后设定一个定时器，让它干一些活，然后通知大家。所以很多公司都使用所谓Home-made的工具，用cron+Ant/Maven来做持续集成，这个就已经可以达到CI的最简单的功能了。而使用工具，就是我们除了基本的编译和通知功能以外，我们还有很多其它的需求，在公司里，选择CI Server主要考虑以下几点：
·便于公司的统一管理（大约有200+ Projects需要统一管理）
·对于项目本身进行流程管理: Daily Build -> QA Build -> Release Build
·公司AD（Active Directory）的连接以对用户进行权限管理
·Continuous Testing的支持，即对于项目的Test要能产生出详尽的报告以及收集Test的统计数据以作为项目的分析和考量
·Continuous Code Quality Analysis的支持，即能处理项目产生的Coverage报告，Code的static analysis报告，并且能收集这些报告的统计数据以作项目的分析和考量
·与SCM工具的集成，我们公司主要有三种VCS，ClearCase, Subversion和StarTeam
·与其它工具的集成，如bug tracking工具，IDE集成等等。
本文链接

持续集成工具的选择

2011-09-16T07:02:00Z

持续集成(continuous integration)作为敏捷编程的基石现在已经被绝大多数的开发团队所广泛采用。而持续集成的工具现如今也是百花齐放，各有千秋，本文主要对比了在 Java领域中比较常见的几种CI server（因为公司要求统一整个公司的CI server）。如果想了解更多的工具，可以看这里：http://confluence.public.thoughtworks.org /display/CC/CI+Feature+Matrix，这个网页集中了决大多数比较流行的CI server，但是我发现很多的内容已经落后于实际产品的功能了，所以如果要对比的话，可能要实际到产品的站点去看一下，最好还是下载下来运行起来看。

在本文中，我主要针对以下几种CI Server作对比，这也是公司里各个项目组目前自行选用的（版本有点多，国内的多选用了一些open source的，而老外那边用得比较多的是商用版本，CruiseControl和TeamCity是我加的，因为名气非常大。）：

CruiseControl (http://cruisecontrol.sourceforge.net/)
Hudson (https://hudson.dev.java.net/)
LuntBuild (http://luntbuild.javaforge.com/)
TeamCity (http://www.jetbrains.com/teamcity/)
AntHill Pro (http://www.anthillpro.com/)
Bamboo (http://www.atlassian.com/software/bamboo/)
QuickBuild (http://www.pmease.com/)

在持续集成领域，OpenSource的CruiseControl和LuntBuild可谓老牌了，尤其是CruiseControl，出自 thoughtworks，这可是Martin Fowler的老巢啊。Hudson作为OpenSource里持续集成的后起之秀，现在已经赶超了这两个前辈，目前恐怕是使用最多的一个CI Server了。而后面4个是商用的CI Server，其中TeamCity是来自jetbrains的，jetbrains是开发著名的IDE IntelliJ的公司。Bamboo则是开发著名的Bug Tracking工具Jira和Wiki Confluence的公司atlassian公司出品的。AntHill也属于Continuous Integration界的元老，QuickBuild则是LuntBuild的商业版本，我在下面重点考量的是QuickBuild，因为 LuntBuild好像现在更新较慢了，而且QuickBuild现在好像也有了免费的所谓的Community Edition，功能齐全，只是配置数有所限制。在这些商业版本中，TeamCity应该是目前市场占有率最高的。由于公司里比较倾向使用商业版本的服务器，所以我重点比较的是后4种，捎带比较了一下CruiseControl和Hudson。TeamCity和QuickBuild都有各自的免费版本，有兴趣的也可以去看看。

功能对比

CI Server在本质上就是一个定时调度器。我们配置一系列的项目，然后设定一个定时器，让它干一些活，然后通知大家。所以很多公司都使用所谓Home- made的工具，用cron+Ant/Maven来做持续集成，这个就已经可以达到CI的最简单的功能了。而使用工具，就是我们除了基本的编译和通知功能以外，我们还有很多其它的需求，在我们公司里，选择CI Server主要考虑以下几点：

便于公司的统一管理（大约有200+ Projects需要统一管理）
对于项目本身进行流程管理: Daily Build -> QA Build -> Release Build
和公司AD（Active Directory）的连接以对用户进行权限管理
Continuous Testing的支持，即对于项目的Test要能产生出详尽的报告以及收集Test的统计数据以作为项目的分析和考量
Continuous Code Quality Analysis的支持，即能处理项目产生的Coverage报告，Code的static analysis报告，并且能收集这些报告的统计数据以作项目的分析和考量
与SCM工具的集成，我们公司主要有三种VCS，ClearCase, Subversion和StarTeam
与其它工具的集成，如bug tracking工具，IDE集成等等。

首先，我们从安装的角度来查看一下

安装CI

安装是我们开始的第一步，同时也对各个CI server都有了初步的印象。按照各自的手册，很快就装好了，我基本上选择的是Standalone的版本，就是不配置数据库，使用自带的，也不 deploy到Tomcat或者其它容器，这点，基本上每个CI Server都非常简单。所以也没看出什么好坏来。这里不得不提一下AntHill，有点小家子气，要download还得提交一个request，然后才能下载，安装，有点烦。

配置项目

在大多数的CI Server中，绝大部分都是以Project或者Project Group来进行管理，只有LuntBuild和QuickBuild比较另类，它们使用了Configuration这个术语，意即一个配置。在配置一个典型的项目的时候，即只处理基本的一个流程：CheckOut, Build, Publish Artifacts，这些工具都完成的非常好，也非常简单，我使用下来，觉得TeamCity的导航最方便，一目了然。而LuntBuild和 QuickBuild在这方面稍显人性化不足，这两个工具都没有使用wizard的模式。

下面，我接着实验配置50个测试项目，这也就开始考验一个CI Server的管理能力了（因为我们项目较多）。使用下来，我发现QuickBuild对于我而言，最实用。因为它使用Configuration而不是 Project，并且QuickBuild是这些CI Server中唯一支持树状结构配置的。我可以把Configuration配置成Team A, Team B ...，然后根据实际情况，对每个Team配置任意多个子节点，孙节点（注意，Configuration的数目在QuickBuild的 Community Edition里是要限制的，好像是最多16个），另外，QuickBuild的继承关系使用起来也非常方便，如果要管理一个大型的CI Server，没有这种继承对我而言简直是一种折磨。比如说用hudson来配置50个项目，我折腾了大半天，而用QuickBuild来，我大约只用了一个小时，我实际配置的Configuration（含有实际step定义的）只有3个，其它的都是继承下来，然后修改了一下参数而已，而如果我们需要批量修改一系列的configurations的时候，则由于有继承关系，通常我们只要去修改一下父节点的设置就可以了。TeamCity支持 Project Group的概念，类似于一种树形，但是还不完备，它只能分成两级关系，即Project Group和Project。另外QuickBuild所拥有的继承的功能，在别的CI里没有看到过，有的只是象TeamCity类似的copy project的功能。而QuickBuild在复制的能力上远远胜过其它的CI Server，它可以整个子树拷贝，这也就意味着，我可以配置一个公司用的template configuration树，然后复制出A部门，B部门，C部门，等等等等。对于不同项目之间的区别则通过变量来控制，赞一个！TeamCity在配置的方便上真得是没话说，非常直观，最酷的是象JUnit，NUnit这样的Tests，连Ant脚本都不需要写了，它直接就可以找出项目里的unit tests，这个在其它的工具里也没有看到过。至于CruiseControl，Hudson，Bamboo等则是中规中矩，无甚亮点。这个环节，QuickBuild和TeamCity胜出。

另外配置一个项目要配的就是项目持续集成的流程管理，在我们这里，基本上是这样一个流程: Daily Build -> QA Build -> Integration Build -> Release Build。所谓Daily Build，顾名思义，就是每天一次的，由development team管理以保证项目的顺畅执行，然后经过一段时间后，development team要提交到QA那边进行测试，通常是2个星期到一个月左右，随项目大小不等，QA测试结束之后，如果没有重大的问题，则提交作 Integration Test，以保证在模拟的实际环境中能正常工作，最后，如果没有什么问题的话则作Release Build以形成发布版本。对于公司里有一些Team使用敏捷编程的，则需要增加所谓的Commit Test Build，也就是developer在作每一个checkin的时候自动触发一个build，以保证build不会被这个checkin破坏（包括不会破坏unit tests和code quality)。这也是所谓的要作continuous testing和continuous code quality analysis，这些都是通过利用JUnit, NUnit，CheckStyle, PMD，Cobertura，FxCop等工具来实现的。我们在后面也会讲到，这里略过。这个环节里，个人比较喜欢AntHill Pro和QuickBuild，这两个工具都是比较强调流程的，尤其是AntHill Pro更是将其作为卖点。AntHill Pro以工作流的模式来定义这个流程，一个项目可以定义多个的workflow，对应于我们的case，就是定义Daily Build的workflow，定义QA Build的workflow，等等，然后在作promote的时候，通过选择不同的workflow来达到目的。而QuickBuild则是利用已有的 configuration的概念，定义不同的Configuration，然后在Configuration的setting里定义一个或多个要 promote的configurations。要作promote的时候，则通过点击某个build的promote按钮将其promote到指定的 configuration上去，也很方便。使用AntHill的模式，概念上很清晰，因为我们要作的是流程管理嘛，所以workflow会听起来比较容易接受。而QuickBuild则是把它绑定在Configuration上，使用起来比较简单，但是找起来要费点事，至少对于我而言是这样。 Hudson也有类似的流程管理，但是它是自动的，而promote在我们这里是需要人来作review的，也就是说要人去参与，判断究竟使用哪个版本来 promote，所以在我们这里，不是很合适。

在配置项目这个环节里，个人感觉QuickBuild比较灵活，既可以做到很简单的配置，也可以做到非常复杂的配置，而且配置起来方便性非常好。只是术语与其它的CI Server有些不同，需要熟悉一下。

Build功能

CI Server最重要的就是Build本身的功能，包括SCM的连接，用户的权限管理，Build工具的支持。首先我们来看看SCM的支持。

SCM支持

在这些CI Server中，AntHill Pro和Hudson支持的种类最多，尤其是Hudson，基本上市面上的SCM都有所支持。对于象比较常见的 Subversion，CVS，ClearCase，StarTeam，SourceSafe等，各家都已经支持了。而在上一项目中表现较好的 QuickBuild，则属于在SCM里支持最少的一家，它还不支持git，Team Foundation Server，这个目前已经很流行的两种SCM，实在有些遗憾。不过瑕不掩瑜，QuickBuild在支持SCM的时候，由于使用变量的支持，却是多家 CI Server中最灵活的一家，它可以使用变量来配置SCM的URL，而其它的，则是通过定义一个基本的URL，然后针对不同项目来定义各自的SCM repository。而QuickBuild还有一个它自有的QuickBuild Repository，用于在不同的Configuration中传递artifacts，实际用起来也很方便，比如说我们在一个项目里要用到别的项目的 artifacts，那么就可以定义一下这个repository。当然，这个功能也可以通过Maven的repository来完成来达到相同的目的。 TeamCity也提供了类似的机制，只不过TeamCity的Repository其实就是一个Ivy的扩展。

SCM的数据在这些CI Server中都有体现，从每一个Build的change sets到历史统计。说明现在大家都很重视对于这些数据的收集和分析。其中TeamCity能直接从Web页面上直接调用IDE来打开这些改动的文件是一大亮点，毕竟是做IntelliJ的公司啊！

用户管理

这个基本上是每个CI Server的必备功能了，基本上都是既可以用内置的数据库管理（Hudson好像没用数据库），又可以连接LDAP服务器。我只是简单测试了一下，没有深入，也就没有什么发言权了。

Build的Dependencies管理 (Dependent Builds)

在实际的项目中，我们常常会出现项目之间的依赖关系，比如说A项目依赖于B项目，B项目依赖于C项目。所以当我们要编译A项目的时候，我们需要先编译C项目，然后编译B项目，最后再来编译A项目，这样做的好处显而易见，就是保证我们总是使用最新开发的code来编译一个版本，如果发生了什么问题，我们也可以很容易的知道究竟是哪个项目break了整个build的流程。这个功能基本上所有的这些CI Server都有提供，而能力各有千秋。TeamCity在这里属于最弱的一个，它只能通过定义Ivy来达到Artifacts在不同项目中的依赖管理，而AntHill Pro，Bamboo和QuickBuild则都有提供两种类型的dependency管理，即artifacts和项目本身的依赖管理。不过 TeamCity却有另外的杀手锏，就是导入项目的功能，它支持从IntelliJ的项目，Maven的项目中直接导入创建这种依赖关系。

分布式Build Pool

由于公司的项目繁多，平台繁多，对于一个项目需要分布到不同的平台去编译，测试，这时候就需要建立一个Build Pool了，基本上上述各家的CI Server都已经支持了这种分布式的build pool，其实质是利用了grid computing技术来进行管理。也就是一个build server带上一群的build agent，然后把build的任务分布到不同的agent上去执行。在这里不得不再赞一个QuickBuild了（呵呵，这个QuickBuild好像给人惊喜不断啊），其实QuickBuild的agent与其它家的倒没什么不同，只不过就是一个computing unit，关键在于QuickBuild里配置一个configuration，它使用了step的概念（这个QuickBuild的术语倒是不少嘛），这个step在AntHill Pro里也存在，关键在于这个step是可以分布的，也就是说，我配置一个项目的时候，可以定义一系列并行的分布式的step，这样对于管理和收集 artifacts非常方便，我们可以定义Test On Windows, Test On Mac, Test On Linux，然后设置一下运行这些step的时候需要什么类型的agent，QuickBuild就可以把这些任务分布到这些平台的agents上去运行了。而其它家的可能是因为收费的方式，象TeamCity，一个build只能在一个agent上运行，我如果要做到同样的效果，就需要定义出三个项目，然后让这三个项目在不同的agents上运行，最后，还要再定义一个项目，让这个项目去收集它们的artifacts，非常麻烦。Bamboo和 AntHill也类似于TeamCity。而Hudson在这块的能力很弱，个人感觉不如其它的产品强大，而且使用起来也更复杂一些。

Report功能和统计

上述各家CI SERVER都提供了Report的功能和统计的功能，在这个领域里，Hudson毫无悬念的是支持报告类型最多，最全的（谁叫咱OpenSource 呢，有的是人开发）。Bamboo属于支持报告类型最少的，不过也有很多第三方的plugin供选择。我们所关心的几个reports都有被各家支持，其中QuickBuild的report给我的感觉最华丽，不过好像是参考google analytics来的，从界面上看和analytics简直就是一个翻版。在使用上，QuickBuild和TeamCity的最方便，直接点报告中的链接就可以作一些过滤。在统计信息方面，各家对tests的统计都非常完备，这也从一个侧面反应出test driven现在那是深入人心啊。在支持Test Driven方面，TeamCity是力拔头筹，得益于开发IntelliJ的经验，TeamCity不仅可以自动寻找出项目中的unit tests（你不用在Ant脚本里调用junit task，或者在Maven里调用surefire），而且对于上次运行失败的test cases，它可以在下次build中自动先运行，这样就可以避免一个build运行了很久才发现上次失败的test还没有被更正过来呢，强！

另外，要提一下的是QuickBuild中那个Build的Dashboard我非常喜欢，对于一个项目当前的状况可以一目了然，有多少个 tests成功了，多少失败了，多少被fix了，多少还没有fix，总之，信息很丰富，不过就是配置起来有点复杂，需要我去一个报告一个报告去加 step，如果能做到TeamCity的程度，简直就是完美了。

对于其它的CI Server则是亮点不多（其实也很强，只不过是对比而言，我觉得TeamCity和QuickBuild更强，更好）。

与第三方工具的集成

在与第三方工具的集成中，Hudson遥遥领先，是所有CI Server里Plugin最多的。可以和FaceBook，Google Calendar，Twitter，反正基本上你能想到的，它都有。不过对于我们而言，好多Plugin没有太大的价值。Bamboo在与它自己的几个产品中集成度也非常好，比如说Jira，Wiki，Clover等。这几个我们公司都有用到，在这点上非常理想。

价格

不得不考虑一下价格的因素，好像记得有人说过，Price is nothing, but price is everything，尤其在这个金融危机的年代里。这点，勿庸置疑，OpenSource永远是最好的。而在商用的这几个里QuickBuild最便宜，它使用的是Site License，一个Site收$2999，AntHill最贵，我询问了一下，按我的配置，随便搞搞就要$10000了，TeamCity的入门也很便宜，$1999带3个agents，可是针对我们的情况，算了一下也要上$8000了（它是按agent收费的），Bamboo也很贵，按照它的功能而言，我觉得性价比不是很好。

总结

综合各方面因素的考虑，我们最终选择了QuickBuild，虽然这个产品名声不是很大，不过想想它的客户中，不乏象Cisco，HP这样级别的公司，应该还是可以值得信赖的吧。另外就是我们使用下来觉得它还是拥有诸多亮点，对于我们的统一管理来说，可谓是方便至极。另外价格方面考虑也很不错。当然如果你的团队不是很大，那么选择QuickBuild的Community Edition和TeamCity的Professional Edition都是非常值得的，这两者都是免费的，而且QuickBuild的Community Edition功能没有任何裁剪，只是限制了一下configuration的数目，非常适合要求比较高而项目不是很多的团队。

好了，有太多太多需要讨论的东西了，CI这个领域现在还处于高速发展阶段，本文纯属探讨，欢迎大家拍砖。由于时间有限，对每个产品了解的不是很深入，错误在所难免，如果我有什么地方不是很准确，也欢迎告诉我。

转自：http://www.iteye.com/topic/482658

本文链接

深入了解CLR异常处理机制

2011-08-03T13:06:00Z

CLR实现的异常处理具有以下特点：

（1）处理异常时不用考虑生成异常的语言或处理异常的语言。换句话说，可以在C#程序中捕获用Visual Basic.NET编写的组件中引发的异常。

（2）异常处理时不要求任何特定的语言语法，而是允许每种语言定义自己的语法。

（3）允许跨进程甚至跨计算机边界引发异常。

（4）以一致的方式处理托管和非托管代码引发的异常。

任何一种.NET编程语言所实现的异常捕获功能，本质上都是CLR异常处理系统所提供的功能的一个子集。

如果使用IL编写程序，则可以使用CLR异常处理系统的所有功能。

显然直接使用IL编程不太现实，但如果希望能深入地了解CLR异常处理系统，分析编译器生成的IL指令代码是一个好方法。

1 方法的异常处理表

请看以下这个简单的C#程序（参见示例项目CatchException）：

class Program

{

static void Main(string[] args)

{

try

{

int number = Convert.ToInt32(Console.ReadLine());

}

catch (FormatException ex)

{

Console.WriteLine(ex.Message);

}

finally

{

Console.WriteLine("finally");

}

使用ilasm工具反汇编出来的代码框架如图 1所示：

图 1 CLR级别实现异常处理的代码框架

上述代码中涉及到的与异常处理相关的IL指令有两条：

（1）leave.s <int32>：离开受保护块，从当前位置转移并执行指定地址处的IL指令。

（2）endfinally：标识finally语句块结束。

从上述代码中我们可以知道：

C#编程语言中“单层”的try…catch…finally结构会被转换为“两层嵌套”的类似结构，CLR通过执行leave指令在IL汇编程序的.try、catch和finally指令块间跳转，实现应用程序所定义的异常捕获和处理工作。

图 1所示Main()方法IL代码是经过ildasm程序出于易于阅读的目的而调整过的，它实际上“隐瞒”了真正的IL指令代码序列。

请从ildasm的“View”菜单中取消“Expand try/catch”选项（默认情况下此选项是选中的），可以看到C#编译器生成的IL代码的“真面目”（图 2）。

图 2“真实”的IL指令代码序列

如图 2所示，具体功能代码被统一地放置在方法IL代码的前半部分，而用于实现异常捕获的代码放在方法IL代码的后半部分，我们将其称为“异常处理表（Exception Handling Table）”，“ret”指令是两部分的天然分界线。

C#编译器通过在合适的地方插入leave.s指令使得在无异常情况下永远不会执行到异常处理代码。

异常处理表中的每个表项是一个“异常处理子句（Exception Handling Clause）”，IL汇编程序使用.try、catch、handler和finally关键字，配合相应地址给前面的功能代码“自然分块”。

位于方法IL代码后半部分的异常处理表是CLR实现异常捕获的关键。

下面我们简要介绍一下CLR如何使用异常处理表捕获并处理异常。

2 CLR如何捕获并处理异常

对于任何一个.NET应用程序中的类，其所包容的方法都包容着一个异常处理表，如果此方法中没有使用try…catch…finally，则此表为空（即此方法生成的IL指令中不包容任何的异常处理子句）。

当.NET应用程序运行时，如果正在执行的某个方法引发了一个异常，CLR会首先将相应的异常对象推入计算堆栈，然后扫描此方法所包容的异常处理表查找处理程序，其处理过程可以简述如下：

CLR获取引发异常的IL指令地址，然后从上到下地扫描异常处理表，取出每个catch子句中“.try”关键字后面跟着的用于定位“块”的起始和结束地址，判断一下引发异常的IL指令地址是否“落”入此地址范围中。如果是，取出“catch”关键字后跟着的异常类型，比对一下是否与抛出的异常对象类型一致（或相兼容），如果这个条件得到满足，CLR取出handler后的两个IL地址，“准备”执行这两个地址指定范围的IL指令（这就是catch指令块中的异常处理代码）。

如果本方法所包容的异常处理表中找不到合适的catch子句，CLR会依据引发异常的线程所关联的方法调用堆栈，查找此方法的调用者所包容的异常处理表。

此过程将一直进行下去，直到找到了一个可以处理此异常的处理程序为止。

假设CLR在整个方法调用链的某个“环节”（即调用此方法的某个“祖先”方法）所包容的异常处理表中找到了可处理此异常的catch异常处理子句，它就作好了执行此子句所定义的异常处理指令代码块的“准备”。

“扫描并查找相匹配的catch子句”过程，是CLR异常处理流程的第一轮。

当找到了合适的异常处理代码后，CLR再“回到原地”，再次扫描引发异常方法所包容的异常处理表，这回，CLR关注的不再是catch子句，而是finally子句，如果找到了合适的finally子句（只需判断一下引发异常的IL指令地址是否“落入”某finally子句所监视的IL指令地址范围之内即可），CLR执行finally子句所指定的处理指令（即其handler部分所定范围内的IL指令）。

“扫描并查找相匹配的finally子句”过程，是CLR处理异常流程的第二轮。

这“第二轮”的扫描，开始于引发异常的方法，结束于最顶层的包容了那个引发异常的方法的方法（这句话很拗口，举个例子就清楚了，比如，如果你有一个嵌套了很深的函数调用语句，并且在被调用的最底层的函数中引发了异常，而你在顶层Main()函数中又用try...catch...finally包围了这一函数调用语句，则第2轮扫描会“直达”最顶层Main（）方法的异常处理表，不会中途停止于找到了合适catch子句的那个中间“站”。

在所有“下层”finally子句执行结束之后，相应的catch子句所指定的异常处理代码块才开始执行。之后，与此catch子句“同层”的finally子句所指定的异常处理代码块得到执行。

但事情还没完，现在轮到所有包容被执行catch子句所在方法的“父辈”方法中的finally子句执行。

经过两轮的扫描，CLR就完成了对.NET应用程序引发异常的捕获与处理工作。

这里还遗留着一个问题：

CLR找不到合适的catch异常处理子句怎么办？

如果某.NET应用程序中根本没有定义处理某种异常类型的代码，而此程序在运行时又真的引发了这种类型的异常（真是哪壶不开提哪壶），那么CLR在第一轮扫描过程中，会一直“上溯”到Main()方法所包容的异常处理表，然后“无功而返”。

紧接CLR会进行第二轮的扫描，执行所有“应该被执行”的finally子句。

故事的尾声是：在执行完了所有finally代码后，CLR强制中止此进程所创建的所有线程（哪怕它们运行正常），由操作系统显示一个“出错”对话框，等用户响应后，或结束或附加一个调试器来调试这个进程。

3 CLR的异常筛选和故障响应

上一小节介绍了.NET应用程序中的异常处理表，并介绍了构成异常处理表中的两种类型的异常处理子句（catch和finally）。事实上，CLR异常处理表中还可以包容另两种类型的子句：异常筛选（filter）子句和故障（fault）响应子句。

我们分别来看看这两种子句有什么特殊性。

1 异常筛选

在Visual Basic.NET中，有一个When关键字用于控制是否捕获特定的异常。

请看以下代码（示例程序VBException）：

Module Module1

Sub Main()

Dim ShouldCatch As Boolean = True

Try

Dim number As Integer = Convert.ToInt32(Console.ReadLine())

Catch ex As FormatException When ShouldCatch

Console.WriteLine(ex.Message)

End Try

End Sub

End Module

当ShouldCatch=True时，FormatException 对象将被捕获被处理，否则，此异常将导致进程被CLR强行中止。

下面列出ildasm反汇编示例程序集得到的IL代码，代码较长，为了方便阅读，我用“====”划分出了其中的代码块，并加了详细的注释，对于不熟悉IL指令或没有耐心看这些枯燥代码的读者，可以直接看代码后的文字说明：

.method public static void Main() cil managed

{

.entrypoint

.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )

// Code size 60 (0x3c)

.maxstack 3

.locals init ([0] bool ShouldCatch,

[1] int32 number,

[2] class [mscorlib]System.FormatException ex)

//=================================================

// IL_0000到0001：初始化ShouldCatch=True

IL_0000: ldc.i4.1

IL_0001: stloc.0

//================================================

//从0002到000d：“保护块”

IL_0002: call string [mscorlib]System.Console::ReadLine()

IL_0007: call int32 [mscorlib]System.Convert::ToInt32(string)

IL_000c: stloc.1

IL_000d: leave.s IL_003b //没有异常，则跳去执行ret指令结束

//=====================================================

//从IL_000f到0026：异常筛选块，最终结果（为0或1）将会被压入到计算堆栈中

//判断异常是否是FormatException

IL_000f: isinst [mscorlib]System.FormatException

IL_0014: dup //复制计算堆栈栈顶值，再压入堆栈

IL_0015: brtrue.s IL_001b //如果异常是FormatException，跳转到IL_001b

//如果异常不是FormatException，将0压入堆栈，然后跳转到IL_0026

IL_0017: pop //出栈

IL_0018: ldc.i4.0

IL_0019: br.s IL_0026

IL_001b: dup //复制计算堆栈栈顶值，再压入堆栈

IL_001c: stloc.2 //保存异常对象到方法局部变量ex中

IL_001d: call void [Microsoft.VisualBasic]

Microsoft.VisualBasic.CompilerServices.ProjectData::SetProjectError(

class [mscorlib]System.Exception)

// IL_0022到IL_0024：将ShouldCatch值和常量0先后压入计算堆栈，

// 比较这两个值谁大谁小，结果（为0或1）再压入计算堆栈

IL_0022: ldloc.0

IL_0023: ldc.i4.0

IL_0024: cgt.un

//依据两数比较结果决定是否调用IL_ 0028到003b所定义的异常处理块

IL_0026: endfilter

//======================================================

//IL_ 0028到003b：异常处理块

IL_0028: pop

IL_0029: ldloc.2

IL_002a: callvirt instance string [mscorlib]System.Exception::get_Message()

IL_002f: call void [mscorlib]System.Console::WriteLine(string)

IL_0034: call void [Microsoft.VisualBasic]

Microsoft.VisualBasic.CompilerServices.ProjectData::ClearProjectError()

IL_0039: leave.s IL_003b

IL_003b: ret //方法运行结束

//=========================================

//异常处理表

.try IL_0002 to IL_000f filter IL_000f handler IL_0028 to IL_003b

} // end of method Module1::Main

解析一下上述IL代码中的关键点。

在方法最后的“异常处理表”中包容了一个“异常筛选”子句，其中明确地定义从IL_0002到IL_000f是“保护块”，如果在此范围内的IL指令引发了异常，则将跳去执行IL_000f处的指令：

IL_000f: isinst [mscorlib]System.FormatException

isinst指令将判断一下程序抛出的异常是不是FormatException。如果不是，后面的IL指令会将0压入堆栈，否则，依据ShouldCatch变量的值，将0或1压入堆栈。

IL_000f到IL_0026构成了“异常筛选块”，此代码块的执行结果不是0就是1（注意此结果会被压入计算堆栈）。

“异常筛选块”中最后endfilter指令非常关键，它检查保存在计算堆栈中的值，如果是1，则结束第一轮扫描，并为在第2轮扫描中执行异常处理表中所定义的“异常处理块（示例程序是从IL_ 0028到003b范围内的IL指令块）”做好了准备，此代码块其实对应着Visual Basic.NET示例程序中放在Catch语句块中的VB代码。

如果计算堆栈中的值是0，CLR将跳过本方法中定义的异常处理块，转去搜索上一级“父辈”方法的异常处理表，重复上述处理过程，如果还找不到合适的异常处理子句，再去搜索“父辈的父辈”，最后可能会搜索到最远古的“北京猿人”级别的方法（比如Main()方法）才结束。这就是CLR使用filter子句的第一轮搜索过程。

紧接着CLR会进行第二轮搜索，执行合适的finally子句（其实还包括后面马上要介绍的fault子句）所定义的指令代码块。其处理流程与上一小节介绍的一样，就不再废话了。

注意：

由于C#编译器不生成使用CLR“异常筛选”功能的IL指令，因此，C#语言不能使用CLR提供的“异常筛选”功能。

2 故障响应

除了catch、finally和filter三种类型的异常处理子句，CLR还支持一种名为“fault”异常处理子句。

它的样子是这样的：

.try 起始地址 to 结束地址 fault handler 起始地址 to 结束地址

fault异常处理子句的功能与finally子句非常类似，不同之处在于：

无论被保护块是否引发了异常，finally子句所定义的处理指令块都会被执行。而fault子句所定义的处理指令块“仅当”被保护块引发异常（不管是什么类型的异常）时被执行，如果被保护块未引发任何异常，则不会执行此fault子句所定义的处理指令块。

由此可知，可以使用 fault异常处理子句让CLR“响应”应用程序引发的任何一种异常，所以我们可将fault子句称为“故障响应”子句。fault子句的功能类似于消防员的职责（平时无事，一旦有突发火灾发生，灭火就是消防员义不容辞的责任）。

3 小结

本文深入介绍了CLR所提供的异常处理机制，可以看到， C#和Visual Basic.NET等编程语言所提供的异常处理机制都只是CLR异常处理系统功能的子集。

应该来说，在实际开发中很少有这个必要去深入探究CLR异常处理的内部工作原理，大多数情况下，程序员们只要了解清楚所使用的编程语言所提供的异常处理功能，并会用就行了。

然而，如果您的好奇心还没有被中国的应试教育所泯灭的话，不满足于“知其然”，而且要“知其所以然”，那么，我相信本文的内容能部分地满足您对技术“刨根问底”的需求。

转自：http://www.cnblogs.com/bitfan/archive/2009/12/03/1616550.html

本文链接

持续集成理论和实践的新进展

2011-08-03T12:07:00Z

最近雷镇同学将Martin Fowler先生的著名论文《持续集成》第二版翻译成中文并发布出来，掀起了国内对于持续集成理论和实践讨论的新的高潮。笔者在本文中将全面对比持续集成论文前后两版的异同，分析并展示ThoughtWorks在持续集成领域的理论和实践方面的研究成果，以图对国内企业实施持续集成起到参考和借鉴作用。需要说明的是，本文所介绍的内容毕竟限于笔者的水平，并且主要是ThoughtWorks内部开发和对外咨询实践的总结，所以未必对读者所遇到的情况是适用的，请自行甄别。

《持续集成》第二版虽然是最近才翻译出来，但是实际上Martin Fowler先生完成此文是在5年前的事情。这五年恰好是ThoughtWorks中国公司快速成长的五年。在这五年内ThoughtWorks中国在持续集成领域也有很多的发展，这包括：著名的持续集成工具Cruise主要是由中国公司负责开发¹; 中国公司帮助国内很多大中型企业完成持续集成实施和相关的流程改进;2009年中国公司的很多同事对于持续集成的度量进行了深入的讨论并且最终由胡凯将其实现为一款软件iAnalysis;2010年至2011年成功的交付了从需求提供方到多个技术服务提供商的持续集成方案，以及企业级自动化中心方案。所以，本文主要包括两部分内容，一部分是通过对比第一版与第二版的异同介绍2000年到2006年之间持续集成领域的主要发展，另一部分则是介绍第二版发表之后持续集成领域的新进展。读者如果之前没有阅读过《持续集成》论文的第二版，建议将本文第一部分一同阅读，因为本文并非对论文的重述，所以很多地方还需要参考原文中的内容。

第一部分《持续集成》第一版与第二版

《持续集成》第一版由ThoughtWorks首席科学家Martin Fowler先生和Matthew Foemmel共同完成²，第二版由Martin Fowler先生更新。

《持续集成》的第一版中并没有给出比较正式的定义，虽然作者在文中说是借鉴了XP实践中的术语，但是目前能看到的XP实践中对持续集成的定义实际上大多数都是指向了Martin的文章。那么我们还是来看看第二版中给出的定义。

持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成会经过自动构建（包括自动测试）的验证，以尽快发现集成错误。许多团队发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。³

第二版相对于第一版增加了不少内容，其中最重要的几点包括：

详细介绍了使用持续集成进行软件开发的工作流程。
突出了配置管理在持续集成实践中的作用。
提出分阶段构建的概念。
增加了持续集成报告的内容。
增加了持续部署的内容。
给出了引入持续集成的建议。

持续集成的流程

在持续集成领域，我们经常会用到的一个术语就是“构建（Build）”。很多人认为“构建=编译+链接（Build=Compile+Link）”，Martin在第一版中指出一次成功构建包括：

所有最新代码从配置管理工具中取出（check out或者update）。
所有的代码从干净的状态开始编译。
将编译结果链接并部署，以备执行。
执行部署的应用并运行测试套。
如果上述所有操作没有任何错误，没有人工干预，并通过了所有测试，我们认为这才是一次成功的构建。

实际上，目前很多团队对成功持续集成构建的定义基本上是符合上述定义的。这个定义的特点在于它是相对独立的，它是一个从干净状态的源代码最终获得可运行的通过验证的软件的过程。

Martin在第二版中则在成功构建的基础上给出了成功集成的定义。成功集成关注的不是一次“编译+链接+部署+验证”的过程，而是从开发流程的角度介绍一次完整的在持续集成约束下的代码提交过程⁴：

将已集成的源代码复制一份到本地计算机。
修改产品代码和添加修改自动化测试。
在自己的计算机上启动一个自动化构建。
构建成功后，把别人的修改更新到我的工作拷贝中。
再重新做构建。
把修改提交到源码仓库。
在集成计算机上并基于主线的代码再做一次构建。
只有这次构建成功了，才说明改动被成功的集成了。

下图展示了Martin对成功集成的定义：

当然在第一版的“代码提交”这一节，Martin也提到了本地构建的概念，只是不如第二版这么明确。

配置管理

Martin在第一版中有两处提及配置管理，分别是：单一代码源（Single Source Point）和代码提交（Checking In）。第二版中则包括：通过持续集成构建特性（Building a Feature with Continuous Integration）、只维护一个代码仓库（Maintain a Single Source Repository）、每人每天都要向主线提交代码（Everyone Commits To The Mainline Every day）、每次提交都应在集成计算机上重新构建主线（Every Commit Should Build the Mainline on an Integration Machine）。不仅条目数量上增加明显，作者提出的很多实践都是基于配置管理来讲的。

工具

配置管理是持续集成的输入。在第一版中作者所推荐的配置管理工具是CVS，到第二版中作者推荐的配置管理工具已经换成了SVN⁵（参见第二部分中的配置管理工具部分）。

分支策略

实现进度与质量的平衡是配置管理的重要目的。Martin在第二版中对滥用分支给出了警告：

尽量减少分支数量。典型的情况是保持一条主线，......，每个人都从这条主线开始自己的工作。（对之前发布版本进行Bug修正或者临时性的实验都是创建分支的正当理由。）

但是这里给出的建议对于大型团队来说并不十分合适。我们将在第二部分对于配置管理的分支策略进行详细描述。

内容

Martin在第一版中给出的原则是：

任何人都可以找到一台干净的机器，连上网，通过一个命令就可以取得要构建所开发的系统需要的所有源文件。

第二版中的原则增加了对构建的支持⁶：

任何人都可以找到一台干净的机器，做一次取出（checkout）动作，然后对系统执行一次完整的构建。

分阶段构建（Staged Build）

分阶段构建是Cruise（已经更名为Go）引入的重要概念。其主要的意义在于：

分离关注度不同的验证阶段，比如Commit Build和Regression Tests，团队会对不同的验证阶段采取不同的策略
构建流程可视化
通过分阶段并发构建来缩短反馈周期

当构建的时间过长时，我们通常会要求开发人员只运行速度较快的价值较高的构建阶段就可以继续自己的开发任务，而不必等待漫长的次级构建完成。这里作者提到ThoughtWorks不同的团队有很多有趣的实践，我们将在第二部分向读者介绍其中的一部分。

报告

作者在第二版中专门拿出一节“每个人都能看到进度（Everyone Can See What's Happening）”来介绍有关持续集成报告的内容。因为：

持续集成的目的是为了沟通。

这是第二版相对于第一版来说一个非常明显的变化。在第一版中通知的手段还主要是电子邮件，实际上在作者撰写第二版的时候，ThoughtWorks已经不赞成将电子邮件作为主要的持续集成通知工具了。更好的沟通工具包括音乐、熔岩灯、显示器等。

对于沟通的重视从工具的角度也可以体现出来。Cruise Control最主要做的事情是任务调度，在报告部分做的相对来说非常粗糙，比较有价值的报告大部分是从Cruise移植过去的。Cruise在从一开始就非常重视这一点，通过Cruise你可以非常清晰地知道，代码发生了什么变化、正在进行的构建的状态和历史构建的状态。网页的形式对于分布式团队来说具有不可替代的优势。

正如我们前面所说的，音乐、熔岩灯等物理手段，具有更强的信息辐射能力。站起来往周围看一看就知道哪个团队的构建成功了，哪个失败了。

持续部署

持续集成实践有一个基本的思想就是：越是痛苦的事情，越要经常做。集成之后更令人心惊胆颤的事情就是——部署。部署到生产环境的流程通常要严格得多，然而所有的工作必须经历了生产环境的验证才算是成功的，所以——持续部署才是王道。Martin在第二版中建议：

你应该有一个脚本帮助你很容易地将系统部署到生产环境中去。......同时要特别考虑的是要能够自动回滚。

引入持续集成的建议

作者在第二版中特别给出了逐步引入持续集成的建议。包括：

引入版本控制。
实现自动化构建。
添加自动化测试。
加快提交构建。
寻找帮助。（比如ThoughtWorks）

第二部分持续集成领域的新进展

正如前文所说，ThoughtWorks中国公司在过去的几年里面对于持续集成实践和帮助客户实施持续集成都积累了很多的经验，同时在理论体系方面也更加丰富完整。这也使ThoughtWorks在这个领域继续保持了行业领先的位置。

正如我们在第一部分讲到的，持续集成不应该只作为一个孤立的实践来应用。我们的经验表明如果只把持续集成作为一个孤立的实践应用很难从持续集成长期受益。持续集成往往进入“长红”或者“长绿”的不正常的状态。长红意味着系统长期无法集成；长绿则往往意味着缺少足够的验证。为了术语上的澄清，我们明确地将持续集成的定义区分为狭义的持续集成和广义的持续集成。

狭义的持续集成：基于某种或者某些变化对系统进行的经常性的构建活动。

广义的持续集成：软件开发团队在上述活动的约束下所采用的开发流程。

狭义的持续集成

一般来说，狭义的持续集成包括如下几个方面：持续检查、持续编译（链接）、持续验证、持续部署、持续基础设施、持续报告等6个方面。

持续检查

持续检查的目的是保证代码风格一致，主要关注于代码的静态质量和内部质量，比如变量命名方式、大括号位置等等。大部分的现代集成开发环境（IDE）都具备实时检查代码质量的功能。为了保证主线上的代码质量能够达到一致的标准，应当在持续集成脚本中加入静态检查阶段。比如，Java的PMD、 FindBugs等等。

持续编译

持续编译是一个很朴素的想法，就是保证主线上的代码始终处于可编译的状态。但是这对于很多大中型团队来说却并非想当然的简单。这是因为很多团队并未采用集体代码所有权策略，导致存在依赖的团队的代码无法编译。针对这样的问题，一方面我们建议采用集体代码所有权；另一方面，对于确实因为安全原因需要隔离的代码应该明确边界与接口，很少存在大部分代码需要对大部分人保密的情况。

持续检查和持续编译是持续集成中最基本的验证手段。

持续验证

持续验证的目的是检查主线上的代码是否能够实现所要求的功能，或者已有的功能是否被破坏。在大部分的构建中，验证部分是耗时最长、成本最高的部分，但同时也是收益最大的部分。在这个阶段，我们看到的主要问题是验证不充分和验证时间过长。针对这样的问题，我们通常采用分层分级的持续集成策略。后面有详细的描述。

持续部署

于大型软件应用来说，部署往往是一个费时费力又容易出错的步骤，因为这里面涉及到数据迁移、版本兼容等各种棘手的问题。持续部署的思想是将这些工作标准化自动化，使其能够可靠地、自动地、快速地运行。持续部署是当前DevOps运动中的热门话题之一。

持续基础设施集成

现代大型软件开发，尤其是互联网应用开发中经常依赖于一些常见的基础设施——比如Spring、Tomcat、Database等等。这些基础设施发生变化的时候，我们应当及时地触发持续集成，以确保我们的系统是能够与新的基础设施一起工作的。

持续报告

报告是将持续集成的状态以适当的形式展现给关系人的基本手段。报告是持续集成的晴雨表，所以它必须直观、易懂，而且对关注点不同的角色展现不同的内容和粒度。比如，开发人员可能更关心错误的日志；项目经理可能更关心测试覆盖率；产品经理可能更关心持续集成通过率的趋势等等。

广义的持续集成及持续集成策略

当要把持续集成实践应用到团队的时候，有很多额外的技术或者非技术因素需要考虑。

组织结构

持续集成是一个重要的沟通工具，而开发过程中两个最需要紧密沟通的角色就是开发和测试。在我们常见的组织结构中开发和测试往往隶属于不同的部门，甚至这些部门隶属于不同的高级经理。这往往会给持续集成的推广带来很大的阻力。这是因为持续集成从环境搭建到运行维护都需要两种角色的通力合作。我们的经验是这类涉及到人力资源的事情除非某一级“共同的大老板”出面，否则是很难协调的。“借调”这样的方式往往不能保证效果。

流程

放到团队的角度看待流程应当更加关注于各个成员之间的配合。每个开发人员提交代码之前应当确保是经过本地构建的；开发人员在提交之前应该确认主线上的代码是通过了持续集成的；测试人员测试的版本应该是通过了某次持续集成的，并且有相应的具体版本信息。

为了保障流程的顺利执行，我们还经常采用持续集成看板、提交令牌等辅助手段。

环境

环境是指持续集成运行时所依赖的软件和硬件的集合。我们经常遇到的一个问题是，软件在一台机器上能够通过持续集成的验证，而在另一台机器上则不能通过。这通常是因为我们对持续集成环境的定义不明确造成的。所以在搭建持续集成和在组织内推广持续集成的时候，我们需要特别注意持续集成环境的标准化，明确指出持续集成运行时依赖哪些第三方库，机器配置如何，端口和网络状况如何等等。

我们经常采用将持续集成环境加入配置管理的方式来解决环境标准化的问题。

分层

在大型团队（超过100人）中，扁平的开发组织结构是运行起来是比较困难的。常见的做法是按照特性，将团队划分为10人左右的小团队。一般来说，如果团队数量超过10个，还会再增加一层架构。这时候，配置管理的策略也应当做出调整。常见的做法是为每个团队拉出一个分支，设置一个集成分支用于将各个特性分支的内容整合在一起。需要注意的是，这里每个分支都应该具备所有代码的访问权限，也就是所有分支是同根的、等价的。

测试分级

在实施持续集成时，对于测试的类型应该有比较明确的定义。一般来说，我们经常把测试分为三级——单元测试、集成测试和系统测试。这是一个很大的话题，这里只是说明此处的单元测试并不是指针对函数的测试。虽然单元测试主要是函数基本的测试，但是每个单元测试应该针对的是特性或者对应代码在实现该特性上所发挥的作用。

单元测试的运行速度通常非常快，应该在数秒到数分钟。单元测试应该覆盖绝大部分的特性需求。集成测试单个测试的运行速度通常会比单元测试慢一个数量级，比如存在文件读写或者其他的IO和网络操作。集成测试主要用于保证系统的各个组件之间的调用是工作的。系统测试的运行速度一般会比集成测试慢，通常需要将整个系统运行起来，比如Web开发中的selenium测试。系统测试主要用于测试系统的正确路径（Happy Path）可以工作。有的团队会开发很多基于整个系统的回归测试，也属于系统测试。就场景的覆盖而言，单元测试>集成测试>系统测试，从运行时间来看则相反。

持续集成的成熟度评估

在帮助客户实施和推广持续集成的过程中我们逐渐总结出一些原则，帮助客户评估现状，分析和设计未来的目标。该评估方法借鉴了ThoughtWorks敏捷成熟度模型中有关配置管理、测试、构建等内容，并做了适当的简化。

构建：

级别	描述
3+：对外防御的	团队能够根据自己的需要，协调其他团队的持续集成，当依赖的其他团队的代码和组件或者第三方库和基础设施发生改变时自动进行构建。团队对于外部依赖的可靠性有信心。
3：对内防御的	构建是自动的。由测试和检查来保证团队内部的开发质量。持续集成的修复具有最高的优先级。团队对持续集成的结果有信心。
2：频繁的	构建是自动的，而且构建的速度较快。构建的触发条件是明确的，通常每次代码提交都会触发构建。团队中的每个人都会触发构建，并且了解构建的状态。
1：重复执行	构建是自动的，但是执行的不够频繁。构建的触发是随机的或者频率是非常低的（低于每天一次）。构建的速度通常非常慢，比如一次构建超过半个小时。
0：可重复的	主要依赖于手动的方式构建软件，但是每次构建的方式都是相同的或者相似的。通常有相关的文档的指导。经常团队指定某个人负责构建软件，虽然大部分人都能够做这件事情。
-1：手动的	主要依赖于手动的方式集成软件。每次集成的方式可能不一样。经常团队中只有个别人能够将软件集成起来。

测试：

级别	描述
3+：全面集成的	全团队对测试负责。测试驱动整个开发过程。测试与构建完全集成。
3：测试驱动的	业务分析人员和开发人员均参与测试。测试在构建过程中自动执行。开发人员实践测试驱动开发。
2：集成的	开发人员参与测试。部分测试集成在构建过程中执行。大部分测试在软件开发过程中执行。
1：共享的	开发人员参与测试。测试并未集成在构建过程中。部分测试在软件开发过程中执行，大部分测试在软件开发结束后执行。
0：审查的	测试由专门的测试人员负责。有部分测试是在软件开发过程中执行。但大部分测试在软件开发结束后执行。
-1：独立的	测试由专门的测试人员负责。仅在软件开发结束后执行。

配置管理：

级别	描述
3+：企业级的	企业有统一的配置管理策略。
3：跨项目的	配置管理在多个项目之间协调。
2：自动的	配置管理策略与持续集成策略紧密结合，团队成员有频繁提交的意识。一般采用乐观锁策略，原子提交。
1：集成的	版本管理下的内容是受控的。通常在版本管理中的代码是可以编译的。开发人员能够访问到自己工作所需要的代码。开发人员按照一定的规则访问配置管理工具和提交代码。一般采用悲观锁策略。版本管理工具和构建过程集成在一起的。
0：基本的	有基本的版本管理。但版本管理下的内容不全面，或者不足以支撑团队的开发。
-1：无配置管理	没有配置管理。或者使用方式完全错误。

常用实践和工具

持续集成看板⁷

问题：

我们需要让整个团队能够方便快捷的了解持续集成的状态。

上下文：

在完成了基本的构建基础设施的搭建之后，我们需要让团队成员及时获得持续集成的状态信息。传统的邮件方式可能会使人厌烦，或者错过重要的构建信息。

解决方案和实现：

安装一个显示器，将构建的状态信息以简明的方式展示在显示器上。将显示器放置在团队所有成员都能够很容易看到的地方。

个人构建中心

问题：

在某些情况下，构建环境的成本很高，而我们需要每一个开发人员提交之前完成一次个人构建。

上下文：

有些测试是依赖于设备的，而这些设备非常昂贵，并且配置复杂，所以无法给每个开发/测试人员一套构建环境。我们发现根据本地构建的理论模型，每个人的提交应该是串行的，这样我们实际上可以做到让这些人共享一套环境，但是从逻辑上就像是每个人有一套自己的环境一样。

解决方案：

在运行个人构建的时候将本地的代码同步到一台共享的机器上执行构建，构建完成后结果反馈给提交这次个人构建的人。

实现：

个人构建中心的实现有很多种方案。这些方案的区别主要在于如何将代码同步到个人构建中心服务器上。两种常见的方式：一个是使用rsync或者类似方式同步；另一个是使用分布式配置管理工具如git/hg同步。其拓扑结构如下：

第一种方式相对独立灵活；第二种方式稳定、高效，但是对于配置管理工具有依赖。

后果：

个人构建中心节省了大量的计算资源，同时也容易使得中心服务器成为单点失败的源头。一旦中心服务器出现问题，可能会导致团队的流程受到较大影响。

提交令牌

问题：

在实施本地构建的时候，向目标分支的提交应该是串行的，以避免构建被破坏后难以定位问题来源。但是团队往往缺乏一种有效的机制来保证这种串行。

上下文：

有些团队试图通过技术的手段来解决这个问题，比如通过配置管理上的锁机制，这种方式和乐观锁模式有较大冲突。有些团队通过团队内部沟通的方式解决，比如谁提交之前都会通知别人，或者通过持续集成监视器来了解当前的构建状态，以决定自己是否可以提交。这些方式各自有各自的适用情形，较容易理解。

解决方案和实现：

使用一个实物作为令牌，准备提交的代码的人首先取得令牌，当代码提交完成（包括相应的提交构建）之后，将令牌交还。令牌要醒目，并且移动方便。小型奖杯、毛绒玩具、较大的头饰（如下图）都是不错的令牌。

分阶段构建

问题：

在某些团队中完整构建所花费的时间可能很长，如果每次提交都运行完整的构建会浪费很多时间。

上下文：

随着持续集成的日益完善，我们往往会发现验证所花费的时间越来越长，而大部分验证趋于稳定，失败的情况很少见。通过技术手段缩短构建时间是解决问题的根本办法，但是缩短构建时间是一个耗时耗力的工作，很难短期内见效。

解决方案和实现：

将构建分为几个阶段执行，在本地构建中仅执行速度比较快、可信度比较高、出错概率比较大的验证。利用晚上或者其他合适的时间执行全面的验证——我们这次构建称为全量构建。需要注意的是，这种情况下仍然要保证提交构建和本地构建的一致性。

iAnalysis

iAnalysis是一款轻量级的持续集成报告工具。该工具的核心思想是将持续集成构建过程中产生的数据以趋势和对比的方式展示出来。正如前文所说，我们在2009年的ThoughtWorks Away-Day上讨论了敏捷度量的话题，大家最后一致认为，数据有两种最基本的用法——横向对比和纵向对比。横向对比就是不同的人、不同的团队之间对比；纵向对比就是现在和过去对比。iAnalysis正是这种思想的体现。

关于作者

肖鹏，ThoughtWorks资深咨询师，程序员，敏捷过程教练。拥有7年以上软件开发实践经验，多次担任大中型企业敏捷流程改进咨询和培训，服务对象涉及通信设备制造、通信运营、互联网行业等。他关注于设计模式、架构模式、敏捷软件开发等领域，并致力于软件开发最佳实践的推广和应用。他曾参与翻译《Visual Studio 2005技术大全》，主持翻译《面向模式的软件架构》第四卷和第五卷等图书。

¹目前Cruise的开发任务已经不在中国公司了。

²实际上这篇文章介绍的是Matthew所在团队在2000年早些时候已经在使用的实践，ThoughtWorks中国公司的总经理郭晓先生当时也在这个团队。

³为了与ThoughtWorks常用的术语保持一致，部分术语与雷镇和熊节同学所译略有差别，下同。

⁴笔者对其格式略作处理，与原文稍有出入。

⁵Martin最近在自己的一篇博客上对几种流行的配置管理工具做了对比。

⁶注意，本文并非为指出第一版的缺陷，只是通过对比来说明作者论文中重点的变化。

⁷这里只是借用“看板”这个词的字面含义，与精益中的看板有区别。

转自：http://www.infoq.com/cn/articles/ci-theory-practice

本文链接

厂商	Java.net
支持的编程语言	Java
是否开源	是
价格	免费
主流 SCM 支持程度	Clear Case ， VSS, CVS, Subversion ， PVCS 等， SCM 支持最为完善
构建管理	并行构建，分布式构建，增量构建，人工强制构建， SCM 触发构建等都有支持
消息通知机制	Email ， Run executable ， FTP ， IRC ， Jabber ， Lotus Sametime ， RSS,SCP,Windows System Tray,Formatted Logging
构建工具支持	Shell 脚本与命令行， Ant, Groovy, OpenMake Meister, Maven, Maven2 ， MSbuild ， NAnt ， Rake (Ruby)
项目管理工具集成	无
测试工具集成	CppUnit result rendering ， JUnit result rendering ， NUnit result rendering ， Selenium result rendering ， PHPUnit result rendering ， MSTest result rendering ， SilkCentral ， Clover result rendering ， PMD result rendering
安装与配置	有 windows 安装程序， Self contained distribution (except SCM clients) ， N 无需修改构建脚本，支持多个项目，自动配置构建脚本
IDE 集成	Eclipse Plug-in ， IntelliJ Plugin

博客园_kivenhou's bookmark

最奇特的编程语言的特征

HTTPS和HTTP的区别

持续集成相关总结(五)

（五）持续集成的深层理解与相关问题研究

7.跌跌撞撞的持续集成之路（分享持续集成经验） 网站链接：http://cd.qq.com/a/20090910/000715.htm本文链接

持续集成学习总结(四)

持续集成学习总结(三)

持续集成学习总结(二)

用户管理这个基本上是每个CI Server的必备功能了，基本上都是既可以用内置的数据库管理（Hudson好像没用数据库），又可以连接LDAP服务器。

持续集成学习总结(一)

持续集成工具的选择

深入了解CLR异常处理机制

持续集成理论和实践的新进展

7.跌跌撞撞的持续集成之路（分享持续集成经验）
网站链接：http://cd.qq.com/a/20090910/000715.htm
本文链接

用户管理
这个基本上是每个CI Server的必备功能了，基本上都是既可以用内置的数据库管理（Hudson好像没用数据库），又可以连接LDAP服务器。