實際開發中我們需要對一些公共類庫進行開發,並基於Jenkins進行CI/CD(CI:持續整合,CD:持續部署),其他專案通過NuGet引用。上文講述瞭如何搭建本地NuGet伺服器併發布NuGet包,這裡不再贅述。
CI/CD流程如下圖:
首先公共類庫程式碼通過Git管理,編輯完程式碼後上傳到Git伺服器。
配置Jenkins Job,按設定的觸發條件進行構建任務。
構建開始,刪除Workspace中舊檔案,從Git伺服器下載最新程式碼,執行編譯,生成NuGet包,上傳到NuGet伺服器。
這樣,別人就可以引用或者更新最新的公共類庫的NuGet包進行業務開發了。
在Visual Studio中操作
- 自定義打包類庫
新建一個.net core 的類庫,在工程檔案處右鍵,選擇屬性,在“打包”中勾選“在版本中生成NuGet包”,然後設定基本資訊。如下圖:
編譯生成,就會在Debug/Release目錄生成一個nupkg檔案:
- 自動更新編譯版本
關於版本號:
這裡指Net Framework風格的版本號,
即,主版本號.子版本號[.編譯版本號[.修訂版本號]]
英文對照:
Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
主版本號和次版本號是必選的;
編譯版本號和修訂號是可選的,但是如果定義了修訂號部分,則編譯版本號就是必選的。
所有定義的部分都必須是大於或等於 0 的整數。
應根據下面的約定使用這些部分:
Major :具有相同名稱但不同主版本號的程式集不可互換。例如,這適用於對產品的大量重寫,這些重寫使得無法實現向後相容性。
Minor :如果兩個程式集的名稱和主版本號相同,而次版本號不同,這指示顯著增強,但照顧到了向後相容性。例如,這適用於產品的修正版或完全向後相容的新版本。
Build :編譯版本號(內部版本號)的不同表示對相同源所作的重新編譯。這適合於更改處理器、平臺或編譯器的情況。
Revision :名稱、主版本號和次版本號都相同但修訂號不同的程式集應是完全可互換的。這適用於修復以前釋出的程式集中的安全漏洞。
在Visual Studio中選擇NuGet包管理器,搜尋“MSBump”,安裝,然後在工程檔案下新建一個.msbump檔案,寫入如下程式碼:
{
Configurations: {
"Debug": {
BumpLabel: "dev",
LabelDigits: 4
},
"Release": {
BumpRevision: true,
ResetLabel: "dev"
}
}
}
上文表示:當編譯配置為“Debug”時,版本號生成一個dev字首後面跟四位數字的標籤,數字從0001開始遞增。當編譯配置為“Release”時,修訂版本號會+1,清除dev標籤。當然,也可以直接在.msbump中這樣寫:
{
BumpRevision: true
}
意思就是每次編譯不管debug還是release,都會使修訂版本號+1
在Jenkins中操作
前提操作:
需要下載NuGet.exe,並且把NuGet.exe所在目錄和MSBuild所在目錄加入到環境變數中,這樣方便在Jenkins中直接使用msbuild和nuget命令。
- 安裝Jenkins
這裡不再贅述,自行百度,就是安裝Java那套環境
- 新建任務
新建任務,起個名字,選擇“構建一個自由風格的軟體專案”,點選“OK”:
- 編輯配置資訊
我們用的是Git管理程式碼,所以原始碼管理裡選擇Git,輸入倉庫地址和使用者名稱密碼,選擇需要拉取的分支名稱:
觸發條件,可以根據自己的需求,比如每日定時排程:
編譯環境中選擇編譯開始前清空Workspace,保證拉取最新程式碼不衝突:
編譯步驟中,選擇執行Windows批處理命令,主要執行如下操作:
1.進入工程檔案目錄
2.還原所有依賴的包
3.執行編譯Release版本
4.進入Releas目錄
5.將生成的nupkg檔案推送到NuGet伺服器
6.由於生成操作修改的修訂版本號,所以將修改的檔案提交
程式碼:
cd GAIA.GIS
msbuild -t:restore
msbuild /p:Configuration=Release
cd binRelease
nuget push *.nupkg -Source http://192.168.1.209:1024/nuget iwehave2305!
git commit -a -m updateversion
如圖 :
建立編譯後事件,將修改記錄推送到git伺服器,也可以加失敗郵件通知等等操作:
儲存
立即構建測試一下,大功告成~