持续集成相关理论

1.1 极限编程的概述

1.1.1 极限编程的产生

2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

1.1.2 极限编程

极限编程(XP)是敏捷方法中最著名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

下面是极限编程的有效实践：

（1）完整团队 XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

（2）计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

（3）客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

（4）简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

（5）结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

（6）测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

（7）改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

（8）持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。

（9）集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

（10）编码标准，系统中所有的代码看起来就好像是被单独一人编写的。

（11）隐喻，将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

（12）可持续的速度，团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。 极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

1.1.3 极限编程的核心价值

极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）、此外还扩展了第五个价值观：谦逊（Modesty）。 　XP用“沟通、简单、反馈、勇气和谦逊”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

1.2 持续集成

1.2.1 经典软件开发方法的集成方式比较

软件集成是一个软件开发过程，在这个过程中，通过管理和技术手段，将已开发出的软件组件或代码单元，整合成完整的软件产品，并对该产品进行测试和验证以确保产品符合用户需求，通常也被称作系统集成或集成测试。因此集成方式对于软件开发的重要性不言而喻。下面对几种经典的软件开发模型的集成方式进行比较：

瀑布模型^[5]是最早出现的软件开发模型，其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。如下图所示。

图2. 1 瀑布模型

从上可知瀑布模型本质是一种线性顺序模型。在开始下一阶段工作前必须完成上一阶段的所有工作。而后一阶段出现了问题要从前一阶段重新确认解决。所以当问题发现的越晚，解决问题所需要付出的代价就越高。

相对应的，瀑布模型的集成方式可总结为两个步骤：首先是每个模块的需求分析、设计、编码、测试和调试，相当于单元模块开发；然后是将各单元模块进行系统集成。

各个模块在系统集成前并没有一起工作过，因此首次系统集成必然出现许多新问题，一旦出现问题，则所有模块都需要进行调试。一般把这种集成方式成为Big-Bang集成。这种集成方式前提是模块之间的独立性较高，而现代软件开发中开发人员之间的相互合作依赖程度越来越高，几乎不可能存在相互独立的模块。而且很多bug都是在后期的集成中才发现的，这样将直接导致高昂的系统修复代价，严重影响了开发进度，同时使得项目开发进度和现状难以预估。因此Big-Bang集成方式只适用于模块间相互独立的小型项目。

随后Rational公司提出了Rational统一过程（简称RUP）。RUP方法中，通过迭代将整个项目的开发目标划分成为一些更易于完成和达到的阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而所从事的一些列开发活动。在每个迭代开始前都要根据项目当前的状态和所要达到的阶段性目标制定迭代计划，整个迭代过程包含了分析、设计、编码和测试等开发活动，迭代完成后需要对完成的结果进行评估，并以此为依据来制定下一次迭代的目标，如下图所示。

 图2. 2 RUP递增迭代模型

迭代RUP的集成模式步骤分为三步^[6]：

（1）开发系统中一个小的功能模块，它可以说最小的功能块，但应该是系统中一个关键部分，彻底检查调试，然后将该模块作为一个核心，在它基础上设计系统的其他部分模块；

（2）设计、编码、检查和调试程序；

（3）将这些新程序代码集成到已经彻底测试的核心模块上。检查、调试核心模块和这些新程序的组合，在加入新程序之前，一定要确保组合工作正确，如果其余工作已被完成，重复过程从第二部开始。

整个集成过程是一个递增的过程，通常把这种集成方法称为“递增迭代”集成。

递增迭代集成能容易的确定错误位置——错误一定在新程序功能模块上。而且由于每次只集成少量代码程序，因此出现的问题数量也大大减少，降低由于多个问题相互作用产生新问题或者问题间相互掩盖的风险。大大提高的开发效率。

由于迭代递增过程中没有量化迭代间隔和每次增加人物的工作量，从而在实践中容易出现“迭而不增”和“增而不迭”两种错误。“迭而不增”变成简单的重复，并没有增加实际的功能；“增而不迭”变回了简单的线性模型

微软过程模型（MSF）^[7]和“每日构建”集成模式是上述问题的解决方法之一。微软过程模型是由微软公司根据自身实践经验为企业设计的一套有关软件开发的准则。MSF过程模型是一种基于阶段的，由里程碑驱动的，递进的软件开发模型。

MSF过程模型建议项目组首先创建、测试和提供包含核心功能的产品模块，然后再向其中添加功能，提出后续版本。一般被称为递进的版本发布策略。每个版本代表一个开发阶段，这种做法更有利于产品的质量，也更便于在开发过程中对项目进行调整。MSF要求项目组在开发过程中迅速完成每一次递增过程，并在每一次开发周期中都能切实的增加产品的特性，提高产品质量。

MSF其对应的集成模式为“每日构建”（Daily Build）。每日构建包括以下步骤：

（1）定期检查源代码库；

（2）如果源代码库中发生改变将触发构建和后续测试；

（3）给源代码库的当前构建作一个标签，以便将来可以在当前够的基础上进行重新构建；

（4）给相应开发人员发送构建情况反馈。

MSF把集成变成了简单的工作，并把迭代间隔量化为每天，迭代的增量为每天的工作量，解决了迭代递增集成中容易出现的问题。

1.2.2 持续集成过程

技术的发展开始呈现出高速化的姿态，在此驱动下，软件开发也必须实现快速化的开发以适应技术的发展。此时敏捷开发便出现了，简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。它以适应性的过程来代替传统的预测性的过程，在很大程度上满足了现代商业软件业务复杂、需求多变、时间要求紧迫等特点。

相比瀑布式开发漫长严格的开发周期，敏捷开发要求在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。而相比同样强调较短开发周期的迭代式开发，敏捷开发的周期更短，并更注重队伍中的高度协作。

而极限编程作为敏捷开发的方法之一，其中有一项最佳实践，即持续集成。极限编程认为：项目每天可以构建多次，而不只一次，每日构建是最低要求。一个完全自动化的过程应该让项目每天完成多次构建，这是可行的。在工作几个小时的开发后，就要对刚才工作的代码进行集成和测试，并快速获得反馈。持续集成虽然是出自极限编程的实践，但随着持续集成的发展，它已经开始作为一种优秀的软件开发实践应用于各种开发方法中。

持续集成^[8]与“每日构建”相比有几点不同：首先，持续集成比每日构建的集成频率更高，具体依据项目而定；再者持续集成在集成失败后向开发人员提供快速的反馈，让开发人员可以迅速修复错误，而不仅仅是在成功构建后提供一个稳定的版本；最后持续集成鼓励开发人员频繁的提交代码修改并得到尽快的反馈，每次修改的代码量减少后，出现问题的修复也变得容易和迅速。

1.2.3 持续集成的原则

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

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

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

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

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

1.2.4 持续集成的价值

（1）一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况。

（2）减少重复的过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及反馈。通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多的投入到动脑筋的、更高价值的事情上。

（3）持续集成可以在任何时间发布可以部署的软件。从外界来看，这是持续集成最明显的好处，我们可以对改进软件品质和减少风险说起来滔滔不绝，但对于客户来说，可以部署的软件产品是最实际的资产。利用持续集成，您可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。不采用持续集成的情况下，这些问题有可能到交付前的集成测试的时候才发现，有可能会导致延迟发布产品，而在急于修复这些缺陷的时候又有可能引入新的缺陷，最终可能导致项目失败。

（4）持续集成让我们能够注意到趋势并进行有效的决策。如果没有真实或最新的数据提供支持，项目就会遇到麻烦，每个人都会提出他最好的猜测。通常，项目成员通过手工收集这些信息，增加了负担，也很耗时。持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和缺陷率。再者由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息。

（5）持续集成可以建立开发团队对开发产品的信心，因为他们清楚的知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。而长期稳定的成功构建将极大的鼓舞团队的士气。

1.2.5 持续集成的应用

（1）团队开发。工程化软件开发中的开发团队规模往往上百人，且工程中又有许多分支，这时就需要统一的工程管理措施来确保准确有效的开发工作。

（2）作为许多流行的软件开发理论的基础组成部分，例如敏捷开发，Staging Delivery，RUP 中的迭代开发等。拿敏捷开发来说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

（3）运营与开发。像淘宝之类网站在进行开发、测试（压力测试、兼容性测试等）、上线（同时要装到N台服务器上）、数据维护等均需要运用到持续集成技术。

1.2.6 持续集成的常见工具

持续集成概念发展的十多年间，早已经出现了许多用以支持这一概念的工具，这些工具的组合使用为软件开发提供了强大的支持。

一般来说，持续集成工具可以分为两大类：自动化构建工具和构建计划安排工具。

（1）自动化构建工具

自动化构建工具有这样一些基本功能：代码编译、组件打包、程序执行和文件操作。编译源代码是构建的主要工作之一，为了提高效率，编译应该根据相应的源代码是否发生改变而有条件地执行。组件打包是将编译的结果和其他需要包含的文件组织在一起，形成可以部署的组件。构建工具应该知道何时需要重新打包。程序执行是指构建工具能够在它支持的平台上，调用所有提供命令行接口的程序。构建工具应该支持创建、拷贝、删除文件和目录等操作。

某些自动化构建工具还有一些扩展功能：执行开发者测试、版本控制工具集成、文档集成、部署功能、代码品质分析、支持扩展、多平台构建、加速构建。虽然构建工具可以通过命令行执行的方式来集成构建工具和测试工具，但如果它提供更直接的集成方式，开发者就更省力。同样，如果构建工具能够直接与版本控制工具集成，开发者也会觉得更方便。文档集成是指构建工具能够自动从源代码中抽取并生成API文档。构建工具还可以将打包好的组件自动部署到目标测试环境中去。构建工具一般通过一些第三方插件，支持对代码品质进行分析。而提供插件接口，是构建工具实现可扩展性的通用方式。如果您开发的软件需要在多个平台上构建并测试，那么构建工具对多平台的支持就会带来极大的方便。对于较大的代码集，一次构建可能需要好几个小时，这为持续集成带来了一些挑战。有的构建工具支持加速构建，即在多个构建服务器的多个处理器上进行分布式构建。

常见的自动化构建工具包括Ant、NAnt、Gradle、MSBuild、make、Maven、Rake、Doxygen等。

（2）构建计划安排工具

构建计划安排工具，通常也叫做持续集成服务器，其基本功能为：构建执行、版本控制集成、构建工具集成、提供反馈、为构建打上标签。构建计划安排工具的核心功能就是在特定时间执行自动化的构建，这可以通过轮询版本控制库、计划驱动或事件通知等方式来实现。大部分构建计划安排工具都支持大多数流行的版本控制系统，也支持大多数流行的构建工具。构建计划安排工具至少支持通过电子邮件提供反馈信息，有一些工具可以通过即时消息、手机短信或其他设备来提供反馈。大多数构建计划安排工具会提供某种类型的升序计数，作为构建版本的标签。

某些构建计划安排工具还有一些扩展功能：支持项目间依赖关系、提供用户界面、制品发布、安全。如果项目间存在依赖关系，您可能希望在被依赖的项目重新构建时，重新构建依赖于它的项目。设计良好的用户界面会在工作时为您节约时间。制品发布是指除了得到可部署的组件之外，一些成熟的某些构建计划安排工具可以将文档、测试结果、品质分析结构和其他测量指标数据格式化，便于查看。有一些工具提供了身份认证和授权等安全方面的功能，允许您指定谁能查看结果和修改配置。

常见的构建计划安排工具包括AnthillPro、Continuum、CruiseControl、CruiseControl.NET、Draco.NET、Luntbuild、Jenkins等。

（3）其他与持续集成相关的工具

现代软件开发中必然有一个源码管理系统来管理项目代码，不然代码的存储将会杂乱无章。而一个完整的持续集成系统中必然也少不了这一工具。源码管理系统也可称为版本管理工具，主要分为两种：集中式和分布式。集中式版本管理代表为Subversion(SVN)，分布式的代表为：Git。Git还可以配合代码审核工具Gerrit实现强制代码审核功能。Gerrit通过网页的形式方便负责人对开发者提交的代码进行审核、评论等，省去了审核人需要自行下载代码在本地查看提交变化的流程。进一步方便了版本管理。Gerrit可结合持续集成服务器，为每次代码变更触发一次自动编译，若自动编译无法通过，则直接review不通过，省去审核人时间。

1.2.7 持续集成常见方案

一个完整的持续集成系统由以下几部分组成：

（1）一个自动构建过程，包括自动编译、分发、部署和测试等。可使用ANT或者Maven等工具；

（2）一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。例如Subversion、Git、CVS；

（3）一个持续集成服务器。Cruise Control、Jenkins等。

按照该组成，你可以选用自己喜欢的工具来设计你自己的持续集成系统方案。比如PMS平台（JIRA+CruiseControl+Subversion）^[10]、Git+Jenkins+Gerrit^[11]等。

2 基于Jenkins的软件自动构建系统方案设计

2.1 基于Jenkins的自动构建系统方案

Jenkins 是一个可扩展的持续集成引擎。

主要用于：

• l 持续、自动地构建/测试软件项目。
• l 监控一些定时执行的任务。

Jenkins拥有的特性包括：

• l 易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。
• l 易于配置-所有配置都是通过其提供的web界面实现。
• l 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。
• l 生成JUnit/TestNG测试报告。
• l 分布式构建支持Jenkins能够让多台计算机一起构建/测试。
• l 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
• l 插件支持:支持扩展插件，你可以开发适合自己团队使用的工具。

2.2 基于Jenkins的自动构建系统方案的工作过程

下面我们基于以上的模型来描述一下该自动构建系统的工作过程。

部署一个CI系统需要的最低要求是，一个可获取的源代码的仓库，一个包含构建脚本的项目。

下图概括了CI系统的基本结构：

2.3 选用Jenkins插件

在前面两节中我们详细描述了本设计中持续集成系统方案的核心工具的选用和其工作流程，但事实上，每个使用持续集成技术的公司，他们的持续集成系统都有他们自己的特色和要求。这时候Jenkins强大丰富的插件框架就能体现出它得天独厚的扩展能力：超过600种插件和可自主开发的开源环境让你深深体会到：只有想不到，没有做不到。下面我们来介绍一下本设计方案中采用了哪些Jenkins的插件和第三方软件的支持。

（1）android构建常用的插件有：

3  基于Jenkins的软件自动构建系统方案的实践

3.1 Jenkins安装与配置

3.1.1 Jenkins安装

3.1.2 Jenkins配置

3.1 系统管理

在已运行的Jenkins主页中，点击左侧的系统管理进入如下界面：

3.1.1 提示信息

Ps：版本不同提示的消息有可能不同

3.1.1.1 Utf-8编码

Your container doesn‘t use UTF-8 to decode URLs. If you use non-ASCII characters as a job name etc, this will cause problems. See Containers and Tomcat i18n for more details.

Jenkins建议在tomcat中使用utf-8编码，配置tomcat下conf目录的server.xml文件 URIEncoding编码设置

 

Ps：如果Job的控制台中文输出乱码，请将URIEncoding=”utf-8”更改为useBodyEncodingForURI="true"

3.1.1.2 新的版本

点击下载更新

提示有新的版本可以下载了,喜欢更新的点击download去下载吧！

3.1.1.3 安全设置

 

图5 安全提示消息

詹金斯允许网络上的任何人代表您启动进程。考虑至少启用身份验证来阻止滥用。点击Dismiss忽略该消息,点击Setup Security进入设置界面.详细设置请参考 Configure Global Security(安全设置) 章节

3.1.2 系统设置

在已运行的Jenkins主页中，点击左侧的系统管理—>系统设置进入如下界面：

3.1.2.1 JDK、Maven、Ant配置

配置一个JDK、Ant、Maven实例，请在每一节下面单击Add(新增) 按钮，这里将添加实例的名称和绝对地址。下图描述了这两个部分。

JDK别名：给你看的，随便你自己，JAVA_HOME

JAVA_HOME：这个是本机JDK的安装路径（错误的路径会有红字提示你的）

自动安装：不推荐这个选项

后面Ant与Maven的配置是一样的，JDK去oracle官网下载，Ant与Maven去apache官网下载

Ps：每个文本框后面都有个问号，点击问号就会出现帮助信息

3.1.2.2 邮件通知配置

3.1.2.2.1 配置Jenkins访问地址发件人地址

 

System Admin e-mail address：Jenkins邮件发送地址，如果你这个没有配置，等着发邮件的时候报错吧

ps:这里设置服务器URL时：配置的服务器地址URL,必须关闭被设置服务器的防火墙；如设置http：//192.168.16.73:8080/jenkins/

进入远程服务器命令：

设置IE警报：

3.1.2.2.2 配置邮件通知（现没有用上，后续加入配置）

这个就非常的简单了，根据的的邮箱提供者的参数配置就行了。

Ps：小技巧：用户默认邮件后缀配置了后，以后你填写邮件地址只需要@之前的就行了

3.1.2.3 Subversion配置

Subversion Workspace Version：Subversion 的版本号，选择你对应的版本号就行了

3.1.3 Configure Global Security(安全设置)

在已运行的Jenkins主页中，点击左侧的系统管理—>Configure Global Security进入如下界面：

各种权限如下(在配置页面将鼠标放到该权限上即可查看帮助)：

Overall(全局)

Credentials(凭证)

Slave(节点)

Job(任务)

View(视图)

Administer

Read

RunScripts

UploadPlugins

ConfigureUpdateCenter

Create

Update

View

Delete

ManageDomains

Configure

Delete

Create

Disconnect

Connect

Build

Create

Delete

Configure

Read

Discover

Build

Workspace

Cancel

Create

Delete

Configure

Read

管理员(最大)

阅读

运行脚本

升级插件

配置升级中心

创建

更新

查看

删除

管理域

配置

删除

创建

断开连接

连接

构建

创建

删除

配置

阅读

重定向

构建

查看工作区

取消构建

创建

删除

配置

阅读

其中有一些比较特别的权限：

最大的权限是Overall的Administer，拥有该权限可以干任何事情。

最基本的权限是Overall的Read，用户必须赋予阅读的权限，不然什么都看不到。

Job的Discover权限是一个奇葩的权限，帮助说Discover比Read的级别更低。如果匿名用户(没有访问job的权限)直接访问一个Job的Url将重定向到登陆页面。(经测试，这个权限应该是被废弃了。)

Credentials的ManageDomains这个权限没有看懂干嘛的，有懂的大家一起交流哈！

 

ps：如果有个用户被赋予了Overall的Read，并没有被赋予Job的Read权限，那么该用户就无法访问job。原因：没有权限。(这个可以配置基本匿名的查看权限)

 如：

其他都是一些基本的权限，大家根据自己的需求选择。

 小技巧：

每个用户后都有1-2个图标，第一个是反选功能(删除当前已选择的权限，选择其他所有权限)，第二个是删除功能(删除该用户)

 

 

在Job中配置项目安全，如下图：

设置如上图，保存后系统管理中就出现管理用户的选项。页面右上角也会出现登录/注册的选项。

3.1.4 管理用户设置

在右上角点击注册

点击sign up按钮，提示你现在已经登录.返回首页.

登录后和匿名账号看到的首页有几点不同，如下图红框所示：

读取配置，放弃当前内存中所有的设置信息并从配置文件中重新读取 仅用于当您手动修改配置文件时重新读取设置。这个点击配置好后，会使Jenkins重启：

3.1.5 管理插件设置

建议先阅读Jenkins插件章节，在回来安装如下所示的插件。这个插件将生成的构件（war或者ear）部署到主流的服务器上。

插件名称：Deploy Plugin

插件介绍：This plugin takes a war/ear file and deploys that to a running remote application server at the end of a build

3.1.6 系统信息

查看当前Jenkins系统属性的配置；

3.2 项目构建设置

3.2.1 构建自由风格的Job

3.2.1.1 新建自由风格构建任务

在已运行的Jenkins主页中，点击左侧的新建Job进入如下界面：

这时，需要为新的构建任务指定一个名称。（这里输入的任务名称为：Testjenkins）这里有几种的任务类型可供选择，鉴于初步介绍，先选择构建一个自由风格的软件项目。对于其他的类型,经常使用的是拷贝已存在任务;这主要为了能在现有的任务基础上新建任务。点击OK按钮，

3.2.1.2 构建任务配置

3.2.1.2.1 源码管理配置（可设置svn和Git）

演示是使用Subversion的链接，在Repository URL中输入你的项目链接，如果没有权限则会提示如下图：如果是本地jenkins就不用配置自己svn，jenkins它自动会找到系统的配置；

 

点击 enter credential 输入用户名和密码(我猜大家一般都是使用的用户名和密码登陆的)

 

图16 Subversion权限认证界面

Ps：svn的用户名和密码设置了是没有办法在web界面修改的。如果要修改则先去Jenkins目录删除hudson.scm.SubversionSCM.xml文件（点到为止，毕竟这只是入门教程）

3.2.1.2.2 构建触发器

在其他项目构建完成后才执行构建：指定的项目完成构建后，触发此项目的构建。

Poll SCM ：这是CI 系统中常见的选项。当您选择此选项，您可以指定一个定时作业表达式来定义Jenkins每隔多久检查一下您源代码仓库的变化。如果发现变化，就执行一次构建。

例如，表达式中填写0,15,30,45 * * * *将使Jenkins每隔15分钟就检查一次您源码仓库的变化。

Build periodically ：此选项仅仅通知Jenkins按指定的频率对项目进行构建，而不管SCM是否有变化。如果想在这个Job中运行一些测试用例的话，它就很有帮助。

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

Poll SCM：定时检查源码变更（根据SCM软件的版本号），如果有更新就checkout最新code下来，然后执行构建动作。

    这里我选Poll SCM，（H/5 H(9-23) * * *）

    第一个参数代表的是分钟 minute，取值 0~59；
    第二个参数代表的是小时 hour，取值 0~23；
    第三个参数代表的是天 day，取值 1~31；
    第四个参数代表的是月 month，取值 1~12；
    最后一个参数代表的是星期 week，取值 0~7，0 和 7 都是表示星期天。
    如H/5 * * * * 表示的就是每5分钟检查一次源码变化。

3.2.1.2.3 Ant构建配置

因为我的项目是用ant脚本实现的编译和打包，所以我选择的是Invoke Ant，Ant Version选择你Ant配置的那个名字，注意不要选择default喔，那个选择了没有用。

测试环境下配置：

 

测试环境下也可以这样配置，不过没有试过；

正式环境下配置：

如果你的构建脚本build.xml不在workspace根目录、或者说你的构建脚本不叫build.xml。那么需要在高级里设置Build File选项的路径，指明你的脚本。注意：是相对路径

部署请参考：war文件部署章节

打包APK后同时对apk进行签名：

方法一：在Jenkins中配置key各种东西；（记住这里配置SDK位置一定要是配置服务器的地址，要不然它会编译不了）

代码配置:

Jenkins对应的配置：

方法二：直接在local.properies文件中读取配置key;

代码配置：

    Jenkins对应的配置：

PS：后发现这个这两种打正式包都不太好；用Gradle编译打正式包更加麻烦；

 Gradle构建配置（目前发现性能不能好，打包要运行的很久）

打包运行Debug版本：

注意这里得设置保存路径apk位置，pmall/build/outputs/apk/*.apk(得是相对路径)

打包运行Release版本：（待续）

注意上面ant和gradle环境下配置存档文件的配置：（记住这里得配置相对路径的位置）

ant： **/bin/*.apk

gradle:pmall/build/outputs/apk/*.apk

打包APK,签名和zipalign优化后把APK装到与Jenkins主机相连的手机上。

在Jenkins构建Invoke Ant脚本后，增加一个Shell调用步骤，内容如下：

#!/bin/bash

adb uninstall com.zsy.testjenkins(.apk)

adb install /target/dir/apks/com.zsy.testjenkins.apk

前提是：

 （1）安装android usb driver 

  (2)手机与电脑相连 

  (3)电脑进程中没有tadb.exe、豌豆夹等运行。

（4）如果不需要在设备上进行debug，可以更新AndroidManifest.xml文件，去掉android:debuggable。

可能出现的问题：

原因：在64位Linux下打包成APK时缺少x86下C++语言库。

解决： 

# yum install -y libstdc++.so.6 

遇到的问题：tomcat下gradle 构建如果遇到Could not load Logmanager "org.apache.juli.ClassLoaderLogManager"（但是总体apk的编译）

解决：注释掉catalina.bat里面的set JAVA_OPTS=%JAVA_OPTS% %LOGGING_MANAGER%即可

android build.gradle配置

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath ‘com.android.tools.build:gradle:0.5.6‘//依赖
    }
}
 
apply plugin: ‘android‘
 
dependencies {
    compile fileTree(dir: ‘libs‘, include: ‘*.jar‘)//添加android依赖libs
}
 
android {
    compileSdkVersion 17
    buildToolsVersion "17.0.0"
    //签名
    signingConfigs {
        myConfig {
            storeFile file("debug.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
    }
     
    defaultConfig {
        versionCode 1
        versionName getVersionName()
        minSdkVersion 8
        targetSdkVersion 17
    }
 
    //渠道
    productFlavors {
        google{
         
        }
        tantai{
         
        }
    }
     
    buildTypes{
        release {
            signingConfig signingConfigs.myConfig
            runProguard true
            proguardFile ‘proguard.cfg‘
        }
    }
     
    sourceSets {
        main {
            manifest {
                srcFile ‘AndroidManifest.xml‘
            }
            java {
                srcDir ‘src‘
            }
            res {
                srcDir ‘res‘
            }
            assets {
                srcDir ‘assets‘
            }
            resources {
                srcDir ‘src‘
            }
            aidl {
                srcDir ‘src‘
            }
        }
    }
}
 
 
tasks.withType(Compile) {
    options.encoding = "UTF-8"
}
//替换AndroidManifest.xml的UMENG_CHANNEL_VALUE字符串为渠道名称
android.applicationVariants.all{ variant -> 
    variant.processManifest.doLast{ 
        copy{
            from("${buildDir}/manifests"){
                include "${variant.dirName}/AndroidManifest.xml"
            }
            into("${buildDir}/manifests/$variant.name")
 
            filter{
                String line -> line.replaceAll("UMENG_CHANNEL_VALUE", "$variant.name")
            }
 
            variant.processResources.manifestFile = file("${buildDir}/manifests/${variant.name}/${variant.dirName}/AndroidManifest.xml")
        }    
   }
}

这个插件Sounds不错，自己配置编译出错的情况下发送不同的声音：

---

3.2.2 构建Maven风格的Job（待研究）

这个要求配置安装Maven;

3.2.2.1 新建Maven构建任务

 

图18 新建Job界面

这时，需要为新的构建任务指定一个名称。（这里输入的任务名称为：maven_test）这里有几种的任务类型可供选择，鉴于初步介绍，先选择构建一个maven2/3项目。对于其他的类型,经常使用的是拷贝已存在任务;这主要为了能在现有的任务基础上新建任务。点击OK按钮，

3.2.2.2 构建任务配置

 

3.2.2.2.3 Maven构建设置

 

图22 Maven构建配置界面

2013-08-22补充Goals and options ：clean install  -Dmaven.test.skip=true　　#加入了跳过测试的代码

Root POM:填写你项目的pom.xml文件的位置，注意：是相对位置，如果该文件不存在，会有红色字提示。

部署请参考：war文件部署章节

3.2.2.2.4 构建maven项目的心得

使用Jenkins构建maven项目的一点小心得：

maven项目的构建是比较麻烦的，如果你的项目是下图这种结构。那么恭喜你！你新建一个job就可以了，因为只有一个根。如果你的svn地址是：https://192.xxx/Pe_Project/root-pom，那么Root POM只需要保持默认就行了，因为Jenkins可以再workspace目录下面找到pom.xml文件

如果你的svn地址是：https://192.xxx/Pe_Project，那么Root POM需要指定为root-pom/pom.xml，因为Jenkins可以再workspace/root-pom目录下面找到pom.xml文件

 

图23 Maven项目结构界面1

上面这种方法打包的时候非常简单，但是用eclipse开发的时候你就不右键run as —>tomca启动了，如果你想使用这种方式，将tomcat换成jetty即可。

 

如果你的项目是下图这种结构，那么非常悲剧的告诉你，你要建立好几个job来构建这一个项目，因为这个项目有4个根。

 

图24 Maven项目结构界面2

上面这种方法打包的时候比较麻烦，但是用eclipse开发的时候你就可以使用右键run as —>tomca启动了

 

---

3.2.3 邮件通知设置

 

图25 构建后操作界面

选择Add post-build action，然后选择E-mail Notification，如下图：(注意这里这里配置是环境是本地的Jenkins的话，编译会报错。所以配置这个要在外网配置更好)

图26 收件人列表界面

在Recipients中输入收件人邮件地址，如果用多个收件人用“,”英文逗号隔开

3.2.4 War文件部署设置

首先你必须安装好Deploy Plugin插件，然后在tomcat的conf目录配置tomcat-users.xml文件，在<tomcat-users>节点里添加如下内容：

<role rolename="manager-gui"/>

<role rolename="manager-script"/>

<role rolename="manager-jmx"/>

<role rolename="manager-status"/>

<user username="username" password="password" roles="manager-gui,manager-script,manager-jmx,manager-status"/>

引号里的username和password可以随便替换，待会要用的。

好了，回到Jenkins项目配置页面：

 

图27 构建后操作界面

选择Add post-build action，然后选择Deploy war/ear to a container，如下图：

 

图28 远程部署配置界面

WAR/EAR files：war文件的存放位置，如：target/test.war 注意：相对路径，target前是没有/的。

Context path：访问时需要输入的内容，如ofCard访问时如下：http://192.168.x.x:8080/ofCard/如果为空，默认是war包的名字。

Container：选择你的web容器，如tomca 6.x

Manager user name：填入tomcat-users.xml配置的username内容

Manager password：填入tomcat-users.xml配置的password内容

Tomcat URL：填入http://192.168.x.x:8080/

Deploy on failure：构建失败依然部署，一般不选择

注意：虽然这种部署方法可能会导致tomcat加载时出现卡死的现象。但是也是最简单的部署方式。如果卡死了重启下就好了，将tomcat的java内存参数调高可以解决这个问题。

最后不要忘记点击保存喔。

好了！到此一个项目的获取源码，打包，远程部署，邮件通知就完成了。

3.3 监控

当任务一旦运行，您将会看到这个任务正在队列中的仪表板和当前工作主页上运行。这两种显示如下。

图29 主页监控（左），项目监控（右）

一旦构建完成后，完成后的任务将会有三个地方进行显示。

你可以在Jenkins的控制面板上看到它，如下图。

 在上面展示的截图中，您将注意到有两个图标描述当前作业的状态。S栏目代表着“最新构建状态”，W栏目代表着“构建稳定性”。Jenkins使用这两个概念来介绍一个作业的总体状况：

构建状态:下图中分级符号概述了一个Job新近一次构建会产生的四种可能的状态： 

Successful:完成构建，且被认为是稳定的。

Unstable:完成构建，但被认为不稳定。

Failed:构建失败。

Disabled:构建已禁用。

 

图31 构建状态界面

构建稳定性: 当一个Job中构建已完成并生成了一个未发布的目标构件，如果您准备评估此次构建的稳定性，Jenkins会基于一些后处理器任务为构建发布一个稳健指数 (从0-100 )，这些任务一般以插件的方式实现。

它们可能包括单元测试(JUnit)、覆盖率(Cobertura )和静态代码分析(FindBugs)。分数越高，表明构建越稳定。下图中分级符号概述了稳定性的评分范围。任何构建作业的状态(总分100)低于80分就是不稳定的。

 

图32 构建稳定性界面

当前作业主页上还包含了一些有趣的条目。左侧栏的链接主要控制Job的配置、删除作业、构建作业。右边部分的链接指向最新的项目报告和构件。

通过点击构建历史（Build History）中某个具体的构建链接，您就能跳转到Jenkins为这个构建实例而创建的构建主页上。如下图

 

图34 构建历史界面

如果你想通过视图输出界面来监控当前任务的进展情况。进入每次编译的结果中查看后台打印的信息；

你可以单击Console Output（控制台输出）。如果工作已完成，这将显示构建脚本产生的静态输出；如果作业仍然在运行中，Jenkins将不断刷新网页的内容，以便您可以看到它运行时的输出。如下图：

4 Jenkins插件

从Jenkins现有的功能扩展或开发者们为Jenkins提供的新功能都可以称之为Jenkins插件。有些插件可以无缝添加到您的构建过程，而其它，诸如除CVS和Subversion的SCM插件则需要源代码控制系统的支持。

4.1 Jenkins插件安装

Jenkins 插件管理器允许您安装新的插件，和更新您Jenkins服务器上的插件。管理者将连接到联机资料库，检索可用的和已更新的插件。如果您的Jenkins服务器 无法直接连接到外部资源，您可以从Jenkins网站上下载。

在已运行的Jenkins主页中，点击左侧的系统管理—>管理插件进入如下界面：（Jenkins默认的安装了部分很有用的插件）

注意如果安装是要FQ的软件，确保你当前的Jenkins的设置的代理FQ；（如下载Gradle插件）：

方法一：当前Jenkins环境下FQ下；

方法二：离线安装；

方法三：通过已经安装的gradle，复制到插件文件夹中；

图36 插件管理界面

它包含四个标签：

更新:清单中列示了Jenkins为某些插件搜索到了可用的更新。列出的每个插件可以被选择并应用更新。

可选安装:清单中列示了可用于安装（而不是目前已安装的）的所有插件。列出的每个插件都可以被选择并安装。

已安装:清单中列示了已经安装的插件。

高级:允许您通过设定HTTP代理的方式使Jenkins与在线插件库建立连接。此外，还提供了一个上传设备，可以安装你在Jenkins以外已下载的那些插件。

由上图可知，Jenkins缺省集成了maven2插件，并且一旦插件有新版本，会提示更新新版本插件。

如果想安装新的插件，可以点击tab分页中的可选插件。如下图：

从图可知，各种Jenkins插件根据之前所记述的类型进行分门别类。可勾选任意想安装的Jenkins插件，点击Install without restart按钮进行安装。安装后，所有插件以hpi作为后缀名放置在plugins文件夹下。如果是高级用户还可以自行开发插件方便具体项目使用。

注意：安装完成后需要重启Jenkins部署的容器。这样才能使用新装的插件。

4.2 Jenkins插件安装示例

Jenkins运行自动部署war包到servlet容器内，要实现这个功能必须安装一个插件。

 

图38 安装插件界面

 

图39 插件安装界面

好了，到此Deploy Plugin插件安装完成！

Project pmall_app_android_as

一元拼宝、拼宝持续集成 
备注: 
1:android这边目前用CI配置打包Debug(非Release)版本的； 
2:测试部要构建打包时，请提前通知下开发部提交代码； 
3:由于是Debug版本不能用于测试app分享功能和发布正式版本； 
4:如要测试分享功能请手动打包并且切换到正式环境测试； 
apk安装方法步骤： 
1：卸载手机上拼宝apk;（有的手机可省略这步） 
2：点击pmall-debug.apk下载到本地通过手机助手安装；

来源： <http://192.168.16.73:8080/jenkins/job/pmall_app_android_as/>

2015年4月30日 11:17:40 edit by samy 

---

 CI性能优化：

目前发现：单独用用1.2as运行一次；

gradle clean build:

gradle build:

gradle build:

    1:没有修改代码时：

    2:修改代码时：

gradle assembleDebug:(可以用这个打编译Debug的版本包)

gradle assembleRelease:(可以用这个打编译Release的版本包)

---

Jenkins ant配置App打包总结

0：环境；

1：进入本地app和相关Lib运行命令：

android update project -p . 

2:运行完后会生成相应的三个文件：build.xml   progurd-project.txt  local.properties(这个本身有)

修改project.properties文件的配置确保跟服务器SDK版本和路径一致；（这个非常重要，一个项目负责人一定要维护好这个配置）

目前服务器SDK编译版本：21 和19

SDK路径：

#Local sdk 

#sdk.dir=D:\\samy\\android\\sdk

#Server sdk 

sdk.dir=E:\\software\\work\\android\\sdk

3:进入项目主项目DOS环境。运行命令：ant clean debug（release） (编译下本地看是否有错误)

4:在本地编译不会出错的情况下，上传的svn（记住确保在SVN中的当前项目所在目录只有当前项目项目相关项目）;通过相应的配置Jenkins运行自动构建

Jenkins服务器配置：