1、持续集成 Continuous integration 简介（持续集成是什么）.持续集成源于极限编程 (XP)， 是一种软件实践， 软件开发过程中集成步骤是一个漫长并且无法预测的过程。集成过程中可能会爆发大量的问题，因此集成过程需要尽可能小而多，实际上持续集成讲的是不断的去做软件的集成工作。持续集成作用（使用持续集成和不适用持续集成的区别）场景一、 某项目最后做模块集成的时候， 发现很多接口都不通， 甚至有的模块连安装包都没有。场景二、没有可用的软件包，需要人手动去编译打包最新的代码。场景三、搭建测试环境的时候需要手动去解压包然后一系列拷贝修改配置等等。场景四、团队成员或者 teamleade
2、r 想了解当前项目的状态，该如何去展示这些信息。持续集成就是用来解决以上问题， 它的价值主要在于减少重复的步骤， 降低项目的风险，任何时间任何地点生成可用的软件，增强项目的可见性等。持续集成实践（持续集成怎么做）持续集成，最简单的形式是包括一个监控版本控制系统（ SVN等等）变化的工具。当变化被发觉时，这个工具可以自动的编译并测试你的应用。下面是持续集成中一些良好的实践维护一个单一的代码库使构建自动化使构建自测试每人每天都向主线提交代码每次提交都应在集成机上进行构建快速构建使任何人都能轻易获得可执行文件人人都能看到正在发生什么自动化部署(上面是持续集成介绍，下面引出 jenkins) jenk
3、ins 简介持续集成是一种实践，而 jenkins 可以帮助团队去尽量好的去完成这种实践Jenkins 是基于 java 语言的开源持续集成工具，提供了一套非常易用的用户界面jenkins 类似于 eclipse，基于插件化的架构，方便功能的扩展，目前有几百个现成插件可以使用，这些插件涵盖从版本控制、构建工具、代码质量、构建通知、集成外部系统、 UI 定制、游戏等等各个方面安装 jenkins jenkins 默认提供了三种安装方式1. 最 简 单 的 方 式 是 通 过 java web 的 启 动 方 式 ， 访 问http:/ 默认第一次下载 jenkins.jnlp 即可启动2.下载可
4、执行的 war 包启动 jenkins 3.部署到 tomcat 中（推荐）一个最简单的 jenkins 应用在介绍该应用前，先提及两个非常重要的概念job 一个完整的构建可能需要很多步骤，每个步骤都称作是一个 job。一个 job 是一个专一做某事的步骤，比如编译，测试，打包，部署等等。 jenkins 中默认提供了四种不同类型的 job Jenkins 家目录jenkins 为每个项目都会建立一个 workspace 目录，源码会下载到这个目录下，然后编译等动作都在该目录中进行。下面是一个 jenkins 的家目录结构jobs 下面按照项目的维度进行划分，每个项目下有 builds 和 w
5、orkspace 目录，其中源码会保存在各个项目的 workspace 中， builds 目录包含构建的历史记录。假设项目基于 svn 控制系统， 并且有简单的编译打包脚本。 该应用要实现的功能是检测到代码提交后触发构建动作，调用已有的编译打包脚本生成可用的软件包。（上面的配置步骤就不列出来了，想讲的话可以大概讲讲也可以截图）这个最简单的 jenkins 应用执行的原理是应用 svn 的插件，当有代码提交的时候被插件检测到， jenkins 将源码下载到本地的 workspace（包括编译打包脚本） ，此时 jenkins 调用本地项目源码中的编译打包脚本（在配置 job 的时候指定） 。这
6、就是最简单的一个流程，复杂的流水线构建都是基于此而完善的。触发构建的条件除了上面提到的提交构建，能够触发构建的方式还有以下几种隔某段时间构建一次，比如隔一小时自动构建一次。定时轮询 SCM 的改变去触发构建， 比如隔一小时去轮询一次 svn 是否有更改，有的话触发构建，否则不做处理。手动构建自动化测试Jenkins 不仅仅能做源码编译打包的动作， Jenkins 中有很多插件可以方便的实现自动化测试。单元测试功能测试集成测试性能测试验收测试进行自动化测试仅仅是一部分功能，关于测试结果的收集和展示 jenkins 也能够做到，并且是以图形化的方式展示出来。只需要告诉 jenkins 测试结果在哪
7、里，它会自动去取，并生成可视化的图形。另外一种关于自动化测试的是代码的覆盖率， jenkins 同样支持对代码覆盖率的统计。上图中的自动化测试给出详细的失败列表通知持续集成讲究的是快速的发现问题， 尽早的发现问题，因此当出现问题 （编译失败，用例通过率不足等）时需要有通知的手段让相关的人员了解情况。 Jenkins 提供了丰富的通知插件，最常用的是 Email 通知，当然除此之外还有即时通讯软件IRC 桌面通知代码质量代码质量的度量同样也非常重要，比如圈复杂度， checkstyle ， findbugs 等等的静态检查。这些检查都可以使用 jenkins 的插件完成， jenkins 负责收
8、集质量结果，做图形展示，很方便开发人员根据质量结果进行代码重构。自动化部署自动化部署目的就是减少不必要的时间。最简单的是自己实现部署的脚本然后供jenkins 去调用，但是对于复杂的部署需求，自己实现脚本恐怕有些力不从心，我们可以借助插件完成 Puppet 或者 Chef 。对于数据库的自动化部署同样有插件供我们选择比如Liquibase 。Jenkins 的高级功能高级构建参数构建类似普通的构建任务， 但是功能更强大。 可以为本次构建指定一些参数， 这些参数可能会在某几个构建中被使用到，参数的传递由 jenkins 去维护。由此一个普通的构建通过获取不同的参数能够表现的更多样化。更强大的是多
9、配置构建， 类似参数构建， 提供一个配置列表， 比如针对不同的数据库或者浏览器的列表， jenkins 会自动的执行不同场景下的测试，这些测试可以并行的执行，从而大大的减少了测试的时间。分布式构建jenkins 也支持 master/slave 的分布式方式， master 主要用来分发构建任务给 slave ，实际的执行在 slave 中。 Master 监控 slave 的状态， 并收集展示构建的结果。 但是在实际情况中master 同样可以执行构建任务。 可以通过 master 指定某个项目总是运行在特定的 slave 或者某类 slave 或者简单的任何一台 slave 中。分布式构建
10、中， jenkins 提供了对代理节点的监控，如果发现某台 slave 不可用，则会主动将其下线，避免后续的任务被分配到该节点上。流水线所谓的流水线很容易理解， 就是整个构建流程按照一定的流程去构建。 当你的构建步骤变得复杂的时候， 并且并行和串行都有的时候， 通常就不太容易管理了。 流水线能够方便的定义某个构建后要触发的下一个构建， 或者同时触发的后面几个构建。 当然也能够等待某几个构建执行完毕后去执行某一个构建。其中 TheDependency Graph View 插件能够帮助你分析构建任务之间的关系。并且如果涉及到构建的资源竞争，也提供了锁的功能。jenkins 安全管理jenkins
11、 中有多个维度来管理安全，一个是安全域，一个是授权。安全域能够识别出合法的用户，授权则是针对合法的用户给出不同的权限。最简单的授权是允许所有的合法用户做任何事情。最简单的管理用户账号的方式是使用 jenkins 内建的数据库，但是也能够和其他的用户管理系统做集成。针对授权有好多种不同的策略，比如基于项目，基于角色。另外一种重要的功能是审计，也就是记录用户的操作日志。有两种插件能够实现该功能。Audit Trail 插件能够记录用户的操作动作。 JobConfigHistory 插件能够存储前一个版本系统的变化和 job 的配置文件。后面的内容是可选的，可以讲也可以不讲。总结：持续集成一般会经历
12、一下几个阶段阶段一 没有构建服务器最初的阶段， 团队没有任何一种构建服务器。 软件由开发人员手动的去构建， 尽管使用的是Ant 脚本或者类似的东西。源码可能存储在一个中央源码仓库中，但是开发者未必要定期的提交更改后的代码。 有时候在一个版本要发布的时候， 开发人员手动的去集成这些变化， 这是一个非常痛苦的过程。阶段二 夜间的构建在这个阶段，团队有一台构建服务器，并且定时的去执行构建任务（通常在夜里）。因为并没有一个可靠的可重复的单元测试， 所以这里的构建通常只是代码编译。 如果有自动化测试，也并没有强制集成到构建阶段， 也许根本不会正确的运行。 但是现在开发人员已经能够有规律的定期提交代码了，
13、 至少在每天下班前。 如果一个开发人员提交的代码和另外一个人有冲突， 构建服务器会在第二天的早上将告警通过邮件发出来。 然而， 整个团队只是将构建服务器作为一个参考 如果构建挂了， 他们并没有意识去立即把它修复好， 因此构建可能会在一段时间内不可用。阶段三 夜间构建和基本的自动化测试团队现在已经更加严格的使用持续集成和自动化测试了。 构建服务器被配置为当有代码提交的时候便会执行构建， 团队的成员也可以很方便的看到是哪些代码中的变化引起了构建， 这些变化引发了什么问题。 除此之外， 构建脚本编译应用并且自动的执行一些单元和集成测试。对于邮件， 构建服务器能够更加积极主动的去呈现构建中出现的问题。
14、 失败的构建也能够被快速的修复。阶段四 进入度量自动化的代码质量和覆盖率度量也能够执行了， 并且可以帮助评估代码的质量和测试的相关性和有效性。代码质量的构建也能够为应用生成 API 文档。所有的这些帮助团队去维护高质量的代码。团队中可以设置一个醒目的屏幕去时刻展现项目的状态。阶段五 更严格的测试持续集成的好处是非常接近立体的测试。现在，测试驱动开发（ TDD ）被广泛的应用，对于自动构建的结果更加的有信心。 对于应用程序不再是简单的编译和测试， 而是会继续更复杂的端到端测试和性能测试。阶段六 自动化验收测试和自动化部署验收测试驱动开发（ Acceptance-Test Driven Devel
15、opment ）在这个阶段被应用，引导开发的工作并且提针对项目的状态提供一个高层次的报告。这些自动化测试使用行为驱动测试（ Behavior-Driven Development ）和验收测试驱动开发工具，并且从商业的角度生成开发人员不理解的报告。 因为这些高层次的测试在项目的早期开展， 因此能够清晰的指出， 哪些特性已经完成了， 哪些需要后面去完成。 每当代码有改变或者夜里， 应用程序被自动的部署到 QA 的测试环境来完成测试。 当测试人员完成了充分的测试后， 应用程序可以被一键式的部署到生产环境。 当然也能够通过构建工具去备份当前的发布版本， 或者当有问题出现的时候，回归当前的版本。阶段七 持续部署处于对自动化的单元、集成、验收测试的信任，现在团队能够应用自动化部署技术，直接将新的特性增加到前一个版本中，该版本处在生产环境中。这些阶段可以是按部就班的来， 但有时候也不一定非得按照上面的步骤， 比如在集成代码质量和覆盖率测试之前可以先完成自动化的 web 测试。 这里只是给出了部署一套 CI 的常规流程。
