實際開發中咱們須要對一些公共類庫進行開發,並基於Jenkins進行CI/CD(CI:持續集成,CD:持續部署),其餘項目經過NuGet引用。上文講述瞭如何搭建本地NuGet服務器併發布NuGet包,這裏再也不贅述。git
CI/CD流程以下圖:
json
首先公共類庫代碼經過Git管理,編輯完代碼後上傳到Git服務器。安全
配置Jenkins Job,按設定的觸發條件進行構建任務。bash
構建開始,刪除Workspace中舊文件,從Git服務器下載最新代碼,執行編譯,生成NuGet包,上傳到NuGet服務器。服務器
這樣,別人就能夠引用或者更新最新的公共類庫的NuGet包進行業務開發了。併發
新建一個.net core 的類庫,在工程文件處右鍵,選擇屬性,在「打包」中勾選「在版本中生成NuGet包」,而後設置基本信息。以下圖:
visual-studio
編譯生成,就會在Debug/Release目錄生成一個nupkg文件:
測試
關於版本號:
這裏指Net Framework風格的版本號,
即,主版本號.子版本號[.編譯版本號[.修訂版本號]]
英文對照:
Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
主版本號和次版本號是必選的;
編譯版本號和修訂號是可選的,可是若是定義了修訂號部分,則編譯版本號就是必選的。
全部定義的部分都必須是大於或等於 0 的整數。
應根據下面的約定使用這些部分:
Major :具備相同名稱但不一樣主版本號的程序集不可互換。例如,這適用於對產品的大量重寫,這些重寫使得沒法實現向後兼容性。
Minor :若是兩個程序集的名稱和主版本號相同,而次版本號不一樣,這指示顯著加強,但照顧到了向後兼容性。例如,這適用於產品的修正版或徹底向後兼容的新版本。
Build :編譯版本號(內部版本號)的不一樣表示對相同源所做的從新編譯。這適合於更改處理器、平臺或編譯器的狀況。
Revision :名稱、主版本號和次版本號都相同但修訂號不一樣的程序集應是徹底可互換的。這適用於修復之前發佈的程序集中的安全漏洞。ui
在Visual Studio中選擇NuGet包管理器,搜索「MSBump」,安裝,而後在工程文件下新建一個.msbump文件,寫入以下代碼:spa
{ Configurations: { "Debug": { BumpLabel: "dev", LabelDigits: 4 }, "Release": { BumpRevision: true, ResetLabel: "dev" } } }
上文表示:當編譯配置爲「Debug」時,版本號生成一個dev前綴後面跟四位數字的標籤,數字從0001開始遞增。當編譯配置爲「Release」時,修訂版本號會+1,清除dev標籤。固然,也能夠直接在.msbump中這樣寫:
{ BumpRevision: true }
意思就是每次編譯無論debug仍是release,都會使修訂版本號+1
前提操做:
須要下載NuGet.exe,而且把NuGet.exe所在目錄和MSBuild所在目錄加入到環境變量中,這樣方便在Jenkins中直接使用msbuild和nuget命令。
這裏再也不贅述,自行百度,就是安裝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服務器,也能夠加失敗郵件通知等等操做:
保存
當即構建測試一下,大功告成~