Jenkins初探

Jenkins重启/关闭

http://localhost:8080/jenkins/exit − 关闭jenkins

http://localhost:8080/jenkins/restart − 重启jenkins

http://localhost:8080/jenkins/reload − 重新加载配置

上线过程可分为四个小流程

构建（build）、测试、部署、发布。

构建和部署

构建意味着，处理我的所有代码/工件，并为部署做好准备。意义编译，生成代码，包等。部署应该意味着拿走我的所有工件，并将它们复制到服务器，或者在服务器上执行它们。它应该是一个简单的过程。

Jenkins功能

可以备份配置

可以单元测试（JUnit）

可以自动化测试（Selenium浏览器自动测试）

可以邮件通知结果

可以生成构建报表

可以代码分析，有很多插件可用

可以主从配置（配置从机jenkins）

可以自动部署

可以新建用户

Jenkins的特点

Jenkins有一个非常强大的特点就是插件，庞大的插件能力大大拓展了Jenkins的能力，但插件有可能没有人维护；

Jenkins是本地文件存储，所有的内容都是通过文件保存的。会带来非常大的IO压力，因为系统会一直读写磁盘上的文件。

Jenkins启动时

简单来说Jenkins在每次启动的时候会做以下几件事：

1. 加载Jenkins主要的配置，也就是Jenkins的系统配置；
2. 会加载所有插件，插件越多，加载的内容也就越多，导致Jenkins性能越来越慢。

Jenkins的问题

Jenkins在任务调度的时候倾向于使用之前成功执行任务的节点，并非是按照实时资源负载进行调度，会导致各种节点闲的闲死，忙得忙死。

Jenkins默认的行为就是使用master节点，当我们新建任务不指定工作节点的时候，Jenkins会自动替我们寻找可用的节点，这里面当然就包含master，并且Jenkins的大量碎片文件和所有的插件都是保存在Master节点上的。

cron定时触发任务，即使代码或者配置没有任何改变也会执行完整的任务流程，造成资源浪费。

持续集成的概念（即持续集成测试）

持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元、自动化）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

首先，解释下集成。我们所有项目的代码都是托管在SVN服务器上。每个项目都要有若干个单元测试，并有一个所谓集成测试。所谓集成测试就是把所有的单元测试跑一遍以及其它一些能自动完成的测试。只有在本地电脑上通过了集成测试的代码才能上传到SVN服务器上，保证上传的代码没有问题。所以，集成指集成测试。

再说持续。不言而喻，就是指长期的对项目代码进行集成测试。既然是长期，那肯定是自动执行的，否则，人工执行则没有保证，而且耗人力。对此，我们有一台服务器，它会定期的从SVN中检出代码，并编译，然后跑集成测试。每次集成测试结果都会记录在案。完成这方面工作的就是Jenkins软件。当然，它的功能远不止这些。在我们的项目中，执行这个工作的周期是1天。也就是，服务器每1天都会准时地对SVN服务器上的最新代码自动进行一次集成测试。

持续集成的作用

代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个发布（release）的复杂度和风险越高，持续集成可以保证团队开发人员提交代码的质量，减轻了软件发布时的压力；

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

及早的发现代码中的问题，及早解决，代码越早推送（PUSH）出去，用户能越早用到，快就是商业价值。