dotnet CBB 爲何決定推送 Tag 才能打包

經過推送 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 服務的網絡