.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