部署群組和組建完成觸發程式 – VSTS 短期衝刺 132 更新
Visual Studio Team Services (VSTS 的Sprint 132 更新) 帶來幾個重要功能，可協助您調整組建和發行管線。 在 [建置] 中，使用新的 組建完成觸發程式，將可能由不同小組擁有的相關組建鏈結在一起 。 在 發行中，我們宣佈 部署群組正式運作，您可以使用此群組在具有高可用性的多個虛擬機器之間調整部署，包括生產環境。
其他重點包含：
VSTS 的新功能
功能
程式碼
建置和發行
套件
Wiki
報告
程式碼
使用認可訊息快速描述提取要求
撰寫描述性認可訊息會將值新增至任何 Git 存放庫的歷程記錄。 若要鼓勵品質認可訊息，新的提取要求 (具有多個認可的 PR) 將需要參與者手動輸入標題。
提取要求描述預設會繼續是空的，但新功能可讓您更輕鬆地將來自 PR 認可的認可訊息併入 PR 描述中。 若要新增認可訊息，只要按一下 [ 新增認可訊息 ] 即可將認可訊息附加至 PR 描述文字結尾。
直接從 Windows 檔案總管執行 TFVC 命令
TFVC Windows Shell 擴充功能提供整合至 Windows 檔案總管的輕量型版本控制體驗，現在支援 VSTS 和 TFS 2018。 此工具可讓您方便地存取 Windows 檔案總管操作功能表中的許多 TFVC 命令。
此工具先前是 TFS Power 工具的一部分，已發行為 Visual Studio Marketplace 上的獨立工具。
建置和發行
使用建置完成觸發程式將相關的組建鏈結在一起
大型產品有數個彼此相依的元件。 這些元件通常會獨立建置。 當上游元件 (程式庫時，例如) 變更時，必須重建並重新驗證下游相依性。 Teams 通常會手動管理這些相依性。
現在，您可以在成功完成另一個組建時觸發組建。 上游組建所產生的成品可以下載並用於稍後的組建中，您也可以從下列變數取得資料：Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName。 如需詳細資訊 ，請參閱組建觸發 程式檔。
此功能的優先順序是根據目前 #2 最高投票建議的 1，129 個投票。
請記住，在某些情況下，單一 多階段建置 可能符合您的需求。 不過，如果您的需求包含不同的組態設定、選項或不同的小組來擁有相依程式，建置完成觸發程式就很有用。
使用部署群組將部署調整至 VM
現已正式推出「部署群組」功能，可提供更強固且現成可用的多電腦部署。 有了「部署群組」功能，就可以跨多部伺服器協調部署，並執行輪流更新，同時確保整個應用程式的高可用性。 您也可以部署到內部部署伺服器，或是 Azure 或任何雲端的虛擬機器上，還可擁有已部署成品版本的完整追蹤能力，可追蹤至伺服器層級。
代理程式型部署功能依賴已推出的相同組建和部署代理程式。 您可以在部署群組階段中，於目標電腦上使用完整工作目錄。 以擴充性觀點而言，您還可以針對部署群組和目標使用 REST API，以程式設計方式進行存取。
共用部署目標
如果您使用相同的伺服器來裝載多個應用程式，您可以使用部署集區跨小組專案共用伺服器 (也稱為部署目標) 。
新增範本
部署至多個目標現在很容易使用新的發行定義範本。 現可取得 IIS 網站的多個範本、具有資料庫的 IIS 網站，以及 SQL DB 的多個部署範本。
布建 VM
使用增強的Azure 資源群組工作，在 Azure 上新布建或預先存在的虛擬機器上動態啟動代理程式。
當我們在上一個 5 月啟動部署群組時，我們出貨了以幾個主要案例為目標的簡單使用者介面。 您現在會發現更一致的介面，其感覺就像產品的其餘部分。
如需開始使用的詳細資訊，請參閱 部署群組 檔。
建置以 Go 撰寫的應用程式
現在您可以在 VSTS 中建置 Go 應用程式！
使用 Go 工具安裝程式 工作，即時安裝一或多個 Go 工具版本。 此工作會取得專案所需的特定 Go 工具版本，並將它新增至組建代理程式的 PATH。 如果代理程式上已安裝目標 Go 工具版本，此工作將會略過下載並再次安裝的程式。
Go工作可協助您下載相依性、建置或測試應用程式。 您也可以使用此工作來執行您選擇的自訂 Go 命令。
使用工作延伸模組擴充發行閘道
發行閘道 會將健康情況訊號資訊直接帶入您的發行管線。 閘道會在部署之前或之後重複收集一組健康情況訊號，以判斷發行是否應該繼續進行下一個階段。 提供一組內建閘道，而且目前已建議使用 [叫用 Azure 函 式] 選項來整合其他服務。
現在，閘道可以採用延伸模組的形式，讓您或延伸模組作者更容易整合新的或自訂服務並設定閘道。
如需詳細資訊，請參閱 撰寫閘道工作 檔。
套件
使用 VSTS 中其他位置的上游 npm 套件
我們會繼續投資上游來源，這可讓您集中處理單一摘要中的所有套件相依性，並保留您所使用之所有套件的已儲存複本。 如果您有多個具有 npm 套件的 VSTS 摘要，現在您可以在相同的 VSTS 帳戶中，將其中一個作為另一個套件的上游來源。 因為 npm 大部分會將您限制為專案設定中的單一摘要/登錄，上游來源可讓您彈性地使用多個 npm 摘要，例如每個小組或產品的一個。
我們也正努力儘快啟用 VSTS NuGet 摘要的上游來源。 如需詳細資訊 ，請參閱上游來源 檔。
使用保留原則維護摘要查詢速度
隨著時間，套件版本數目可能會變得廣泛，舊版未使用。 對於常見套件發行者，除非手動刪除一些版本，否則這可能導致 NuGet 套件管理員和其他用戶端中有速度較慢的摘要查詢。
現在您可以在摘要上啟用保留原則。 符合保留閾值之後，保留原則會自動刪除最舊版本的套件。 提升至檢視的套件會無限期保留，讓您能夠保護用於生產環境或廣泛用於您組織的版本。
若要啟用保留原則，請編輯摘要，並在 [保留原則] 區段的 [Maximum number of versions per package號] \(每個套件的最大版本編) 中輸入值。
Wiki
將 Markdown 檔案從 Git 存放庫發佈為 Wiki
開發人員會在程式碼存放庫中建立「API」、「SDK」和「說明程式碼的說明文件」檔。 接著，讀者必須篩選程式代碼，才能尋找正確的檔。 現在，您只要從程式碼存放庫發佈 Markdown 檔案，並將其裝載在 Wiki 中即可。
從 Wiki 中，從按一下 [ 發佈程式碼為 Wiki] 開始。 接下來，您可以在應該升級的 Git 存放庫中指定資料夾。
按一下 [ 發佈] 之後，選取資料夾下的所有 Markdown 檔案都會發佈為 Wiki。 這也會將分支的前端對應至 Wiki，以便立即反映您對 Git 存放庫所做的任何變更。
如果您有多個版本的產品，而且想要輕鬆地流覽這些版本的檔，您也可以使用不同的分支，將新版本的檔發佈至 Wiki。
一旦發佈 Markdown 檔案，頁面也會在 Wiki 搜尋中樞中搜尋。
如果您發佈錯誤的存放庫，只要取消發佈 Wiki，就會讓基礎存放庫保持不變。
您也可以從存放庫變更頁面的順序，或甚至轉換資料夾，以看起來像 Wiki 頁面。
如需詳細資訊，請參閱 產品檔部落格文章 。 這項功能是根據建議設定優先順序。
在 Wiki 頁面標題中保留特殊字元
您現在可以建立具有特殊字元的 Wiki 頁面，例如 : < > * ? | - 。 現在可以在 Wiki 中建立標題為「常見問題」或「設定指南」的頁面。 下列字元會轉譯為其 UTF-8 編碼字串：
| 字元 | 編碼字串 |
|---|---|
| : | %3A |
| < | %3C |
| > | %3E |
| * | %2A |
| ? | %3F |
| | | %7C |
| - | %2D |
這項功能是根據建議設定優先順序。
使用 REST API 擴充 Wiki
Wiki REST API 現在是公用的。 如需詳細資訊，請參閱 Wiki 函式 和 Wiki 搜尋 檔。
報告
使用檢視整合 Power BI 與 VSTS 分析
分析檢視會使用我們的 VSTS Power BI 資料連線器。 它們可讓您輕鬆地將 VSTS 資料放入 Power BI，以便開始建立自訂報表。
當您安裝 VSTS 分析 延伸模組時，我們會建立一組可在 Power BI 中使用 的預設分析檢視 。 現在您可以編輯預設檢視，並 建立新的檢視 ，以微調傳回至 Power BI 的記錄、欄位和歷程記錄。
後續步驟和意見反應
我們希望聽到您對這些功能的想法。 如果您有想要透過意見反應功能表查看我們優先順序的專案的想法，請回報問題或提供建議。
您也可以在 Stack Overflow上取得社群所回答的建議和問題。
感謝您！
Gopinath Chigakkagari