Jenkins项目构建操作

使用环境：Jenkins+Maven+SVN

时间：2015-12-21

文档编写人：张颖

注：文档中若发现任何错误，请联系IMO“张颖  基础架构运维工程师”

1持续集成概述

1.1什么是持续集成

 随着软件开发复杂度的不断提高，团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来，敏捷（Agile）在软件工程领域越来越红火，如何能在不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。

  持续集成正是针对这一类问题的一种软件开发实践。它倡导团队开发成员必须经常集成他们的工作，甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证，包括自动编译、发布、测试等，从而尽快地发现集成错误，让团队能够更快的开发内聚的软件。

持续集成的核心价值在于：

  a)持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量；

  b) 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能；

  c) 持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。

1.2持续集成的原则

业界普遍认同的持续集成的原则包括：

a）需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 IBM Rational ClearCase、CVS、Subversion 等；

b）开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地；

c）需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每半个小时构建一次；

d）必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。

1.3持续集成系统的组成

由此可见，一个完整的构建系统必须包括：

a)一个自动构建过程，包括自动编译、分发、部署和测试等。

b)一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。

c) 一个持续集成服务器。本文中介绍的 Jenkins 就是一个配置简单和使用方便的持续集成服务器。

2Jenkins简介

Jenkins是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。Jenkins的基本功能就是监控代码管理仓库，发现有新的提交，则进行相应的项目构建，将源代码进行编译，并且打成war包，然后通过publish over ssh插件，将程序部署到远程的tomcat服务器。

3Jenkins创建新任务

Jenkins登录地址：http://10.167.210.209:8080/

注：暂时未配置安全，后期增加安全账号登录。

a) 创建一个新的任务

根据项目情况选择项目类型，一般使用自有风格、maven项目。

b) 选择需要创建任务的类型，例如：maven项目

c) 点击OK后进入Job详细配置，首先填写源码管理

    注：

    1、对于项目，没有依赖关系，可直接填写Repository URL，

       例:"https://10.167.210.231/svn/chp-sms" , Local module directory (optional) 默认为“.”无需改变，为workspace目录。

2、此处需要注意，如果遇到构建项目有父项目继承，即pom.xml中含有"parent"，此时源码管理处，需要新增一个源码管理配置“Add more locations”,这里要填写的即为父项目的仓库位置，同时子项目和父项目的“Local module directory (optional)”处不可直接使用默认，需要填写与项目一致的目录名称，例如：Repository URL  "https://10.167.210.231/svn/chp-sms" 对应Local module directory (options) 为"chp-sms"

3、使用git时，需要单独安装Multiple SCMs plugin插件实现

    3、如果在Repository URL填写项目路径后，出现credentials类似提示，说明需要svn该项目的用户名和密码的验证，输入自己对应项目的svn账号和密码即可。

d) 配置项目构建触发器

   Build whenever a SNAPSHOT dependency is built   依赖快照的构建

   Build after other projects are built    在某个Job完成后触发此Job

   Build periodically      周期进行项目构建（它不care源码是否发生变化）

   Poll SCM    "定时检查源码变更，如果有更新就执行构建动作"

根据实际情况选择构建方式。

e)配置构建环境

建议选择此项，需要安装“Workspace Cleanup Plugin”插件（系统管理-管理插件），每次构建时自动清理工作目录

maven构建项目，此处配置pom.xml即可，Goals and options为构建时可增加的参数选项，指定构建时所使用的配置文件目录：-P test   跳过单元检测：-Dmaven.test.skip=true

f)配置远程部署

配置远程部署，需要安装 “Publish over ssh”插件（系统管理-管理插件），安装完毕后，进入系统配置进行Publish over ssh的相关配置，以便在Jobs中调用。

g)增加远程部署任务

选择自定义配置，如：Run only if build succeeds，构建成功后执行，选择SSH远程部署

对远程部署进行配置

以上配置完成后，点击“应用”——》“保存”

h)任务构建

    回到主页面，即可看到已经配置完成的任务，点击任务右侧下拉箭头，选择“立即构建”即可开始Jenkins自动化构建及部署工作。

i)查看构建日志

    1、点击立即构建后，可看到左侧构建进度显示。

    2、直接点击任务进度条处，可进入查看任务进度日志。

4 Jenkins配置邮件通知

a）配置邮件通知

 建议使用Email Extension Plugin扩展插件，比默认EMAIL功能完善，到插件管理下载插件并安装即可。

b）进入系统设置配置邮件

   1、配置smtp服务器

   2、配置触发条件

c）全局属性详解（以下内容为百度摘抄）

1. Override Global Settings：如果不选，该插件将使用默认的E-mail Notification通知选项。反之，您可以通过指定不同于( 默认选项)的设置来进行覆盖。

此项已不存在，默认就会使用EMAIL插件。

2. Default Content Type：指定构建后发送邮件内容的类型，有Text和HTML两种.

3. Use List-ID Email Header：为所有的邮件设置一个List-ID的邮件信头，这样你就可以在邮件客户端使用过滤。它也能阻止邮件发件部分的自动回复(诸如离开办公室、休假等等)。你可以使用你习惯的任何名称或者ID号，但是他们必须符合如下其中一种格式(真实的ID必须要包含在<和>标记里)：

Build Notifications 

“Build Notifications” 

关于更详细的List-ID说明请参阅RFC-2919.

4. Add 'Precedence: bulk' Email Header：设置优先级,更详细说明请参阅RFC-3834.

5. Default Recipients：自定义默认电子邮件收件人列表。如果没有被项目配置覆盖,该插件会使用这个列表。您可以在项目配置使用$ DEFAULT_RECIPIENTS参数包括此默认列表，以及添加新的地址在项目级别。添加抄送：cc:电子邮件地址例如,CC:*********************

6. Reply To List：回复列表, A comma separated list of e-mail addresses to use in the Reply-To header of the email. This value will be available as $DEFAULT_REPLYTO in the project configuration.

7. Emergency reroute：如果这个字段不为空，所有的电子邮件将被单独发送到该地址（或地址列表）。

8. Excluded Committers：防止邮件被邮件系统认为是垃圾邮件,邮件列表应该没有扩展的账户名(如:@domain.com),并且使用逗号分隔

9. Default Subject：自定义邮件通知的默认主题名称。该选项能在邮件的主题字段中替换一些参数，这样你就可以在构建中包含指定的输出信息。

10. Maximum Attachment Size：邮件最大附件大小。

11. Default Content：自定义邮件通知的默认内容主体。该选项能在邮件的内容中替换一些参数，这样你就可以在构建中包含指定的输出信息。

例如：

(本邮件是程序自动下发的，请勿回复！)

项目名称：$PROJECT_NAME

构建编号：$BUILD_NUMBER

svn版本号：${SVN_REVISION}

构建状态：$BUILD_STATUS

触发原因：${CAUSE}

构建日志地址："${BUILD_URL}console"

构建地址："$BUILD_URL"

12. Default Pre-send Script：默认发送前执行的脚本（注：grooy脚本，这是我在某篇文章上看到的，不一定准确）。

13. Enable Debug Mode：启用插件的调试模式。这将增加额外的日志输出，构建日志以及Jenkins的日志。在调试时是有用的，但不能用于生产。

14. Enable Security：启用时，会禁用发送脚本的能力，直接进入Jenkins实例。如果用户试图访问Jenkins管理对象实例，将抛出一个安全异常。

15. Content Token Reference：邮件中可以使用的变量，所有的变量都是可选的。

d）进入任务配置邮件

e）选择哪些条件需要发送邮件以及接收人

Jenkins中Check-out Strategy的各个选项

∙Use‘svn update’ as much as possible

▪第一次发布的时候，会把工作目录下的所有文件清空，然后check-out一份完整的项目到工作目录下；

▪以后更新的时候，不会判断已有文件是否在svn里存在。比如工作目录下的文件123在svn里不存在，那么更新的时候不会删除123。

▪不会判断工作目录下的文件是否被改动，只会判断svn是否有新版本需要更新。比如工作目录下的文件zzz.txt内容为zzz，svn上的zzz.txt内容为空，如果svn上zzz.txt没有新版本，则在更新的时候不会更新zzz.txt，也就是说如果手动修改了工作目录下的文件，如果此文件在svn上没有出现新版本，就不会更新。一旦svn上的zzz.txt有新版本后就会更新工作目录的zzz.txt，这时工作目录下会生成如下几个文件：zzz.txt、zzz.txt.mine、zzz.txt.r223、zzz.txt.r224，其中zzz.txt.r223为svn上老版本、zzz.txt.r224为svn上新版本、zzz.txt.mine为工作目录上的zzz.txt的副本、zzz.txt记录了文件变化。

▪svn上删除了文件，更新的时候，工作目录里的此文件也会被删除。但是如上例中的zzz.txt手动修改过，已经和svn上的不一样了，这时将不会被删除。

∙Alwayscheck out a fresh copy

▪第一次发布的时候，会把工作目录下的所有文件清空，然后check-out一份完整的项目到工作目录下；

▪每一次更新的时候，都会先清除工作目录下的所有文件，然后重新check-out一份完整的项目到工作目录下。

∙Emulateclean checkout by first deleting unversioned/ignored files，then ‘svn update’

▪第一次发布的时候，会把工作目录下的所有文件清空，然后check-out一份完整的项目到工作目录下；

▪以后更新的时候会判断工作目录下的文件是否在svn里存在，如果不存在则删除，如果存在且有新版本则更新。

▪会判断工作目录下的文件是否被改动，不管有没有新版本，都会还原为svn上的最新版本。

▪svn上删除了文件，更新的时候，工作目录里的此文件也会被删除。

∙Use‘svn update’ as much as possible，with ‘svn revert’ before update

▪第一次发布的时候，会把工作目录下的所有文件清空，然后check-out一份完整的项目到工作目录下；

▪以后更新的时候不会判断工作目录下的文件是否在svn里存在。

▪会判断工作目录下的文件是否被改动，不管有没有新版本，都会还原为svn上的最新版本。

▪svn上删除了文件，更新的时候，工作目录里的此文件也会被删除。