jenkins简介
Jenkins是什么
Jenkins 是一个可扩展的持续集成引擎。
主要用于:
持续、自动地构建/测试软件项目。
监控一些定时执行的任务。
下图概括了CI系统的基本结构:
从图中我们可以看出该系统的各个组成部分是按如下顺序来发挥作用的:
- 开发者检入代码到源代码仓库。
2.CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时,它将把源代码仓库的源码存放到对应的工作区。
- CI系统会在对应的工作区内执行构建过程。
4.(配置如果存在)构建完成后,CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。
5.(配置如果存在)如果构建成功,这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分,也可以是一个外部的仓库,诸如一个文件服务器或者像Java.net、 SourceForge之类的网站。
- CI系统通常会根据请求发起相应的操作,诸如即时构建、生成报告,或者检索一些构建好的构件。
Jenkins就是这么一个CI系统。之前叫做Hudson。
以下是使用Jenkins的一些理由:
是所有CI产品中在安装和配置上最简单的,只要把jenkins.war部署到servlet容器,不需要数据库支持。
基于Web访问,用户界面非常友好、直观和灵活,在许多情况下,还提供了AJAX的即时反馈,集成RSS/E-mail通过RSS发布构建结果或当构建完成时通过e-mail通知,生成JUnit/TestNG测试报告等等。
Jenkins是基于Java开发的(如果你是一个Java开发人员,这是非常有用的),但它不仅限于构建基于Java的软件。
Jenkins拥有大量的插件。这些插件极大的扩展了Jenkins的功能;它们都是开源的,而且它们可以直接通过web界面来进行安装与管理,你可以开发适合自己团队使用的工具。
分布式构建支持Jenkins能够让多台计算机一起构建/测试。
CI到CD的转变
2017年4,Jenkins退出2.0版本,实现CI(Continuous Integration)到CD(Continuous Delivery)。所谓Pipeline,简单来说,就是一套运行于Jenkins上的工作流框架,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂发布流程。
Pipeline脚本:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building..'
}
}
stage('Test') {
steps {
echo 'Testing..'
}
}
stage('Deploy') {
steps {
echo 'Deploying....'
}
}
}
}
项目构建设置
系统管理
构建任务
(1) 新建任务
(2)进行配置(可以选择构建/发布包最大的保存个数/保存时间)
源码管理配置(有Git/SVN等多种选择):
构建触发器:
常用的包括Build periodically和Poll SCM
Poll SCM :当选择此选项,可以指定一个定时作业表达式来定义Jenkins每隔多久检查一下您源代码仓库的变化。如果发现变化,就执行一次构建。例如,表达式中填写0,15,30,45 将使Jenkins每隔15分钟就检查一次您源码仓库的变化。
Build periodically :此选项仅仅通知Jenkins按指定的频率对项目进行构建,而不管SCM是否有变化。如果想在这个Job中运行一些测试用例的话,它就很有帮助。
构建:
我们构建的是JAVA maven项目,选择Invoke top-level Maven targets:
构建命令直接使用:mvn clean install
就可以了,加入Junit需要跳过测试命令为:clean install -Dmaven.test.skip=true
;当我们需要执行测试类的时候,我们需要配置单元测试命令(mvn test) 或者 单元测试&集成测试命令(mvn verify)。如下图所示:
其中,POM是写项目中pom.xml的路径,比如我项目中的pom.xml路径如下就可以直接pom.xml,若pom.xml文件在src文件夹下,需要写为src/pom.xml,默认的根路径是源码管理配置中的路径
构建后操作:
设置构建后操作有很多选项,如下图所示,生产Junit报告,进行邮件通知,设置GitHub提交状态等等,还可以进行发布部署,需要安装插件Deploy Plugin插件
前面我们进行了Junit测试,现在可以在构建结束后生成Junit报告
监控
jenkins的主页面提供了任务的监控
当任务一旦运行,您将会看到这个任务正在队列中的仪表板和当前工作主页上运行。这两种显示如下。
你可以在Jenkins的控制面板上看到它,如下图。
S栏目代表着“最新构建状态”,W栏目代表着“构建稳定性”。Jenkins使用这两个概念来介绍一个作业的总体状况:
构建状态:下图中分级符号概述了一个Job新近一次构建会产生的四种可能的状态:
Successful:完成构建,且被认为是稳定的。
Unstable:完成构建,但被认为不稳定。
Failed:构建失败。
Disabled:构建已禁用。
构建稳定性:
当一个Job中构建已完成并生成了一个未发布的目标构件,如果您准备评估此次构建的稳定性,Jenkins会基于一些后处理器任务为构建发布一个稳健指数 (从0-100 ),这些任务一般以插件的方式实现。它们可能包括单元测试(JUnit)、覆盖率(Cobertura )和静态代码分析(FindBugs)。分数越高,表明构建越稳定。下图中分级符号概述了稳定性的评分范围。任何构建作业的状态(总分100)低于80分就是不稳定的。
将鼠标放在W列上能看到具体稳健指数的组成
点击Name列进入对应的任务
我们可以看到具体的构建情况
选择一个构建版本,可以看到整个构建的日志:
单元测试情况:
集成sonarqube
在build中添加Execute SonarQube Scanner
邮件
插件email-ext
释放个我的配置:
Default Subject:构建通知:$PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS!
Default Content:<hr/>(本邮件是程序自动下发的,请勿回复!)<br/><hr/>
项目名称:$PROJECT_NAME<br/><hr/>
构建编号:$BUILD_NUMBER<br/><hr/>
svn版本号:${SVN_REVISION}<br/><hr/>
构建状态:$BUILD_STATUS<br/><hr/>
触发原因:${CAUSE}<br/><hr/>
构建日志地址:<a href=”${BUILD_URL}console”>${BUILD_URL}console</a><br/><hr/>
构建地址:<a href=”$BUILD_URL”>$BUILD_URL</a><br/><hr/>
变更集:${JELLY_SCRIPT,template=”html”}<br/><hr/>
下节待续
Docker部署jenkins、kubernetes部署jenkins
参考:
http://www.360doc.com/content/17/0213/17/7811581_628728532.shtml
https://blog.csdn.net/enweitech/article/details/51879864