由于公司正在开发的工作流的几个项目经常需要测试，所以我用 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 任务”
公司源代码管理是用的 Svn，我自己的项目用的 Git。在图2 中输入 Svn 地址和帐号信息
因为并不是每次提交代码都需要发布，所以触发器没有做。触发的工作就交给部门新人来做，反正就点一下。
最重要的配置是在 “Build” 步骤。添加一个“执行 Windows 批处理命令”
在文本框里输入一些信息，如下：
这些命令会在 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 服务，然后发布，发布完再开启服务，脚本变成下边的样子：
然后发现发布的时候有点长，会影响到测试服务器其他站点的运行。
然后想到了可以发布到一个临时文件夹，发布好之后再停止服务进行文件替换，替换完开启服务，最终的代码变成了这样：
这样就差不多了。连续跑了几天，没什么问题。