持续集成
上一篇 / 下一篇 2007-01-12 11:13:09 / 个人分类:性能测试
!w tD1?Y8G8F0英文原文版权由Martin Fowler拥有Original text is copyrighted by Martin Fowler
g`aRRs{0 原文链接:http://martinfowler.com/articles/continuousIntegration.html 51Testing软件测试网&R7NUee4TTB
Martin Fowler Chief Scientist, ThoughtWorks 51Testing软件测试网#XU%Z)\4l.t&J@
译者语:
aU-K(kg nv h3B0 由于这是Fowler先生送给全体中国软件开发者的礼物,所以我绝对不敢独占。任何人都可以在任何地方随意转载本文,但是在转载时请保持本文完整性--包括标题、版权声明、原文链接、译者语……总之,请不要在转载的时候做任何改动或增删。另外,如果能在转载的时候顺手给我一个mail,我会更加高兴。
#{4[8[sCzD1m}4O0 51Testing软件测试网fsZ B.e1y{M 下面,请开始欣赏这篇精彩的文章。
OR&`)@c051Testing软件测试网'u6X8C)@l{6t8V
在任何软件开发过程中都有一个重要的部分:得到可靠的软件创建(build)版本。尽管知道创建的重要性,但是我们仍然会经常因为创建失败而惊讶不已。在这篇文章里,我们将讨论Matt(Matthew Foemmel)在ThoughtWorks的一个重要项目中实施的过程,这个过程在我们的公司里日益受到重视。它强调完全自动化的、可重复的创建过程,其中包括每天运行多次的自动化测试。它让开发者可以每天进行系统集成,从而减少了集成中的问题。
ThoughtWorks公司已经开放了CruiseControl软件的源代码,这是一个自动化持续集成的工具。此外,我们还提供CruiseControl、Ant和持续集成方面的顾问服务。如果需要更多的信息,请与Josh Mackenzie(jmackenz@ThoughtWorks.com)联系。
&M%yc jq:i.{#C)[|,F0 v}$Rm@0I"GU0 本文有以下主要内容:51Testing软件测试网.A4H5nY1H/H
持续集成的优点
[{y;]5i5~0 集成越频繁,效果越好
m*H
K G4^:b1m2k0 一次成功的创建是什么样的?
o9[NCj[0 单一代码源
AJ0u(i4NB0 自动化创建脚本 51Testing软件测试网{8|-qgf3?G|
自测试的代码 51Testing软件测试网oJ}|:{Rm
主创建
Oi:|_;[#Oe9J0 代码归还
%|"nP/TmgZ[0 总结 51Testing软件测试网/hS@i,w
在软件开发的领域里有各种各样的"最佳实践",它们经常被人们谈起,但是似乎很少有真正得到实现的。这些实践最基本、最有价值的就是:都有一个完全自动化的创建、测试过程,让开发团队可以每天多次创建他们的软件。"日创建"也是人们经常讨论的一个观点,McConnell在他的《快速软件开发》中将日创建作为一个最佳实践来推荐,同时日创建也是微软很出名的一项开发方法。但是,我们更支持XP社群的观点:日创建只是最低要求。一个完全自动化的过程让你可以每天完成多次创建,这是可以做到的,也是完全值得的。
uI0\lq|)l6_0 51Testing软件测试网 OfH.M ~6q9D3lv*`在这里,我们使用了"持续集成(Continuous Integration)"这个术语,这个术语来自于XP(极限编程)的一个实践。但是我们认为:这个实践早就存在,并且很多并没有考虑XP的人也在使用着它。只不过我们一直用XP作为软件开发过程的标准,XP也对我们的术语和实践产生了深远的影响。尽管如此,你还是可以只使用持续集成,而不必使用XP的任何其他部分--实际上,我们认为:对于任何切实可行的软件开发活动,持续集成都是很基本的组成部分。
i D(d:j6UI0M0X(a;R \/eQj0 实现自动化日创建需要做以下几部分的工作:
&`XmH(E8NA;I@0iuC+XrtS5U1G0 将所有的源代码保存在单一的地点,让所有人都能从这里获取最新的源代码(以及以前的版本)。 51Testing软件测试网&zh`5_8u oUM
5pP6Y"k G8Q0 使创建过程完全自动化,让任何人都可以只输入一条命令就完成系统的创建。 51Testing软件测试网2i\:Pe3ao1ZT}r5sk
51Testing软件测试网 N]Ck?使测试完全自动化,让任何人都可以只输入一条命令就运行一套完整的系统测试。
(u%VcW5b xe.h0Yhzpza5Xl3wX0 确保所有人都可以得到最新、最好的可执行文件。 51Testing软件测试网+|g/JeW9J1u"O@
)CY/Q7{a/WX%e0 所有这些都必须得到制度的保证。我们发现,向一个项目中引入这些制度需要耗费相当大的精力。但是,我们也发现,一旦制度建立起来,保持它的正常运转就不需要花多少力气了。
K,W&_N^ Ev0 51Testing软件测试网&Pp$K"fx"rB G*`持续集成的优点 51Testing软件测试网W#chJp9_3L }:P
51Testing软件测试网6?'Iv${J'G描述持续集成最大的难点在于:它从根本上改变了整个开发模式。如果没有在持续集成的实践环境中工作过,你很难理解它的开发模式。实际上,在单独工作的时候,绝大多数人都能感觉到这种气氛--因为他们只需要与自己的系统相集成。对于许多人来说,"团队开发"这个词总让他们想起软件工程领域中的一些难题。持续集成减少了这些难题的数量,代之以一定的制度。
$u#rA.D8Bew%x0gPr;?$\_RF0 持续集成最基本的优点就是:它完全避免了开发者们的"除虫会议"--以前开发者们经常需要开这样的会,因为某个人在工作的时候踩进了别人的领域、影响了别人的代码,而被影响的人还不知道发生了什么,于是bug就出现了。这种bug是最难查的,因为问题不是出在某一个人的领域里,而是出在两个人的交流上面。随着时间的推移,问题会逐渐恶化。通常,在集成阶段出现的bug早在几周甚至几个月之前就已经存在了。结果,开发者需要在集成阶段耗费大量的时间和精力来寻找这些bug的根源。 51Testing软件测试网MLO {%N ^;r
f9?0?"V)]a/q?h0 如果使用持续集成,这样的bug绝大多数都可以在引入的同一天就被发现。而且,由于一天之中发生变动的部分并不多,所以可以很快找到出错的位置。如果找不到bug究竟在哪里,你也可以不把这些讨厌的代码集成到产品中去。所以,即使在最坏的情况下,你也只是不添加引起bug的特性而已。(当然,可能你对新特性的要求胜过了对bug的憎恨,不过至少你可以多一种选择。)
eJWt$d,]q0ln XR X8iYoc7j"l0 到现在为止,持续集成还不能保证你抓到所有集成时出现的bug。持续集成的排错能力取决于测试技术,众所周知,测试无法证明已经找到了所有的错误。关键是在于:持续集成可以及时抓到足够多的bug,这就已经值回它的开销了。