ASP.NET Core 本身跨平台特性，使得他非常合適活在 Docker Container 裡。這裡試著把一個 github 專案先匯入 VSTS，然後在 VSTS Build 的 CI 服務進行 build image 和 pull image 的動作，pull image 我們採用 Microsoft Azure 的 Container Registry 服務來當私有庫。有了 image 之後，在使 VSTS Release 的 CD 服務將 image 送到 Web App for Container 去進行執行動作。
VS / VS Code <--> VSTS git <--> Build / Pull Image <--> ACR <--> Release <--> > Web App for Container <--> User
關於的Web.config瞭解與使用，在開發的網站規模越來越大時，需要瞭解的越多，之前也做有幾次的討論：
但這一次是碰到VSTS在自動化建置後產出Web.config一直不正常，一開始有點鬼打牆的狀態，但在新聞追追追的精神下，讓我又對Web.config組熊轉換又更進一步瞭解。
早上簽入一專案，VSTS CI Build沒幾秒立即出現紅燈：
此專案為類別庫專案，差異點是之前是用 Visual Studio 2015 開發，目前改用 Visual Studio 2017 並重構 C# 6 語法改使用一些 C# 7 out variables 語法。就簽出來使用 Visual Studio 2017 開啟專案狀態來看，Visual Studio 2017 並無修改任何專案內容，在使用 C# 7 out variables 也能正常編譯出 dll 並讓其他專案參考使用。
直覺反應：VSTS 不支援 C# 7 編譯？不會吧！
在導入持續整合(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(CI) 建立 build definition 時，通常會選擇範本來調整修改，例如，選擇 Visual Studio 範本：
在不修改範本步驟與內容的情況下，我們直接進行 Build 動作，我們可以看到所有動作都亮起綠燈：
看到綠燈，心情就非常好。但我發現一個可怕的事實...
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 上的站台！
這裡有個很大的問題 Azure Web Site，預設的 NuGet Server 是個公開的環境，除了上傳套件需要 ApiKey 外，其他瀏覽或下載使用很非常自由的。也就是，在非公司內網環境，你的私有套件可能有一天突然就被下載與看光光了。
以前是無解，現在終於有一個很好的選擇：Visual Studio Team Service - Package Management。
前一篇「雲端VSTS透過地端MAC建置iOS專案-以Cordova專案為例」我們建立雲端 Visual Studio Team Services(VSTS) 與地端 MAC 的 Agent 的連接，但要觸發地端 MAC 的 Build 行為，還需要在 VSTS 裡去定義 Build 的步驟與行為，然後 Agent 會依照我們在 VSTS 定義的步驟一一執行。而 Cordova 專案在 iOS 上有二種 Build 的方法，一種是 Cordova Build，另一種是 Xcode Build。
想要在 VSTS 裡去定義 Cordova Build，必須先安裝 VSTS 的擴充程式，請先在 VSTS 登入的瀏覽器去開啟 Cordova Build 網頁進行安裝。這樣 Cordova Build 會才出現在"add build step..."的步驟裡。
VSTS 除了可以透過本身提供的 agent 來建置之外，它也提供 private agent 的設計，意思是自行架設的 agent 來進行 Build 的工作。今天我們需要編譯一個iOS專案，例如，Cordova 專案，VSTS本身沒有提供這個iOS agent，那麼我們需要準備一台 MAC，然後在這台地端 MAC 安裝一支 agent 與 VSTS 連線，這樣雲端的 VSTS 就能發專案發行至地端 MAC。
以下先建立一組PAT帳號，以便地端的MAC Agent可以與雲端的VSTS連線。
在巡覽列自己帳號選擇「My Profile」，選擇「Security」的頁籤，選擇「PerPersonal access tokens」選擇「Add」，新增後即可取得 Token。
如果你沒有權限可加入，可以請管理員幫忙加入。
我在設定時碰到我已經加入 Security 的 Administrators 的群組，還是無法加入上述兩個群組。這時只能請連絡管理員幫忙加入也行。
Visual Studio Code(VS Code)是微軟新推出跨平台(Linux, OSX, Windows)的程式編輯器。前較於Visual Studio，VS Code非常的輕量化，且對於前端程式的支援非常的強大。我們想要透過VS Code當成Visual Studio Team Service(VSTS)專案的另一個開發工具(尤其是MAC OSX的使用者)，這樣就不用特地在MAC OSX上去安裝虛擬機再裝Visual Studio。
