4、jenkins+gerrit+Git 搭建CI系统

简介:

1、CI工作流程

当开发人员将本地Git仓库中的代码更新后,执行commit和push操作;该动作会生成一个事件,并触发Jenkins进行构建。如果开发人员在代码中加入和Junit或者testng测试用例,也会在构建过程中执行;构建完成后,jenkins会将构建的结果以Gerrit投票的方式传到Gerrit服务器上。项目Owner登录Gerrit Web UI,进行Code Review时会看到Jenkins构建的结果并进行code review。只有当构建成功,并且code review通过时,项目owner才会将代码合到主分支上,如果说jenkins上构建失败,则表示代码肯定有问题,Owner不用Code Review,直接通知开发检查代码并重新提交。

2、CI工作环境

Gerrit + Jenkins(安装Gerrit Trigger插件) +Git

Gerrit服务器:10.10.10.206

Jenkins服务器:10.10.10.202

两台服务器都安装了Git

3、CI配置

Gerrit上的配置

1、安装Label Verified 

初次安装Gerrit时,在交互安装过程中,系统会问你是否安装Label Verified ,默认是不安装的。如果要搭建CI系统,这里需要选择安装。如果gerrit系统中没有安装这个东西,后期可以通过重装gerrit的方式再装上。重装gerrit和初次安装gerrit的命令一样:java -jar /path/to/gerrit.war  /path/to/gerrit_dir。至于如何安装gerrit,请参考第一篇文档。

重装前,先停掉gerrit服务,交互安装过程中,很多步骤使用老的配置,默认即可。唯独提示是否安装Label Verified 时 选择y,表示安装。

2、在Gerrit服务器上为Jenkins服务器创建一个账号为jenkins。用该账号登录Gerrit Web UI,将该账号加入系统预设的Non-Interactive Users组。该组默认就已有监听Stream Events权限,Steam Events的原理是:Gerrit收到代码提交后,会以event的形式发给Jenkins,从而触发Jenkins自动构建。

3、为该账号设置SSH Key,即将Jenkins服务器的root账户下的公钥传到Gerrit上jenkins账号下的SSH Public Keys中,如果不知道如何设置,请参考前面的Gerrit用户配置文档。

4、为jenkins账号注册邮箱

5、设置jenkins用户的权限,注意设置权限,要对All-Projects进行设定

image2016-6-2%2016%3A13%3A58.png?version

image2016-6-2%2016%3A17%3A10.png?version

image2016-6-2%2016%3A15%3A14.png?version

设置jenkins用户的read'权限

image2016-6-2%2016%3A20%3A45.png?version

image2016-6-2%2016%3A21%3A39.png?version

给jenkins用户设置Code Review权限和Verified权限,Code Review权限为-2~+1,当jenkins构建失败时,直接将gerrit投票结果设置为-2。

image2016-6-5%2018%3A22%3A29.png?version

 

Jenkins上的配置

1、安装Gerrit Trigger插件

系统管理==>管理插件==>可选插件,搜索Gerrit Trigger,安装后重启Jenkins

  

2、配置Gerrit Trigger

系统管理==>Gerrit Trigger==>Add New Server

image2016-6-2%2016%3A29%3A5.png?version=


设置jenkins的对构建结果的一个gerrit投票值,构建失败则为-2,项目owner在不用code review了。项目如果构成成功则不表示代码一定OK,还是需要owner进行Code Review后在确认是否要merge

image2016-6-5%2018%3A29%3A48.png?version

4、CI工作流程演示

这里我们还是用第4篇文档中的TEST项目来测试。

登录jenkins,创建一个maven项目

image2016-6-2%2016%3A38%3A9.png?version=

 

 

源码管理这里选择Git,Repository URL就是Gerrit Web上的为匿名用户提供的地址,注意把地址中的

git clone命令去掉,Jenkins服务器自身安装了git,集成了git环境。

注意:开发人员push的代码还没有merged,是保存在gerrit上的临时分支上的,所以我们要构建的话,应该去下载临时分支上的代码去构建。而不是下载$GERRIT_BRANCH上已经merge过的代码

Refspec:设置为refs/changes/*:refs/changes/*  

Bracnes to build:设置为$GERRIT_REFSPEC,这个是git插件自带的宏,还有一个宏为$GERRIT_BRANCH,表示Gerrit上的分支。下面是Jenkins官方对这两个宏的解释:

To get the Git Plugin to download your change; set Refspec to $GERRIT_REFSPEC and the Choosing strategy to Gerrit Trigger. You may also need to set 'Branches to build' to $GERRIT_BRANCH. If this does not work for you set Refspec torefs/changes/*:refs/changes/* and 'Branches to build' to $GERRIT_REFSPEC.

Note: Be aware that $GERRIT_BRANCH and $GERRIT_REFSPEC are not set in the Ref Updated case. If you want to trigger a build, you can set Refspec and 'Branches to build' to $GERRIT_REFNAME.

只有这两个地方设置对,jenkins才能到gerrit上下载changes(即开发人员push的最新的代码)去构建。

image2016-6-6%2013%3A7%3A11.png?version=

 

 

构建触发器选择Gerrit event

Choose a server:选择前面配置的Gerrit Server

Trigger on:可以不配置,jenkins会默认选择 Patchset Created  Draft Published。表示开发人员只要push代码则触发构建,这是我们期望的。Change Merged表示当代码审核通过后,并且成功地Merge后才触发构建。Comment Added:这个选项可以自定义Code Review和Verified的值来触发构建,假如我这里Trigger on选择Comment Added,并且Code Review的值选择1,那么当项目管理员审核代码时,给的值为1,就会触发构建。

下面是官网的解释:

  • Draft Published: Sent when a change moves from draft state to new. (only available in version 2.5 or higher of Gerrit).

  • Patchset Created: Sent when a new patchset arrives on a change. Before version 2.6.0, this was the only event you could trigger on.

  • Change Merged: Sent when a change is merged on the Gerrit server.

  • Comment Added: Sent when a comment is added to a change. Which category and value to trigger on can be configured. The available categories can be configured in the server settings for the plugin.

  • Ref Updated: Sent when a ref is updated on the Gerrit server, i.e. someone pushes past code review.


 Silent Mode:静默模式,即gerrit上做了code review和submit操作,Gerrit上对应的jenkins账号不发送邮件通知。

 

image2016-6-5%2019%3A3%3A24.png?version=

 

Gerrit Project:左边选择项目,右边选择分支,支持以下三种方式:

  • Plain: The exact name in Gerrit, case sensitive equality.

我选择Path,后面写**,表示该项目所有分支。

image2016-6-6%2013%3A40%3A38.png?version


image2016-6-2%2016%3A48%3A32.png?version

构建后的操作,选择邮件通知

image2016-6-2%2016%3A50%3A7.png?version=


测试CI是否成功

用user2用户登录jenkins服务器10.10.10.202, 从Gerrit Web UI上clone TEST项目,

第一次clone TEST项目时,由于这个项目没有开发人员参与,所以TEST文件夹为空,这里的所有文件都是user2用户创建的。

pom.xml文件是构建maven项目必须的,cat  pom.xml,可以看到我这里加入了testng的测试框架

image2016-6-2%2017%3A17%3A40.png?version

 

在./src/test/java/com/carkey/testng/AppTest.java文件中写好了测试用例

image2016-6-2%2017%3A19%3A24.png?version


 

创建代码文件,并将代码push到Gerrit服务器对应的项目仓库中

user2@localhost:~/TEST$ git add *
user2@localhost:~/TEST$ git commit -m "init" 
[master 96c15a5] init
1 files changed, 1 insertions(+), 133 deletions(-)
rewrite code.sh (100%)
user2@localhost:~/TEST$ git push origin master:refs/for/master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 362 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Processing changes: new: 1, refs: 1, done 
remote: 
remote: New Changes:
remote: http://10.10.10.206:8081/35 init
remote: 
To ssh://user2@10.10.10.206:29418/TEST
* [new branch] master -> refs/for/master

 登录Jenkins,看到项目构建时测试通过了,构建结果为Success。

image2016-6-5%2018%3A58%3A55.png?version

image2016-6-5%2018%3A43%3A55.png?version


用user2登录Gerrit Web UI,查看Jenkins的投票结果(也可以理解为构建结果),并邀请admin管理员进行Code Review

如下图可以看到jenkins构建成功了,Code-Review和Verified都是+1,这两个值是前面在Gerrit Trigger中配置的。

image2016-6-5%2018%3A48%3A56.png?version

邀请admin进行Code-Review

image2016-6-5%2018%3A53%3A25.png?version

 

admin用户进行Code Review。管理员根据jenkins的投票指导构建结果是Success。然后进行Code-Review,如果代码没有问题,则Code-Review+2,并Submit。

此时代码才会合到对应的分支上。

image2016-6-5%2018%3A53%3A54.png?version

image2016-6-2%2017%3A26%3A30.png?version

到这里CI工作流程就结束了。

 

5、Gerrit Trigger插件的的其他功能

安装这个插件后,在首页能看到Query and Trigger Gerrit Patches的功能

image2016-6-2%2017%3A42%3A10.png?version

该功能可以查询Gerrit服务器上的所有项目的所有状态的事件

根据状态查询

image2016-6-2%2017%3A46%3A37.png?version

根据项目查询

image2016-6-2%2017%3A47%3A47.png?version

根据用户查询

image2016-6-2%2017%3A48%3A53.png?version

 

根根据时间来查询

image2016-6-2%2017%3A58%3A46.png?version

 

image2016-6-2%2017%3A59%3A31.png?version

 

6、build-metrics插件介绍

这个插件是全局性的插件,能查看所有项目的构建情况,包括成功、失败、不稳定、被终止等状态的构建。

安装:

这个插件的安装过程就不在详细描述,在插件管理--可选插件中直接搜索build-metrics,安装,重启jenkins即可

image2016-6-2%2018%3A4%3A39.png?version=

 

使用:

系统管理中,找到build-metrics,点击进去

image2016-6-2%2018%3A7%3A39.png?version=


根据时间和Job名来查询

image2016-6-2%2018%3A11%3A49.png?version

image2016-6-2%2018%3A10%3A38.png?version

按项目来查询

image2016-6-2%2018%3A11%3A7.png?version=

 










本文转自 曾哥最爱 51CTO博客,原文链接:http://blog.51cto.com/zengestudy/1786555,如需转载请自行联系原作者
目录
相关文章
|
3月前
|
敏捷开发 存储 开发工具
版本控制系统的选择:Git与SVN的比较
【8月更文挑战第14天】Git和SVN都是优秀的版本控制系统,它们各自具有独特的优势和适用场景。在选择版本控制系统时,需要根据具体的项目需求、团队特点和开发模式来综合考量。对于需要分布式团队协作、高效处理大型项目或采用敏捷开发模式的团队来说,Git是一个更好的选择。而对于传统团队、集中式开发或简单项目来说,SVN可能更加合适。无论选择哪种版本控制系统,都应该充分利用其提供的工具和功能来提高代码质量和开发效率。
|
17天前
|
运维 监控 jenkins
运维自动化实战:利用Jenkins构建高效CI/CD流程
【10月更文挑战第18天】运维自动化实战:利用Jenkins构建高效CI/CD流程
|
1月前
|
jenkins Shell 持续交付
Jenkins持续集成GitLab项目 GitLab提交分支后触发Jenkis任务 持续集成 CI/CD 超级详细 超多图(二)
Jenkins持续集成GitLab项目 GitLab提交分支后触发Jenkis任务 持续集成 CI/CD 超级详细 超多图(二)
65 0
|
17天前
|
运维 监控 jenkins
运维自动化实践:利用Jenkins实现高效CI/CD流程
【10月更文挑战第18天】运维自动化实践:利用Jenkins实现高效CI/CD流程
|
1月前
|
Ubuntu jenkins 持续交付
Ubuntu系统 用docker安装jenkins
Ubuntu系统 用docker安装jenkins
|
1月前
|
jenkins Shell 持续交付
Jenkins持续集成GitLab项目 GitLab提交分支后触发Jenkis任务 持续集成 CI/CD 超级详细 超多图(一)
Jenkins持续集成GitLab项目 GitLab提交分支后触发Jenkis任务 持续集成 CI/CD 超级详细 超多图(一)
107 0
|
3月前
|
数据可视化 jenkins 测试技术
GitLab CI/CD 和 Jenkins对比
8月更文挑战第25天
336 5
|
3月前
|
jenkins Linux 持续交付
在Linux中,如何使用Jenkins和Ansible进行虚拟化环境的自动化和持续集成/持续部署(CI/CD)?
在Linux中,如何使用Jenkins和Ansible进行虚拟化环境的自动化和持续集成/持续部署(CI/CD)?
|
3月前
|
jenkins 持续交付 开发工具
"引爆效率革命!Docker+Jenkins+GIT+Tomcat:解锁持续集成魔法,一键部署Java Web应用的梦幻之旅!"
【8月更文挑战第9天】随着软件开发复杂度的增加,自动化变得至关重要。本文通过实例展示如何结合Docker、Jenkins、Git与Tomcat建立高效的持续集成(CI)流程。Docker确保应用环境一致性;Jenkins自动化处理构建、测试和部署;Git管理源代码版本;Tomcat部署Web应用。在Jenkins中配置Git插件并设置项目,集成Docker构建Tomcat应用镜像并运行容器。此外,通过自动化测试、代码质量检查、环境隔离和日志监控确保CI流程顺畅,从而显著提高开发效率和软件质量。
74 3
|
3月前
|
jenkins 持续交付 网络安全
[jenkins]连接git仓库
[jenkins]连接git仓库