前沿
其实本来是想把标题叫做持续集成的，只是后来看看研究出的内容，就只有发布这一个动作，自动化测试等内容也未涉及到，所以改名叫持续编译及发布应该更加贴切吧？
问题背景
其实目前我们传统方式上的发布方式，一般都是开发人员本地打包，然后传给测试，测试完成之后，发包到项目经理或者实施人员，最后进行部署，对于非互联网项目也许通过人力操作，也可以很好的完成，虽然可能会磕磕碰碰，但是对于互联网的产品，这种方式就显得低效了，每次迭代开发打包验证可能都要花掉不少时间，测试部署也要花掉不少时间，在这种情况下，自动化方案也就显得尤其重要
按照面向对象理解就是将编译发布等操作进行封装抽象，减少重复的过程（果然万物皆对象么）
什么是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./
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等互联网相关（最近被互联网架构搞的死去活来- -）
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，如有问题， 可站内信告知.