目录
Jenkins概述
Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。它是一个功能强大的应用程序，允许持续集成和持续交付项目，无论用的是什么平台。这是一个免费的源代码，可以处理任何类型的构建或持续集成。集成Jenkins可以用于一些测试和部署技术。Jenkins是一种软件允许持续集成。
持续集成：CI（Continuous Integration），是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
一句话概括：持续集成就是把多个码农写的代码集成到同一个分支，然后经过编译、测试、打包之后将程序保存到Artifact Repository 里。
持续交付：（Continuous Delivery），在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。
一句话概括：持续交付就是定时地、自动地从 Artifact Repository 将最新的程序部署到测试环境里。
持续部署：（Continuous Deployment）
一句话概括：持续部署就是定时地、自动地将过去一个稳定的发布版本部署到生产环境里。
总结：
集成、交付和部署是软件开发到发布流程中的不同阶段。那所谓的持续是相对于过去的流程提出的。过去的流程是所有人写好代码之后再进行合并，然后再进行测试，最后再发布。这种流程会把风险堆到软件发布前的最后阶段。那持续的概念就是，做一点就马上递交给下一个流程，这样能够尽早地发现并解决问题。持续交付和持续部署是不是相同的概念，一直有争议。不过个人认为，只要在团队内部达成一致就可以了，不用太纠结于是不是同一个概念。
产品发布流程：产品设计成型 -> 开发人员开发代码 -> 测试人员测试功能 -> 运维人员发布上线
Jenkins应用
1.持续、自动的软件版本发布、构建、测试，部署项目。
2.监控外部调用执行的工作：监控软件开发流程，快速问题定位及处理，提示开发效率。
3.监控定时执行的任务。
Jenkins特性(优点)
1.易于安装-只要把jenkins.war部署到servlet容器，不需要数据库支持。是所有CI产品中在安装和配置上最简单的。
2.易于配置-所有配置都是通过其提供的web界面实现。基于Web访问，用户界面非常友好、直观和灵活，在许多情况下，还提供了AJAX的即时反馈。
3.集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知。
4.生成JUnit/TestNG测试报告。
5.分布式构建支持：Jenkins能够让多台计算机一起构建/测试。
6.文件识别：Jenkins能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。
7.插件支持：支持扩展插件，你可以开发适合自己团队使用的工具。Jenkins拥有大量的插件。这些插件极大的扩展了Jenkins的功能；它们都是开源的，而且它们可以直接通过web界面来进行安装与管理。
8.Jenkins是基于Java开发的(如果你是一个Java开发人员，这是非常有用的)，但它不仅限于构建基于Java的软件。
CI系统的基本结构
部署一个CI系统需要的最低要求是，一个可获取的源代码的仓库，一个包含构建脚本的项目。
最低配置：不少于256M内存，不低于1G磁盘，jdk版本>=8
该系统的各个组成部分是按如下顺序来发挥作用的：
1.开发者检入代码到源代码仓库。
2.CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区。
3.CI系统会在对应的工作区内执行构建过程。
4.（配置如果存在）构建完成后，CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。
5.（配置如果存在）如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。 软件仓库可以是CI系统的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.net、SourceForge之类的网站。
6.CI系统通常会根据请求发起相应的操作，诸如即时构建、生成报告，或者检索一些构建好的构件。
目前持续集成(CI)已成为当前许多软件开发团队在整个软件开发生命周期内侧重于保证代码质量的常见做法。它是一种实践，旨在缓和和稳固软件的构建过程。并且能够帮助您的开发团队应对如下挑战：
1.软件构建自动化 ：配置完成后，CI系统会依照预先制定的时间表，或者针对某一特定事件，对目标软件进行构建。
2.构建可持续的自动化检查 ：CI系统能持续地获取新增或修改后嵌入的源代码，也就是说，当软件开发团队需要周期性的检查
新增或修改后的代码时，CI系统会不断确认这些新代码是否破坏了原有软件的成功构建。这减少了开发者们在检查彼此相互依存的代码中变化情况需要花费的时间和精力(说直接一点就是节省成本)。
3.构建可持续的自动化测试：构建检查的扩展部分，构建后执行预先制定的一套测试规则，完成后触发通知(Email,RSS等等)给相关的当事人。
4.生成后后续过程的自动化:当自动化检查和测试成功完成，软件构建的周期中可能也需要一些额外的任务，诸如生成文档、打包软件、部署构件到一个运行环境或者软件仓库。这样，构件才能更迅速地提供给用户使用。
Jenkins目标
Jenkins的主要目标是监控软件开发流程，快速显示问题。所以能保证开发人员以及相关人员省时省力提高开发效率。CI系统在整个开发过程中的主要作用是控制：当系统在代码存储库中探测到修改时，它将运行构建的任务委托给构建过程本身。 如果构建失败了，那么CI系统将通知相关人员，然后继续监视存储库。它的角色看起来是被动的；但它确能快速反映问题。
再一次强调Jenkins的优点：
Jenkins一切配置都可以在web界面上完成。有些配置如MAVEN_HOME和Email，只需要配置一次，所有的项目就都能用。当然也可以通过修改XML进行配置。
支持Maven的模块(Module)，Jenkins对Maven做了优化，因此它能自动识别Module，每个Module可以配置成一个job。相当灵活。
测试报告聚合，所有模块的测试报告都被聚合在一起，结果一目了然，使用其他CI，这几乎是件不可能完成的任务。
构件指纹(artifact fingerprint)，每次build的结果构件都被很好的自动管理，无需任何配置就可以方便的浏览下载。
Jenkins安装配置
1）Jenkins分布式构建
当自动化测试用例需要在多个PC机或虚拟机中执行时，如果在每个虚拟机中均搭建类似tomcat+jenkins的环境，将会造成例如每台虚拟机资源占用大、对环境的配置维护成本大等弊端，此时，就可以采用Jenkins分布式构建方式了。Jenkins的分布式构建，在Jenkins的配置中叫做节点，分布式构建能够让同一套代码或项目在不同的环境(如：Windows和Linux系统)中编译、部署等。当我们使用多台服务器时，并且配置了tomcat或jboss集群服务，可通过jenkins的节点配置，将jenkins项目发布在不同服务器上（分布jenkins工作空间，部署项目到不同服务器的tomcat或jboss），这就形成了jenkins的分布式。节点服务器不需要安装jenkins（只需要运行一个slave节点服务），构建事件的分发由master端（jenkins主服务）来执行。本次选择hadoop03作为jenkins的master端，所以只在hadoop03一台机器上安装配置即可。
2）jenkins的安装
因为jenkins是基于java的，所以基础环境需要有jdk。
因为公司项目均为maven项目，所以需要hadoop03需要有maven
下载最新版本（一个war文件），jenkins官方网址：http://Jenkins-ci.org/
运行 java -jar jenkins.war
注意：Jenkins 需要运行 Java 5以及以上的版本。
还有一种安装方式就是将下载的war包文件部署到servlet容器(tomcat)，然后启动容器，在浏览器的URL地
址栏中输入类似http://ip:8080/jenkins/这样的地址即可。
tomcat上部署jenkins.war包，保证tomcat启动，将该包放到tomcat的webapps目录下。
在webapps目录下会自动生成jenkins目录。
本次在官网上下载的是2.121.1版本，将下载好的jenkins.war，放到hadoop03的tomcat的webapps路径下
编辑环境变量：vim /etc/profile
添加export JENKINS_HOME=/usr/software/jenkins
source /etc/profile
如果不添加环境变量JENKINS_HOME，则默认工作目录用户工作目录下在：/root/.jenkins
过了一段时间jenkins自动让你重新初始化到设定的/usr/software/jenkins目录下·
Jenkins的部署好后，不需要任何启动直接访问http://hadoop03:8080/jenkins即可进入Jenkins安装配置首页
首先需要解锁：
通过上面提示，在命令行输入
cat /usr/software/jenkins/secrets/initialAdminPassword
查看出初始化密码：XXXX
输入密码后下一步，选择：安装推荐的插件，出现进度条开始安装
插件安装完成后，进入创建管理员的界面，创建第一个管理员，如图：
密码统一设定为：aba姓名全拼(例：abatest),保存后出现下图继续即可
以下为jenkins初始页面
Jenkins实际应用
1）系统管理->全局工具配置
目前只配置配置jdk和maven，之后相继安装部署
2）Jenkins分布式构建
保存后出现从节点hadoop02，从节点配置成功。
系统连接日志，表示连接成功
这样，表示master（hadoop03）和其它机器已经连接上
系统管理->系统设置中配置邮件通知中，
密码处填写qq邮箱的授权码：ngtpldjibaxvbbfa
确保SMTP服务为开启状态
安装插件：Maven Integration，使jenkins能够配置maven工程
安装插件：Deploy to container(Deploy Plugin)，下图证明该插件安装成功！
常用插件：
delpoy to container plugin
publish over SSH
Maven Integration plugin
SSH plugin
SVN Publisher plugin
Hudson SCP publisher plugin
安装SSH相关插件：
配置maven：
标记部分为SVN的用户名和密码
然后触发器和构建环境可以编辑也可以用默认，之后是编辑build
任务创建成功
构建任务：
构建任务过程中会遇到错误：
此错误就是pom.xml中的maven包与maven镜像仓库不匹配导致，在$MAVEN_HOME/conf/settings.xml中配置maven仓库最后构建成功：
构建成功后发布到tomcat应用服务器上
构建后操作，把通过maven命令打好的war包，copy到tomcat中，这要求tomcat开启热部署，说白了就是在tomcat的conf目录下的tomcat-users.xml中加入tomcat的用户密码
上面面这段话，可以完全照抄，当然用户名和密码根据你自己的需要来配置这里设置的用户名和密码，必须和你填入上面Deploy to cotainer板块中的Manager user name和password一致。另外，关于Deploy插件，虽然写着只支持到tomcat7.x，但实际上，8.x的tomcat它照样可以支持。
以上热部署方式有一个很大弊端：
就是发布多次之后，内存会持续上涨。所以这并不是一种好的方式。
一种更加好的方式是使用脚本，将tomcat关闭，然后把webapps下的旧的部署应用删除，再把新的war包放过来，然后启动所以，我们这里需要用到另外一个插件：PostBuildScript：下载完此插件再回到"构建后操作"
#!/bin/sh
war=$1
bin=$(cd '/usr/software/java/apache-tomcat-8.5.27'; pwd)
if [ ! -n "${war}" ]; then
echo "***Usage: $0 [project.war]"
exit 0
fi
if [ ! -f "${war}" ]; then
echo "***Error: ${war} does not exist."
exit 0
fi
if [ ! "${war##*.}" = "war" ]; then
echo "***Error: ${war} is not a war file."
exit 0
fi
echo "Deploy ${war##*/}..."
rm -rf ${bin}/webapps/ROOT/ && unzip -qo ${war} -d ${bin}/webapps/ROOT/
rm -rf ${bin}/work/Catalina/localhost/
rm -rf ${bin}/work/Catalina/hadoop03/
echo "Restart tomcat..."
exec ${bin}/bin/restart.sh
添加执行权限：chmod +x deploy.sh
deploy.sh会先清空tomcat下的ROOT目录，再将指定的war包加压至ROOT目录，最后执行restart.sh重启tomcat。
写好restart.sh
restart.sh是用来重启tomcat的，如果tomcat没有启动则直接启动，如果已经启动就先shutdown再启动，如果shutdown
之后3s没有停掉tomcat进程，则kill掉原来的进程再启动。
#!/bin/sh
bin=/usr/software/java/apache-tomcat-8.5.27
pid=$(ps aux | grep tomcat | grep -v grep | grep -v restart | grep ${bin} | awk '{print $2}')
if [ -n "${pid}" ]; then
echo "Shutdown..."
sh ${bin}/bin/shutdown.sh
sleep 3
pid=$(ps aux | grep tomcat | grep -v grep | grep -v restart | grep ${bin} | awk '{print $2}')
if [ -n "${pid}" ]; then
kill -9 ${pid}
sleep 1
fi
fi
echo "Startup..."
sh ${bin}/bin/startup.sh
if [ "$1" = "-v" ]; then
tail -f ${bin}/logs/catalina.out
fi
写好deploy.sh，deploy.sh放到tomcat的bin目录下，根据以上两个shell写出满足需求的shell
1.关闭tomcat2.删除旧的部署应用和war包3.启动tomcat
$1输入参数为：/usr/software/jenkins/workspace/harbour/target/harbour.war
$2输入参数为：harbour.war
$3输入参数为：harbour/
#!/bin/sh
war=$1
war_former=$2
project_path=$3
bin=$(cd '/usr/software/java/apache-tomcat-8.5.27'; pwd)
echo "delete existed war.."
rm -rf ${bin}/webapps/${war_former}
rm -rf ${bin}/webapps/${project_path}
if [ ! -n "${war}" ]; then
echo "***Usage: $0 [project.war]"
exit 0
fi
if [ ! -f "${war}" ]; then
echo "***Error: ${war} does not exist."
exit 0
fi
if [ ! "${war##*.}" = "war" ]; then
echo "***Error: ${war} is not a war file."
exit 0
fi
echo "move war"
mv ${war} ${bin}/webapps/
sleep 3
echo "Deploy ${war##*/}..."
#rm -rf ${bin}/webapps/ROOT/ && unzip -qo ${bin}/webapps/${war_former} -d ${bin}/webapps/ROOT/
#rm -rf ${bin}/work/Catalina/localhost/
#rm -rf ${bin}/work/Catalina/hadoop03/
#echo "start tomcat..."
#exec ${bin}/bin/restart.sh
保存退出！
cd /usr/software/java/apache-tomcat-8.5.27
bin/deploy.sh /usr/software/jenkins/workspace/harbour/target/harbour.war harbour.war harbour/
/usr/software/java/apache-tomcat-8.5.27/bin/deploy.sh /usr/software/jenkins/workspace/harbour/target/harbour.war harbour.war harbour/
引入deploy.sh shell之后保存
再次构建出现问题：
按照脚本执行，删除完原来war包和工程之后，重新移动war包到webapps后，重启tomcat，出现tomcat关闭之后无法重启的现象
此时在命令行执行restart.sh时，出现以下错误：
SEVERE: Could not contact [localhost:[8005]]. Tomcat may not be running
此错误意思是： 在tomcat没完全启动前就关闭tomcat，Kill掉进程后重启，等待一段时间再关闭
因为在删除war包和工程，包括移动war包后，tomcat一直处于启动状态，这样当删除工程和原有war包后，转移来新的war包，tomcat会自动监测并进行解压新来的war包，而此shell中没有写等待，所以还未解压完成就关闭tomcat，所以出现这个错误。
以上由于tomcat机制导致的：
war不能在tomcat运行时删除，否则会删除自动解压的工程。 你可以停止tomcat后删除war。
当你重新部署的时候，如果有与war文件相同的文件夹，就不会重新部署。
这是因为，tomcat在运行期会监控webapps下的war文件，如果有新增war，就解压，有删除war，就连同项目一起删除
所以，如果您要删除，可以先关闭tomcat再删除，这样不会有影响的
Tomcat下WAR包和同名已解压项目，如何加载：
当tomcat启动时候会去查看webapps下的所有war包，同时查看是否有该war包对应的已解压文件，如果已经存在就 不会再解压，也不会将你已经修改的jsp覆盖掉，只有当你删除war包对应的同名文件夹（你的工程）后，启动tomcat时才会再解压war文件。
通过以上，所以正确的执行顺序应该是先关闭tomcat，然后再删除原有war包和工程，再转移进新来war包再启动tomcat
不过，在tomcat启动时，直接删除war包和工程也是可行，不过还是按照标准的工作流程执行。
但是本次安装jenkins依赖tomcat，当tomcat关闭后，jenkins也跟着关闭，关闭后执行步骤就不起作用了。所以还是采取：
tomcat一直启动，然后删除war包和工程，然后把新war包放入webapps下，让tomcat重新解压新war包即可
最后，不用重启tomcat，根据tomcat的监测解压功能，重新部署成功！！
3070
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
