有关持续集成和jenkins

源码管理选择Git

百度百科上对于持续集成的解释

大

开发中，我们经常遇到一些奇怪问题，比如本地可以编译成功的代码但是同事们更新代码后编译出错，或者在项目有多个Target的时候，资源文件只添加到了当前的Target，另外一个Target这个时候是不能正常编译的，再比如写的工具类，被同事改了，或者自己有改动，很多地方用到了，怎么保证这个类的行为没有发生变化而影响到项目中的其它模块呢？诸如此类。

那么这些问题原因在哪，可否避免呢？当然是可以避免的，如果代码有新的改动，提交到版本库中的时候，有一个人帮我们检查必要事项，然后做做测试不就好了，这个当然是可以的，前提是老板同意专门招一个这样的人。

引起各种奇怪问题的原因有很多，比如开发环境比较复杂不干净，IDE的bug，提交前有一些必要的检查需要做，但是开发时因为各种原因没做，这些机械重复的事情我们可以找一个工具来帮我们完成，而且这个工具跑在一个专门的服务器上，该服务器环境相对干净，可以运行一些自动化操作，而自动编译，代码检查，测试等环节，那么这种东西，就是接下来讲的［持续集成］。

个人理解持续集成：为解决程序代码提交质量低，提交内容导致原有系统的bug，按时或按需自动编译版本，自动进行自动化测试。

师Martin Fowler对持续集成是这样定义的:持续集成是一种 软件开发实践 ，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布， 自动化测试 )来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发 内聚 的软件。

减少重复过程

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

任何时间、任何地点生成可部署的软件

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

要素

编辑

1.统一的代码库

2.自动构建

3.自动测试

4.每个人每天都要向代码库主干提交代码

5.每次代码递交后都会在持续集成服务器上触发一次构建

6.保证快速构建

7.模拟生产环境的自动测试

8.每个人都可以很容易的获取最新可执行的应用程序

9.每个人都清楚正在发生的状况

10.自动化的部署

原则

编辑

1. 所有的开发人员需要在 本地机器上做本地构建，然后再提交的 版本控制库中，从而确保他们的变更不会导致持续集成失败。

2. 开发人员每天至少向版本控制库中提交一次代码。

3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

5. 每次构建都要100%通过。

6. 每次构建都可以生成可发布的产品。

7. 修复失败的构建是优先级最高的事情。

8. 测试是未来，未来是测试

齿轮：如果将java/maven/ant/git/tomcat/jenkins等软件比喻为齿轮，如下图

2）两个软件在一起可以驱动另外一个软件，如下图

3）如果把这些软件要集成在一起工作，那么这个软件就可以存在其他软件的中间来驱动各个软件工作，如下图：

4）jenkins就是类似中间那个齿轮，来驱动其他软件的集成一起工作，如下图

jenkins作为持续集成的标志性工具，自然是有了持续集成的众多优点。jenkins可以做一些自动化的build，只要我们把jenkins搭建成功，可以设置几分钟build一次，在定时自动build，验证单元测试，如果发生错误则把错误报告以email形式发送给项目模块负责人。

jenkins是一个开源软件项目，旨在提供一个开放易用的软件平台，使得持续集成编程可能。它的前身是hudson，是基于java开发的一种持续集成工具，它可以根据配置进行持续定期编译，运行相应的代码，将运行结果发送至邮件或者展示成报告等。

［为什么］

jenkins作为持续集成的标志性工具，自然是有了持续集成的众多优点。jenkins可以做一些自动化的build，只要我们把jenkins搭建成功，可以设置几分钟build一次，在定时自动build，验证单元测试，如果发生错误则把错误报告以email形式发送给项目模块负责人。

［宏观理解］

先来张图，大致理解下宏观：

详细介绍：

至于关于邮件的配置，也是为了方便我们的开发和管理，jenkins很强大。

讲到这里，还是“啊呀呀，完蛋，还是有点不懂“的话，不如直接甩图（从网上copy下来的）：

这里是选择Gitlab作为git server。Gitlab的功能和Github差不多，但是是开源的，可以用来搭建私有git server，也提供非常强大的web GUI，比如开发者互相review源代码的时候就会很方便。

系统的工作流程大概分为以下几步:

1> 开发者将新版本push到git server (Gitlab)。

2> Gitlab随后触发jenkins master结点进行一次build。(通过web hook或者定时检测)

3> jenkins master结点将这个build任务分配给若干个注册的slave结点中的一个，这个slave结点根据一个事先设置好的脚本进行build。这个脚本可以做的事情很多，比如编译，测试，生成测试报告等等。这些原本需要手动完成的任务都可以交给jenkins来做。

4> 我们在build中要进行编译，这里使用了分布式编译器distcc来加快编译速度。

notes

jenkins的工作原理是先将源代码从gitlab中拷贝一份到本地，然后根据设置的脚本进行build。我们可以看出，整个系统的关键就是那个build脚本，用来告诉jenkins在一次集成中需要执行的任务。

不过我之后是用的Github作为git server。但其实差不多，先讲到这里，重点难点还是在之后jenkins的安装配置使用上。