.NET 半天搭建Jenkins持续集成与自动化部署系统

 相信每一位程序员都经历过深夜加班上线的痛苦！而做为一个加班上线如屡见不鲜的码农，更是深感其痛。

因为咱们所作的系统业务复杂，系统庞大，设计到多个系统之间的合做，而核心系统更是采用分布式系统架构，因为当时对系统划分的不合理等等缘由致使每次发版都会设计到多个系统的发布，小的版本三五个，大的版本十几个甚至几十个系统的同时发布！而咱们也没有相应的基础设施的支撑，发版方式更是最传统的，开发人员将发布包发给运维人员，由其讲各个发布包一个一个覆盖到生产环境。所以每次上线仅仅发版就须要2-3个小时。

这种方式不只仅耗时、耗力，更是因为人工操做常常致使一些丢、落的现象。而咱们当时的测试也是采用纯手工的测试，发版完毕后一轮回归测试就须要3-4个小时(当时主要是手工测试)。以前也一直提倡持续集成、自动化的测试和运维，但迟迟没有推动落地。终于在一个加班到凌晨四点的夜晚后，我再也受不了。

回家后躺在床上迟迟睡不着，心想这个自动化的发布能有多难，他们搞不了，老子本身搞，因而6点爬起来来到公司，正式开始了个人持续集成、自动化部署的研究与推动之路。

1、初识Jenkins

因为以前亦没有相关知识的积累，所以也是对如何实现也是一头雾水。因而只能找度娘，关键字"自动化发布"。

搜索到不少工具和方法，但都是以Java平台居多，.net平台相关资料很少。其中以Jenkins介绍较多，微软也提供一套自动化部署的方式，也有一些其余持续集成工具能够实现自动化的发布，但最终仍是选择了Jenkins。主要有如下几个缘由：

代码开源、插件丰富完善、系统稳定

社区活跃，成功实践和网上资源较为丰富

安装配置简单

web形式的可视化的管理页面

一、Jenkins是什么

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工做，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。

持续集成：

持续集成是一种软件开发实践，即团队开发成员常常集成他们的工做，经过每一个成员天天至少集成一次，也就意味着天天可能会发生屡次集成。每次集成都经过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

二、Jenkins能干什么

众所周知，工业革命解放了人类的双手，使得人们避免了不少重复性的工做，而Jenkins能帮助开发测试运维人员解决不少重复性工做，咱们能够将一些重复性的工做，写成脚本，如：代码提交，执行单元测试，程序的编译、构建、发布等封装成脚本，由Jenkins替咱们定时或按需执行。事实上Jenkins的众多插件就是如此，究其根本就是执行一个或多个windows或linux命令来完成咱们的需求。

三、Jenkins的一个工做流程

经过对Jenkins的简单了解后，对完成自动化发布有了大体思路，以下图为Jenkins的一个工做流程

思路已经有了，接下来就是针对此流程，一步一步简单实现.NET Web应用程序基于Jenkins的自动化部署。

2、Jenkins 安装

Jenkins有windows版本也有linux版本，因为咱们项目都是基于.net freamwork进行开发，而jenkins构建须要编译.net程序,为了更方便的编译，所以选择安装windows版本。

一、下载

可从Jenkins官网https://jenkins.io/download/下载windows安装包。

二、安装

下载完成后，可按照提示进行安装便可。(windows下傻瓜式安装，注意Jenkins是java开发，所以需先安装对应jdk版本)

三、配置

安装完成后会自动安装并启动一个windows服务，名为Jenkins，打开浏览器localhost:8080(Jenkins默认端口号为8080，如需修改可打开Jenkins安装目录找到Jenkins.xml修改其中端口，而后打开服务重启Jenkins服务便可)以后按照提示进行配置便可！配置完成后看到以下界面表明安装成功!

整个安装过程很是简单，基本上是傻瓜式按照提示操做便可，期间并未遇到问题，基本上10分钟左右就搞定了！接下来将介绍如何按照上述流程实现.NET下Jenkins的持续集成与自动化部署!

3、经过SVN获取源代码

一、安装插件

根据咱们的思路，首先要作的就是获取到咱们的源代码。因为咱们公司使用的源代码管理工具主要是SVN所以在这里主要介绍SVN的方式方法。根据度娘的指引，咱们须要安装一个SVN的插件:Subversion Plug-in(若是：安装Jenkins时选择的安装推荐的插件，则Jenkins会直接给安装上这个插件，无需本身安装)。

二、项目配置

安装插件后，选择新建一个自由风格的软件项目，起个名字，进入到项目配置后，找到源代码管理选项：

主要有如下几个选项须要配置:

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的工做空间内，则表明配置成功!

4、经过MSBuild编译应用程序

一、安装插件与环境

编译.NET应用程序可经过微软提供的MSBuild工具，先安装插件:MSBuild。(注意:Jenkins服务器需安装MSBuild，建议在Jenkins上安装VS开发工具，能够在构建出问题的时候打开VS调试，省去不少没必要要的麻烦)。

二、全局配置

插件安装完毕后，进入系统管理->全局工具配置(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路径内。

三、项目配置

打开咱们以前建立的项目，找到构建选项->增长构建步骤->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文件夹内。

配置完成后，点击构建，查看控制台信息，如能构建成功，则表明咱们的配置无误！

四、遇到的问题

原觉得按照度娘的一系列解决方案可以很顺利的构建，但是在连续失败了几十次以后，才明白远远没有那么简单。期间主要遇到几个问题：

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工做空间内。

以上两个问题解决后，基本没有遇到太难的问题。因而可知咱们的源代码管理的科学、规范是多么的重要。

几十次的构建失败，一堆乱七八糟的引用是多么痛的领悟!

5、经过Ftp发布至应用服务器

构建成功后，Test.pubxml会指定发布的包的路径(最好是放到工做空间下)，按照思路，接下来就是要想办法把发布包Copy到应用服务器的根目录下。

因为咱们的应用服务器都是windows系统，所以不能像linux系统同样经过ssh远程Copy过去，当时能想到的就是使用Ftp直接上传到应用服务器。

一、安装插件与环境

Jenkins 安装插件Publish Over FTP,应用服务器上需开启Ftp。

二、全局配置

系统管理->系统配置下找到Publish over FTP配置项

Name:起个名字，后面项目配置里会用的到

HostName:Ftp主机名(端口号默认21，在高级里面能够改)

Username:Ftp用户名

Password:Ftp密码

三、项目配置

打开咱们以前建的项目，找到构建后操做->增长构建后操做步骤->Send build artifacts over FTP

Name:选择全局配置里的

Source files:选择你的发布包路径(这里是相对于工做空间的路径)

Remote directory：放到远程的哪一个路径里(这里是相对于Ftp根目录的路径)

配置完成后，点击保存，构建便可！

6、结束语

如上，就基本实现了咱们的自动化发布的需求，这期间从早晨六点开始，差很少中午就完成了，固然也并不像上面介绍的那么简单，期间也遇到了许多问题，构建了大概一百屡次，才最终成功了第一次。

本文主要介绍实现自动化部署的一种基本的思路，固然还有不少方案能够实现咱们的需求，甚至不只仅局限于Jenkins。

而这种方案其中也有许多细节的地方在文章中没有提到，如：如何实现自动化的Nunit单元测试，如何定时构建......，由于当时我在完成以后也给个人团队成员提供了一个很是详细的配置文档，而且培训了不少次，但事实证实，讲的越详细越会限制他们本身的主动思考与动手的能力。

这也致使了后来我去作其余工做的时候，咱们将近一年的时间仍是停留在我这半天的研究结果的层面上，而生产环境更是迟迟没有使用。

 

原连接地址：https://www.cnblogs.com/hunternet/p/9590287.html