VSTS-One Repository Multi-Solutions的CI問題

在導入持續整合(CI)後，方案與專案架構方式 的分享，從小朱與董大偉老師得到很棒的回應：

小朱：我兩種都用過，但我最後採用 Multiple Solutions。

董大徫：目前我們team的VSTS專案，一個Repository裡面會有多個solutions(如果有必要的話，小一點的專案只有一個)，一個solutions裡面會有多個project(幾乎都是這樣)。只要會彼此reference或必須一起build的project，我們大多會放在同一個solution。如果本質上不需要一起build(但架構上有關，例如一套ERP中的某幾個部分，例如mobile App, desktop client)、且Work Items/Sprints在一起控管的project，會切成兩(多)個solutions(但大多放在同個Repository)。至於Deploy，一個Solution裡面有多個Web Project應該不少見，在Build完之後(同一個build definition)可以同時deploy到各自的web site這應該沒問題。但我們用的是TFVC。

VSTS Build - Test Assemblies如何使用NUnit進行測試？

在 VSTS 的 Build(CI) 建立 build definition 時，通常會選擇範本來調整修改，例如，選擇 Visual Studio 範本：

在不修改範本步驟與內容的情況下，我們直接進行 Build 動作，我們可以看到所有動作都亮起綠燈：

看到綠燈，心情就非常好。但我發現一個可怕的事實...

VSTS使用Package Management擴充架設有權限功能的私有NuGet Server

https://www.nuget.org/ 提供套件管理的好處大家都知道，處理相依性、web.config組態管理、套件升降級等等方便性，免費。大量佛心人員提供可重覆使用的元件(輪子)，免費(絕大多數)。而自從有了 NuGet Server 之後，架設私有NuGet Server就是一件簡單不過的事。對於要上傳套件至 Nuget Server 也走過一些路，最早是用 NuGet Package Explorer 發行與管理，後來知道了 NuGet Packager 這個好物，可以直接從 Visual Studio 進行發行，超高興的。不過好景不長，大家又開始流行 DevOps，希望往自動化更進一步，所以我們又開始在VSTS上進行 Team Build + Release Management 發行至 Microsoft Azure 上的站台！

非內網 NuGet Server 問題

這裡有個很大的問題 Azure Web Site，預設的 NuGet Server 是個公開的環境，除了上傳套件需要 ApiKey 外，其他瀏覽或下載使用很非常自由的。也就是，在非公司內網環境，你的私有套件可能有一天突然就被下載與看光光了。

以前是無解，現在終於有一個很好的選擇：Visual Studio Team Service - Package Management。

使用dotnet watch讓ASP.NET Core擁有自動編譯功能

如果你有跟著 ASP.NET Core (1)(2) 篇練習的話，會發現開發上有那麼些許的不方便，就是我們要不斷中斷dotnet程序，重覆dotnet build、dotnet run的流程。我們希望後端的 C# 也能像前端擁有 LiveReload 或 React Hot Loader 的功能，在 Visual Studio 我們介紹過 Reload 來解決此一問題，而在.NET Core dotnet watch 套件可以實現自動編譯的工作。

部署ASP.NET Core至Azure Web APP

發行ASP.NET Core至Azure Web APP

前篇：使用ASP.NET Core建立Web API服務，我們使用 VS Code 來開發了一個.NET Core(ASP.NET Core) 的 Web API 服務，接著我們要把開發好的服務發行至Microsoft Azure來執行。和前篇相同，如果是使用 Visual Studio 那麼發行動作只在點選之間就完成了，不過這篇，我們依然是不採用 Visual Studio 來實作，還是使用 VS Code 與指令來完成。

初始化 git

在 VS Code 切換至 git 圖示，點擊"初始化 git 儲存機制"並且在訊息輸入第一次簽入的資訊。