什么是持续集成

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

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

持续集成的核心价值在于

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

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

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

持续集成的原则

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

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

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

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

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

持续集成系统的组成

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

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

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

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

Jenkins 简介

Jenkins 是一个开源项目，提供了一种易于使用的持续集成系统，使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上。同时 Jenkins 能实施监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性。Jenkins前身是hudson，Jenkins 是一个可扩展的持续集成引擎。

Jenkins特点

• 易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。

• 易于配置-所有配置都是通过其提供的web界面实现。

• 集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。

• 生成JUnit/TestNG测试报告。

• 分布式构建支持Jenkins能够让多台计算机一起构建/测试。

• 文件识别:Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。

• 插件支持:支持扩展插件，你可以开发适合自己团队使用的工具。

jenkins基本结构

1. 开发者检入代码到源代码仓库。

2. 系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区。

3. 系统会在对应的工作区内执行构建过程。

4. （配置如果存在）构建完成后，CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。

5. （配置如果存在）如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.NET、 SourceForge之类的网站。

6. 系统通常会根据请求发起相应的操作，诸如即时构建、生成报告，或者检索一些构建好的构件。

本文转自pizibaidu 51CTO博客，原文链接：http://blog.51cto.com/pizibaidu/1917078，如需转载请自行联系原作者