Hudson简要介绍
（1） CI的作用主要有如下几个方面：
软件构建自动化：CI过程可以依照预先制定的时间表，或者针对某一特定事件，对目标软件进行一次构建过程。这个构建过程面向的是开发该软件的所有团队成员；
? 构建可持续的自动化检查：CI过程能够设定成持续地执行新增或修改后签入的源代码，当软件开发团队需要周期性的检查新增或修改后的代码时，CI系统会不断 确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在检查彼此相互依存的代码所发生的变化而带来的开销；
? 构建可持续的自动化测试：一个构建检查的扩展部分，这个过程确保当新增或修改代码时不会导致预先制定的一套测试在构建构件后失败。构建检查和测试一样，失败都会触发通知单(Email,RSS等等)给相关的当事人，告知对方一次构建或者一些测试失败了。
? 生成后后续过程的自动化：一旦自动化检查和测试的构建已经完成，一个软件构件的构建周期中可能也需要一些额外的任务，诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。这样，构件才能更迅速地提供给用户使用。
（2）实现CI的上述功能，需要三个组件：
? 用 Ant 或 Maven 等工具建立的自动构建过程。这是成功的CI过程最重要的方面，CI过程会经常集成软件，这需要通过构建来完成。Ant和Maven都是常用的构建平台，它们能可靠地自动执行编译、测试等任务，甚至可以执行软件检查和部署。
? 一个代码存储库，比如 CVS 或 Subversion。CI 服务器向源代码管理系统（SCM）存储库查询代码修改。在找到修改时，CI服务器执行签出（即更新本地沙箱）并执行构建。除了执行得更频繁之外，构建过程与在本地环境中执行的构建相同。
? 一个 CI 服务器，比如 Hudson，但是 cron 作业也可以满足需要。CI服务器能自动监视SCM存储库并在探测到修改时运行构建。它应具有以下基本要素：1.CI服务器要能够比较容易的获取源代码仓库 以及内部的源代码；2.要能够添加构建脚本和程序；3.还要有一系列围绕构件构建的可执行测试。 下图为CI系统的基本结构
该系统的各个组成部分是按如下顺序来发挥作用的：
- 开发者检查新增和修改到源代码仓库后的代码。（图中 Source Code Updates）
- CI服务器会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区，哪里构建就执行哪里。（图中Project Workspace）
- CI服务器会在新近创建或者更新的工作区内执行构建过程。 （图中Build）
- 一旦构建完成，CI服务器就会在一个新的构件中选择性地执行原先定义的一套测试。（图中Test）如果构建失败，相关责任人将会通过电子邮件、即时短信或者其他的方式获取到(失败)通知。（图中Reporting & Notifications）
- 如果构建成功，这个构件会被打包（图中Package）并转移到一个部署目标(如应用服务器) 和/或存储为软件仓库中的一个新版本（图中Deploy/Publish）。这个如软件仓库可以是CI服务器的一部分，也可以是一个外部的仓库，诸如一个 文件服务器或者像Java.net、SourceForge分发的一个有效网址。源代码仓库和构件仓库是可以分开的，实际上它可以利用一些根本没有包含任 何源代码控制系统(CVS、SVN、CSS等等)的CI服务器。
- CI服务器通常会用某种控制台来进行项目的配置和调试，并且根据请求发起相应的操作，诸如即时构建、生成报告，或者检索一些构建好的构件。（图中Server Console）
二．关于Hudson
Hudson 是一种革命性的开放源码 CI 服务器，它从以前的 CI服务器吸取了许多经验教训。Hudson最吸引人的特性之一是它很容易配置：很难找到更容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的CI 服务器。Hudson 容易使用的第二个原因是它具有强大的插件框架 ，所以很容易添加特性。例如，一个 Hudson 插件可以随时间的推移跟踪FindBugs 和代码覆盖。它还可以报告测试结果的趋势（来自 JUnit 或 TestNG）以及构建结果和对应的执行时间。有人调查过，Hudson是目前使用最多的CI服务器。
下面介绍使用Maven和Subversion来配置Hudson的过程。
（1）下载并安装、运行Hudson
在 https://hudson.dev.java.net/下载Hudson的war包（Hudson.war）[[BR]]
用jar运行Hudson服务器端，命令为：java –jar Hudson.war
另外还可以将它部署在 Tomcat 或 JBoss 等容器中，方法后面会介绍。
（2）在安装并运行 Hudson 之后（将 WAR 文件部署到 servlet 容器或从命令行执行java -jar hudson.war ），访问 http://localhost:8080/进入Hudson的启动页面，如下图所示：[[BR]]
在新建任务之前，可以使用“系统管理”来为Hudson进行全局配置，如“管理插件”可以添加、删除、禁用或启用Hudson的各种功能扩展插件。最重要 的是“系统设置”，在这里可以配置安全，勾选“Enable security”，配置hudson 服务器的访问权限。在默认关闭的状态下，匿名用户可以进行所有的操作。打开这个选项后，hudson 将采用应用服务器所配置的帐号权限策略。下面还有指定Maven的安装位置以及JDK的安装位置等。“E-mail Notification”是邮件通知，Hudson 通过邮件向开发人员通知某些事件的发生， 如编译失败/测试失败/集成恢复正常等等。在这里需要配置邮件的SMTP 服务器和发 件人。 点击“新建任务”选择“Build a free-style software project”，它在构建时可以集成任意的SCM，任意的构建系统等。也可以通过“Build a maven2 project”来建一个Maven2项目。“复制先有任务”在复制现有的工作基础上新建一次构建工作
配置 Hudson 如下图所示
新建一个项目后，要对它进行配置。
? Project name :项目名称
? Description : 这是一个自由项，主要用来说明你关于这次构建工作的描述。可不填。
? This build is parameterized : 如果选择此选项，Hudson将允许您提供一套任意的键值对参数，它们会被传递到构建过程里。配置的参数往往是构建运行环境中的一些环境变量。(当你使用 了Hudson的各种自动化，有时要求在构建过程中提供一组用户的输入，使用“parameterize”就能够更方便构建。例如，你可能会设立一个按需 测试，在那里用户可以提交一个二进制文件的压缩文件来进行测试。
? Disable build : 如果这里被勾选，这项工作将不会执行构建，直到选项禁用为止。(比如：你想每一个小时构建一次，但却发现SVN服务器将在未来24小时内down机。当这 个选项被设置后，关于这个项目就不会再有新的构建。这样一来，您就可以在不想改变外部依赖或者提交错误通知的情况下禁用构建过程。)
? Advanced options :
Quiet period : 在这里可以配置一个静态监控，当构建准备按某个计划运行时，实际上它就已经在执行了。
Use custom workspace : 默认情况下，Hudson将在${jboss-home}/.hudson/jobs/[项目名称](注:Linux环境 )下创建一个工作区 。此选项将允许您使用指定的地址替代(它)。
? Source code management : 在默认情况下是这三个选项：
o Subversion
o CVS
o None
项目的源码获取方式。根据项目所采用的版本控制系统，选择cvs 或者svn 并填写Repository URL 即可。这里有一个选项Use update。为了保证每一次build 不受前一次build 结果的影响，这里不推荐选择Use Update 选项。
关于None：如果你安装了一个与SCM相关的插件，选择None，并重新启动Hudson，那么在这个清单上也将出现一些新的选择。
Build Triggers：设置构建的触发器。
? Build after other projects are built : 此选项支持一条装配(流水作业)线——作业依赖: 一个作业依赖于另一个作业的输出的情况 —— 或者如以下情形：你只是想简单的把一些有关的工程构建编入一个组以便一起构建。当您一选择它，你将得到一个字段，输入其他工程的名字[多个项目名间用逗号 分隔]后，这个构建应该就可以运行。
? Build periodically 选项支持类似crontab格式的任务周期定制。
? Poll SCM : 这是CI 系统中常见的选项。当您选择此选项，您可以指定一个定时作业表达式来定义Hudson每隔多久检查一下您源代码仓库的变化。如果发现变化，就执行一次构 建。例如，表达式中填写0,15,30,45 * * * *将使Hudson每隔15分钟就检查一次您源码仓库的变化。更多信息请查阅Quartz CronTrigger中关于这个定时作业语法的详细描述。 Build：构建脚本设置。
? Add build step : 按一下这个按钮，添加了一项指令以执行构建脚本。您的指令可以是下列之一：
o 执行 Shell
o 执行 Windows 批处理
o 使用Ant
o 使用Maven
Post-build Actions：构建完成后需要进行的处理。
Archive the artifacts：将构建完成的结果存档打包，并提供下载。
Publish JUnit test result report：收集整理junit 的测试报告，并发布。
? Build periodically : 此选项 (也是使用定时作业表达式)仅仅通知Hudson按指定的频率对项目进行构建，而不管SCM是否有变化。我这个作业就属于目标测试环境是按某种方式定期修 订的而SCM却是静态的情况。如果您想在这个作业中运行一些测试用例的话，它可能就很有帮助。
? Archive the artifacts :指定文件和目录的掩码，当与掩码相匹配的构件在构建时将被添加到Hudson的构件仓库，它们会用作业（名）和构建序号来标识。所有以前构建过的构件可以选择性地丢弃，以节省Hudson服务器上的磁盘空间。
? Record fingerprints of files to track usage :使用类似Ant方式的掩码，恁可以指示Hudson去生成构件的指纹码，确保能够更容易地找到它们的位置，另外判断系统中的这些构件是否还在使用。
? Publish javadoc : 如果构建脚本能生成JavaDoc，此选项将指示Hudson发布这些内容，而且立即把它公布在当前工作的主页上。每一个成功构建的文档内容都可以保留，但在默认情况下只保留最新的。
? Publish JUnit test result report : 如果构建脚本执行了JUnit测试，此选项将指示Hudson处理XML测试文档并为每次连续构建产生一份可持续的报告，依据正在进行的测试汇总处理结 果。其结果是当前工作主页的一份报告，作业中的单元测试会随着时间的推移按由老至新进行陈列。
? Aggregate downstream test results : 在某些情况下，作业中一组单元测试花费的时间大大长于实际构建它所花的时间。在这些情况下，你可以选择把构建和测试分为不同的作业，以便完成构建能相对迅 速，一旦与这相关的一个或多个测试作业就执行完毕，构建也就成功完成了。 当选择这个选项， Hudson就会把构建后作业的测试结果进行统计，并且能追溯到它们的明细。用以做为本次构建成功或失败的主要依据。
? Build other projects : 较之前面的选项，这个选项主要用来实现一个合乎逻辑的构建和测试过程，它会被分为两个或两个以上的物理工作，并且会按顺序执行。当此项被选择后，您将得到 一个字段，可以在其中输入您想在当前作业中后执行的其它作业名[多项作业可用逗号分隔]。[BR]]
? E-mail notification : 当选择此选项，可以输入一个或多个电子邮件地址[多个可用空格分隔]，当Hudson完成了执行作业后，将会给它们发送通知。事件触发时将产生一份 Email，包括构建失败、构建不稳定等。这儿有一个额外的选项，当由于用户的错误提交造成Hudson决定废弃此次构建，将会发送一份专门的邮件给这位 SCM提交者，以便让他检查源代码
建好后，点左栏的“立即生成”，Hudson就自动将代码编译成可执行文件。