前沿 其實本來是想把標題叫做持續集成的，只是後來看看研究出的內容，就只有發佈這一個動作，自動化測試等內容也未涉及到，所以改名叫持續編譯及發佈應該更加貼切吧？ 問題背景 其實目前我們傳統方式上的發佈方式，一般都是開發人員本地打包，然後傳給測試，測試完成之後，發包到項目經理或者實施人員，最後進行部署，對 ...
前沿
其實本來是想把標題叫做持續集成的，只是後來看看研究出的內容，就只有發佈這一個動作，自動化測試等內容也未涉及到，所以改名叫持續編譯及發佈應該更加貼切吧？
問題背景
其實目前我們傳統方式上的發佈方式，一般都是開發人員本地打包，然後傳給測試，測試完成之後，發包到項目經理或者實施人員，最後進行部署，對於非互聯網項目也許通過人力操作，也可以很好的完成，雖然可能會磕磕碰碰，但是對於互聯網的產品，這種方式就顯得低效了，每次迭代開發打包驗證可能都要花掉不少時間，測試部署也要花掉不少時間，在這種情況下，自動化方案也就顯得尤其重要
按照面向對象理解就是將編譯發佈等操作進行封裝抽象，減少重覆的過程（果然萬物皆對象麽）
什麼是jenkins
那標題既然是基於jenkins，那什麼是jenkins呢？百度解釋我就抄一個過來了：Jenkins是一個開源軟體項目，是基於Java開發的一種持續集成工具，用於監控持續重覆的工作，旨在提供一個開放易用的軟體平臺，使軟體的持續集成變成可能。
那既然是持續集成的工具，那發佈功能肯定也是有的，SO我們就採用jenkins來實現我們的訴求，想想啥時候我們公司也可以有真正的持續集成方式出現呢？
安裝技能準備：
rpm安裝方法：
rpm -ivh XXXX.rpm
jenkins安裝&配置
安裝:
1、要安裝jenkins，那就必須得先安裝JDK，先從官方找個jdk的地址（rpm安裝）：jdk-8u161-linux-x64.rpm，找那個jdk-8u161-linux-x64.rpm，rpm安裝之。
2、jenkins的rpm下載，給個地址：jenkins-2.89.4-1.1.noarch.rpm，然後rpm安裝之
3、安裝完關閉防火牆（或者開放8080埠也可以）
4、service jenkins start；開啟jenkins
配置:
瀏覽器打開ip:8080
根據紅字部分目錄，找到密鑰信息輸入
選擇第一個推薦安裝，等待一段時間，則安裝結束，第一步的初始化配置就到這裡結束了
.NETCore安裝
git安裝
既然我們要基於gitlab跟jenkins，那必須還得裝一個git才能pull源碼到本地啊，安裝方式如下：一句一句執行（參照https://www.cnblogs.com/gsliuruigang/p/7899803.html）
yum -y groupinstall "Development Tools"//下載編譯工具 yum -y install zlib-devel perl-ExtUtils-MakeMaker asciidoc xmlto openssl-devel//下載依賴包 wget https://github.com/git/git/archive/v2.16.2.tar.gz//下載文件 tar -zxf v2.16.2.tar.gz//解壓文件 cd git-2.16.2/
autoconf
./configure --prefix=/usr/local/git make && make install//編譯安裝 export PATH="/usr/local/git/bin:$PATH"//配置全局路徑 source /etc/profile//使配置生效
gitlab配置
登錄ip:8080,到管理插件的地方，安裝GitLab Plugin插件，如下圖所示
打開gitlab地址——>個人設置——>account——>複製Private token備用
jenkins——>系統管理——>系統設置——>找到gitlab
點擊add按鈕
最後點擊test connection，顯示success的話那就是連接是成功的了
任務構建
回到jenkins首頁——>新建任務——>輸入名稱——>生成
1、General
如下圖所示，gitlabconnection選擇之前配置的信息
2、源碼管理
源碼管理主要配置源碼庫的信息，具體配置如下兩圖所示，如果以上操作沒報錯，就是說明成功了，如果報錯的話會在Repository URL下麵有紅字提示，jenkins的branch Specifier會對輸入的分支進行構建，所以要選擇一個當前庫中存在的分支填寫。Credentials可以選擇通過ssh或者通過http進行，如果通過ssh的話 需要通過公私鑰的方式進行認證，我們這邊選用用戶名密碼的方式進行，所以選擇Username with password這個選項
3、構建觸發器
構建觸發器我們選擇Poll SCM，如下圖所示，這個表示每隔5分鐘構建一次，當然也可以選擇webhook的方式，通過提交來進行構建，這個在以後需要的時候我會去研究（目前我司還沒這需求）
4、構建
這些linux的命令應該都是比較簡單的，大家應該都能明白，其實就是模仿人工操作到一個目錄下 執行dotnet restore 以及dotnet publish動作，最後publish的目錄我設置成了bin/release下麵
5、執行構建
點擊立即構建，如果不抱錯的話，/var/lib/jenkins/workspace/test/bin/release下就會有編譯好的代碼
持續發佈
以上我們只是將代碼從gitlab中獲取並且執行了編譯，那編譯之後呢如何發佈到指定的伺服器呢，總不能直接就拿jenkins的伺服器使用吧，所以接下來我們要做的就是將編譯好的程式發佈到需要的伺服器，還好，jenkins也考慮到了這個需求，有一個publish over ssh插件可以很好的幫我們完成這個工作。
我們回到之前下載插件的地方，下載publish over ssh
回到之前配置gitlab的地方，現在多出了Publish over SSH的配置，如下圖所示，我們這裡也是選擇了使用用戶名密碼的方式進行操作（同樣可以使用ssh的方式進行授權登錄）
這裡配置好了後，我們重新進入任務里，發現多出了一個構建環境，如下所示，紅字可以不用管（應該是jenkins的bug）
Source files表示要複製的文件信息（ps:這裡的目錄是相對於workspace的）
remove prefix是去除首碼的意思，否則會創建相應的文件夾，這邊我只需要文件，所以整個都去除了
remote directory 這個文件夾如果不存在的話，那麼會在服務端進行創建
Exec command 拷貝成功後要執行的命令，這裡一般的話 都是寫個腳本放在服務端，直接執行服務端上的腳本，這裡由於dotnet test.dll命令運行後，進程是不會結束的，所以，這裡的這個文件我實際上是寫了個空文件，真實使用的話可以使用Supervisor開啟進程守護，每次發佈之後殺掉相應進程，然後由進程守護去啟動程式
點擊構建，如果沒問題的話，你應該在對應的伺服器的目錄下看到了publish出來的內容，如果構建失敗的話，這裡的控制台輸出也有非常詳細的日誌記錄，通過日誌記錄應該是比較容易發現問題的
總結
jenkins是一個很強大的工具，目前也只是因為公司的需要開始研究，很多功能也還未接觸到，包括自動化測試等，後續的方向上，應該是朝著docker以及k8s的方向研究，結合自動化的測試方案，完成真正的持續集成。
docker方案思考，也是給大家一個思路，其實也就是把構建的腳本換成docker build的方式，再pull到鏡像庫中，最後通知目標伺服器重新拉取鏡像生成，運行，問題在於歷史的版本庫的序號如何一步步生成？
遺留的問題：針對於資料庫的持續集成或者發佈，到底要如何去實現？
作者： Mango
出處： http://www.cnblogs.com/OMango/
關於自己：專註.Net桌面開發以及Web後臺開發，開始接觸微服務、docker等互聯網相關（最近被互聯網架構搞的死去活來- -）
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，如有問題， 可站內信告知.
