通過推送 Tag 才打 NuGet 包的方法的作用不僅僅是讓打包方便，讓打包這個動作可以完全在本地執行，無需關注其他系統的使用步驟，更重要的是可以強制每個可能被安裝的 NuGet 包版本都能有一個和他對應的 Tag 號，原因是為了解決回退到某個版本發現有一個坑，這個坑是因為某個依賴庫的版本問題，此時我期望最小改動，我雖然能拿到這個庫的代碼，但是我很難知道我這個版本安裝的 NuGet 庫對應依賴庫的哪個 commit 的代碼
我之前每次需要追蹤某個 NuGet 包對應的依賴庫的源代碼的版本的時候，都需要進入打包服務器，查看打包日志，在這樣很坑玩了很久，公司的配置管理員干掉了服務器，洗掉了日志，而我接到一個很古老的專案需要修復某個坑，此時這個專案參考了一個底層庫的古老版本，此時我不能升級底層庫，應該底層庫的改動量太大了，但是我又很難定位我現在專案參考的 NuGet 庫對應的底層庫的哪個 commit 代碼，后面只能通過二分的方法，用了幾天的開發才完成
所以看到了我上面的坑，小伙伴大概也就能知道為什么我期望將 Tag 和 NuGet 包關聯了
在我現在團隊的約定里面，只要添加了 alpha 也就是預覽版，就可以隨意推送測驗的 Tag 讓服務器幫你打包 NuGet 包，然后在其他的專案安裝，為什么會鼓勵這樣做？原因是有小伙伴說我的某個專案的開發依賴某個庫，但是假設這個庫一定是合并到主分支之后才能打出 Tag 打包，也就是小伙伴在某個專案的代碼將一直不能推送，同時小伙伴也不能在 csproj 里面參考某個私有的版本，因為私有的版本只有小伙伴自己能構建通過，其他小伙伴可構建不通過
假設小 A 需要開發專案 F 而這個專案以來庫 L 的更改
而庫 L 的更改如果沒有合并到 master 分支，就不允許推送 Tag 打包
此時小 A 如果推送了代碼，這個代碼參考了還沒有被發布的 L 庫的代碼，那么其他小伙伴將無法構建通過
此時小 A 如果推送了代碼，這個代碼參考了小 A 本地生成的 NuGet 庫，那么其他小伙伴將找不到這個 NuGet 庫，無法構建通過
如果小 A 不推送代碼，只是寫了一個 commit 但是這個 commit 包含了 L 庫的代碼，但是沒有在 csproj 里面升級 L 庫版本，那么在回滾代碼的時候，進入到這個 commit 將構建失敗
如果小 A 在 commit 里面升級到他本地生成的 NuGet 庫，那么回滾代碼的時候，因為公共服務器不存在小 A 的本地的 NuGet 庫，依然會構建失敗
此時有一個叫頭像的小伙伴出了一個餿主意，小 A 雖然 L 庫代碼沒有被合并，但是可以知道這個 L 庫被合并之后分配的版本號，此時就在 csproj 里面更新到這個版本，然后通過本地打包的方法參考和推送，但是這個方法存在以下問題
- 小伙伴本地打包第一次，發現翻車了，想要第二次打包，但是此時的版本號就重疊了，需要經過黑科技洗掉 NuGet 快取重新構建，此時的效率特別低
- 小伙伴在這次 commit 寫的代碼是他認為發布的時候將會添加的公開方法，但是實際上最后發布的時候更改了公開方法，此時回滾到這個 commit 雖然能下載到 NuGet 庫，但是發現 L 庫的公開方法不匹配，構建失敗
這就是為什么選用推送 Tag 打包的原因，允許小伙伴自己選擇預覽版的版本推送，自動打包，這樣就可以在專案中使用此Tag 打出的預覽版的代碼，此時的 commit 其他小伙伴也能構建，回滾代碼的時候也可以在公共服務器找到 NuGet 包或切換到對應版本的源代碼
在 VisualStudio 的幫助下，使用推Tag打包的成本非常低，因為在 VS 里面只需要簡單5次點擊加上輸入版本號就能完成 Tag 新建和推送，詳細請看 VisualStudio 如何快速添加一個 Git Tag 推送
在本地推Tag打包還有一個好處是能提升不少的效率，有很多團隊例如我現在的團隊之前就是使用 jenkins 打包，這個工具太強大而讓上手和維護成本都特別高，加上使用的小伙伴太多，服務器性能不足，每次打包都需要等待緩慢的系統回應，而通過 Tag 打包的方式可以隱藏這部分動作，所有動作都在本地執行，只有最后一步推送需要依賴 Git 服務的網路
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/9657.html
標籤：.NET Core
上一篇：如何參與 .NET 的開發和設計