译自： http://www.javaworld.com/javaworld/jw-12-2008/jw-12-hudson-ci.html
持续集成已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。在本系列文章中，Nicholas Whitehead给您介绍Hudson ，一个现在非常流行的开源CI服务器。他将告诉读者在您的应用开发环境下（实例中包含Windows XP+Tomcat6或Ubuntu Linux+JBoss AS ）如何搭建一个Hudson服务器环境，还包含了Hudson中许多配置项的概述，和执行一个自动编译、测试、报告过程的示例。
持续集成(CI)是一种实践，旨在缓和和稳固软件的构建过程。CI能够帮助您的开发团队应对如下挑战：
- 软件构建自动化 ：使用CI，您只要按一下按钮，它会依照预先制定的时间表，或者响应某一特定事件，就开始进行一次构建过程。如果您想取出源码并生成构件，该过程也不会局限于某一特定IDE、电脑或者个人。
- 持续自动的构建检查 ：CI系统能够设定成持续地对新增或修改后签入的源代码执行构建，也就是说，当软件开发团队需要周期性的检查新增或修改后的代码时，CI系统会不断要求确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在手动检查彼此相互依存的代码中变化情况需要花费的时间和精力(说直接一点也是钱啊，呵呵)。
- 持续自动的构建测试 ：这个是构建检查的扩展部分，这个过程将确保当新增或修改代码时不会导致预先制定的一套测试方案在构建构件后失败。构建测试和构建检查一样，失败都会触发通知(Email,RSS等等)给相关的当事人，告知对方一次构建或者一些测试失败了。
- 构件生成后续过程的自动化 :一旦自动化检查和测试的构建已经完成，一个软件构件的构建周期中可能也需要一些额外的任务，诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。只有这样，构件才能更迅速地提供给用户使用。
实现一个CI服务器你需要的最低要求是，一个易获取的源代码仓库(包含源代码)，一套构建脚本和流程和一系列围绕构件构建的可执行测试。图1概括了CI系统的基本结构。
图1. CI系统的基本结构
该系统的各个组成部分将按如下顺序来发挥作用：
- 开发者检查新增和修改到源代码仓库后的代码。
- CI服务器会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区，在哪里构建就执行到哪个目录下。
- CI服务器会在新近创建或者更新的工作区内执行构建过程。
- 一旦构建完成，CI服务器就会在一个新的构件中选择性地执行原先定义的一套测试。如果构建失败，相关责任人将会通过电子邮件、即时短信或者其他的方式获取到(失败)通知。
- 如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器) 和/或存储为软件仓库中的一个新版本。这个如软件仓库可以是CI服务器的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.net、SourceForge分发的一个有效网址。源代码仓库和构件仓库是可以分开的，实际上它可以利用一些根本没有包含任何源代码控制系统(CVS、SVN、CSS等等)的CI服务器。
- CI服务器通常会通过某种控制台来进行项目的配置和调试，并且根据请求响应相应的操作，诸如即时构建、生成报告，或者检索构件。
Hudson: 持续集成服务器
持续集成 在过去几年因为它的逐渐成熟而颇受欢迎，今天您有不少的CI服务器可供选择，包括商业的和开源的。我个人在同事推荐Hudson 之前已经使用过4个CI服务器。一接触Hudson，它就让我印象深刻。虽然我最初以为Hudson应该不会广为人知，但是在一个名为survey at the Java Power Tools site 的网站显示，在调查谁是最广泛使用的CI服务器时，受访者给它投了37.8%的选票(本文写作之时)。
构件：构建完成后的软件成品，如JAR或WAR等，后续文章将不再重新说明。