共计 5048 个字符，预计需要花费 13 分钟才能阅读完成。
前言
相信每一位程序员都经历过深夜加班上线的痛苦！而作为一个加班上线如家常便饭的码农，更是深感其痛。由于我们所做的系统业务复杂，系统庞大，设计到多个系统之间的合作，而核心系统更是采用分布式系统架构，由于当时对系统划分的不合理等等原因导致每次发版都会设计到多个系统的发布，小的版本三五个，大的版本十几个甚至几十个系统的同时发布！而我们也没有相应的基础设施的支撑，发版方式更是最传统的，开发人员将发布包发给运维人员，由其讲各个发布包一个一个覆盖到生产环境。因此每次上线仅仅发版就需要 2 - 3 个小时。这种方式不仅仅耗时、耗力，更是由于人工操作经常导致一些丢、落的现象。而我们当时的测试也是采用纯手工的测试，发版完毕后一轮回归测试就需要 3 - 4 个小时(当时主要是手工测试)。之前也一直提倡持续集成、自动化的测试和运维，但迟迟没有推进落地。终于在一个加班到凌晨四点的夜晚后，我再也受不了。回家后躺在床上迟迟睡不着，心想这个自动化的发布能有多难，他们搞不了，老子自己搞，于是 6 点爬起来来到公司，正式开始了我的持续集成、自动化部署的研究与推进之路。
一、初识 Jenkins
由于之前亦没有相关知识的积累，因此也是对如何实现也是一头雾水。于是只能找度娘，关键字 ” 自动化发布 ”。搜索到很多工具和方法，但都是以 Java 平台居多，.net 平台相关资料不多。其中以 Jenkins 介绍较多，微软也提供一套自动化部署的方式，也有一些其他持续集成工具可以实现自动化的发布，但最终还是选择了 Jenkins。主要有以下几个原因：
- 代码开源、插件丰富完善、系统稳定
- 社区活跃，成功实践和网上资源较为丰富
- 安装配置简单
- web 形式的可视化的管理页面
1. Jenkins 是什么
Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。
** 持续集成：**
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
2.Jenkins 能干什么
众所周知，工业革命解放了人类的双手，使得人们避免了很多重复性的工作，而 Jenkins 能帮助开发测试运维人员解决很多重复性工作，我们可以将一些重复性的工作，写成脚本，如：代码提交，执行单元测试，程序的编译、构建、发布等封装成脚本，由 Jenkins 替我们定时或按需执行。事实上 Jenkins 的众多插件就是如此，究其根本就是执行一个或多个 windows 或 linux 命令来完成我们的需求。
3.Jenkins 的一个工作流程
通过对 Jenkins 的简单了解后，对完成自动化发布有了大致思路，如下图为 Jenkins 的一个工作流程
思路已经有了，接下来就是针对此流程，一步一步简单实现.NET Web 应用程序基于 Jenkins 的自动化部署。
二、Jenkins 安装
Jenkins 有 windows 版本也有 linux 版本，由于我们项目都是基于.net freamwork 进行开发，而 jenkins 构建需要编译.net 程序, 为了更方便的编译，因此选择安装 windows 版本。
1. 下载
可从 Jenkins 官网 https://jenkins.io/download/ 下载 windows 安装包。
2. 安装
下载完成后，可按照提示进行安装即可。(windows 下傻瓜式安装，注意 Jenkins 是 java 开发，因此需先安装对应 jdk 版本)
3. 配置
安装完成后会自动安装并启动一个 windows 服务，名为 Jenkins，打开浏览器 localhost:8080(Jenkins 默认端口号为 8080，如需修改可打开 Jenkins 安装目录找到 Jenkins.xml 修改其中端口，然后打开服务重启 Jenkins 服务即可)之后按照提示进行配置即可！配置完成后看到如下界面代表安装成功!
整个安装过程非常简单，基本上是傻瓜式按照提示操作即可，期间并未遇到问题，基本上 10 分钟左右就搞定了！接下来将介绍如何按照上述流程实现.NET 下 Jenkins 的持续集成与自动化部署!
三、通过 SVN 获取源代码
1. 安装插件
根据我们的思路，首先要做的就是获取到我们的源代码。由于我们公司使用的源代码管理工具主要是 SVN 因此在这里主要介绍 SVN 的方式方法。根据度娘的指引，我们需要安装一个 SVN 的插件:Subversion Plug-in(如果：安装 Jenkins 时选择的安装推荐的插件，则 Jenkins 会直接给安装上这个插件，无需自己安装)。
2. 项目配置
安装插件后，选择新建一个自由风格的软件项目，起个名字，进入到项目配置后，找到源代码管理选项：
主要有以下几个选项需要配置:
-
Repository URL: 要获取的 SVN 的路径，如:https://127.0.0.1:9666/svn/HS.Mall/SoureCode/Trunk/Test
-
Credentials: 配置 SVN 用户名和密码
-
Ignore externals: 是否忽略 SVN 外部引用(这个很重要，稍后会用到，关于 SVN 外部引用，可自行百度)
-
Additional Credentials: 当你的 SVN 版本库使用外部引用关联其它版本库是这个就很重要了
Realm：填写 SVN 服务器的地址
<https://127.0.0.1:9666> VisualSVN Server //(注意这个格式)Credentials: 填写 SVN 用户名和密码信息
其它一些选项直接按照默认值就可以，关于每一项的详细介绍可以点击后面的小？号查看。
配置完成后点击保存后，构建该项目查看结果。若能够将源代码更新至 Jenkins 的工作空间内，则代表配置成功!
四、通过 MSBuild 编译应用程序
1. 安装插件与环境
编译.NET 应用程序可通过微软提供的 MSBuild 工具，先安装插件:MSBuild。(注意:Jenkins 服务器需安装 MSBuild，建议在 Jenkins 上安装 VS 开发工具，可以在构建出问题的时候打开 VS 调试，省去很多不必要的麻烦)。
2. 全局配置
插件安装完毕后，进入系统管理 -> 全局工具配置 (ConfigureTools) 找到 MSBuild 配置选项:
- Name：自己起个名字
- Path to MSBuild:MSBuild.exe 程序的物理路径
注意: 此处 MSBuild.exe 必须与程序所使用 freamwork 版本相对应，此处我在这就遇到了一个大坑，一开始随便找个一个 MSBuild 工具，没想到根本编译不了 C#6.0 的语法。建议直接指向 visual studio 安装目录内的 MSBuild.exe, 可以避免很多问题。如 VS2017 在:Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin 路径内。
3. 项目配置
打开我们之前创建的项目，找到构建选项 -> 增加构建步骤 ->Build a Visual Studio project or solution using MSBuild
-
Name: 选择全局 MSBuild 配置的名称
-
MSBuild Build File: 填写我们的要构建的项目.csproj 文件，所相对工作的路径。如:/Test.csproj
-
Command Line Arguments:MSBuild 的参数如：/t:Rebuild /P:Configuration=Release /p:VisualStudioVersion=14.0 /p:DeployOnBuild=True;PublishProfile=Test.pubxml
-
/t:Rebuild 重新生成
- /p:Configuration=Release Release 生成模式
- /p:VisualStudioVersion=14.0 指定子工具集(VS2015 为 14.0，2017 为 15.0)，不设置会报错
-
/p:DeployOnBuild=True;PublishProfile=Test.pubxml 使用 Test.pubxml 发布文件来发布项目 .pubxml 文件可在 VS 发布时配置，位于 Properties 文件夹内。
配置完成后，点击构建，查看控制台信息，如能构建成功，则代表我们的配置无误！
-
4. 遇到的问题
原以为按照度娘的一系列解决方案能够很顺利的构建，可是在连续失败了几十次之后，才明白远远没有那么简单。期间主要遇到几个问题：
- MSBuild 版本不对导致构建不了 C#6.0 的语法
- Jenkins 是讲版本库源代码更新到自己的工作空间内，再执行后续的构建工作。我们的程序很不规范，其中引用了许多不属于自己版本库的第三方依赖包，和一些自己开发的公共库，当时这些第三方包和公共库放在我们 SVN 的另一个版本库里进行管理，因此在构建的时候导致很多程序集找不到引用。
关于问题 1: 上面已经提过，只需要找到对应版本即可
而问题 2: 一开始找了很多资料也没有找到解决方案，后来还是从源代码管理上找到了方案。
方案 1：
借鉴 Nuget 的思想，使用 Nuget 服务器管理我们自己开发的一些公共依赖库。关于 Nuget 管理依赖的文章在另一篇博客里。
方案 2:
就是上面提到的 SVN 外部引用，当时也是走投无路，于是疯狂翻译 Jenkins 的这些英文解释，在翻译到 SVN 插件的 Ignore externals 时，找到了这种方案，就是 SVN 可以设置外部引用，这样在更新版本库的时候就可以把依赖的版本库也更新下来，然后 Jenkins SVN 插件把这个 Ignore externals 选项去掉，然后在 Additional Credentials 选项里填上所依赖版本库的 SVN 配置，就能够把这些依赖也更新到 SVN 工作空间内。
以上两个问题解决后，基本没有遇到太难的问题。由此可见我们的源代码管理的科学、规范是多么的重要。
几十次的构建失败，一堆乱七八糟的引用是多么痛的领悟!
五、通过 Ftp 发布至应用服务器
构建成功后，Test.pubxml 会指定发布的包的路径(最好是放到工作空间下)，按照思路，接下来就是要想办法把发布包 Copy 到应用服务器的根目录下。由于我们的应用服务器都是 windows 系统，因此不能像 linux 系统一样通过 ssh 远程 Copy 过去，当时能想到的就是使用 Ftp 直接上传到应用服务器。
1. 安装插件与环境
Jenkins 安装插件 Publish Over FTP, 应用服务器上需开启 Ftp。
2. 全局配置
系统管理 -> 系统配置下找到 Publish over FTP 配置项
- Name: 起个名字，后面项目配置里会用的到
- HostName:Ftp 主机名(端口号默认 21，在高级里面可以改)
- Username:Ftp 用户名
- Password:Ftp 密码
3. 项目配置
打开我们之前建的项目，找到构建后操作 -> 增加构建后操作步骤 ->Send build artifacts over FTP
- Name: 选择全局配置里的
- Source files: 选择你的发布包路径(这里是相对于工作空间的路径)
- Remote directory：放到远程的哪个路径里(这里是相对于 Ftp 根目录的路径)
配置完成后，点击保存，构建即可！
六、结束语
如上，就基本实现了我们的自动化发布的需求，这期间从早晨六点开始，差不多中午就完成了，当然也并不像上面介绍的那么简单，期间也遇到了许多问题，构建了大概一百多次，才最终成功了第一次。本文主要介绍实现自动化部署的一种基本的思路，当然还有很多方案可以实现我们的需求，甚至不仅仅局限于 Jenkins。而这种方案其中也有许多细节的地方在文章中没有提到，如：如何实现自动化的 Nunit 单元测试，如何定时构建 ……，因为当时我在完成之后也给我的团队成员提供了一个非常详细的配置文档，并且培训了很多次，但事实证明，讲的越详细越会限制他们自己的主动思考与动手的能力。这也导致了后来我去做其他工作的时候，我们将近一年的时间还是停留在我这半天的研究结果的层面上，而生产环境更是迟迟没有使用。其实思路才是最重要的，有了思路我们就可以通过各种方式来解决我们的问题，还是建议大家注重解决问题的思路，多动手，自己实践，才能学得更透! 关于.NET 平台下 Jenkins 实现持续集成与自动化部署的落地与实现的问题与讨论，可以在文章下留言。
