Windows服务器使用Jenkins自动部署

由于公司正在开发的工作流的几个项目经常需要测试,所以我用 Jenkins 实现了一个持续集成部署的方案。
持续集成部署的意义也在这里:在经常性的重复性部署工作中解放自己。

由于.net framework 的项目占多数,公司的测试机都是WINDOWS系统,生产机也是WINDOWS系统。在WINDOWS系统安装 Jenkins 也很方便。先装 Jdk,就可以装 Jenkins 了。  注意选择插件时,如果用的Svn Subversion Plug-in。

.net framework的项目,使用 Jenkins 会有些别扭,因为得安装和使用 Msbuild ,Msbuild 我没有找到新版本的独立安装包,后来就直接装的VS里的 Msbuild,还是会有奇奇怪怪的问题,直到完全安装了VS,才不出什么问题。.net core 的项目就简单多了,装了 dotnet core  的SDK就基本OK了。本文就使用 .net core 的项目进行讲解。

打开 Jenkins 点击 “New 任务”

Windows服务器使用Jenkins自动部署_第1张图片

公司源代码管理是用的 Svn,我自己的项目用的 Git。在图2 中输入 Svn 地址和帐号信息

Windows服务器使用Jenkins自动部署_第2张图片

因为并不是每次提交代码都需要发布,所以触发器没有做。触发的工作就交给部门新人来做,反正就点一下。

最重要的配置是在 “Build” 步骤。添加一个“执行 Windows 批处理命令”

Windows服务器使用Jenkins自动部署_第3张图片

在文本框里输入一些信息,如下:

Windows服务器使用Jenkins自动部署_第4张图片

这些命令会在 Jenkins 下载完 Svn 的代码后执行。

cd trunk 这是因为从我的 Svn 下载下来的目录结构,代码都是放在 trunk 文件夹下的。如果你的代码放在根目录,就不要这句。

dotnet restore WebApp --source "https://api.nuget.org/v3/index.json;http://nuget.mydomain.com.cn/nuget/"

我发布的项目名是 WebApp,其他类库项目我不关心。 dotnet 会依照依赖顺序执行 restore。
另外后边的 source 参数是因为我的项目引用了我自己的nuget 站点上的程序包,没有引用自己私有包的可以省略这个参数。

dotnet build
这句是生成,我不确定这句应不应该省略,因为 publish 的时候也会生成。读者有时间可以试一下删掉这句是不是也完全正常。

dotnet publish WebApp\WebApp.csproj  -o E:\WebAppWebsite

这句是发布,-o 是指定发布位置,这里是我的站点所在路径。

本以为这样跑起来没问题,可是事实没这么乐观。因为网站运行时,dotnet 会占用程序文件,所以在最后发布的步骤,会报告错误,替换文件失败。如果部署在 Docker 里,可以先停掉 Docker ,更新完文件再运行起来,但在 Windows 服务器里,应该是没有命令行可以控制某个网站的运行,PowerShell 应该可以,但是我没研究过。那可以用一个折中的办法,停掉 3w 服务,然后发布,发布完再开启服务,脚本变成下边的样子:

Windows服务器使用Jenkins自动部署_第5张图片

然后发现发布的时候有点长,会影响到测试服务器其他站点的运行。
然后想到了可以发布到一个临时文件夹,发布好之后再停止服务进行文件替换,替换完开启服务,最终的代码变成了这样:

Windows服务器使用Jenkins自动部署_第6张图片

这样就差不多了。连续跑了几天,没什么问题。

你可能感兴趣的:(Windows服务器使用Jenkins自动部署)