Hudson与持续集成v0.1

- Hudson与持续集成 Hudson与持续集成 [0.1] 文档修订记录 版本 *变化状态 简要变更说明 变更人签字/日期 0.1 新建 添加平台功能分析章节 2013-08-4 0.2 0.3 目 录 21. Hudson 22. 持续集成 33. Hudson环境安装与环境配置 44. Hudson的系统配置 65. Hudson的使用 Hudson Hudson 是一种革命性的开放源码 CI 服务器，它从以前的 CI 服务器吸取了许多经验教训。Hudson 最吸引人的特性之一是它很容易配置：很难找到更容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的 CI 服务器。Hudson 容易使用的第二个原因是它具有强大的插件框架，所以很容易添加特性。例如，一个 Hudson 插件可以随时间的推移跟踪 FindBugs 和代码覆盖。它还可以测试结果的趋势（来自 JUnit 或 TestNG）以及构建结果和对应的执行时间。 持续集成 持续集成(CI)是一种实践，旨在缓和和稳固软件的构建过程。CI能够帮助您的开发团队应对如下挑战： 软件构建自动化 ：使用CI，您只要按一下按钮，它会依照预先制定的时间表，或者响应某一特定事件，就开始进行一次构建过程。如果您想取出源码并生成构件，该过程也不会局限于某一特定IDE、电脑或者个人。 持续自动的构建检查 ：CI系统能够设定成持续地对新增或修改后签入的源代码执行构建，也就是说，当软件开发团队需要周期性的检查新增或修改后的代码时，CI系统会不断要求确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在手动检查彼此相互依存的代码中变化情况需要花费的时间和精力(说直接一点也是钱啊，呵呵)。 持续自动的构建测试 ：这个是构建检查的扩展部分，这个过程将确保当新增或修改代码时不会导致预先制定的一套测试在构建构件后失败。构建测试和构建检查一样，失败都会触发通知(Email,RSS等等)给相关的当事人，告知对方一次构建或者一些测试失败了。 构件生成后续过程的自动化 :一旦自动化检查和测试的构建已经完成，一个软件构件的构建周期中可能也需要一些额外的任务，诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。只有这样，构件才能更迅速地提供给用户使用。 CI系统的基本结构  该系统的各个组成部分将按如下顺序来发挥作用： 开发者检查新增和修改到源代码仓库后的代码。 CI服务器会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区，在哪里构建就执行到哪个目录下。 CI服务器会在新近创建或者更新的工作区内执行构建过程。 一旦构建完成，CI服务器就会在一个新的构件中选择性地执行原先定义的一套测试。如果构建失败，相关责任人将会通过电子邮件、即时短信或者其他的方式获取到(失败)通知。 如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器) 和/或存储为软件仓库中的一个新版本。这个如软件仓库可以是CI服务器的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.net、SourceForge分发的一个有效网址。源代码仓库和构件仓库是可以分开的，实际上它可以利用一些根本没有包含任何源代码控制系统(CVS、SVN、CSS等等)的CI服务器。 CI服务器通常会通过某种控制台来进行项目的配置和调试，并且根据请求响应相应的操作，诸如即时构建、生成报告，或者检索构件。 Hudson环境安装与环境配置 需要环境：jdk,tomcat ant安装 下载页面：http://ant.apache.org/bindownload.cgi wget http://labs.renren.com/apache-mirror//ant/binaries/apache-ant-1.8.3-bin.zip unzip -d /usr/local apache-ant-1.8.3-bin.zip  配置变量 vim ~/.profile export ANT_HOME=/usr/local/apache-ant-1.8.3 export PATH=$ANT_HOME/bin:$PATH 变量生效 source ~/.profile 测试 ant -version hudson 主页：http://hudson-ci.org/ 此处下载为rpm版本: wget http://java.net/projects/hudson/downloads/download/Redhat/hudson-redhat-2.2.0.rpm 安装：rpm -ivh hudson-redhat-2.2.0.rpm 默认配置 启动脚本：/etc/init.d/hudson 配置文件：/etc/sysconfig/hudson 日志文件：/var/log/hudson/hudson.log HUDSON_HOME：/var/lib/hudson War文件：/usr/lib/hudson/hudson.war Hudson的系统配置 Hudson安装完成后需要对其进行一些配置，进入系统配置页面如下： 参数说明: system.message 填写一些说明信息 Quiet period:hudson定时构建工程的时间(秒)  Enable security:设置hudson登陆的规则(默认为匿名登陆) TCP port for JNLP slave agents:不了解JNLP不敢胡写总之就是三种方式:固定(fixed) 随机(Radom) 不使用(disabled),使用固定时可以填入JNLP信息 security realm:可以使用中间件容器,数据库,LDAP来验证安全,具体怎样用法没用过,以后会有更新,研究中. authorized:可以设置身份的验证方法:系统用户,匿名用户,自定义用户,还有继承用户(此处也在研究中,建议使用匿名用户) JDK installations:设置JDK的安装路径 Shell executable:设置window shell命令 Ant installation:设置ant 的安装路径 mave installation设置mave的安装路径 cvs executable:设置cvsnt执行进程的路径(cvs.exe) .cvspass file:设置cvsnt管理员文件的路径(passwd文件) e-mail notification:设置当发生错误时发送的邮箱地址 hudson url:就是hudson的默认地址 可以配置服务器的其他几个方面，比如向 Hudson 提供一个电子邮件服务器的位置，以便在构建失败时接收电子邮件 这需要安装hudson 的一些插件： 可以在 系统管理”》“管理插件 里安装 这里先推荐２个 Hudson Deploy Plugin | Hudson Email Extension Plugin Hudson的使用 创建job   · Project name :项目命名 ， · Description : 这是一个自由项，主要用来说明你关于这次构建工作的描述。可不填。(帮助:这说明放在项目的首页，以便访问者可以知道这个工作的内容。您也可以在这里使用任何HTML标记。) · Discard old builds : Hudson默认将保留过去的构建，除非你事先选中此框。(帮助:这里控制着您想要在Hudson所在的磁盘把构建记录存储的有效期(诸如控制台输出、编译构件等等)。Hudson为此提供了两个标准：1。时间驱动。在Hudson中您可以判断如果达到一定时限来删除一条记录(例如，七天前)。2。数量驱动。在Hudson中您可以确保它拥有N份构建。如果又有新的构建开始，最早的那份(记录)就将被删除。Hudson也可以让您建立的个别构建定义为'永远保持这个记录'，以便防止某些重要的构建被自动丢弃。) · This build is parameterized : 如果选择此选项，Hudson将允许您提供一套任意的键值对参数，它们会被传递到构建过程里。配置的参数往往是构建运行环境中的一些环境变量。(帮助：当您使用了Hudson的各种自动化，有时要求在构建过程中提供一组用户的输入，使用“parameterize”就能够更方便构建。例如，您可能会设立一个按需测试，在那里用户可以提交一个二进制文件的压缩文件来进行测试。  本节参数可以完全按照您构建的需要配置。参数是以名字区分的，所以您可以有多个参数，只要它们名称不同。  关于此功能的更多资料请查看。) · Enable project-based security : Hudson支持全面的安全方案，可以强制用户在通过身份验证后，再访问Hudson网页;它也可以通过控制用户的权限来管理用户的工作。在这个Hudson例子中我没有配置安全 [你可以参考我的另外两篇文章：Use Hudson之标准安全设置和使用matrix security对Hudson进行细粒度Job的安全控制，获取关于安全的详细配置]。 · Disable build : 如果这里被勾选，这项工作将不会执行构建，直到选项禁用为止。(帮助：有时候，你会想暂停某个构建中的项目。例如，也许您正准备一次大的迁移，而且你知道新版本会失败。或者您想每一个小时构建一次，但您却发现CVS服务器将在未来24小时内down机。当这个选项被设置后，关于这个项目就不会再有新的构建。这样一来，您就可以在不想改变外部依赖或者提交错误通知的情况下禁用构建过程。) · Advanced options : 我没有使用这些选项，但是当此复选框被选中时，选项中就会暴露下面的接口： · Quiet period : 在这里您可以配置一个静态监控，当构建准备按某个计划运行时，实际上它就已经在开始执行了。 · Use custom workspace : 默认情况下，Hudson将在${jboss-home}/.hudson/jobs/[项目名称](注:Linux环境 )下创建一个工作区 。此选项将允许您使用指定的地址替代(它)。 · Source code management : 在默认情况下是这三个选项： · Subversion · CVS · None  这个None会误解我先前的主张 ：一个先决条件是要有一个源代码仓库。但我坚持认为，在大多数情况下，为Hudson选择某个仓库是绝对必要的。本文稍后，我将讨论如何安装Hudson插件。如果您安装了一个与SCM相关的插件，并重新启动Hudson，那么在这个上也将出现一些新的选择。本文，我使用 Subversion 。当您选择Subversion后，将展开一个配置表单。我会在下面的某一部分中单独描述这个配置(见“ Subversion的工作配置” ) 。 · Build after other projects are built : 此选项支持一条装配(流水作业)线——作业依赖: 一个作业依赖于另一个作业的输出的情况 —— 或者如以下情形：你只是想简单的把一些有关的工程构建编入一个组以便一起构建。当您一选择它，你将得到一个字段，输入其他工程的名字[多个项目名间用逗号分隔]后，这个构建应该就可以运行。 · Poll SCM : 这是CI 系统中常见的选项。当您选择此选项，您可以指定一个定时作业表达式来定义Hudson每隔多久检查一下您源代码仓库的变化。如果发现变化，就执行一次构建。例如，表达式中填写0,15,30,45 * * * *将使Hudson每隔15分钟就检查一次您源码仓库的变化。更多信息请查阅Quartz CronTrigger中关于这个定时作业语法的详细描述(新版Quartz支持从秒开始触发，所以请查阅下面的cron帮助，对此引起的误导表示歉意)。 · Build periodically : 此选项 (也是使用定时作业表达式)仅仅通知Hudson按指定的频率对项目进行构建，而不管SCM是否有变化。我这个作业就属于目标测试环境是按某种方式定期修订的而SCM却是静态的情况。如果您想在这个作业中运行一些测试用例的话，它可能就很有帮助。 · Add build step : 按一下这个按钮，添加了一项指令以执行构建脚本。您的指令可以是下列之一： · 执行 Shell · 执行 Windows 批处理 · 使用Ant(这是我将要使用的选项，在下面我会做详细的说明) · 使用Maven · Archive the artifacts : 当您选择此选项，就可以指定文件和目录的掩码(Ant风格的掩码，可以指定包含与排除)，当与掩码相匹配的构件在构建时将被添加到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 : 较之前面的选项，这个选项主要用来实现一个合乎逻辑的构建和测试过程，它会被分为两个或两个以上的物理工作，并且会按顺序执行。当此项被选择后，您将得到一个字段，可以在其中输入您想在当前作业中后执行的其它作业名[多项作业可用逗号分隔]。即使目前的作业得出结论说构建可能不稳定，您也可以选择这样做。(关于“作业的稳定性”请查阅“作业状态”章节以获取更多信息) · E-mail notification : 当您选择此选项，您可以输入一个或多个电子邮件地址[多个可用空格分隔]，当Hudson完成了执行作业后，将会给它们发送通知。事件触发时将产生一份Email，包括构建失败、构建不稳定等。这儿有一个额外的选项，当由于用户的错误提交造成Hudson决定废弃此次构建，将会发送一份专门的邮件给这位SCM提交者，以便让他检查源代码。 如果你使用一个shell脚本来完成你的构建，你可以把这些环境变量直接插入到你的shell脚本，或者在你的脚本中把它们作为参数调用。下面的例子将告诉你如何做： 如果你使用Ant 脚本来完成你的构建，你可能会在属性设置中包含环境变量。点击 Advanced... 按钮下方正好显示你想要构建的Ant目标。这将显示Properties框。下面的例子告诉你如何使用Hudson环境变量在Properties 框中设置Ant 属性值。 Hudson的自动部署 完成一系统以上操作后， 在%Hudson_home%/jobs/projecct_name/ workspace/ projecct_name/ target下发布一个项目的war包 这里需要安装hudson的 tomcat 插件。上一章节有提到。 如下图： war包地址一定要填写相对路径 点击立即构建后，可以通过点击构建号---》命令行输出 查看整个构建的过程 1/9