【.NetCore】基于jenkins以及gitlab的持续编译及发布

前沿

　　其实本来是想把标题叫做持续集成的，只是后来看看研究出的内容，就只有发布这一个动作，自动化测试等内容也未涉及到，所以改名叫持续编译及发布应该更加贴切吧？

问题背景

　　其实目前我们传统方式上的发布方式，一般都是开发人员本地打包，然后传给测试，测试完成之后，发包到项目经理或者实施人员，最后进行部署，对于非互联网项目也许通过人力操作，也可以很好的完成，虽然可能会磕磕碰碰，但是对于互联网的产品，这种方式就显得低效了，每次迭代开发打包验证可能都要花掉不少时间，测试部署也要花掉不少时间，在这种情况下，自动化方案也就显得尤其重要

　　按照面向对象理解就是将编译发布等操作进行封装抽象，减少重复的过程（果然万物皆对象么）

什么是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到镜像库中，最后通知目标服务器重新拉取镜像生成，运行，问题在于历史的版本库的序号如何一步步生成？

　　遗留的问题：针对于数据库的持续集成或者发布，到底要如何去实现？

 

作者： Mango

出处： http://www.cnblogs.com/OMango/

关于自己：专注.Net桌面开发以及Web后台开发，开始接触微服务、docker等互联网相关（最近被互联网架构搞的死去活来- -）

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，如有问题， 可站内信告知.