共用方式為

Team Foundation Server 2017 版本資訊

  • 發行項

開發人員社群 | 系統需求與相容性 | 授權條款 | TFS DevOps 部落格 | SHA-1 雜湊 | | 最新 Visual Studio 2019 版本資訊|

注意

這不是最新版本的 Team Foundation Server。 若要下載最新版本，請瀏覽 Team Foundation Server 2018 Update 3 的最新版本資訊。 若要變更此頁面的語言，請按一下頁尾的地球圖示，然後選取您想要的語言。

本文提供 Team Foundation Server 2017 的相關資訊。 按一下這個按鈕進行下載。

下載 Team Foundation Server 2017

若要深入了解 Team Foundation Server 2017，請參閱 Team Foundation Server 的需求與相容性 (英文) 頁面。

如需詳細資訊，請參閱 TFS 安裝頁面。

版本資訊圖示發行日期：2018 年 2 月 28 日

此更新修正潛在的跨網站指令碼 (XSS) 和其他安全性漏洞。 如需詳細資訊，請參閱部落格文章 \(英文\)。 它是完整升級，因此您可以直接升級至 TFS 2017.0.1。

版本資訊圖示發行日期：2016年11月16日

Team Foundation Server 2017 的新功能摘要

已知問題

Team Foundation Server 2017 的新功能詳細資料

程式碼搜尋

程式碼搜尋提供在所有程式碼中進行快速、靈活且正確的搜尋。 當程式碼基底擴展，並隨多個專案和儲存機制而分割時，尋找所需程式碼就會愈來愈困難。 程式碼搜尋可以快速有效地找出您所有專案的相關資訊，以便將跨小組共同作業與共用程式碼發揮到極致。

從探索 API 實作的範例、瀏覽其定義，到搜尋錯誤文字，程式碼搜尋是能一次解決所有程式碼探索與針對需求進行疑難排解的解決方案 (圖 1)。

程式碼搜尋提供︰

  • 跨一或多個專案的搜尋
  • 語意排名
  • 進階篩選
  • 程式碼共同作業

程式碼搜尋

如需詳細資料，請參閱搜尋所有程式碼 (英文)。

封裝管理

封裝可讓您跨組織共用程式碼︰您可以撰寫大型產品、開發以一般共用架構為基礎的多項產品，或建立及共用可重複使用的元件和程式庫。 套件管理 (圖 2) 藉由裝載您的套件、與您選取的人員共用套件，並讓套件可輕鬆存取 Team Build 和發行管理，來協助程式碼共用。

封裝管理可直接在您的 Team Foundation Server 中裝載 NuGet 封裝，而不需要裝載個別的 NuGet 伺服器或檔案共用。 它具有 NuGet 3.x 的頂級支援，也支援 NuGet 2.x 舊版用戶端。 它可順暢地搭配現有的 TFS 基礎結構、小組和權限，因此不需要進行識別的同步處理、在多個位置管理群組等作業。它也可輕易地與 Team Build 整合，讓您可以在持續整合工作流程中建立和使用封裝。

如需詳細資料，請參閱封裝管理概觀。

封裝管理
(圖 2) 套件管理

敏捷式改善

在 Team Foundation Server 2017 中，我們增加了工作項目和工作流程看板的新功能。

新的工作項目表單

新的工作項目 (圖 3) 表單擁有新的外觀及操作體驗。 它也加入了一些很棒的新功能︰

  • 進階的工作項目討論經驗。
  • 附件的拖放功能支援。
  • 改善的歷程記錄體驗 (History & auditing) (歷程記錄與稽核)。
  • 改善的程式碼和組建整合。
  • 狀態色彩設定。
  • 回應式設計。

注意

新的工作項目表單只是新集合的預設值。 如果您要移轉現有集合，則必須從 [管理設定] 啟用新的工作項目表單。 如需詳細資訊，請參閱 Manage roll out of the new web form (管理新 Web 表單的展示)。

新的 WIT 表單
(圖 3) 新的 WIT 表單

跟進工作項目

您現在只要按一下表單中新的 [跟隨] 按鈕 (圖 4)，即可設定警示來追蹤單一工作項目的變更。 當您追蹤工作項目時，您會隨時收到工作項目變更的通知，包括欄位更新、連結、附件和註解。

新的 WIT 表單
(圖 4) 新的 WIT 表單

如需詳細資料，請參閱跟進工作項目 (英文)。

工作流程看板面板即時更新

工作流程看板現在是即時的了！

您有沒有按下過 F5，看看工作流程看板一天都做了些什麼？ 請試試看以下螢幕擷取畫面 (圖 5) 中的圖示。

工作流程看板即時更新
(圖 5) 工作流程看板即時更新

當小組中的任何人在面板上建立、更新或刪除工作項目時，您會立即收到面板的即時更新。 此外，如果系統管理員進行面板或小組層級的更新，例如新增新的資料行或啟用待辦項目的 Bug，系統會通知您重新整理面板以更新面板的版面配置。 您只需啟用工作流程看板上的塔台圖示，並開始與小組共同作業。

如需詳細資訊，請參閱 Kanban basics (看板基本概念)。

檢查清單改善

檢查清單的運作方式有許多的改善。

檢查清單項目現在會顯示為超連結 (圖 6)。 您可以按一下項目來開啟工作項目表單。

檢查清單改善
(圖 6) 檢查清單超連結

檢查清單現在也支援操作功能表，讓您開啟、編輯或刪除檢查清單項目 (圖 7)。

檢查清單操作功能表
(圖 7) 檢查清單快顯功能表

如需詳細資訊，請參閱 Add task checklists (新增工作檢查清單)。

Epic 和功能面板向下鑽研

您現在可以在 Epic 和功能面板上向下鑽研 (圖 8)。 檢查清單格式可讓您輕鬆將工作標示為已完成，並提供已完成與未完成工作的可用鳥瞰檢視。

Epic 功能向下鑽研
(圖 8) Epic 功能向下鑽研

如需詳細資訊，請參閱 Kanban features and epics (看板功能和 Epics)。

開啟/關閉面板註釋

我們讓您能進一步控制面板卡片顯示的其他資訊。 您現在可以選取想要在工作流程看板卡上檢視的註釋 (圖 9)。 只要取消選取某項註釋，它就不會再出現於工作流程看板上。 這裡顯示的前兩項註釋是子工作項目 (本範例中的工作) 和測試註釋。

開啟/關閉面板批注
(圖 9) 開啟/關閉面板註釋

如需詳細資訊，請參閱 Customize Cards (自訂卡片)。

清除格式設定命令

工作項目的所有 RTF 文字控制項都新增了新的命令，可讓您清除選取文字的所有格式。 如果您和大多數使用者一樣，以前可能也在這個無法復原 (或清除) 的欄位中複製並貼上格式化文字，搞得焦頭爛額。 現在只要醒目提示任何文字、選取 [清除格式設定] 工具列按鈕 (或按 CTRL+空格鍵)，就會看到文字回復到預設格式。

工作流程看板中的篩選

請針對使用者、反覆項目、工作項目類型和標記設定篩選條件，個人化您的工作流程看板 (圖 10)。 這些篩選條件會保留，以便您即使從多個裝置連線時，也可以檢視個人化的面板。

工作流程看板中的篩選
(圖 10) 工作流程看板中的篩選

小組成員也可以篩選其面板，以檢視分配到特定父工作項目的進度。 例如，使用者可以檢視連結至特定功能的使用者劇本，或是跨兩個或多個彙總至 Epic 的功能檢視工作。 這項功能 (如同檢查清單) 是我們為不同的待處理項目層級提供可見性所做的努力。

如需詳細資訊，請參閱 Filter Kanban board (篩選工作流程看板)。

新工作項目的預設反覆項目路徑

當您從 [查詢] 索引標籤或 [新增工作項目] 儀表板 Widget 建立新的工作項目時，該工作項目的反覆項目路徑一律會設為目前的反覆項目。 並非所有的小組都希望這樣，因為這表示 Bug 可能會立即出現在工作面板上。 使用這項改善，小組可以選擇應用於新工作項目的預設反覆項目路徑 (特定的或目前的反覆項目)。 瀏覽至您小組的系統管理區域，選擇預設的反覆項目。

如需詳細資訊，請參閱 Customize area and iteration paths (自訂區域和反覆項目路徑) 頁面。

核取方塊控制項

您現在可以在工作項目中新增核取方塊控制項 (圖 11)。 這個新的欄位類型 (布林值) 具有一般欄位的所有屬性，並可新增至流程的任何類型中。 當顯示在卡片或查詢結果中時，此值會顯示為 True/False。

核取方塊控制項
(圖 11) 核取方塊控制項

如需詳細資訊，請參閱 Customize a field (自訂欄位)。

大量編輯標籤

您現在可以使用大量編輯對話方塊，從多個工作項目新增和移除標記 (圖 12)。

大量編輯對話框
(圖 12) 大量編輯對話方塊

如需詳細資訊，請參閱 Add tags to work items (將標記加入工作項目)。

新的擴充點

我們已在面板和待辦項目頁面上新增新的貢獻點，以允許您將延伸模組撰寫為面板/待辦項目/產能索引標籤旁邊的樞紐分析索引標籤。

我們已公開推出新的擴充點。 延伸模組可以在右側將窗格作為目標，即現在對應和工作詳細資料所在的位置 (圖 13)。

待辦項目擴充點
(圖 13) 待辦項目擴充點

電子郵件改善

我們大幅改善了由 TFS 所傳送的工作項目警示、追蹤及 @mention 電子郵件的格式設定與可用性 (圖 14)。 電子郵件現在包含一致的標頭、清楚的動作呼叫和改善的格式，以確保郵件中的資訊更易於使用和了解。 此外，所有這些電子郵件的設計都是為確保它們能在行動裝置中完好呈現。

電子郵件改善
(圖 14) 電子郵件改善

如需詳細資訊，請參閱 Work item alerts (工作項目警示)。

工作項目範本

新增了可將豐富的工作項目範本直接建立至原生 Web 體驗的功能 (圖 15)。 這項功能先前在 Web 中極度受限，且僅能透過 Visual Studio 的強大工具以此新形式使用。 小組現在可以建立並管理一組範本，快速修改一般欄位。

工作項目範本
(圖 15) 工作項目範本

如需詳細資訊，請參閱 Work item templates (工作項目範本)。

不再支援 Project Server 整合

Team Foundation Server 2017 和更新版本不再支援 Project Server 整合。 自 RC2 起，如果您升級的 TFS 資料庫已設定 Project Server 整合，您會收到下列警告：

偵測到此資料庫已設定 Project Server 整合。 Team Foundation Server 2017 和更新版本不再支援 Project Server 整合。

升級後，Project Server 整合將不再運作。

接下來，將倚賴合作夥伴提供整合解決方案。

如需有關這項變更的詳細資訊，請參閱下列主題︰同步處理 TFS 與 Project Server。

儀表板和 Widget 改善

Team Foundation Server 2017 已在多個 Widget 上進行了改善，例如查詢磚 Widget 和提取要求 Widget。

重新設計的小工具目錄

我們已經重新設計小工具目錄來容納不斷成長的小工具集合，並提供更好的整體體驗 (圖 16)。 新的設計包括改進的搜尋體驗，並已重新設定樣式，使符合 Widget 組態面板的設計。

Widget 目錄
(圖 16) Widget 目錄

如需詳細資訊，請參閱 Widget Catalog (Widget 目錄)。

小工具更新

查詢磚小工具現在支援最多 10 個條件式規則，並且可以選取色彩 (圖 17)。 當您想要使用這些磚當作關鍵效能指標 (KPI) 來識別健康狀態及/或可能需要的動作時，這十分方便。

儀表板更新
(圖 17) 儀表板更新

提取要求 Widget 現在可以支援多種大小，讓使用者控制 Widget 的高度。 我們正努力讓大部分的小工具都能調整大小，詳情請看這裡。

新增工作項目小工具現在可讓您選取預設的工作項目類型，不會強迫您選取從下拉式清單中重複建立的最常見類型。

WIT 圖表小工具已可調整大小。 這可讓使用者在儀表板上看到任何 WIT 圖表的展開檢視，無論其原始大小為何。

小組成員小工具已更新，更容易為小組新增成員 (圖 18)。

Widget 更新
(圖 18) Widget 更新

小組現在可以設定儀表板「查詢結果」Widget 的大小，讓它可以顯示更多結果。

短期衝刺概觀小工具經過重新設計，讓小組方便查看其是否正常運行。

[指派給我] 小工具協助使用者管理受到指派的工作，而無須離開儀表板內容 (圖 19)。 藉由提供專門用於此用途的 widget，小組系統管理員可以將此功能新增至 16 較少的按下其儀表板、 沒有內容切換和需要任何輸入。 使用者現在可以在小工具內容中檢視、排序、篩選及管理受到指派的工作。

指派給我
(圖 19) 指派給我

儀表板 REST API

您現在可以使用 REST API 以程式設計方式在儀表板上新增、刪除和取得資訊。 API 也可讓您在 Widget 或儀表板上的 Widget 清單中新增、移除、更新、取代和取得資訊。 文件位於 Visual Studio 線上文件。

允許的儀表板

非系統管理員的使用者現在可以建立和管理小組儀表板。 小組系統管理員可以透過儀表板管理員限制非系統管理員權限。

如需詳細資訊，請參閱 Dashboards (儀表板)。

Git 改善

Team Foundation Server 2017 已對 Git 進行一些重大變更。 包括重新設計 [分支] 頁面和「壓縮合併」的新選項。

重新設計的 [分支] 頁面

[分支] 頁面已完全重新設計。 它有「我的」樞紐，顯示您建立、推送或加入最愛的分支 (圖 20)。 每個分支都會顯示其組建和提取要求的狀態，以及類似 [刪除] 的其他命令。 如果分支名稱中有斜線，如 "features/jeremy/fix-bug"，就會顯示為樹狀結構，以輕鬆瀏覽大型的分支清單。 如果您知道分支名稱，就可以快速搜尋找到您想要的分支。

重新設計的 [分支] 頁面
(圖 20) 重新設計的分支頁面

如需分支的詳細資訊，請參閱 Manage branches (管理分支)。

新的提取要求體驗

提取要求體驗在此版本中有一些重大更新，引入一些功能非常強大的 Diff 功能、全新的註解體驗，以及煥然一新的 UI。

如需詳細資訊，請參閱 Review code with Pull Requests (使用提取要求檢閱程式碼)。

重新設計的 UI

開啟提取要求時，馬上就能體會到新的外觀及感受 (圖 21)。 標頭已重新整理過，以彙總所有重大狀態和動作，如此便可在體驗中的每個檢視加以存取。

提取要求標頭
(圖 21) 提取要求標頭
概觀

概觀現在會將提取要求描述反白顯示，讓您比以往更加輕鬆地提供意見反應 (圖 22)。 最上層會連同最新項目顯示事件和註解，讓檢閱者得以查看極為重要的最新變更和註解。 詳盡提供原則、工作項目以及檢閱者，並加以重新整理，變得更清楚精確。

提取要求概觀
(圖 22) 提取要求概觀
Files

此版本中最重大的新功能是能夠查看對提取要求所做的先前更新 (圖 23)。 在先前的預覽中，我們發行了能夠正確追蹤提取要求進行變更更新時的註解。 不過，您不一定能夠輕鬆查看更新之間的項目。 現今在 [檔案] 檢視中，您可以查看每當新的程式碼推送至提取要求時的完整變更項目。 在您對一些程式碼提供意見反應，並想完整查看其變更方式時而不受到檢閱中所有其他變更的干擾時，便相當實用。

提取要求檔案
(圖 23) 提取要求檔案
更新

新的 [更新] 檢視會顯示 PR 隨著時間變更的方式 (圖 24)。 [檔案] 檢視顯示檔案隨著時間變更的方式，而 [更新] 檢視顯示每個更新中新增的認可。 如果發生強制推送時，[更新] 檢視會繼續顯示在歷程記錄中發生的過去更新。

提取要求更新
(圖 24) 提取要求更新
註解，現在可搭配 Markdown 和 Emoji

在所有討論中發揮 Markdown 的完整威力，包括格式化、語法反白顯示的編碼、連結、影像及 Emoji (圖 25)。 註解控制項的編輯體驗也讓使用者更容易上手，可一次編輯 (及儲存) 多個註解。

提取要求批注
(圖 25) 提取要求註解
在提取要求中新增及移除檢閱者

現在從提取要求中新增和移除檢閱者更為容易。 若要將檢閱者或群組加入您的提取要求中，只要將其名稱輸入 [檢閱者] 區段中的 [搜尋] 方塊即可。 若要移除檢閱者，在 [檢閱者] 區段中將滑鼠停留在其磚上，並按一下 X 即可移除 (圖 26)。

在提取要求中新增檢閱者
(圖 26) 在提取要求中新增檢閱者
改善的組建和提取要求追蹤

組建和提取要求之間的追蹤已經改善，讓您輕鬆地從 PR 瀏覽至組建再返回。 在提取要求觸發之組建的組建詳細資料檢視中，來源現在會顯示之前佇列組建的提取要求連結。 在 [組建定義] 檢視中，任何由提取要求觸發的組建都會在「觸發者」資料行中提供提取要求連結。 最後，[Build 總管] 檢視會在來源資料行中列出提取要求。

提取要求的註解追蹤

已改進 VSTS 中的提取要求，以在適當的列上顯示檔案中留下的註解，即使那些檔案在新增該註解後已經變更。 在之前，註解一律會在檔案中原始新增註解的那一行上顯示，即使檔案內容已變更。換句話說，第 10 行上的註解一律會在第 10 行上顯示。 透過最新的改善功能，註解會隨程式碼顯示使用者預期的內容。如果在第 10 行上新增註解，且後續又在檔案的開頭新增了兩個新行，則該註解將會顯示在第 12 行上。

下列為在第 13 行上新增註解的變更範例 (圖 27)：

批注追蹤
(圖 27) 註解追蹤

即使在程式碼已變更為將包含原始註解的行從第 13 行轉換至第 14 行，註解仍顯示在預期的位置 (第 14 行) (圖 28)。

具有變更的批注追蹤
(圖 28) 對於變更的註解追蹤
自動完成等候原則的提取要求

使用分支原則保護其分支的小組可以試用自動完成動作。 很多時候，提取要求的作者已就緒合併其 PR，但必須等待組建完成後，才能按一下 [完成]。 而其他時候，組建已通過，但是尚有一位檢閱者未提供最終核准。 在這些情況下，作者可透過自動完成的動作將提取要求設為在所有原則皆核准時自動完成 (圖 29)。

自動完成
(圖 29) 自動完成

如同手動完成動作，作者有機會自訂合併認可的訊息，並選取適當的合併選項 (圖 30)。

Autodialog
(圖 30) 自動對話方塊

設定自動完成後，提取要求會顯示橫幅，確認自動完成已設定並等待原則完成 (圖 31)。

自動完成確認
(圖 31) 自動完成確認

符合所有原則時 (例如組建已完成，或已授與最終核准時)，便會使用指定的選項和註解合併 PR。 如預期般，如果發生組建失敗或檢閱者未核准，PR 會維持作用中，直到通過原則為止。

Squash 合併提取要求

現在當您完成提取要求時，可以選擇 Squash 合併 (圖 32)。 這個新的選項會產生單一認可，其中包含要套用到目標分支的主題分支變更。 一般合併和 Squash 合併之間最顯著的差異，是 Squash 合併認可只會有一個父認可。 這表示更簡單的歷程記錄圖，因為在產生的認可圖形中無法連接到對主題分支所做的任何中繼認可。

Squash 合併提取要求
(圖 32) Squash 合併提取要求

您可以在 Squash merge pull requests (壓縮合併提取要求) 找到詳細資訊。

認可追蹤

組建狀態 (成功或失敗) 現在會清楚地顯示在 [程式碼總管] 和 [認可詳細資料] 檢視中 (圖 33)。 只要按一下即可取得詳細資料，好讓您持續掌握認可的變更是否通過組建。 您也可以在組建定義的儲存機制選項中自訂哪些組建會發佈狀態。 此外，[認可詳細資料] 檢視中的最新變更會有關於變更的更深入資訊。 如果使用提取要求來合併變更，您會看到將變更導入主分支的提取要求連結 (若為合併認可則是建立認可的 PR)。 當變更到達主分支時，分支連結會出現以確認是否包含變更。

認可追蹤
(圖 33) 認可追蹤

檢視 Web 中的 Git LFS 檔案

如果您已經在使用 Git 中的大型檔案 (音訊、視訊、資料集等)，您就會知道 Git 大型檔案儲存體 (LFS) 是用 Git 內的指標來取代這些檔案，同時將檔案內容儲存在遠端伺服器中。 這可讓您透過按一下儲存機制中的檔案，來檢視這些大型檔案的完整內容。

如需詳細資訊，請參閱 Manage large files with Git (使用 Git 管理大型檔案)。

輕鬆地使用程式碼連結來共用程式碼參考 (圖 34)。 只要選取檔案中的文字並按一下連結圖示即可。 它會將連結複製到選取的程式碼。 當有人檢視該連結時，您醒目提示的程式碼就會顯示金色的背景。 選取部分行也有用。

傳送程式碼連結
(圖 34) 傳送程式碼連結

狀態 API

組建成功或失敗現在會清楚地顯示在 [程式碼總管] 和 [認可詳細資料] 檢視中 (圖 35)。 只要按一下即可取得詳細資料，好讓您持續掌握認可的變更是否通過組建。 您也可以在組建定義的儲存機制選項中自訂哪些組建會發佈組建狀態。

狀態 API
(圖 35) 狀態 API

檔案類型圖示

您會在總管、提取要求、認可詳細資料、擱置集、變更集或任何其他顯示檔案清單的檢視中，看到符合檔案副檔名的新檔案圖示 (圖 36)。

檔類型範例
(圖 36) 檔案類型範例

在建立存放庫期間新增讀我檔案

已改進新的 Git 存放庫建立方式，讓使用者能新增讀我檔案 (圖 37)。 將讀我檔案新增至儲存機制不僅能協助其他人了解程式碼基底的用途，也可讓您立即複製儲存機制。

新增自述檔
(圖 37) 新增讀我檔案

組建改善

我們在本版中增加記錄檔大小、新增 Java 組建範本，並且改善了 Xamarin 支援，以命名一些變更。

重新設計的 [組建佇列] 索引標籤

已實作 [已佇列組建] 頁面的新設計，並顯示較長的已佇列及執行中組建清單，更加直接好用 (圖 38)。

[組建佇列] 索引標籤
(圖 38) [組建佇列] 索引標籤

如需詳細資訊，請參閱 Administer your build system (管理建置系統)。

啟用組建結果擴充功能以指定順序和資料行

組建結果區段延伸模組現在可以指定要顯示的資料行和出現順序 (圖 39)。 結果檢視有兩個資料行，而所有的延伸模組預設位於第一個資料行中。 注意︰所有的協力廠商擴充功能都會出現在我們加入的組建結果區段之後。

組建順序和資料行
(圖 39) 組建順序和資料行

行號的組建

現在您可以從組建錯誤跳到造成錯誤的程式碼行。 請看我們在內部作為提取要求原則之主要組建的最新錯誤，您就會看到 (圖 40)︰

行號的組建
(圖 40) 組建至行號

組建記錄檔檢視支援更大的記錄檔

舊版的記錄檔檢視最多只支援 10,000 行的記錄檔。 新的檢視器是以 VS 程式碼中使用的摩納哥編輯器為基礎，最多可支援 150,000 行的記錄檔。

Java 組建範本

我們甚至新增 Ant、Maven 和 Gradle 的組建範本，讓 Java 開發人員能更輕鬆地開始建立組建 (圖 41)。

Java 組建範本
(圖 41) Java 組建範本

如需範本的詳細資訊，請參閱 Build steps (建置步驟)。

Xamarin 組建工作

我們對 Xamarin 支援進行了一些重大改善︰

  • Xamarin.Android 步驟現在支援 Mac 和 Linux。
  • Xamarin.iOS 步驟現在支援簽署和封裝。
  • Xamarin Test Cloud結果可以顯示在組建摘要頁面。
  • 新的 Xamarin component restore (Xamarin 元件還原) 步驟。
  • NuGet Installer (NuGet 安裝程式) 步驟現在支援 Mac OS。

已不再需要 Xamarin 授權步驟，並已從建置範本移除。 我們將會淘汰工作，作為這項作業的一部分。 所有使用此工作的組建定義都應更新為移除該工作，以免在最終移除該工作時造成中斷。

最後，我們已增強 Xamarin 組建定義範本，以使用這些新的工作。 Build your Xamarin app (組建 Xamarin 應用程式)。

針對組建和發行管理的 Docker 整合

善用組建功能來建置您的 Docker 映像，並上傳至 Docker 中樞作為連續整合流程的一部分 (圖 42)。 接著，將這些映像部署至數部 Docker 主機，作為 Release Management 的一部分。 Marketplace 擴充功能加入了使用 Docker 所需的所有服務端點類型和工作。

Docker 映像
(圖 42) Docker 映像

SonarQube 導致提取要求檢視

如果為合併提取要求所執行的組建包含 SonarQube MSBuild 工作，您現在會看到新的程式碼分析問題顯示為提取要求中的討論註解 (圖 43)。 凡將外掛程式安裝在 SonarQube 伺服器的所有語言都會經歷這項體驗。 如需詳細資訊，請參閱 SonarQube Code Analysis issues integration into Pull Requests (將 SonarQube 程式碼分析問題整合至提取要求) 部落格文章。

SonarQube 提取要求
(圖 43) SonarQube 提取要求

組態狀態 API 報告組建定義

您現在可以選擇哪些組建定義向 Git 狀態 API 回報其狀態。 如果您有多項定義組建指定的儲存機制或分支，但只有一項代表實際的健康狀態，這特別有用。

如需詳細資訊，請參閱 Build REST API reference (組建 REST API 參考)。

小組室中的組建 vNext 支援

XAML 組建的通知一向可以在小組聊天室中新增。 透過這個短期衝刺，使用者也可以收到組建 vNext 完成的通知。

啟用 Git CI 觸發程序的路徑篩選器

裝載的 Git 儲存機制的 CI 觸發程序可以包含或排除特定的路徑。 這可讓您設定組建定義，僅在特定路徑中的檔案變更時才執行 (圖 44)。

Git CI 觸發程序
(圖 44) Git CI 觸發程序

發行管理改善

自從 Team Foundation Server 2015 引進整合式網頁型發行管理之後，我們已在這個版本中加入了許多改進功能。

複製、匯出和匯入發行定義

我們已在發行中樞內納入複製、匯出和匯入發行定義的功能，而不需要安裝延伸模組 (圖 45)。

[發行摘要] 頁面上的複製和匯出命令
(圖 45) [發行摘要] 頁面上的複製和匯出命令

如需詳細資訊，請參閱 Clone, export, and import a release definition(複製、匯出和匯入發行定義) 文件。

測試結果會顯示於發行摘要中

在發行摘要頁面中，我們已啟用外部服務的貢獻點，以顯示環境特定資訊。

在 Team Services 中，當測試作為發行環境的一部分執行時，此功能可用於顯示測試結果的摘要 (圖 46)。

測試結果會顯示於發行摘要中
(圖 46) 發行摘要中顯示的測試結果

如需詳細資訊，請參閱 Understand the summary view of a release (了解發行的摘要檢視) 文件。

將 OAuth 權杖傳遞至指令碼

如果您需要執行自訂 PowerShell 指令碼，以在 Team Services 上叫用 REST API (可能是為了建立工作項目或查詢組建中的資訊)，您需要在指令碼中傳遞 OAuth 權杖。

當您設定環境時，此新選項可將指令碼作為環境中的工作來執行，以存取目前的 OAuth 權杖 (圖 47)。

將 OAuth 權杖傳遞至指令碼
(圖 47) 將 OAuth 權杖傳遞至指令碼

如需詳細資訊，請參閱 Environment general options (環境的一般選項) 文件。

這是一個簡單的範例，示範如何取得組建定義 (圖 48)：

使用所傳遞之 oAuth 權杖的範例指令碼
(圖 48) 使用所傳遞 oAuth 權杖的範例指令碼

部分成功部署上的觸發程序

建置與發行工作在每個工作的 [控制選項] 參數中，具有於 [發生錯誤時繼續] 的選項。

在組建定義中，如果有工作已設定此選項並且失敗，將會導致「組建已部分成功」的結果。

發行定義中目前已提供相同的行為。 如果工作失敗，整體發行結果會顯示為「發行已部分成功」(圖 49)。

發行摘要會以橙色顯示部分成功的發行
(圖 49) 發行摘要會以橙色顯示部分成功的版本

根據預設，部分成功的發行不會自動觸發針對後續環境的發行，即使此行為已在環境部署選項中指定。

不過，有一個新的選項可以在每個發行環境中設定，以在先前的發行為部分成功的情況下，指示發行管理觸發針對後續環境的發行 (圖 50)。

設定選項以從部分成功的發行進行觸發
(圖 50) 設定選項以從部分成功的版本進行觸發

如需詳細資訊，請參閱 Environment deployment triggers (環境的部署觸發程序) 文件。

直接使用儲存在 GitHub 中的成品

有時候，您可能會想要在不經過建置程序的情況下，直接使用儲存在版本控制系統中的成品，如本主題中所述。

現在，如果您的程式碼儲存在 GitHub 存放庫中，您也可以這麼做 (圖 51)。

將 GutHub 儲存機制中的程式碼連結至發行定義
(圖 51) 將 GutHub 存放庫中的程式碼連結至版本定義

如需詳細資訊，請參閱 TFVC, Git, and GitHub sources (TFVC、Git 和 GitHub 來源) 文件。

使用 ARM 的 Web 應用程式部署

Azure Web 應用程式部署工作有新的版本可用，稱為 AzureRM Web 應用程式部署。

它使用 MSDeploy 和 Azure Resource Manager 服務端點連線。 除了 ASP.NET 4、Node 和 Python Web 應用程式之外，使用此工作可部署 Azure Web 工作和 Azure API 應用程式。

此工作也支援常見的發佈選項，例如保留應用程式資料、將應用程式離線及移除目的端其他檔案的能力。

未來版本可能會出現更多功能，例如組態轉換 (圖 52)。

使用 ARM 的 Web 應用程式部署
(圖 52) 使用 ARM 的 Web 應用程式部署

工作群組

「工作群組」 可讓您將組建或發行定義中已定義的工作序列，封裝成可重複使用的單一工作，以便如同任何其他工作一樣新增至組建或發行定義 (圖 53)。

您可以選擇從封裝式工作擷取參數作為組態變數，並摘要其餘的工作資訊。

新的工作群組會自動加入工作目錄，以準備加入其他發行和組建定義。

使用工作組將 GutHub 存放庫中的程式代碼連結至發行定義
(圖 53) 將 GutHub 存放庫中的程式碼連結至版本定義

如需詳細資訊，請參閱 Task Groups (工作群組) 文件。

發行的虛刪除

當您刪除某個發行或由保留原則自動刪除時，該發行會從 [概觀] 和 [詳細資料] 清單中移除。

不過，它會隨發行定義保留一段期間 (通常是 14 天)，再永久刪除。

在這段期間，它會顯示在 [概觀] 和 [詳細資料] 清單的 [已刪除] 索引標籤中。

您可以開啟捷徑功能表並選擇 [取消刪除]，以還原任何版本 (圖 54)。

取消刪除版本
(圖 54) 取消刪除發行

如需詳細資訊，請參閱 Restore deleted releases (還原已刪除的發行) 文件。

保留每個環境的發行和組建

發行定義的發行保留原則會決定發行及連結組建的保留時間。

根據預設，發行會保留 60 天。 在這段期間尚未部署或修改的發行將會自動予以刪除。

不過，您可能想要保留已部署至特定環境 (例如生產環境) 的多個發行，或將這些發行保留得比部署至其他環境 (例如測試、預備和 QA) 的發行更久。

如果您需要重新部署該發行，也可以在保留發行的期間，保留連結至發行的組建，以確保成品可供使用 (圖 55)。

保留版本
(圖 55) 保留發行

如需詳細資訊，請參閱 Release and build retention (發行和組建保留) 文件。

連結成品改善

您可以透過兩項新功能，輕鬆地使用成品和成品來源：

  • 您可以將多個成品來源連結至發行定義 (圖 56)。 每個成品都會下載至代理程式上的資料夾，稱為來源別名。 您現在可以編輯連結成品的來源別名。 例如，當您變更組建定義的名稱時，您可以編輯來源別名，以反映組建定義的名稱。
連結成品改善
(圖 56) 連結成品改善
如需詳細資訊，請參閱 [成品來源別名](/vsts/pipelines/release/artifacts?preserve-view=true&view=vsts#source-alias) 文件。
  • 工作參數中會公開使用格式為 Build.* 的一些變數 (例如 Build.BuildId and Build.BuildNumber)。 如果有多個來源與某個發行建立關聯，這些變數現在會填入指定為主要來源之成品來源中的值。 如需詳細資訊，請參閱 Artifact variables (成品變數) 文件。

部署 - 手動操作工作

您現在可以在環境部署期間暫停執行。

在環境中加入手動操作工作可讓您暫時停止部署、執行手動步驟，再繼續進行其他自動化步驟。

您也可以拒絕部署，以防止在手動操作之後執行其他步驟 (圖 57)。

手動介入工作
(圖 57) 手動操作工作

如需詳細資訊，請參閱 Manual intervention (手動操作) 文件。

SQL Database 部署工作指令碼

Azure SQL Database 部署 (圖 58) 工作已經增強，現在可對 Azure SQL Database 執行 SQL 指令碼。 指令碼可以檔案形式提供，或內嵌在工作中。

SQL Database 部署工作指令碼
(圖 58) SQL Database 部署工作指令碼

發行定義摘要 - 儀表板 Widget

將發行定義釘選到儀表板 - 一個讓全部的小組成員都能看到該定義發行摘要的簡易方式。

如需詳細資訊，請參閱 Add release information to the dashboard (將發行資訊新增至儀表板) 文件。

於指定的時間針對特定環境宣傳發行

想要讓所有的生產環境部署都在午夜發生嗎？ 您可以在某個環境上設定條件，以從另一個環境選取一項成功的部署 (或是最新的部署)，並在指定的時間部署它 (圖 59)。

針對特定環境排定發行
(圖 59) 針對特定環境排定發行

根據多個環境中的條件進行部署

在先前的版本中，您可以執行平行部署 (「分岔部署」)，但是您無法根據多個環境的狀態對某個環境開始進行部署 (「聯結部署」)。 現在您可以這麼做了。

如需詳細資訊，請參閱 Parallel forked and joined deployments (已平行分叉部署和已連結部署) 文件。

適用於發行管理的 REST API

您可以使用適用於發行管理服務的 REST API 來建立發行定義和發行，以及管理部署發行的各個層面。

如需詳細資訊，請參閱 API 參考文件。

服務勾點整合

在建立新發行、開始或完成部署，或是暫止或完成核准時傳送發行通知。 整合協力廠商工具 (例如 Slack) 以接收這類通知。

Azure 國家/地區雲端部署

使用 Azure 傳統服務端點中以特定 Azure 雲端為目標的新 [環境] 設定，包括預先定義的國家/地區雲端，例如 Azure 中國雲端、Azure 美國政府雲端和 Azure 德國雲端。

如需詳細資訊，請參閱 Azure Classic service endpoint (Azure 傳統服務端點) 文件。

測試改善

Team Foundation Server 2017 中已加入索引鍵的測試改善。

已更新測試結果儲存體結構描述

我們在本版中要將測試結果成品移轉至精簡而有效率的新儲存體結構描述。 由於測試結果是 TFS 資料庫儲存空間首要取用者的其中之一，我們希望這項功能可以轉譯成 TFS 資料庫已減少的儲存體使用量。 若為從舊版 TFS 升級的客戶，測試結果會在 TFS 升級期間移轉至新的結構描述。 這項升級作業可能耗用相當長的時間，視資料庫有多少測試結果資料而定。 建議設定測試保留原則 (英文)，等候原則開始運作並減少測試結果使用的儲存體，以利縮短 TFS 升級時間。 在安裝 TFS 後，但在升級 TFS 執行個體之前，可以使用 TFSConfig.exe 工具來清除測試結果。 請參閱 TFSConfig.exe 說明以取得詳細資料。 如果您在升級之前沒有設定測試保留期或清除測試結果的彈性，請確定您已針對升級時機做出適當的規劃。 如需更多的設定測試保留原則範例，請參閱使用 Team Foundation Server 2015 測試結果資料保留 (英文)。

測試中樞改善

在測試中樞測試組態管理

我們也在測試中樞內新增 [組態] 索引標籤，為 Web UI 帶來測試組態管理 (圖 61)。 現在您可以從測試中樞內建立和管理測試組態及測試組態變數。

組態中樞
(圖 61) 設定中樞

如需詳細資訊，請參閱 Create configurations and configuration variables (建立組態和組態變數)。

將組態指派給測試計劃、測試套件和測試案例

指派組態變得更容易了。 您可以直接在測試中樞內將測試組態指派給測試計劃、測試套件或測試案例 (圖 62)。 以滑鼠右鍵按一下項目，然後選取 [Assign configurations to …] (將組態指派給...)，即開始執行。 您也可以在測試中樞內依組態篩選 (圖 63)。

指派組態
(圖 62) 指派設定
組態篩選
(圖 63) 設定篩選

如需詳細資訊，請參閱 Assign configurations to Test plans and Test suites (將組態指派給測試計劃和測試套件)。

在 [測試結果] 窗格中檢視測試計劃/測試套件資料行

我們已在 [測試結果] 窗格中新增新的資料行，向您顯示在其下執行測試結果的測試計劃和測試套件。 這些資料行會在深入探索測試結果時，提供更多的內容 (圖 64)。

顯示結果窗格
(圖 64) 測試結果窗格
排序測試中樞和卡片上的測試

您現在可以從測試中樞 (圖 65) 內排序手動測試，無論其所在套件類型為何︰靜態的、需求型或查詢式套件。 只要拖放一或多個測試或使用內容功能表，即可重新排序測試。 完成排序時，您可以依 [順序] 欄位排序測試，然後從 Web 執行器中依序執行。 也可以直接在工作流程看板上的使用者劇本卡片上排序測試 (圖 66)。

排序測試
(圖 65) 排序測試
訂購卡片上的測試
(圖 66) 卡片上的排序測試
在測試中樞中排序測試套件

測試小組現在可以根據需求排序測試套件。 在此功能推出之前，套件僅能依字母順序排序。 現在，透過使用測試中樞中的拖放功能，使用者可以在對等套件之間重新排序套件，或是將套件移至階層中的另一個套件 (圖 67)。

排序測試套件
(圖 67) 排序測試套件
作為指派測試人員的一部分搜尋使用者

作為在不同中樞推出全新身分識別選取器控制項的一部分，我們在測試中樞中也啟用了在指派一或多個測試的測試人員時搜尋使用者的選項 圖 68)(。 這在小組成員數目龐大時特別有用，但操作功能表只會顯示有限的項目 *(圖 69)。

搜尋使用者
(圖 68) 搜尋使用者
指派使用者
(圖 69) 指派使用者
挑選要測試的組建

您現在可以在測試中樞 (圖 70) 中使用 [以選項執行]，選擇您想要測試的「組建」並啟動 Web 執行器。 執行期間所提報的任何 Bug，會自動與選取的組建建立關聯。 此外，系統會針對該特定組建發佈測試結果。

挑選組建
(圖 70) 挑選組建
從測試中樞使用資料收集器啟動 Microsoft 測試執行器用戶端

您現在可以選擇要與測試回合 (圖 71) 建立關聯的資料收集器與組建，並從測試中樞以具效能的方式啟動 Microsoft 測試執行器 2017 (用戶端)，而不用在 Microsoft Test Manager 用戶端中針對它們加以設定。 Microsoft 測試執行器會在不需開啟整個 Microsoft Test Manager 殼層的情況下啟動，且會在測試執行完成時關閉。

以選項執行
(圖 71) 以選項執行

如需詳細資訊，請參閱 Run tests for dektop apps (針對傳統應用程式執行測試)。

選擇資料收集器並從測試中樞啟動 Exploratory Runner 用戶端

您現在可以選擇資料收集器，並從測試中樞以具效能的方式啟動 Exploratory Runner 2017 (用戶端)，而不用在 Microsoft Test Manager 用戶端中針對它們加以設定。 從操作功能表 (圖 72) 為需求式套件叫用 [以選項執行]，然後選擇 Exploratory Runner 以及您所需的資料收集器。 Exploratory Runner 將以上方所述類似 Microsoft 測試執行器的方式啟動。

以選項執行 - XT
(圖 72) 以選項執行 - XT
跨不同測試套件為測試設定測試結果

現已新增可在相同測試計劃下為不同測試套件共用的測試設定測試結果的行為 (圖 73)。 若選取此選項並設定測試的結果 (從測試中樞、Web 執行程式，Microsoft 測試執行器，或工作流程看板上的卡片，將其標示為通過/失敗/已封鎖)，該結果會以相同的組態，在相同測試計劃下跨不同測試套件傳播到所有存在的其他測試。 使用者可從測試中樞測試計劃操作功能表，或從 [常見設定組態] 對話方塊中的工作流程看板測試頁面，設定特定測試計劃的 [設定測試結果] 選項。 預設會關閉此選項，您必須明確加以啟用才會生效。

設定測試結果
(圖 73) 設定測試結果
驗證工作項目中的 Bug

您現在可以重新執行識別 Bug 的測試來驗證 Bug (圖 74)。 您可以從 Bug 工作項目表單操作功能表叫用 [驗證] 選項，以啟動 Web 執行器中的相關測試案例。 請使用 Web 執行器執行驗證，並在 Web 執行器內直接更新 Bug 工作項目。

確認 Bug
(圖 74) 驗證 Bug
用於測試計劃/測試套件複製的 REST API

我們已新增 REST API 以複製測試計劃和測試套件。 您可以在 Team Services 整合網站的 [測試管理] 區段下找到它們。

從工作流程看板卡測試進度

您現在可以直接從工作流程看板上的劇本新增、檢視測試案例，並與之互動。 使用新的 [新增測試] 功能表選項來建立連結的測試案例，然後直接從作為項目進度的卡片監視狀態 (圖 75)。

內嵌測試
(圖 75) 內嵌測試

使用這項新功能，您現在可以直接在面板卡上執行下列動作︰

  • 加入測試。
  • 開啟測試。
  • 在使用者劇本之間拖放測試以重設測試。
  • 使用 CTRL+拖放，將相同的測試複製到另一個使用者劇本 (適用於以同一測試案例測試多個使用者劇本的案例)。
  • 快速標示通過/失敗/等等，以更新測試狀態。
  • 在 Web 測試執行器中啟動測試來執行測試，在此可以通過或失敗個別步驟、報告 Bug 等等。
  • 檢視指出該劇本通過多少測試及保留多少測試的彙總狀態摘要。

如果您需要進階的測試管理功能 (如指派測試人員、指派組態、集中化參數、匯出測試結果等等)，您可以再切換至測試中樞，開始使用已自動為您建立的預設測試計劃/需求式套件。 如需詳細資訊，請參閱 Add, run, and update inline tests (新增、執行和更新內嵌測試)。

從卡片周遊至測試計劃/測試套件

您現在可以直接從工作流程看板上的卡片，輕鬆地周遊至建立測試的基礎測試計劃/測試套件。 按一下此連結 (圖 76) 將會帶您前往測試中樞、開啟正確的測試計劃，然後選取控制那些內嵌測試的特定套件。

周遊至計劃/套件
(圖 76) 周遊至計劃/套件
工作流程看板一般設定組態中的測試頁面

現在，透過使用工作流程看板上一般設定組態對話方塊中的新測試頁面，您將可以控制建立內嵌測試的測試計劃 (圖 77)。 之前，在卡片上建立的所有測試都會自動新增至新建立的測試計劃 (前提是沒有符合該卡片區域與反覆項目路徑的測試計劃)。 現在，您可以透過設定您選擇的現有測試計劃來覆寫此行為，所有的測試會新增至選取的測試計劃。 請注意，此功能僅在測試註釋開啟時啟用。

一般設定
(圖 77) 一般設定

Web 執行器增強功能

在手動測試期間加入測試步驟附件

我們已增強 Web 測試執行器，讓您能夠在手動測試期間新增測試步驟附件 (圖 78)。 這些步驟的結果附件會自動出現在您於工作階段報告的任何 Bug 中，以及後續的 [測試結果] 窗格中。

測試步驟附件
(圖 78) 測試步驟附件
Web 執行器中支援的螢幕擷取畫面、螢幕錄製、影像動作記錄和系統資訊 (使用 Chrome 瀏覽器)

在 Chrome 中使用 Web 執行器時，您現在可以拍攝螢幕擷取畫面，並內嵌標註 (圖 79)。 您不只可以擷取 Web 應用程式的隨選螢幕錄製，也可以擷取傳統應用程式的隨選螢幕錄製。 這些螢幕擷取畫面和螢幕錄製都會自動加入目前的測試步驟。 除了螢幕擷取畫面與螢幕錄製之外，您也可以從您的 Web 應用程式擷取隨選影像動作記錄。 您需要指定要擷取動作的瀏覽器視窗 - 該視窗上的所有動作 (任何現有或在該視窗開啟的新索引標籤) 或任何您所啟動的新子瀏覽器視窗，將會針對 Web 執行器中正在測試的測試步驟自動擷取並產生關聯。 這些螢幕擷取畫面、螢幕錄製和影像動作記錄將會加入您在執行期間所提報的任何 Bug，並會附加至目前的測試結果。 同樣地，會自動擷取系統資訊資料，並包含為您從 Web 執行器報告之任何 Bug 的一部分。 全部都會利用 Chrome 型測試與意見反應擴充功能的功能。

使用 Chrome 瀏覽器的 Web 執行器
(圖 79) 使用 Chrome 瀏覽器的 Web 執行器

如需詳細資訊，請參閱 Collect diagnostic data during tests (在測試期間收集診斷資料)。

Bug 回報為子系 - Web 執行器/測試與意見反應延伸模組

在 Web 執行器中執行測試時，從面板卡片或從測試中樞的需求式套件啟動，所有回報的新 Bug 現在都會自動建立為該使用者劇本的子項。 同樣地，如果您從探勘測試延伸模組來探索使用者劇本，您報告的任何新 Bug 也會建立為該使用者劇本的子項。 這項新行為讓跨劇本和 Bug 的追蹤更簡單。 只有在 [一般設定] 之 [組態] 頁面中的 [使用 Bug] 設定設為 [Bug 不會出現在待辦項目或面板上] 或 [Bug 會出現在待辦項目和面板上，並有工作] 時才適用。 針對 [使用 Bug] 選項的所有其他設定，以及在某些其他情況下，例如新增已定義父項的現有 Bug，會改為建立相關的連結。

從 Web 執行器更新現有的 Bug

除了從 Web 執行器建立新的 Bug 之外，您現在也可以更新現有的 Bug (圖 80)。 所有收集的診斷資料、重新產生步驟及可從目前工作階段追蹤的連結，都會自動加入現有的 Bug。

加入現有的 Bug
(圖 80) 新增至現有的 Bug

測試與意見反應延伸模組 - 增強功能

以瀏覽器為基礎的測試與意見反應擴充功能可以從 Visual Studio Marketplace 進行安裝。 它支援 Visual Studio Team Services 和 Team Foundation Server (2015 或更新版本)。

探索工作項目

您現在可以進行特定工作項目的探勘測試 (圖 81)。 這讓您能建立所選工作項目與進行中測試工作階段的關聯，以及從延伸模組內檢視驗收準則和描述。 此功能也會在您對所選工作項目提出的 Bug 或工作之間，產生完整的可追蹤性。 您可以直接從工作項目，或是從延伸模組內，探索工作項目：

• 直接從工作項目 (圖 81)：直接在產品內使用操作功能表中的 [進行探勘測試] 選項，來啟動特定工作項目的探勘測試工作階段。 我們在所有的卡片、方格和測試中樞裡都新增了進入點。

• 在延伸模組內 (圖 82)：從 XT 工作階段內搜尋工作項目，然後建立它與進行中工作階段的關聯。

來自卡片的 XT
(圖 81) 來自工作項目的 XT
探索工作專案
(圖 82) 來自延伸模組的 XT

如需詳細資訊，請參閱 Explore work items with the Test & Feedback extension (使用測試與意見反應擴充功能探索工作項目)。

使用測試與意見反應擷取影像動作記錄、螢幕錄製和網頁載入資料

影像動作記錄：此延伸模組提供新選項，讓您新增只要按一下即可自動導向 Bug 的步驟。 選取 [Include image action log] (包含影像動作記錄) 選項 (圖 83) 來擷取滑鼠、鍵盤及觸控動作，並直接在 Bug 或工作中新增相對應的文字和影像。

視訊形式的螢幕錄製：您也可以使用擴充功能來擷取隨選螢幕錄製。 這些螢幕錄製不只可從 Web 應用程式擷取，還可從您的桌面應用程式擷取。 您可以設定此延伸模組，以自動停止螢幕錄製，並使用延伸模組的 [選項] 頁面將它們附加至所提報的 Bug。

頁面載入資料：我們已將新的背景擷取功能新增至延伸模組 - 可擷取「網頁載入」資料。 就像「影像動作記錄」擷取您在探索 Web 應用程式時所執行的動作一樣，「網頁載入」功能也會在背景以影像的形式，自動擷取網頁完成載入作業的詳細資料。 相對於仰賴主觀/認知的緩慢網頁載入速度，現在您可以客觀地在 Bug 中量化緩慢的程度。 提報 Bug 之後，除了並排顯示之外，系統也會在錯誤上附加一份詳細報告，這可協助開發人員進行初始調查。

XT 映像動作記錄檔
(圖 83) XT 影像動作記錄
根據影像動作記錄資料建立測試案例

當您在探勘工作階段期間建立測試案例時，會自動為您填入附有影像的測試步驟 (圖 84)。 同步的測試設計和測試執行則為真正探勘測試的基礎，而這項新功能則讓它成為現實。 您可以編輯擷取的文字、加入預期的結果、取消核取不相關的資料列，以及儲存它供即將進行/執行的測試使用。

XT 建立測試案例
(圖 84) XT 建立測試案例

如需詳細資訊，請參閱 Create test cases based in image action log data (建立以影像動作記錄資料為基礎的測試案例)。

探勘測試工作階段深入資訊

您現在可以在小組或個人層級，使用測試與意見反應擴充功能，檢視於指定時段建立的已完成探勘測試工作階段。 您可以按一下 Web 存取中測試中樞群組內執行中樞的 [最近的探勘工作階段] 連結，取得此深入資訊頁面。 這個新檢視會協助您衍生有意義的深入資訊，包括︰

  • 摘要檢視：顯示已探索的工作項目、已建立的工作項目和工作階段擁有者分析，以及這些工作階段耗費的總時間 (圖 85)。
  • 分組檢視：可依已探索的工作項目、工作階段、工作階段擁有者，或是無來建立樞紐分析表。 針對任何樞紐分析表，您可以檢視所有已建立的工作項目清單 (Bug、工作、測試案例)，或將清單範圍限定到特定的工作項目類型。
  • 詳細資料窗格檢視會根據分組檢視中的選取項目顯示資訊。 針對選取的樞紐資料列 (假設是已探索的工作項目)，您可以在詳細資料窗格中檢視其摘要資訊，例如工作階段總數、這些工作階段耗費的總工時、探索它的工作階段擁有者、針對工作階段建立的 Bug/工作/測試案例，以及它們的狀態和優先權。 針對選取的工作項目資料列，您可以檢視其內嵌的工作項目表單，並適當予以變更。
XT 工作階段深入資訊
(圖 85) XT 工作階段深入資訊

如需詳細資訊，請參閱 Get insights across your exploratory testing sessions (跨探勘測試工作階段深入探索)。

探勘測試工作階段：檢視未探索的工作項目

除了在 [最近的探勘工作階段] 檢視中查看所有已探索工作項目的詳細資料 (依照指定日期範圍的全部/我的工作階段進行篩選) 之外，我們也在相同的檢視中新增了查看所有「尚未」探索之工作項目清單的功能 (圖 86)。 您可以透過指定您感興趣之工作項目的共用查詢來開始，而工作階段頁面會顯示所有來自查詢的工作項目清單，並在 [摘要] 區段中包含已探索與未探索項目的解析。 此外，依樞紐分析分組使用 [未探索的工作項目]，將可以看到尚未探索的項目清單。 這對於追蹤未探索的劇本數量或尚未通過群眾挑錯的劇本特別有用。

檢視未探索的 WIT
(圖 86) 檢視未探索的 WIT
端對端專案關係人意見反應流程
要求意見

具有基本存取層級的使用者現在可以使用工作項目功能表中的 [要求意見] 選項，直接向專案關係人要求進行中或已完成功能/劇本的意見 (圖 87)。 這會開啟 [要求意見] 表單，您可以在此選擇要徵求意見的專案關係人，並選擇性地提供一組簡單的指示，以提示需要意見的產品區域。 這會傳送個別郵件給所選取的專案關係人，並提供指示 (如果有的話)。

XT 要求意見反應流程
(圖 87) XT 意見反應流程

如需詳細資訊，請參閱 Request stakeholder feedback using the Test & Feedback extension (使用測試與意見反應擴充功能要求專案關係人的意見)。

提供意見反應

專案關係人可以按一下所收到之郵件中的 [提供意見反應] 連結來回應意見要求，這會自動設定內含所選取意見要求的測試與意見反應擴充功能 (先前稱為探勘測試擴充功能)；如果尚未安裝此擴充功能，則會提示安裝。 專案關係人接著可以使用此擴充功能的完整擷取功能來擷取結果，並以意見回應/Bug/任務工作項目的格式來送出意見。 此外，專案關係人可以巡覽至 [意見要求] 頁面，在一個位置檢視收到的所有意見要求。 他們可以從清單中選取要提供意見反應的意見要求、管理其「擱置的意見要求」(圖 88) (將其標示為完成或予以拒絕)，也可以按一下所需的選項按鈕 (圖 89) 在不同的意見要求類型之間進行切換。

提供意見反應連結
(圖 88) 提供意見反應連結
XT 提供意見反應流程
(圖 89) XT 意見反應流程

如需詳細資訊，請參閱 Provide feedback using the Test & Feedback extension (使用測試與意見反應擴充功能提供意見反應)。

自發意見反應

除了上述的要求流程之外，專案關係人也可以使用此延伸模組提供自發意見反應 (圖 90)。 他們可以開啟延伸模組、在 [連線設定] 頁面中選取「已連線」模式，並連線到他們想要提供意見反應的帳戶和專案/小組。 接著可以使用此擴充功能來擷取結果，並以意見回應/Bug/任務工作項目的格式來送出意見。

自發意見
(圖 90) 自發意見反應

如需詳細資訊，請參閱 Provide voluntary feedback using the Test & Feedback extension (使用測試與意見反應擴充功能提供自發意見)。

自動化測試改善

組建的 [測試] 索引標籤/[發行摘要] 中的主控台記錄和測試持續時間

trx 檔案中所擷取的測試結果主控台記錄會以測試結果附件形式擷取及發佈 (圖 91)。 您可以選擇在 [測試] 索引標籤中預覽此記錄，而不再需要下載 trx 檔案以檢視此記錄。

主控台記錄檔和持續時間
(圖 91) 主控台記錄和持續時間
組建的測試趨勢小工具

我們在小工具程式庫中新增「測試結果趨勢」小工具 (圖 92)。 使用此 Widget 將最多 30 個特定組建定義的最新組建測試結果趨勢圖表加入儀表板。 Widget 組態選項可協助您自訂圖表，包含通過的測試計數、失敗的測試計數、總測試計數、通過百分比和測試持續時間等樞紐分析表。

「測試結果趨勢」小工具
(圖 92)「測試結果趨勢」小工具
發行環境摘要的測試狀態

建議您使用 [發行環境] 來部署應用程式，並對它們執行測試。 在此發行中，我們已在 [發行摘要] 頁面的 [環境] 區段中整合發行環境的測試成功率 (圖 93)。 如螢幕擷取畫面所示，如果某個環境發生失敗，您可以透過查看 [測試] 資料行，來快速推斷失敗是否是因測試失敗所造成。 您可以按一下 [成功率] 以巡覽至 [測試] 索引標籤，並調查該環境失敗的測試。

發行環境摘要的測試狀態
(圖 93) 含發行環境摘要的測試狀態
分支與發行環境的自動化測試歷程記錄

個別的測試會在多個分支、環境及組態上執行，這是相當常見的案例。 當這類測試失敗時，識別該失敗是否只發生在開發分支 (例如主分支)，或是也影響到已部署至生產環境的發行分支，是一件非常重要的事情。 您現在可以透過查看 [結果] 摘要頁面中的 [歷程記錄] 索引標籤，針對多個正在進行測試的分支，視覺化該測試的歷程記錄 (圖 94)。 同樣地，您可以依 [環境] 樞紐分析分組，以視覺化執行測試之不同發行環境上的歷程記錄。

使用發行環境摘要的自動化測試狀態
(圖 94) 含發行環境摘要的測試狀態
持續測試的可追蹤性

使用者現在可以直接在儀表板上追蹤其需求的品質 (圖 95)。 我們已針對已規劃測試使用者的需求品質設計出解決方案，並將會提供給追蹤「連續測試」的使用者。 使用者能夠直接將自動化測試連結至 [需求]，然後使用儀表板小工具追蹤您有興趣追蹤的需求品質，並從 [組建] 或 [發行] 提取品質資料。

需求品質 Widget
(圖 95) 需求品質小工具
遠端測試 - 根據電腦數目散發測試

使用者將可以使用 [執行功能測試] 工作以將來自組件內的測試散發至遠端電腦 (圖 96)。 在 TFS 2015 中，您僅可以在組件層級散發測試。 這可以透過使用工作中的核取方塊來啟用，如下所示。

工作設定
(圖 96) 工作設定
SCVMM 與 VMWare 的自動化測試

使用者可以在雲端中 (透過 Azure) 或是在內部部署上 (使用 SCVMM 或 VMWare) 動態設定測試電腦，然後使用這些電腦以分散的方式執行其測試。 使用者可以使用其中一種電腦佈建工作 (Azure、SCVMM 或 VMWare)，並接著使用 [執行功能測試] 工作來執行測試。

Maven 和 Gradle 工作中的 SonarQube 分析

您現在可以透過選取 [執行 SonarQube 分析]，並提供端點、SonarQube 專案名稱、專案金鑰及版本，在 Maven 及 Gradle 建置工作中觸發 SonarQube 分析 (圖 97)。

工作設定
(圖 97) 執行 SonarQube 分析

您現在也會取得 SonarQube 專案的連結 (圖 98)。 您可以要求完整的分析，查看品質閘門詳細資料，並在不符合的情況下選擇中斷組建。

工作設定 1
(圖 98) 執行 SonarQube 分析

如需詳細資訊，請參閱 Gradle 建置工作現已支援 SonarQube 分析。

市集改善

專案集合系統管理員現在可以從 Team Foundation Server 瀏覽至 Visual Studio Marketplace，並在小組專案集合中安裝免費的擴充功能。 延伸模組會自動從 Visual Studio Marketplace 下載、針對 Team Foundation Server 進行上傳，並在選取的小組專案集合中安裝 (圖 99)。

工作設定
(圖 99) 安裝免費延伸模組

購買並安裝付費延伸模組

專案集合系統管理員現在可以從 Team Foundation Server 瀏覽至 Visual Studio Marketplace、購買付費延伸模組，並在選取的小組專案集合中加以安裝 (圖 100)。 系統管理員可以使用 Azure 訂用帳戶支付延伸模組費用，然後選取要指派這些延伸模組的目標使用者數目。 這些延伸模組會自動從 Visual Studio Marketplace 下載、針對 Team Foundation Server 進行上傳，並在選取的小組專案集合中安裝。

工作設定
(圖 100) 購買付費延伸模組

如需詳細資訊，請參閱 Get extensions for Team Foundation Server (取得 Team Foundation Server 的延伸模組) 文件。

系統管理改善

Windows 驗證

在舊版本中，您需要在設定加入網域的 TFS 部署時，決定使用 NTLM 和 Negotiate 安全性支援提供者來進行 Windows 驗證。 在 2017 中，我們已從組態體驗中移除此設定。 如果您要在 2017 年繼續使用 NTLM 驗證，則不需要採取任何動作。 如果您一直都使用 Kerberos 驗證，並且要在 2017 年繼續使用，則不需要採取任何動作。 TFS 2017 現在一律會設定 Negotiate 和 NTLM 安全性支援提供者 (依此順序)。 運用此組態，會在可能時使用 Kerberos 驗證，並提供增強式安全性。 無法使用 Kerberos 時，會使用 NTLM 驗證。 我們執行廣泛的測試，確保不會因這項變更而對使用 NTLM 驗證的現有 TFS 部署進行任何影響。

現代化的瀏覽體驗

在此發行中，我們啟用了一個全新改進的上方導覽列。 新的巡覽方式有兩個核心目標︰

  • 透過只需按一下便能快速存取任何中樞，進而增加跨產品區域的導覽效率。
  • 為產品帶來新式的視覺美術設計和使用者體驗。

由於這對使用者來說是很大的變更，且我們仍然在對功能進行逐一查看，因此我們決定預設將新的巡覽 UX 關閉。 如果您想要嘗試使用此新功能，請移至 Team Foundation Server 管理區域的 [控制台] 並選擇 [開啟新巡覽]。 請注意，這將會針對伺服器中的所有使用者啟用此功能。

Team 專案重新命名權限

控制哪些使用者可以重新命名已變更之 Team 專案的權限。 過去，具有 Team 專案的編輯專案層級資訊權限的使用者才能重新命名專案。 現在，透過新的重新命名 Team 專案權限可以授與或拒絕使用者重新命名 Team 專案的能力。

管理設定工作中樞

我們介紹了將一般設定 (圖 101)、反覆項目和區域結合在單一索引標籤中之 [管理設定] 頁面的新「工作」中樞。透過這項變更，使用者會看到專案層級設定和小組設定之間的明顯差異。 針對小組設定，使用者只會看見與小組相關的區域和反覆項目。 在專案層級，設定頁面能讓管理員管理整個專案的區域和反覆項目。 此外，專案區域路徑已加入名為「小組」的新資料行，方便管理員快速且輕鬆地分辨哪些小組已選取特定的區域路徑。

工作設定
(圖 101) 管理工作中樞

處理序組態 REST API

這個公用 API 可讓使用者取得指定專案的處理序組態。 處理序組態包含下列設定︰

  • TypeFields：敏捷式工具所使用的可自訂欄位抽象概念。 例如，「故事點數」欄位的類型是「投入時間」。
  • 待辦項目定義︰定義每個待辦項目上的工作項目類型。 這是客戶組建擴充功能經常要求的 API。 使用這項資料，擴充功能就可以了解如何利用特定處理序的欄位，在敏捷式工具中啟用常見案例 (例如變更工作項目的活動或投入時間、了解指定的待辦項目層級包含哪些工作項目，或判斷由區域路徑或自訂欄位來識別小組)。 如需詳細資訊，請參閱工作概觀。

Team Foundation Server 2017 引進了管理群組和群組成員資格的全新體驗。 您可以針對使用者/群組名稱使用前置詞型的搜尋準則，來搜尋 Active Directory 或本機電腦使用者/群組。 例如 'John D' 及 samaccountname (例如 'businessdomain\johbdnd')，並查看使用者/群組的連絡人卡片。

使用者安全性設定

您可以在新的 [我的安全性] 體驗中管理您的個人存取權杖和 SSH (圖 102)。 使用 [我的設定檔] 管理 SSH 的使用者，現在將需要在使用者安全性設定中管理其 SSH 公開金鑰 (圖 103)。

工作設定
(圖 102) 我的安全性
我的設定檔
(圖 103) 我的設定檔

整合組態精靈

在舊版中，您會根據您嘗試執行的動作，針對您的 TFS 部署從多個組態精靈中挑選其中一個。 [基本精靈] 和 [完整精靈] 可用來設定新的部署、[升級精靈] 可用於生產環境升級和進入生產階段前升級，而 [僅限應用程式層精靈] 可用於各種不同的案例，包括相應放大現有部署、使用新的硬體取代應用程式層等。 在 TFS 2017 中，這些案例都已整合為單一 [伺服器組態精靈]，它可透過要求您做出簡單的選擇，以引導您設定各個案例。 此外，進入生產階段前升級與複製現有部署等進階設定，現在會自動化過去需透過 tfsconfig.exe 完成的動作，包括變更伺服器識別碼、重新對應資料庫連接字串，以及移除外部相依性的參考 (過去需透過 tfsconfig.exe 的 PrepareClone 才能完成)。

新的存取層級

新的 Visual Studio Enterprise 群組已新增至 Team Foundation Server 中的存取層級系統管理員入口網站，您現在可以快速識別出哪些人員具有 Visual Studio Enterprise 訂閱。 識別後，這些使用者不需另外付費，即可完整存取自 Visual Studio Marketplace 安裝的所有第一方 TFS 延伸模組。

個人存取權杖

除了 SSH 以外，您現在可以使用個人存取權杖連線到任何 Team Foundation Server。 如果您在 Linux 或 Mac 上進行開發並想要使用任何自動化工具與 GIT，這會很有幫助。 您可以從使用者安全性設定頁面管理您的個人存取權杖。

已知問題

這是此發行中已知問題的完整清單。

沒有用於 Team Foundation Server 2017 的 Power Tools

  • 問題：

    TFS 2017 尚未發行 Power Tools。

  • 因應措施：

    我們很興奮地宣佈大部分的舊版 Power Tools 都已整合到 TFS 2017。 不巧的是，Process Template Editor 尚未經過整合，但您可以在 Visual Studio Marketplace 中取得。

更新自訂控制項延伸模組

匯入工作項目類型定義時發生錯誤

  • 問題：

    已安裝工作項目頁面延伸模組的客戶若匯出工作項目類型定義再匯入該定義，就會收到下列錯誤：「‘LayoutMode’ 屬性未宣告」。

  • 因應措施：

    每次當您匯出工作項目類型定義時，PageContribution 元素上都會有額外的 LayoutMode 屬性。 匯入定義之前，請搜尋 PageContribution 模式並移除 LayoutMode 屬性。 例如，移除 LayoutMode="FirstColumnWide"。

客戶應更新至 Git LFS 1.3.1 版或更新版本

  • 問題：

    1.3.1 之前的 Git LFS 版本不受未來版本支援。

  • 因應措施：

    強烈建議使用 Git LFS 的客戶更新至 Git LFS 1.3.1 版或更新版本。 舊版的 LFS 用戶端與此版 TFS 中的驗證變更不相容。 為了讓客戶有時間進行移轉，我們實作了短期的 RTW 因應措施。 Update 1 中將移除因應措施，屆時 1.3.1 版本以下的 Git LFS 用戶端就無法再運作。

NuGet 還原不是尋找位在 nuget.org 的封裝

  • 問題：

    使用 NuGet 3.4.3 或更新版本時，NuGet 還原工作不會從 NuGet.org 還原套件，除非其為 NuGet.Config 中的明確來源。

  • 因應措施：

    確定 NuGet.org 位於 NuGet.Config。

    <packageSources><add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3">
    </packageSources>

NuGet 組建和發行工作不會驗證

  • 問題：

    當使用 Team Foundation Server/套件管理時，如果組建代理程式是以網路服務使用者的身分執行 (這在代理程式是以服務的形式執行時為預設值)，NuGet 建置和發行工作將不會針對摘要進行驗證。 這是因為 3.5 之前的 NuGet 版本會使用執行組建代理程式的使用者帳戶認證，而非建置工作所提供的認證。

  • 因應措施：

    若要搭配使用作為網路服務執行之代理程式的 TFS 摘要來使用 NuGet 組建/版本工作，您必須使用 NuGet 3.5 或更新版本。

NuGet 建置和發行工作使用代理程式的認證

  • 問題：

    3.5 之前的 NuGet 版本會使用執行組建代理程式的使用者帳戶認證，而非建置工作所提供的認證。 這可能會導致非預期的存取權，或缺少摘要存取權。

  • 因應措施：

    在 TFS 組建代理程式上使用 NuGet 3.5 或更新版本。

升級 TFS 時，不會自動升級外部擴充功能

  • 問題：

    如果您從 Visual Studio Marketplace 下載延伸模組、將它發佈至您的 TFS 2015 安裝，然後升級至 TFS 2017，當新版延伸模組發佈至 Marketplace 時，不會自動更新延伸模組。

  • 因應措施：

    升級至 TFS 2017 之後，請解除安裝 TFS 2015 中已安裝的擴充功能。 然後重新安裝最新的擴充功能。 在 TFS 2017 中，我們新增了一項功能，會每天自動檢查一次是否有已更新的外部擴充功能，並進行升級。

無法執行發行定義中的「Jenkins 佇列作業」工作

  • 問題：

    執行發行定義中的「Jenkins 佇列作業」工作時，客戶收到 500 伺服器錯誤。

  • 因應措施：

    目前，「Jenkins 佇列作業」工作可當做 TFS 組建定義的一部分執行，但不能當做發行定義的一部分執行。 未來版本將新增此功能。

必須對 TFS 2017 DLL 重建自訂 TFS 伺服器外掛程式

  • 問題：

    自訂 TFS 伺服器外掛程式在升級至 TFS 2017 之後無法運作。

  • 因應措施：

    請對 TFS 2017 組件重建您的自訂伺服器外掛程式。

自 TFS 2015 RTM 以來，自訂 TFS 伺服器外掛程式的伺服器物件模型已變更

  • 問題：

    自訂 TFS 伺服器外掛程式未編譯。

  • 因應措施：

    請修正原始程式碼，如這篇部落格文章中所述。

使用系統管理員動作時，擲回例外狀況

  • 問題：

    當小組系統管理員在 [警示管理] 頁面中使用 [尋找特定使用者的警示] 搜尋來尋找小組的訂閱時，可能會發生例外狀況。

  • 因應措施：

    • 選項 1：按一下 [所有警示] 節點，並設定要顯示的 [我的所有小組警示] 篩選器。 這將會顯示使用者可存取之所有群組的所有警示。

    • 選項 2：如果群組是一個小組，而不是依小組名稱搜尋，請巡覽至此小組的 [警示管理] 頁面來管理訂閱。

使用在 Team Build/Release Management 中執行功能測試之工作的問題

  • 問題：

    使用工作目錄中的 [Visual Studio Test Agent 部署] 和 [執行功能測試] 工作在 Team Build/Release Management 中執行功能測試，目前使用 Agents for Visual Studio 2015 Update 3，而且只能用來執行使用 Visual Studio 2013 和 Visual Studio 2015 所建置的測試。 這些工作不能用於執行使用 Visual Studio 2017 RC 所建置的測試。 如需詳細資訊，請參閱此部落格文章。

  • 因應措施：

    沒有因應措施。 在 TFS 2017 Update 1 時間範圍中，新增使用 Test Agent 2017 以及執行使用 Visual Studio 2017 所建置之測試的支援。

延伸模組不會自動更新

  • 問題：

    如果從舊版的 TFS 升級到 TFS 2017 並在連線模式中執行 TFS 2017，則您的延伸模組不會自動更新成應有的版本。

  • 因應措施：

    目前尚無解決的方法。 我們已修正問題，且 TFS 2017 Update 2 中會提供自動更新行為。 如有任何原因無法等待 Update 2，請透過支援通道連絡我們，我們會儘早與您共用修正程式。

如果您遇到問題，而使您無法在生產環境中 (Go-Live) 部署，請連絡 Microsoft 產品支援。 (只有英文版) 僅限美國營業時間 (太平洋標準時間週一至周五上午 6 點至下午 6 點)，1 個工作天之內回應。

查看 Team Foundation Server 2017 的客戶回報問題。

開發人員社群入口網站

建議與意見反應

我們很希望聽聽您的意見！ 您可以透過開發人員社群 \(英文\) 建議功能、回報問題及追蹤問題，並在 Stack Overflow 上取得建議。

頁首