實際開發中我們需要對一些公共類庫進行開發，並基於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 bin\Release\
nuget push *.nupkg -Source http://192.168.1.209:1024/nuget iwehave2305!
git commit -a -m updateversion
如圖 ：
創建編譯后事件，將修改記錄推送到git服務器，也可以加失敗郵件通知等等操作：
保存
立即構建測試一下，大功告成~