基于Jenkins以及Gitlab的持续编译及发布

发表于:2018-4-12 10:19

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Mango    来源:博客园

  前沿
  其实本来是想把标题叫做持续集成的,只是后来看看研究出的内容,就只有发布这一个动作,自动化测试等内容也未涉及到,所以改名叫持续编译及发布应该更加贴切吧?
  问题背景
  其实目前我们传统方式上的发布方式,一般都是开发人员本地打包,然后传给测试,测试完成之后,发包到项目经理或者实施人员,最后进行部署,对于非互联网项目也许通过人力操作,也可以很好的完成,虽然可能会磕磕碰碰,但是对于互联网的产品,这种方式就显得低效了,每次迭代开发打包验证可能都要花掉不少时间,测试部署也要花掉不少时间,在这种情况下,自动化方案也就显得尤其重要
  按照面向对象理解就是将编译发布等操作进行封装抽象,减少重复的过程(果然万物皆对象么)
  什么是jenkins
  那标题既然是基于jenkins,那什么是jenkins呢?百度解释我就抄一个过来了:Jenkins是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。
  那既然是持续集成的工具,那发布功能肯定也是有的,SO我们就采用jenkins来实现我们的诉求,想想啥时候我们公司也可以有真正的持续集成方式出现呢?
  安装技能准备:
  rpm安装方法:
  rpm -ivh XXXX.rpm
  jenkins安装&配置
  安装:
  1、要安装jenkins,那就必须得先安装JDK,先从官方找个jdk的地址(rpm安装):jdk-8u161-linux-x64.rpm,找那个jdk-8u161-linux-x64.rpm,rpm安装之。
  2、jenkins的rpm下载,给个地址:jenkins-2.89.4-1.1.noarch.rpm,然后rpm安装之
  3、安装完关闭防火墙(或者开放8080端口也可以)
  4、service jenkins start;开启jenkins
  配置:
  浏览器打开ip:8080
  根据红字部分目录,找到密钥信息输入
  选择第一个推荐安装,等待一段时间,则安装结束,第一步的初始化配置就到这里结束了
  .NETCore安装
  参照微软官方安装方法
  git安装
  既然我们要基于gitlab跟jenkins,那必须还得装一个git才能pull源码到本地啊,安装方式如下:一句一句执行(参照https://www.cnblogs.com/gsliuruigang/p/7899803.html)
yum -y groupinstall "Development Tools"//下载编译工具
yum -y install zlib-devel perl-ExtUtils-MakeMaker asciidoc xmlto openssl-devel//下载依赖包
wget https://github.com/git/git/archive/v2.16.2.tar.gz//下载文件
tar -zxf v2.16.2.tar.gz//解压文件
cd git-2.16.2/
autoconf
./configure --prefix=/usr/local/git
make && make install//编译安装
export PATH="/usr/local/git/bin:$PATH"//配置全局路径
source /etc/profile//使配置生效
  gitlab配置
  登录ip:8080,到管理插件的地方,安装GitLab Plugin插件,如下图所示
  打开gitlab地址——>个人设置——>account——>复制Private token备用
  jenkins——>系统管理——>系统设置——>找到gitlab
  点击add按钮
  最后点击test connection,显示success的话那就是连接是成功的了
  任务构建
  回到jenkins首页——>新建任务——>输入名称——>生成
  1、General
  如下图所示,gitlabconnection选择之前配置的信息
  2、源码管理
  源码管理主要配置源码库的信息,具体配置如下两图所示,如果以上操作没报错,就是说明成功了,如果报错的话会在Repository URL下面有红字提示,jenkins的branch Specifier会对输入的分支进行构建,所以要选择一个当前库中存在的分支填写。Credentials可以选择通过ssh或者通过http进行,如果通过ssh的话 需要通过公私钥的方式进行认证,我们这边选用用户名密码的方式进行,所以选择Username with password这个选项
  3、构建触发器
  构建触发器我们选择Poll SCM,如下图所示,这个表示每隔5分钟构建一次,当然也可以选择webhook的方式,通过提交来进行构建,这个在以后需要的时候我会去研究(目前我司还没这需求)
  4、构建
  这些linux的命令应该都是比较简单的,大家应该都能明白,其实就是模仿人工操作到一个目录下 执行dotnet restore 以及dotnet publish动作,最后publish的目录我设置成了bin/release下面
  5、执行构建
  点击立即构建,如果不抱错的话,/var/lib/jenkins/workspace/test/bin/release下就会有编译好的代码
  持续发布
  以上我们只是将代码从gitlab中获取并且执行了编译,那编译之后呢如何发布到指定的服务器呢,总不能直接就拿jenkins的服务器使用吧,所以接下来我们要做的就是将编译好的程序发布到需要的服务器,还好,jenkins也考虑到了这个需求,有一个publish over ssh插件可以很好的帮我们完成这个工作。
  我们回到之前下载插件的地方,下载publish over ssh
  回到之前配置gitlab的地方,现在多出了Publish over SSH的配置,如下图所示,我们这里也是选择了使用用户名密码的方式进行操作(同样可以使用ssh的方式进行授权登录)
  这里配置好了后,我们重新进入任务里,发现多出了一个构建环境,如下所示,红字可以不用管(应该是jenkins的bug)
  Source files表示要复制的文件信息(ps:这里的目录是相对于workspace的)
  remove prefix是去除前缀的意思,否则会创建相应的文件夹,这边我只需要文件,所以整个都去除了
  remote directory 这个文件夹如果不存在的话,那么会在服务端进行创建
  Exec command 拷贝成功后要执行的命令,这里一般的话 都是写个脚本放在服务端,直接执行服务端上的脚本,这里由于dotnet test.dll命令运行后,进程是不会结束的,所以,这里的这个文件我实际上是写了个空文件,真实使用的话可以使用Supervisor开启进程守护,每次发布之后杀掉相应进程,然后由进程守护去启动程序
  点击构建,如果没问题的话,你应该在对应的服务器的目录下看到了publish出来的内容,如果构建失败的话,这里的控制台输出也有非常详细的日志记录,通过日志记录应该是比较容易发现问题的
  总结
  jenkins是一个很强大的工具,目前也只是因为公司的需要开始研究,很多功能也还未接触到,包括自动化测试等,后续的方向上,应该是朝着docker以及k8s的方向研究,结合自动化的测试方案,完成真正的持续集成。
  docker方案思考,也是给大家一个思路,其实也就是把构建的脚本换成docker build的方式,再pull到镜像库中,最后通知目标服务器重新拉取镜像生成,运行,问题在于历史的版本库的序号如何一步步生成?
  遗留的问题:针对于数据库的持续集成或者发布,到底要如何去实现?

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号