Team Foundation Server 2017.0.1 Team Foundation Server 2017.0.1


如果您是從非英文語言版本的頁面存取此頁面,並想查看最新的內容,請瀏覽此版本資訊頁面的英文版本。If you are accessing this page from a non-English language version, and want to see the most up-to-date content, please visit this Release Notes page in English.


您可以在此頁面的底部切換頁面語言。You can switch the page language at the bottom of this page. 按一下Click the 圖示,搜尋您的語言,或從可用語言的清單中選取。 icon, search for your language, or select from the list of available languages.

Team Foundation Server 2017.0.1 發行日期:2018 年 2 月 28 日Team Foundation Server 2017.0.1 Release Date: February 28, 2018

Team Foundation Server 2017.0.1 的新功能What's New in Team Foundation Server 2017.0.1

此更新修正潛在的跨網站指令碼 (XSS) 和其他安全性漏洞。This update fixes potential cross site scripting (XSS) and other security vulnerabilities. 如需詳細資訊,請參閱部落格文章 (英文)。See the blog post for more information. 它是完整升級,因此您可以直接升級至 TFS 2017.0.1。It is a full upgrade, so you can upgrade directly to TFS 2017.0.1.

按一下按鈕以下載 Team Foundation Server 2017.0.1。Click the button to download Team Foundation Server 2017.0.1.

Download the Team Foundation Server 2017

如需深入了解其他相關下載,請參閱下載頁面。To learn more about other related downloads, see the Downloads page.

Team Foundation Server 2017 發行日期:2016 年 11 月 16 日Team Foundation Server 2017 Release Date: November 16, 2016

本文提供 Team Foundation Server 2017 的相關資訊。In this article, you will find information regarding Team Foundation Server 2017. 這個版本包含最新的功能創新和改善。This release includes our most recent feature innovations and improvements. 請注意,Team Foundation Server 2017 的需求已變更。Note that the requirements have changed for Team Foundation Server 2017. 您可以在 Team Foundation Server Requirements and Compatibility (Team Foundation Server 需求和相容性) 頁面上找到更多詳細資料。You can find more details on the Team Foundation Server Requirements and Compatibility page. 若這些版本資訊不是您所要查看的版本資訊,您已閱讀完最新版本的版本資訊。If these were not the release notes you were expecting, you have reached the release notes for the most current version.

Team Foundation Server 2017 的新功能What's New in Team Foundation Server 2017?

已知問題Known Issues

新功能What's New

程式碼搜尋提供在所有程式碼中進行快速、靈活且正確的搜尋。Code Search provides fast, flexible, and accurate search across all your code. 當程式碼基底擴展,並隨多個專案和儲存機制而分割時,尋找所需程式碼就會愈來愈困難。As your codebase expands and is divided across multiple projects and repositories, finding what you need becomes increasingly difficult. 程式碼搜尋可以快速有效地找出您所有專案的相關資訊,以便將跨小組共同作業與共用程式碼發揮到極致。To maximize cross-team collaboration and code sharing, Code Search can quickly and efficiently locate relevant information across all your projects.

從探索 API 實作的範例、瀏覽其定義,到搜尋錯誤文字,程式碼搜尋是能一次解決所有程式碼探索與針對需求進行疑難排解的解決方案 (圖 1)From discovering examples of an API's implementation, browsing its definition, to searching for error text, Code Search delivers a one-stop solution for all your code exploration and troubleshooting needs (Figure 1).

程式碼搜尋提供︰Code Search offers:

  • 跨一或多個專案的搜尋Search across one or more projects
  • 語意排名Semantic Ranking
  • 進階篩選Rich filtering
  • 程式碼共同作業Code collaboration
Code Search
(圖 1) 程式碼搜尋(Figure 1) Code Search

如需詳細資訊,請參閱 Search across all your codeFor details, see Search across all your code.

封裝管理 Package Management

封裝可讓您跨組織共用程式碼︰您可以撰寫大型產品、開發以一般共用架構為基礎的多項產品,或建立及共用可重複使用的元件和程式庫。Packages enable you to share code across your organization: you can compose a large product, develop multiple products based on a common shared framework, or create and share reusable components and libraries. 套件管理 (圖 2) 藉由裝載您的套件、與您選取的人員共用套件,並讓套件可輕鬆存取 Team Build 和發行管理,來協助程式碼共用。Package Management (Figure 2) facilitates code sharing by hosting your packages, sharing them with the people you select, and making them easily accessible to Team Build and Release Management.

封裝管理可直接在您的 Team Foundation Server 中裝載 NuGet 封裝,而不需要裝載個別的 NuGet 伺服器或檔案共用。Package Management eliminates the need to host a separate NuGet server or file share by hosting NuGet packages directly in your Team Foundation Server. 它具有 NuGet 3.x 的頂級支援,也支援 NuGet 2.x 舊版用戶端。It has best-in-class support for NuGet 3.x as well as support for NuGet 2.x legacy clients. 它可順暢地搭配現有的 TFS 基礎結構、小組和權限,因此不需要進行識別的同步處理、在多個位置管理群組等作業。它也可輕易地與 Team Build 整合,讓您可以在持續整合工作流程中建立和使用封裝。It works seamlessly with your existing TFS infrastructure, teams, and permissions, so there’s no need to deal with synchronizing identities, managing groups in multiple places, etc. It also integrates easily with Team Build so you can create and use packages in continuous integration workflows.

如需詳細資料,請參閱封裝管理概觀For more details, see the Package Management overview.

Package Management
(圖 2) 套件管理(Figure 2) Package Management

敏捷式改善 Agile Improvements

在 Team Foundation Server 2017 中,我們增加了工作項目和工作流程看板的新功能。In Team Foundation Server 2017, we've added new features and functionality to work items and Kanban boards.

新的工作項目表單New work item form

新的工作項目 (圖 3) 表單擁有新的外觀及操作體驗。The new work item (Figure 3) form has a new look and feel. 它也加入了一些很棒的新功能︰It also adds some great new features:

  • 進階的工作項目討論經驗。A rich work item discussion experience.
  • 附件的拖放功能支援。Drag and drop support for attachments.
  • 改善的歷程記錄體驗 (History & auditing) (歷程記錄與稽核)。Improved history experience (History & auditing).
  • 改善的程式碼和組建整合。Improved code and build integration.
  • 狀態色彩設定。State coloring.
  • 回應式設計。Responsive design.


新的工作項目表單只是新集合的預設值。The new work item form is the default for new collections only. 如果您要移轉現有集合,則必須從系統管理員設定啟用新的工作項目表單。If you’re migrating an existing collection you will have to enable the new work item form from the admin settings. 如需詳細資訊,請參閱 Manage roll out of the new web form (管理新 Web 表單的展示)。For more information, see Manage roll out of the new web form.

New WIT Form
(圖 3) 新的 WIT 表單(Figure 3) New WIT Form

跟進工作項目Follow a work item

您現在只要按一下表單中新的 [跟隨] 按鈕 (圖 4),即可設定警示來追蹤單一工作項目的變更。You can now setup an alert for tracking changes to a single work item just by clicking on the new "Follow" button (Figure 4) in the form. 當您跟進工作項目時,您會隨時收到工作項目變更的通知,包括欄位更新、連結、附件和註解。When you follow a work item, you'll be notified any time the work item changes – including field updates, links, attachments, and comments.

New WIT Form
(圖 4) 新的 WIT 表單(Figure 4) New WIT Form

如需詳細資訊,請參閱 Follow a work itemFor details, see Follow a work item.

工作流程看板面板即時更新Kanban board live updates

工作流程看板現在是即時的了!Your Kanban board is now live!

您有沒有按下過 F5,看看工作流程看板一天都做了些什麼?Have you been hitting F5 to figure out what's going on throughout the day with your Kanban board? 請試試看以下螢幕擷取畫面 (圖 5) 中的圖示。Try the icon in the screenshot below (Figure 5).

Kanban live updates
(圖 5) 工作流程看板即時更新(Figure 5) Kanban live updates

當小組中的任何人在面板上建立、更新或刪除工作項目時,您會立即收到面板的即時更新。When anyone in your team creates, updates, or deletes a work item on the board, you will receive live updates on your board immediately. 此外,如果管理員進行面板或小組層級的更新,例如加入新的資料行或啟用待處理項目的 Bug,系統會通知您重新整理面板以更新面板的版面配置。Also, if the administrator makes board or team level updates such as adding a new column or enabling bugs on backlog, you will be notified to refresh the board to update your board layout. 您現在只需啟用工作流程看板上的塔台圖示,並開始與小組共同作業。All you need to do now, is enable the tower icon on your Kanban board and start collaborating with your team.

如需詳細資訊,請參閱 Kanban basics (看板基本概念)。For more information, see Kanban basics.

檢查清單改善Checklist improvements

檢查清單的運作方式有許多的改善。We’ve made several improvements to how Checklists work.

檢查清單項目現在會顯示為超連結 (圖 6)。Checklists titles now appear as hyperlinks (Figure 6). 您可以按一下項目來開啟工作項目表單。You can click on the title to open the work item form.

Checklist improvements
(圖 6) 檢查清單超連結(Figure 6) Checklist hyperlinks

檢查清單現在也支援操作功能表,讓您開啟、編輯或刪除檢查清單項目 (圖 7)Checklists now also support context menus that allow you to open, edit, or delete checklist items (Figure 7).

Checklist context menu
(圖 7) 檢查清單快顯功能表(Figure 7) Checklist context menu

如需詳細資訊,請參閱 Add task checklists (新增工作檢查清單)。For details, see Add task checklists.

Epic 和功能面板向下鑽研Epic and Feature Board Drill-down

您現在可以在 Epic 和功能面板上向下鑽研 (圖 8)。You now have the ability to drill down on your Epic and Feature boards (Figure 8). 檢查清單格式可讓您輕鬆將工作標示為已完成,並提供已完成與未完成工作的可用鳥瞰檢視。The checklist format lets you easily mark work as completed, and provides a handy bird’s eye view of the completed versus outstanding work.

Epic Feature drilldown
(圖 8) Epic 功能向下鑽研(Figure 8) Epic Feature drilldown

如需詳細資訊,請參閱 Kanban features and epics (看板功能和 Epics)。For more information, see Kanban features and epics.

開啟/關閉面板註釋Turning board annotations on/off

我們讓您能進一步控制面板卡片顯示的其他資訊。We are giving you more control of the additional information that shows on the cards on your boards. 您現在可以選取想要在工作流程看板卡上檢視的註釋 (圖 9)。You can now select annotations that you want to view on your Kanban cards (Figure 9). 只要取消選取某項註釋,它就不會再出現在工作流程看板上。Simply unselect an annotation and it will disappear from the cards on your Kanban board. 這裡顯示的前兩項註釋是子工作項目 (本範例中的工作) 和測試註釋。The first two annotations to show up here are child work items (tasks in this example) and the Test annotation.

Turn on/off board annotations
(圖 9) 開啟/關閉面板註釋(Figure 9) Turn on/off board annotations

如需詳細資訊,請參閱 Customize Cards (自訂卡片)。For more information, see Customize Cards.

清除格式設定命令Clear formatting command

工作項目的所有 RTF 文字控制項都加入了新的命令,可讓您清除選取文字的所有格式。We’ve added a new command to all rich text controls on work items that lets you clear all formatting from selected text. 如果您和我一樣,以前可能也在這個無法復原 (或清除) 的欄位中複製並貼上格式化文字,搞得焦頭爛額。If you’re like me, you’ve probably been burned in the past by copying and pasting formatted text into this field that you can’t undo (or clear). 現在只要醒目提示任何文字、選取 [清除格式設定] 工具列按鈕 (或按 CTRL+空格鍵),就會看到文字回復到預設格式。Now you can simply highlight any text, select the Clear Formatting toolbar button (or press CTRL+Spacebar), and you'll see the text return to its default format.

工作流程看板中的篩選Filtering in Kanban board

請針對使用者、反覆項目、工作項目類型和標記設定篩選條件,個人化您的工作流程看板 (圖 10)。Personalize your Kanban boards by setting filters on users, iterations, work item types, and tags (Figure 10). 這些篩選條件會保留,以便您即使從多個裝置連線時,也可以檢視個人化的面板。These filters will persist so that you can view your personalized board, even when you connect from multiple devices.

Filtering in Kanban
(圖 10) 工作流程看板中的篩選(Figure 10) Filtering in Kanban

小組成員也可以篩選其面板,以檢視分配到特定父工作項目的進度。Team members can also filter their boards to view progress accruing to a specific parent work item. 例如,使用者可以檢視連結至特定功能的使用者劇本,或是跨兩個或多個彙總至 Epic 的功能檢視工作。For example, a user can view user stories that are linked to a feature, or view work across two or more features that roll up to an epic. 這項功能 (如同檢查清單) 是我們為不同的待處理項目層級提供可見性所做的努力。This feature, much like Checklists, is one more step in our effort to bring visibility through to the different backlog levels.

如需詳細資訊,請參閱 Filter Kanban board (篩選工作流程看板)。For details, see Filter Kanban board.

新工作項目的預設反覆項目路徑Default iteration path for new work items

當您從 [查詢] 索引標籤或 [新增工作項目] 儀表板 Widget 建立新的工作項目時,該工作項目的反覆項目路徑一律會設為目前的反覆項目。When you create a new work item from the Queries tab or from the New Work Item dashboard widget, the iteration path of that work item is always set to the current iteration. 並非所有的小組都希望這樣,因為這表示 Bug 可能會立即出現在工作面板上。This is not what all teams want, because it will mean that bugs could show up on the task board immediately. 使用這項改善,小組可以選擇應用於新工作項目的預設反覆項目路徑 (特定的或目前的反覆項目)。With this improvement, teams can choose the default iteration path (a specific one or the current iteration) that should be used for new work items. 瀏覽至您小組的系統管理區域,選擇預設的反覆項目。Navigate to the administration area for your team to choose a default iteration.

如需詳細資訊,請參閱 Customize area and iteration paths (自訂區域和反覆項目路徑) 頁面。For more information, see the Customize area and iteration paths page.

核取方塊控制項Checkbox control

您現在可以在工作項目中新增核取方塊控制項 (圖 11)。You can now add a checkbox control to your work items (Figure 11). 這個新的欄位類型 (布林值) 具有一般欄位的所有屬性,並可新增至流程的任何類型中。This new field type (Boolean) has all the properties of normal fields and can be added to any type in your process. 當顯示在卡片或查詢結果中時,此值會顯示為 True/False。When displayed on cards or in a query result, the value is shown as True/False.

Checkbox control
(圖 11) 核取方塊控制項(Figure 11) Checkbox control

如需詳細資訊,請參閱 Customize a field (自訂欄位)。For details, see Customize a field.

大量編輯標籤Tags bulk editing

您現在可以使用大量編輯對話方塊,從多個工作項目新增和移除標記 (圖 12)You can now add and remove tags from multiple work items using the bulk edit dialog (Figure 12).

Bulk edit dialog
(圖 12) 大量編輯對話方塊(Figure 12) Bulk edit dialog

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

新的擴充點New extension points

我們已在面板和待處理項目頁面上加入新的貢獻點,以允許您將擴充功能撰寫為面板/待處理項目/產能索引標籤旁邊的樞紐分析索引標籤。We’ve added a new contribution point on the board and backlog pages to allow you to write extensions as a pivot tab next to Board/Backlog/Capacity tabs.

我們已公開推出新的擴充點。We have exposed a new extension point on the backlog. 延伸模組可以在右側將窗格作為目標,即現在對應和工作詳細資料所在的位置 (圖 13)Extensions can target the pane on the right side, where mapping and work details are today (Figure 13).

Backlog extension points
(圖 13) 待辦項目擴充點(Figure 13) Backlog extension points

如需擴充功能的詳細資訊,請參閱 Extension Points (擴充點)。For more information on extensions, see Extension Points.

電子郵件改善Email improvements

我們大幅改進了由 TFS 所傳送的工作項目警示、跟隨及 @mention 電子郵件的格式設定與使用性 (圖 14)。We’ve significantly improved the formatting and usability of work item alerts, follows, and @mention emails sent by TFS (Figure 14). 電子郵件現在包含一致的標頭、清楚的動作呼叫和改善的格式,以確保郵件中的資訊更易於使用和了解。Emails now include a consistent header, a clear call to action, and improved formatting to make sure the information in the mail is easier to consume and understand. 此外,所有這些電子郵件的設計都是為確保它們能在行動裝置中完好呈現。Additionally, all these emails are being designed to ensure they render well on mobile devices.

Email improvements
(圖 14) 電子郵件改善(Figure 14) Email improvements

如需詳細資訊,請參閱 Work item alerts (工作項目警示)。For more information, see Work item alerts.

工作項目範本Work item templates

新增了可將豐富的工作項目範本直接建立至原生 Web 體驗的功能 (圖 15)。We added the ability to create rich work item templates directly into the native web experience (Figure 15). 這項功能先前在 Web 中極度受限,且僅能透過 Visual Studio 的強大工具以此新形式使用。This capability was previously very limited in the web, and only available in this new form through a Visual Studio power tool. 小組現在可以建立並管理一組範本,快速修改一般欄位。Teams can now create and manage a set of templates for quickly modifying common fields.

Work item templates
(圖 15) 工作項目範本(Figure 15) Work item templates

如需詳細資訊,請參閱 Work item templates (工作項目範本)。For details, see Work item templates.

不再支援 Project Server 整合Project server integration no longer supported

Team Foundation Server 2017 和更新版本不再支援 Project Server 整合。Team Foundation Server 2017 and later versions no longer support Project Server integration. 自 RC2 起,如果您升級的 TFS 資料庫已設定 Project Server 整合,您會收到下列警告︰As of RC2, if you upgrade a TFS database that has Project Server integration configured, you'll receive the following warning:

偵測到此資料庫已設定 Project Server 整合。Team Foundation Server 2017 和更新版本不再支援 Project Server 整合。We have detected that you have Project Server integration configured for this database. Team Foundation Server 2017 and later versions no longer support Project Server integration.

升級後,Project Server 整合將不再運作。After upgrade, the Project Server integration will no longer operate.

接下來,將倚賴合作夥伴提供整合解決方案。Going forward, we will be relying on Partners to provide integration solutions.

如需有關這項變更的詳細資訊,請參閱下列主題︰同步處理 TFS 與 Project ServerFor more information on this change, please read the following topic: Synchronize TFS with Project Server.

儀表板和 Widget 改善 Dashboards and Widgets Improvements

Team Foundation Server 2017 已在多個 Widget 上進行了改善,例如查詢磚 Widget 和提取要求 Widget。Team Foundation Server 2017 has made improvements on multiple widgets, such as the Query Tile and Pull Request widgets.

重新設計的小工具目錄Redesigned widget catalog

我們已經重新設計小工具目錄來容納不斷成長的小工具集合,並提供更好的整體體驗 (圖 16)。We’ve redesigned our widget catalog to accommodate the growing set of widgets and deliver a better overall experience (Figure 16). 新的設計包括改進的搜尋體驗,並已重新設定樣式,使符合 Widget 組態面板的設計。The new design includes an improved search experience and has been restyled to match the design of our widget configuration panels.

Widget catalog
(圖 16) Widget 目錄(Figure 16) Widget catalog

如需詳細資訊,請參閱 Widget Catalog (Widget 目錄)。For more details, see Widget Catalog.

小工具更新Widget updates

查詢磚小工具現在支援最多 10 個條件式規則,並且可以選取色彩 (圖 17)。The Query Tile widget now supports up to 10 conditional rules and has selectable colors (Figure 17). 當您想要使用這些磚當作 KPI 來識別健康狀態及/或可能需要的動作時,這十分方便。This is extremely handy when you want to use these tiles as KPIs to identify health and/or action that may be needed.

Dashboard updates
(圖 17) 儀表板更新(Figure 17) Dashboard updates

提取要求 Widget 現在可以支援多種大小,讓使用者控制 Widget 的高度。The Pull Request widget now supports multiple sizes, allowing users to control the height of the widget. 我們正努力讓大部分的 Widget 都能調整大小,詳情請看這裡。We’re working on making most of the widgets we ship resizable, so look for more here.

新增工作項目 Widget 現在可讓您選取預設的工作項目類型,不會強迫您選取從下拉式清單中重複建立的最常見類型。The New Work Item widget now allows you to select the default work item type, instead of forcing you to select the most common type you’re creating over and over from the drop-down list.

WIT 圖表 Widget 已可調整大小。We've made the WIT chart widgets resizable. 這可讓使用者在儀表板上看到任何 WIT 圖表的展開檢視,無論其原始大小為何。This allows users to see an expanded view of any WIT chart on the dashboard regardless of its original size.

小組成員小工具已更新,更容易為小組新增成員 (圖 18)The Team Members widget has been updated to make it easier to add somebody to your team (Figure 18).

Widget Update
(圖 18) Widget 更新(Figure 18) Widget Update

小組現在可以設定儀表板「查詢結果」Widget 的大小,讓它可以顯示更多結果。Teams can now configure the size of the dashboard's Query Results widget, allowing it to display more results.

短期衝刺概觀小工具經過重新設計,讓小組方便查看其是否正常運行。The Sprint Overview widget has been redesigned making it easier for teams to see if they're on track.

[指派給我] 小工具協助使用者管理受到指派的工作,而無須離開儀表板內容 (圖 19)。The Assigned to Me widget helps users manage the work assigned to them without leaving the dashboard context (Figure 19). 藉由提供專門用於此用途的 widget,小組系統管理員可以將此功能新增至 16 較少的按下其儀表板、 沒有內容切換和需要任何輸入。By providing a widget dedicated to this purpose, team admins can add this functionality to their dashboards with 16 fewer clicks, no context switches and no typing required. 使用者現在可以在小工具內容中檢視、排序、篩選及管理受到指派的工作。Users can now view, sort, filter, and manage the work assigned to them within the widget context.

Assigned to me
(圖 19) 指派給我(Figure 19) Assigned to me

儀表板 REST APIDashboards REST APIs

您現在可以使用 REST API 以程式設計方式在儀表板上新增、刪除和取得資訊。You can now use REST APIs to programmatically add, delete, and get information on a dashboard. API 也可讓您在 Widget 或儀表板上的 Widget 清單中新增、移除、更新、取代和取得資訊。The APIs also let you add, remove, update, replace, and get information on a widget or a list of widgets on a dashboard. 文件位於 Visual Studio 線上文件The documentation is available on Visual Studio online docs.

允許的儀表板Permissible dashboards

非系統管理員的使用者現在可以建立和管理小組儀表板。Non-admin users can now create and manage team dashboards. 小組系統管理員可以透過儀表板管理員限制非系統管理員權限。Team admins can restrict non-admin permissions through the dashboard manager.

如需詳細資訊,請參閱 Dashboards (儀表板)。For more information, see Dashboards.

Git 改善 Git Improvements

Team Foundation Server 2017 已對 Git 進行一些重大變更。Some major changes have been made in Git for Team Foundation Server 2017. 包括重新設計 [分支] 頁面和「Squash 合併」的新選項。Included are a redesign of the Branches page and a new option to “squash merge”.

重新設計的 [分支] 頁面Redesigned Branches page

[分支] 頁面已完全重新設計。The Branches page has been completely redesigned. 它有「我的」樞紐,顯示您建立、推送或加入最愛的分支 (圖 20)。It has a "mine" pivot that shows the branches you created, pushed to, or favorited (Figure 20). 每個分支都會顯示其組建和提取要求的狀態,以及類似 [刪除] 的其他命令。Each branch shows its build and pull requests status, as well as other commands like Delete. 如果分支名稱中有斜線,如 "features/jeremy/fix-bug",就會顯示為樹狀結構,以輕鬆瀏覽大型的分支清單。If there is a slash in a branch name, like "features/jeremy/fix-bug", it's shown as a tree, so it's easy to browse through a large list of branches. 如果您知道分支名稱,就可以快速搜尋找到您想要的分支。If you know the name of your branch, you can search to find the one you want quickly.

Redesigned branches page
(圖 20) 重新設計的分支頁面(Figure 20) Redesigned branches page

如需分支的詳細資訊,請參閱 Manage branches (管理分支)。For more details on branches, see Manage branches.

新的提取要求體驗New pull request experience

提取要求體驗在此版本中有一些重大更新,引入一些功能非常強大的 Diff 功能、全新的註解體驗,以及煥然一新的 UI。The pull request experience has some major updates this release, bringing some really powerful diff capabilities, a new commenting experience, and an entirely refreshed UI.

如需詳細資訊,請參閱 Review code with Pull Requests (使用提取要求檢閱程式碼)。For more details, see Review code with Pull Requests.

重新設計的 UIRedesigned UI

開啟提取要求時,馬上就能體會到新的外觀及感受 (圖 21)When opening a pull request, the new look and feel is evident immediately (Figure 21). 標頭已重新整理過,以彙總所有重大狀態和動作,如此便可在體驗中的每個檢視加以存取。We've reorganized the header to summarize all the critical state and actions, making them accessible from every view in the experience.

Pull request header
(圖 21) 提取要求標頭(Figure 21) Pull request header

概觀現在會將提取要求描述反白顯示,讓您比以往更加輕鬆地提供意見反應 (圖 22)。The Overview now highlights the PR Description and makes it easier than ever to give feedback (Figure 22). 最上層會連同最新項目顯示事件和註解,讓檢閱者得以查看極為重要的最新變更和註解。Events and comments are shown with the newest items on top to help reviewers see the latest changes and comments front and center. 詳盡提供原則、工作項目以及檢閱者,並加以重新整理,變得更清楚精確。Policies, work items, and reviewers are all provided in detail and reorganized to be more clear and concise.

Pull request overview
(圖 22) 提取要求概觀(Figure 22) Pull request overview

此版本中最重大的新功能是能夠查看對提取要求所做的先前更新 (圖 23)。The biggest new feature in this release is the ability to see past updates made to a pull request (Figure 23). 在先前的預覽中,我們發行了能夠正確追蹤提取要求進行變更更新時的註解。In previous previews, we released the ability to properly track comments as a PR is updated with changes. 不過,您不一定能夠輕鬆查看更新之間的項目。However, it's not always easy to see what's between updates. 現今在 [檔案] 檢視中,您可以查看每當新的程式碼推送至提取要求時的完整變更項目。In the Files view, you can now see exactly what changed each time new code is pushed to your PR. 在您對一些程式碼提供意見反應,並想完整查看其變更方式時而不受到檢閱中所有其他變更的干擾時,便相當實用。This is very useful if you've given feedback on some code and want to see exactly how it changed, isolated from all the other changes in the review.

Pull request files
(圖 23) 提取要求檔案(Figure 23) Pull request files

新的 [更新] 檢視用來顯示提取要求隨著時間變更的方式 (圖 24)。The new Updates view is used to show how the PR is changing over time (Figure 24). [檔案] 檢視顯示檔案隨著時間變更的方式,而 [更新] 檢視顯示每個更新中新增的認可。Where the Files view shows how the files have changed over time, the Updates view shows the commits added in each update. 如果發生強制推送時,[更新] 檢視會繼續顯示在歷程記錄中發生的過去更新。If a force push ever happens, the Updates view will continue to show the past updates as they occurred in history.

Pull request updates
(圖 24) 提取要求更新(Figure 24) Pull request updates
註解,現在可搭配 Markdown 和 EmojiComments, now with markdown and emoji

在所有討論中發揮 Markdown 的完整威力,包括格式化、語法反白顯示的編碼、連結、影像及 Emoji (圖 25)。Use the full power of markdown in all your discussions, including formatting, code with syntax highlighting, links, images, and emoji (Figure 25). 註解控制項的編輯體驗也讓使用者更容易上手,可一次編輯 (及儲存) 多個註解。The commenting controls also have a more user friendly editing experience allowing multiple comments to be edited (and then saved) at one time.

Pull request comments
(圖 25) 提取要求註解(Figure 25) Pull request comments
在提取要求中新增及移除檢閱者Add and remove reviewers in pull requests

現在從提取要求中新增和移除檢閱者更為容易。It's now easier to add and remove reviewers from your pull requests. 若要將檢閱者或群組加入您的提取要求中,只要將其名稱輸入 [檢閱者] 區段中的 [搜尋] 方塊即可。To add a reviewer or group to your pull request, simply enter their name into the search box in the Reviewers section. 若要移除檢閱者,在 [檢閱者] 區段中將滑鼠停留在其磚上,並按一下 X 即可移除 (圖 26)To remove a reviewer, hover over their tile in the Reviewers section and click the X to remove them (Figure 26).

Add reviewers in pull requests
(圖 26) 在提取要求中新增檢閱者(Figure 26) Add reviewers in pull requests
改善的組建和提取要求追蹤Improved build and pull request traceability

組建和提取要求之間的追蹤已經改善,讓您輕鬆地從 PR 瀏覽至組建再返回。The traceability between builds and pull requests has improved, making it easy to navigate from a PR to a build and back. 在提取要求觸發之組建的組建詳細資料檢視中,來源現在會顯示之前佇列組建的提取要求連結。In the build details view for a build triggered by a pull request, the source will now show a link to the pull request that queued the build. 在 [組建定義] 檢視中,任何由提取要求觸發的組建都會在「觸發者」資料行中提供提取要求連結。In the Build Definitions view, any build triggered by a pull request will provide a link to the pull request in the "Triggered By" column. 最後,[Build 總管] 檢視會在來源資料行中列出提取要求。Finally, the Build Explorer view will list pull requests in the source column.

提取要求的註解追蹤Comment tracking for pull requests

已改進 VSTS 中的提取要求,以在適當的列上顯示檔案中留下的註解,即使那些檔案在新增該註解後已經變更。Pull requests in VSTS have been improved to show comments left in files on the proper line, even if those files have been changed since the comments were added. 在之前,註解一律會在檔案中原始新增註解的那一行上顯示,即使檔案內容已變更。換句話說,第 10 行上的註解一律會在第 10 行上顯示。Previously, comments were always shown on the line of the file where they were originally added, even if the file contents changed—in other words, a comment on line 10 would always be shown on line 10. 透過最新的改進功能,註解會隨程式碼顯示使用者預期的內容。如果在第 10 行上新增註解,且後續又在檔案的開頭新增了兩個新行,則該註解將會顯示在第 12 行上。With the latest improvements, the comments follow the code to show what the user expects—if a comment was added on line 10, and two new lines were subsequently added to the beginning of the file, the comment will be shown on line 12.

下列為在第 13 行上新增註解的變更範例 (圖 27)Here's an example change with a comment on line 13 (Figure 27):

Comment tracking
(圖 27) 註解追蹤(Figure 27) Comment tracking

即使在程式碼已變更為將包含原始註解的行從第 13 行轉換至第 14 行,註解仍顯示在預期的位置 (第 14 行) (圖 28)Even after the code has changed to shift the line with the original comment from 13 to 14, the comment is appearing in the expected place on line 14 (Figure 28).

Comment tracking with change
(圖 28) 對於變更的註解追蹤(Figure 28) Comment tracking with change
自動完成等候原則的提取要求Auto-complete pull requests waiting on policies

使用分支原則 ( 保護其分支的小組可以試用自動完成動作。Teams that are using branch policies to protect their branches will want to check out the auto-complete action. 很多時候,提取要求的作者已就緒合併其提取要求,但必須等待組建完成後,才能按一下 [完成]。Many times, the author of a pull request will be ready to merge their PR, but they're waiting on a build to finish before they can click Complete. 而其他時候,組建已通過,但是尚有一位檢閱者未提供最終核准。Other times, the build is passing, but there is one reviewer that hasn't given the final approval. 在這些情況下,作者可透過自動完成的動作將提取要求設為在所有原則皆核准時自動完成 (圖 29)In these cases, the auto-complete action lets the author set the PR to automatically complete as soon as the policies are all approved (Figure 29).

(圖 29) 自動完成(Figure 29) Auto-complete

如同手動完成動作,作者有機會自訂合併認可的訊息,並選取適當的合併選項 (圖 30)Just like the manual complete action, the author has a chance to customize the message of the merge commit and select the appropriate merge options (Figure 30).

(圖 30) 自動對話方塊(Figure 30) Autodialog

設定自動完成後,提取要求會顯示橫幅,確認自動完成已設定並等待原則完成 (圖 31)Once auto-complete has been set, the PR will display a banner that confirms that the auto-complete is set and waiting for policies to complete (Figure 31).

Auto-complete confirmation
(圖 31) 自動完成確認(Figure 31) Auto-complete confirmation

符合所有原則時 (例如組置已完成,或已授與最終核准時),便會使用指定的選項和註解合併提取要求。When all the policies have been met (e.g., the build completes, or that final approval is granted), the PR will be merged using the options and comments specified. 如預期般,如果發生組建失敗或檢閱者未核准,提取要求會維持作用中,直到通過原則為止。As expected, if there is a build failure or the reviewer doesn't approve, the PR will remain active until the policies are passing.

Squash 合併提取要求Squash merge pull requests

現在當您完成提取要求時,可以選擇 Squash 合併 (圖 32)。When completing a pull request, you now have the option to squash merge (Figure 32). 這個新的選項會產生單一認可,其中包含要套用到目標分支的主題分支變更。This new option will produce a single commit containing the changes from the topic branch that will be applied to the target branch. 一般合併和 Squash 合併之間最顯著的差異,是 Squash 合併認可只會有一個父認可。The most notable difference between a regular merge and a squash merge is that the squash merge commit will only have one parent commit. 這表示更簡單的歷程記錄圖,因為在產生的認可圖形中無法連接到對主題分支所做的任何中繼認可。This will mean a simpler history graph, as any intermediate commits made to the topic branch will not be reachable in the resulting commit graph.

Squash merge pull request
(圖 32) Squash 合併提取要求(Figure 32) Squash merge pull request

您可以在 Squash merge pull requests (壓縮合併提取要求) 找到詳細資訊。You can find more information at Squash merge pull requests.

認可追蹤Commit traceability

組建狀態 (成功或失敗) 現在會清楚地顯示在 [程式碼總管] 和 [認可詳細資料] 檢視中 (圖 33)。Build status (success or failure) is now clearly visible in the Code Explorer and Commit Details views (Figure 33). 只要按一下即可得知更多的詳細資訊,如此即可掌握認可的變更是否通過組建。More details are just a click away, so you’ll always know if the changes in the commit passed the build or not. 您也可以在組建定義的儲存機制選項中自訂哪些組建會發佈狀態。You can also customize which builds post status in the repository options for the build definition. 此外,[認可詳細資料] 檢視中的最新變更會有關於變更的更深入資訊。Additionally, the latest changes to the Commit Details view provide deeper insights about your changes. 如果使用提取要求來合併變更,您會看到將變更導入主要分支的提取要求連結 (若為合併認可則是建立認可的 PR 連結)。If you’re using pull requests to merge your changes, you’ll see the link to the pull request that introduced the changes into the master branch (or in the case of a merge commit, the PR that created it). 當變更到達主要分支時,分支連結會出現以確認是否包含變更。When your changes have reached master, the branch link will appear to confirm that the changes have been included.

Commit Traceability
(圖 33) 認可追蹤(Figure 33) Commit Traceability

檢視 Web 中的 Git LFS 檔案View Git LFS files in the Web

如果您已經在使用 Git 中的大型檔案 (音訊、視訊、資料集等等),您就會知道 Git 大型檔案儲存 (LFS) 是用 Git 內的指標來取代這些檔案,同時將檔案內容儲存在遠端伺服器中。If you’re already working with large files in Git (audio, video, datasets, etc.), then you know that Git Large File Storage (LFS) replaces these files with pointers inside Git, while storing the file contents in a remote server. 這可讓您透過按一下儲存機制中的檔案,來檢視這些大型檔案的完整內容。This makes it possible to view the full contents of these large files by simply clicking the file in your repo.

如需詳細資訊,請參閱 Manage large files with Git (使用 Git 管理大型檔案)。For more information, see Manage large files with Git.

輕鬆地使用程式碼連結來共用程式碼參考 (圖 34)。Share code references easily with code links (Figure 34). 只要選取檔案中的文字並按一下連結圖示即可。Just select text in a file and click the Link icon. 它會將連結複製到選取的程式碼。It will copy a link to the selected code. 當有人檢視該連結時,您醒目提示的程式碼就會顯示金色的背景。When someone views that link, the code you highlighted will have a gold background. 選取部分行也有用。It even works for partial line selections.

Send links to code
(圖 34) 傳送程式碼連結(Figure 34) Send links to code

狀態 APIStatus API

組建成功或失敗現在會清楚地顯示在 [程式碼總管] 和 [認可詳細資料] 檢視中 (圖 35)。Success or failure of the build is now clearly visible in the code explorer and commit details views (Figure 35). 只要按一下即可取得詳細資料,好讓您持續掌握認可的變更是否通過組建。More details are just a click away, so you'll always know if the changes in the commit passed the build or not. 您也可以在組建定義的儲存機制選項中自訂哪些組建會發佈組建狀態。You can also customize which builds post build status in the repository options for the build definition.

Status API
(圖 35) 狀態 API(Figure 35) Status API

檔案類型圖示File type icons

您會在總管、提取要求、認可詳細資料、擱置集、變更集或任何其他顯示檔案清單的檢視中,看到符合檔案副檔名的新檔案圖示 (圖 36)You will see new file icons matching the extension of the file in the explorer, pull requests, commit details, shelveset, changeset or any other view that shows a list of files (Figure 36).

File type example
(圖 36) 檔案類型範例(Figure 36) File type examples

在建立存放庫期間新增讀我檔案Add a ReadMe during repo creation

已改進新的 Git 存放庫建立方式,讓使用者能新增讀我檔案 (圖 37)。The new Git repository creation has been improved by providing users the ability to add a ReadMe file (Figure 37). 將讀我檔案新增至儲存機制不僅能協助其他人了解程式碼基底的用途,也可讓您立即複製儲存機制。Adding a ReadMe to the repository not only helps others understand the purpose of the codebase, but also allows you to immediately clone the repository.

Add a ReadMe file
(圖 37) 新增讀我檔案(Figure 37) Add a ReadMe file

組建改善 Build Improvements

我們在本版中增加了記錄檔大小、加入了 Java 組建範本,並且改善了 Xamarin 支援,以命名一些變更。In this release, we’ve increased the size of the logs, added Java build templates, and improvements to our Xamarin support to name a few changes.

重新設計的 [組建佇列] 索引標籤Redesigned build queue tab

已實作 [已佇列組建] 頁面的新設計,並顯示較長的已佇列及執行中組建清單,更加直接好用 (圖 38)We've implemented a new design for the Queued builds page that shows a longer list of queued and running builds, and in a more intuitive fashion (Figure 38).

Build queue tab
(圖 38) [組建佇列] 索引標籤(Figure 38) Build queue tab

如需詳細資訊,請參閱 Administer your build system (管理建置系統)。For more information, see Administer your build system.

啟用組建結果擴充功能以指定順序和資料行Enable build result extensions to specify order and column

組建結果區段延伸模組現在可以指定要顯示的資料行和出現順序 (圖 39)。Build result section extensions can now specify which column and the order in which they appear (Figure 39). 結果檢視有兩個資料行,而所有的擴充功能預設位在第一個資料行中。The result view has two columns, and all extensions will be in the first column by default. 注意︰所有的協力廠商擴充功能都會出現在我們加入的組建結果區段之後。Note: All third-party extensions will appear after the build result sections we include.

Build order and column
(圖 39) 組建順序和資料行(Figure 39) Build order and column

行號的組建Build to line number

現在您可以從組建錯誤跳到造成錯誤的程式碼行。Now you can jump from a build error to the line of code that caused it. 請看我們在內部作為提取要求原則之主要組建的最新錯誤,您就會看到 (圖 40)Looking at the latest error on the primary build we use as a pull request policy internally, you see this (Figure 40):

Build to line number
(圖 40) 組建至行號(Figure 40) Build to line number

組建記錄檔檢視支援更大的記錄檔Build log view supports much larger logs

舊版的記錄檔檢視最多只支援 10,000 行的記錄檔。The previous log view only supported logs up to 10,000 lines. 新的檢視器是以 VS 程式碼中使用的摩納哥編輯器為基礎,最多可支援 150,000 行的記錄檔。The new viewer is based on the Monaco editor used in VS Code and will support logs up to 150,000 lines.

Java 組建範本Java build templates

我們甚至新增 Ant、Maven 和 Gradle 的組建範本,讓 Java 開發人員能更輕鬆地開始建立組建 (圖 41)We’ve made it even easier for Java developers to get started with build by adding build templates for Ant, Maven, and Gradle (Figure 41).

Java build templates
(圖 41) Java 組建範本(Figure 41) Java build templates

如需範本的詳細資訊,請參閱 Build steps (建置步驟)。For more information on templates, see Build steps.

Xamarin 組建工作Xamarin build tasks

我們對 Xamarin 支援進行了一些重大改善︰We made some significant improvements to our Xamarin support:

已不再需要 Xamarin 授權步驟,並已從建置範本移除。The Xamarin License step is no longer necessary and has been removed from the build templates. 我們也將會取代工作,作為這項作業的一部分。As part of this effort we will also deprecate the task. 所有使用此工作的組建定義都應更新為移除該工作,以免在最終移除該工作時造成中斷。All build definitions that use this task should be updated to remove it in order to prevent any disruption when the task is finally removed.

最後,強化了 Xamarin 的組建定義範本,以使用這些新的工作。Finally, the Xamarin build definition templates were enhanced to use these new tasks. Build your Xamarin app (組建 Xamarin 應用程式)。Build your Xamarin app.

針對組建和發行管理的 Docker 整合Docker integration for build and release management

善用組建功能來建置您的 Docker 映像,並上傳至 Docker 中樞作為連續整合流程的一部分 (圖 42)。Take advantage of the build capabilities to build your Docker images and upload them to the Docker Hub as part of your continuous integration flow (Figure 42). 接著,將這些映像部署至數部 Docker 主機,作為 Release Management 的一部分。Then, deploy those images to a number of Docker hosts as part of Release Management. Marketplace 擴充功能加入了使用 Docker 所需的所有服務端點類型和工作。The Marketplace extension adds all the service endpoint types and tasks necessary for you to work with Docker.

Docker images
(圖 42) Docker 映像(Figure 42) Docker images

SonarQube 導致提取要求檢視SonarQube results in pull request view

如果為合併提取要求所執行的組建包含 SonarQube MSBuild 工作,您現在會看到新的程式碼分析問題顯示為提取要求中的討論註解 (圖 43)。If the build run to merge a pull request contains SonarQube MSBuild tasks, you will now see new code analysis issues as discussion comments in the pull request (Figure 43). 凡將外掛程式安裝在 SonarQube 伺服器的所有語言都會經歷這項體驗。This experience works for any language for which a plug-in is installed on the SonarQube server. 如需詳細資訊,請參閱 SonarQube Code Analysis issues integration into Pull Requests (將 SonarQube 程式碼分析問題整合至提取要求) 部落格文章。For more information, see the SonarQube Code Analysis issues integration into Pull Requests blog post.

SonarQube pull requests
(圖 43) SonarQube 提取要求(Figure 43) SonarQube pull requests

組態狀態 API 報告組建定義Configure status API reporting for a build definition

您現在可以選擇哪些組建定義向 Git 狀態 API 回報其狀態。You can now choose which build definitions report their status back to the Git status API. 如果您有多項定義組建指定的儲存機制或分支,但只有一項代表實際的健康狀態,這特別有用。This is particularly useful if you have many definitions that build a given repository or branch, but only have one that represents the real health.

如需詳細資訊,請參閱 Build REST API reference (組建 REST API 參考)。For more information, see the Build REST API reference.

小組室中的組建 vNext 支援Build vNext support in team rooms

XAML 組建的通知一向可以在小組聊天室中新增。It has been always possible to add notifications of XAML builds in the team room. 透過這個短期衝刺,使用者也可以收到組建 vNext 完成的通知。With this sprint, users can also receive notifications from Build vNext completions.

啟用 Git CI 觸發程序的路徑篩選器Enable path filters for Git CI triggers

裝載的 Git 儲存機制的 CI 觸發程序可以包含或排除特定的路徑。CI triggers for hosted Git repositories can include or exclude certain paths. 這可讓您設定組建定義,僅在特定路徑中的檔案變更時才執行 (圖 44)This enables you to configure a build definition to run only when files in specific paths have changed (Figure 44).

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

發行管理改善 Release Management Improvements

自從 Team Foundation Server 2015 引進整合式網頁型發行管理之後,我們已在這個版本中加入了許多改進功能。Since the introduction of integrated web-based Release management in Team Foundation Server 2015, we have made several enhancements in this version.

複製、匯出和匯入發行定義Clone, export, and import release definitions

我們已在發行中樞內納入複製、匯出和匯入發行定義的功能,而不需要安裝延伸模組 (圖 45)We have incorporated the ability to clone, export, and import release definitions within Release hub, without requiring installation of an extension (Figure 45).

Clone and export commands on release summary page
(圖 45) [發行摘要] 頁面上的複製和匯出命令(Figure 45) Clone and export commands on release summary page

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

測試結果會顯示於發行摘要中Test results displayed in the release summary

在發行摘要頁面中,我們已啟用外部服務的貢獻點,以顯示環境特定資訊。In the release summary page, we have enabled a contribution point for an external service to show environment-specific information.

在 Team Services 中,當測試作為發行環境的一部分執行時,此功能可用於顯示測試結果的摘要 (圖 46)In Team Services, this functionality is used to display a summary of test results when tests are run as part of a release environment (Figure 46).

Test results displayed in the release summary
(圖 46) 發行摘要中顯示的測試結果(Figure 46) Test results displayed in the release summary

如需詳細資訊,請參閱 Understand the summary view of a release (了解發行的摘要檢視) 文件。For more details, see Understand the summary view of a release documentation.

將 OAuth 權杖傳遞至指令碼Pass OAuth tokens to scripts

如果您需要執行自訂 PowerShell 指令碼,以在 Team Services 上叫用 REST API (可能是為了建立工作項目或查詢組建中的資訊),您需要在指令碼中傳遞 OAuth 權杖。If you need to run a custom PowerShell script that invokes the REST APIs on Team Services, perhaps to create a work item or query a build for information, you need to pass the OAuth token in the script.

當您設定環境時,此新選項可將指令碼作為環境中的工作來執行,以存取目前的 OAuth 權杖 (圖 47)A new option when you configure an environment allows scripts to run as tasks in the environment to access the current OAuth token (Figure 47).

Pass OAuth tokens to scripts
(圖 47) 將 OAuth 權杖傳遞至指令碼(Figure 47) Pass OAuth tokens to scripts

如需詳細資訊,請參閱 Environment general options (環境的一般選項) 文件。For more details, see Environment general options documentation.

這是一個簡單的範例,示範如何取得組建定義 (圖 48)This is a simple example showing how to get a build definition (Figure 48):

Example script using passed oAuth token
(圖 48) 使用所傳遞 oAuth 權杖的範例指令碼(Figure 48) Example script using passed oAuth token

部分成功部署上的觸發程序Trigger on partially successful deployments

建置與發行工作在每個工作的 [控制選項] 參數中,具有於 [發生錯誤時繼續] 的選項。Build and release tasks have an option to Continue on error in the Control Options parameters for each task.

在組建定義中,如果有工作已設定此選項並且失敗,將會導致「組建已部分成功」的結果。In a build definition, this results in a Build partially succeeded result if a task with this option set should fail.

發行定義中目前已提供相同的行為。The same behavior is now available in release definitions. 如果工作失敗,整體發行結果會顯示為「發行已部分成功」(圖 49)If a task fails, the overall release result will show as "Release partially succeeded" (Figure 49).

Release summary shows partially successful releases in orange color
(圖 49) 發行摘要會以橙色顯示部分成功的版本(Figure 49) Release summary shows partially successful releases in orange color

根據預設,部分成功的發行不會自動觸發針對後續環境的發行,即使此行為已在環境部署選項中指定。By default, a partially successful release will not automatically trigger a release to a subsequent environment, even if this behavior is specified in the environment deployment options.

不過,有一個新的選項可以在每個發行環境中設定,以在先前的發行為部分成功的情況下,指示發行管理觸發針對後續環境的發行 (圖 50)However, a new option can be set in each release environment that instructs Release Management to trigger a release to a subsequent environment when the previous release is partially successful (Figure 50).

Setting the option to trigger from a partially successful release
(圖 50) 設定選項以從部分成功的版本進行觸發(Figure 50) Setting the option to trigger from a partially successful release

如需詳細資訊,請參閱 Environment deployment triggers (環境的部署觸發程序) 文件。For more details, see Environment deployment triggers documentation.

直接使用儲存在 GitHub 中的成品Consume artifacts stored in GitHub directly

有時候,您可能會想要在不經過建置程序的情況下,直接使用儲存在版本控制系統中的成品,如本主題中所述。Sometimes you may want to consume artifacts stored in a version control system directly, without passing them through a build process, as described in this topic.

現在,如果您的程式碼儲存在 GitHub 存放庫中,您也可以這麼做 (圖 51)You can now do the same if your code is stored in a GitHub repository (Figure 51).

Linking code in a GutHub repository to a release definition
(圖 51) 將 GutHub 存放庫中的程式碼連結至版本定義(Figure 51) Linking code in a GutHub repository to a release definition

如需詳細資訊,請參閱 TFVC, Git, and GitHub sources (TFVC、Git 和 GitHub 來源) 文件。For more details, see TFVC, Git, and GitHub sources documentation.

使用 ARM 的 Web 應用程式部署Web App Deployment using ARM

Azure Web 應用程式部署工作有新的版本可用,稱為 AzureRM Web 應用程式部署A new version of the Azure Web App Deployment task is available, called AzureRM Web App Deployment.

它使用 MSDeploy 和 Azure Resource Manager 服務端點連線。It uses MSDeploy and an Azure Resource Manager service endpoint connection. 除了 ASP.NET 4、Node 和 Python Web 應用程式之外,使用此工作可部署 Azure Web 工作和 Azure API 應用程式。Use this task to deploy Azure Web Jobs and Azure API apps, in addition to ASP.NET 4, Node, and Python based web apps.

此工作也支援常見的發佈選項,例如保留應用程式資料、將應用程式離線及移除目的端其他檔案的能力。The task also supports common publishing options such as the ability to retain app data, take an app off-line, and remove additional files at the destination.

未來版本可能會出現更多功能,例如組態轉換 (圖 52)More features, such as configuration transformations, may appear in forthcoming versions (Figure 52).

Web app deployment using ARM
(圖 52) 使用 ARM 的 Web 應用程式部署(Figure 52) Web app deployment using ARM

工作群組Task groups

「工作群組」可讓您將組建或發行定義中已定義的工作序列,封裝成可重複使用的單一工作,以便如同任何其他工作一樣新增至組建或發行定義 (圖 53)。A task group lets you encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task that can be added to a build or release definition just like any other task (Figure 53).

您可以選擇從封裝式工作擷取參數作為組態變數,並摘要其餘的工作資訊。You can choose to extract the parameters from the encapsulated tasks as configuration variables, and abstract the rest of the task information.

新的工作群組會自動加入工作目錄,以準備加入其他發行和組建定義。The new task group is automatically added to the task catalogue, ready to add to other release and build definitions.

Linking code in a GutHub repository to a release definition
(圖 53) 將 GutHub 存放庫中的程式碼連結至版本定義(Figure 53) Linking code in a GutHub repository to a release definition

如需詳細資訊,請參閱 Task Groups (工作群組) 文件。For more details, see Task Groups documentation.

發行的虛刪除Soft delete of releases

當您刪除某個發行或由保留原則自動刪除時,該發行會從 [概觀] 和 [詳細資料] 清單中移除。When you delete a release, or it is automatically deleted by a retention policy, the release is removed from the overview and details lists.

不過,它會隨發行定義保留一段期間 (通常是 14 天),再永久刪除。However, it is retained with the release definition for a period (typically 14 days) before it is permanently deleted.

在這段期間,它會顯示在 [概觀] 和 [詳細資料] 清單的 [已刪除] 索引標籤中。During this period, it is shown in the Deleted tab of the overview and details lists.

您可以開啟捷徑功能表並選擇 [取消刪除],以還原任何發行 (圖 54)You can restore any of these releases by opening the shortcut menu and choosing Undelete (Figure 54).

Undelete releases
(圖 54) 取消刪除發行(Figure 54) Undelete releases

如需詳細資訊,請參閱 Restore deleted releases (還原已刪除的發行) 文件。For more details, see Restore deleted releases documentation.

保留每個環境的發行和組建Retain releases and builds for each environment

發行定義的發行保留原則會決定發行及其連結之組建的保留時間。The release retention policy for a release definition determines how long a release and the build linked to it are retained.

根據預設,發行會保留 60 天 - 在這段期間尚未部署或修改的發行將會自動予以刪除。By default, a release is retained for 60 days - releases that have not been deployed or modified during that time will automatically be deleted.

不過,您可能想要保留已部署至特定環境 (例如生產環境) 的多個發行,或將這些發行保留得比部署至其他環境 (例如測試、預備和 QA) 的發行更久。However, you may want to retain more releases that have been deployed to specific environments, such as your production environment, or retain them longer than those that were just deployed to other environments such as test, staging, and QA.

如果您需要重新部署該發行,也可以在保留發行的期間,保留連結至發行的組建,以確保成品可供使用 (圖 55)You can also retain the build linked to a release for the same period as the release to ensure that the artifacts are available if you need to redeploy that release (Figure 55).

Retain releases
(圖 55) 保留發行(Figure 55) Retain releases

如需詳細資訊,請參閱 Release and build retention (發行和組建保留) 文件。For more details, see Release and build retention documentation.

連結成品改善Linked artifact improvements

您可以透過兩項新功能,輕鬆地使用成品和成品來源:Two new features make it easier to work with artifacts and artifact sources:

  • 您可以將多個成品來源連結至發行定義 (圖 56)。You can link multiple artifact sources to a release definition (Figure 56). 每個成品都會下載至代理程式上的資料夾,稱為來源別名。Each of the artifacts is downloaded into a folder on the agent called the source alias. 您現在可以編輯連結成品的來源別名。You can now edit the source alias of a linked artifact. 例如,當您變更組建定義的名稱時,您可以編輯來源別名,以反映組建定義的名稱。For example, when you change the name of the build definition, you can edit the source alias to reflect the name of the build definition.
Linked artifact improvements
(圖 56) 連結成品改善(Figure 56) Linked artifact improvements
For more details, see [Artifact source alias]( documentation.
  • 工作參數中會公開使用格式為 Build.* 的一些變數 (例如 Build.BuildId and Build.BuildNumber)。A number of variables of the format Build.* (such as Build.BuildId and Build.BuildNumber) are exposed for use in task parameters. 如果有多個來源與某個發行相關聯,這些變數現在會填入指定為主要來源之成品來源中的值。When multiple sources are associated with a release, these variables are now populated with values from the artifact source you specify as the primary source. 如需詳細資訊,請參閱 Artifact variables (成品變數) 文件。For more details, see Artifact variables documentation.

部署 - 手動操作工作Deployment - Manual Intervention task

您現在可以在環境部署期間暫停執行。You can now pause execution during deployment to an environment.

在環境中加入手動操作工作可讓您暫時停止部署、執行手動步驟,再繼續進行其他自動化步驟。Including a Manual Intervention task in an environment enables you to temporarily halt a deployment, perform manual steps, and then resume further automated steps.

您也可以拒絕部署,以防止在手動操作之後執行其他步驟 (圖 57)You can also reject the deployment and prevent further steps from executing after a manual intervention (Figure 57).

Manual intervention task
(圖 57) 手動操作工作(Figure 57) Manual intervention task

如需詳細資訊,請參閱 Manual intervention (手動操作) 文件。For more details, see Manual intervention documentation.

SQL Database 部署工作指令碼SQL Database deployment task scripts

Azure SQL Database 部署 (圖 58) 工作已經增強,現在可對 Azure SQL Database 執行 SQL 指令碼。The Azure SQL Database Deployment (Figure 58) task has been enhanced to run SQL scripts against an Azure SQL Database. 指令碼可以檔案形式提供,或內嵌在工作中。The scripts can be provided as a file, or inline within the task.

SQL database deployment task scripts
(圖 58) SQL Database 部署工作指令碼(Figure 58) SQL database deployment task scripts

發行定義摘要 - 儀表板 WidgetRelease definition summary - dashboard widget

將發行定義釘選到儀表板 - 一個讓全部的小組成員都能看到該定義發行摘要的簡易方式。Pin a release definition to the dashboard - an easy way to make a summary of releases for that definition visible to all your team.

如需詳細資訊,請參閱 Add release information to the dashboard (將發行資訊新增至儀表板) 文件。For more details, see Add release information to the dashboard documentation.

於指定的時間針對特定環境宣傳發行Promote releases to an environment at a specific time

想要讓所有的生產環境部署都在午夜發生嗎?Want all your production deployments to happen at midnight? 您可以在某個環境上設定條件,以從另一個環境選取一項成功的部署 (或是最新的部署),並在指定的時間部署它 (圖 59)You can configure a condition on an environment that selects a successful deployment (or just the latest one) from another environment, and deploys it at the specified time (Figure 59).

Schedule release to an environment
(圖 59) 針對特定環境排定發行(Figure 59) Schedule release to an environment

根據多個環境中的條件進行部署Deploy based on conditions in multiple environments

在先前的版本中,您可以執行平行部署 (「分岔部署」),但是您無法根據多個環境的狀態對某個環境開始進行部署 (「聯結部署」)。Until the previous version, you could do parallel deployments (forkdeployments), but you could not start a deployment to an environment based on the status of multiple environments (join deployments). 現在您可以這麼做了。Now you can.

如需詳細資訊,請參閱 Parallel forked and joined deployments (已平行分叉部署和已連結部署) 文件。For more details, see Parallel forked and joined deployments documentation.

適用於發行管理的 REST APIREST APIs for release management

您可以使用適用於發行管理服務的 REST API 來建立發行定義和發行,以及管理部署發行的各個層面。You can use the REST APIs for the Release Management service to create release definitions and releases, and manage many aspects of deploying a release.

如需詳細資訊,請參閱 API 參考文件For more information, see the API reference documentation. 如需一些使用 API 的基本範例,請參閱這篇部落格文章:Using ReleaseManagement REST API’s (使用 ReleaseManagement REST API)。You'll find some basic examples that use the APIs in this blog post, Using ReleaseManagement REST API’s.

服務勾點整合Service hooks integration

在建立新發行、開始或完成部署,或是暫止或完成核准時傳送發行通知。Send release notifications when new releases are created, deployments are started or completed, or when approvals are pending or completed. 整合協力廠商工具 (例如 Slack) 以接收這類通知。Integrate with third party tools such as Slack to receive such notifications.

Azure 國家/地區雲端部署Deployment to national Azure clouds

使用 Azure 傳統服務端點中以特定 Azure 雲端為目標的新 [環境] 設定,包括預先定義的國家/地區雲端,例如 Azure 中國雲端、Azure 美國政府雲端和 Azure 德國雲端 (圖 60)Use the new Environment setting in an Azure Classic service endpoint to target a specific Azure cloud, including pre-defined national clouds such as Azure China cloud, Azure US Government cloud, and Azure German cloud (Figure 60).

Deployment to national Azure clouds
(圖 60) Azure 國家/地區雲端部署(Figure 60) Deployment to national Azure clouds

如需詳細資訊,請參閱 Azure Classic service endpoint (Azure 傳統服務端點) 文件。For more details, see Azure Classic service endpoint documentation.

測試改善 Test Improvements

Team Foundation Server 2017 中已加入索引鍵的測試改善。Key test improvements have been added in Team Foundation Server 2017.

已更新測試結果儲存體結構描述Updated test result storage schema

我們在本版中要將測試結果成品移轉至精簡而有效率的新儲存體結構描述。In this release, we are migrating the test result artifacts to a new compact and efficient storage schema. 由於測試結果是 TFS 資料庫儲存空間首要取用者的其中之一,我們希望這項功能可以轉譯成 TFS 資料庫已減少的儲存體使用量。Since test results are one of the top consumers of storage space in TFS databases, we expect this feature to translate into reduced storage footprint for TFS databases. 若為從舊版 TFS 升級的客戶,測試結果會在 TFS 升級期間移轉至新的結構描述。For customers who are upgrading from earlier versions of TFS, test results will be migrated to the new schema during TFS upgrade. 這項升級作業可能耗用相當長的時間,視資料庫有多少測試結果資料而定。This upgrade may result in long upgrade times depending on how much test result data exists in your databases. 建議您設定 test retention policy,等候原則開始運作並減少測試結果使用的儲存體,以利縮短 TFS 升級時間。It’s advisable to configure the test retention policy and wait for the policy to kick in and reduce the storage used by test results so that the TFS upgrade will be faster. 在安裝 TFS 後,但在升級 TFS 執行個體之前,您可以使用 TFSConfig.exe 工具來清除測試結果。After installing TFS, but before upgrading the TFS instance, you can use the TFSConfig.exe tool to clean up test results. 請參閱 TFSConfig.exe 說明以取得詳細資料。See TFSConfig.exe help for more details. 如果您在升級之前沒有設定測試保留期或清除測試結果的彈性,請確定您已針對升級時機做出適當的規劃。If you don’t have the flexibility to configure test retention or clean up test results before upgrade, make sure you plan accordingly for the upgrade window. 如需更多的設定測試保留原則範例,請參閱 Test result data retention with Team Foundation Server 2015 (使用 Team Foundation Server 2015 測試結果資料保留)。See Test result data retention with Team Foundation Server 2015 for more examples about configuring test retention policy.

測試中樞改善Test Hub improvements

在測試中樞測試組態管理Test configuration management in Test Hub

我們也在測試中樞內新增 [組態] 索引標籤,為 Web UI 帶來測試組態管理 (圖 61)。We’ve brought test configuration management to the web UI by adding a new Configurations tab within the Test Hub (Figure 61). 現在您可以從測試中樞內建立和管理測試組態及測試組態變數。Now you can create and manage test configurations and test configuration variables from within the Test hub.

Configurations hub
(圖 61) 設定中樞(Figure 61) Configurations hub

如需詳細資訊,請參閱 Create configurations and configuration variables (建立組態和組態變數)。For more information, see Create configurations and configuration variables.

將組態指派給測試計劃、測試套件和測試案例Assigning configurations to test plans, test suites, and test cases

指派組態變得更容易了:您可以直接在測試中樞內將測試組態指派給測試計劃、測試套件或測試案例 (圖 62)。Assigning configurations just got easier - you can assign test configurations to a test plan, test suite, or test case(s) directly from within the Test hub (Figure 62). 以滑鼠右鍵按一下項目,然後選取 [Assign configurations to …] (將組態指派給...),即開始執行。Right-click an item, select Assign configurations to …, and you’re off and running. 您也可以在測試中樞內依組態篩選 (圖 63)You can also filter by Configurations in the Test hub (Figure 63).

Assign Configurations
(圖 62) 指派設定(Figure 62) Assign Configurations
Configurations Filter
(圖 63) 設定篩選(Figure 63) Configurations Filter

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

在 [測試結果] 窗格中檢視測試計劃/測試套件資料行View test plan/test suite columns in test results pane

我們已在 [測試結果] 窗格中加入新的資料行,向您顯示在其下執行測試結果的測試計劃和測試套件。We’ve added new columns to the Test results pane that show you the test plan and test suite under which the test results were executed in. 這些資料行會在深入探索測試結果時,提供更多的內容 (圖 64)These columns provide much-needed context when drilling into results for your tests (Figure 64).

Test Results Pane
(圖 64) 測試結果窗格(Figure 64) Test results pane
排序測試中樞和卡片上的測試Ordering of tests in Test Hub & on cards

您現在可以從測試中樞 (圖 65) 內排序手動測試,無論其所在套件類型為何︰靜態的、需求型或查詢式套件。You can now order manual tests from within the Test Hub (Figure 65), irrespective of the type of suite in which they’re included: static, requirement-based, or query-based suites. 只要拖放一或多個測試或使用內容功能表,即可重新排序測試。You can simply drag and drop one or more tests or use the context menu to reorder tests. 完成排序時,您可以依 [順序] 欄位排序測試,然後從 Web 執行器中依序執行。Once the ordering is completed, you can sort your tests by the Order field and then run them in that order from the Web runner. 也可以直接在工作流程看板上的使用者劇本卡片上排序測試 (圖 66)。You can also order the tests directly on a user story card on the Kanban board (Figure 66). 這樣會完成手動測試下其中一個長時間擱置的使用者語音項目 (495 張票)。This completes one of the long-pending user voice items (with 495 votes) under manual testing.

Order tests
(圖 65) 排序測試(Figure 65) Order tests
Order tests on card
(圖 66) 卡片上的排序測試(Figure 66) Order tests on card
在測試中樞中排序測試套件Order test suites in Test Hub

測試小組現在可以根據需排序測試套件 - 在此功能推出之前,套件僅能依字母順序排序。Test teams can now order the test suites as per their needs – prior to this capability, the suites were only ordered alphabetically. 現在,透過使用測試中樞中的拖放功能,使用者可以在對等套件之間重新排序套件,或是將套件移至階層中的另一個套件 (圖 67)。Now, using the drag/drop capability in Test hub, suites can be re-ordered among the peer suites or moved to another suite in the hierarchy (Figure 67). 這將能解決下列位於手動測試/測試案例管理下的 user voice 項目。This addresses the following user voice item under manual testing/test case management.

Order Test suites
(圖 67) 排序測試套件(Figure 67) Order Test suites
作為指派測試人員的一部分搜尋使用者Search for users as part of assigning testers

作為在不同中樞推出全新身分識別選取器控制項的一部分,我們在測試中樞中也啟用了在指派一或多個測試的測試人員時搜尋使用者的選項 圖 68)(As part of the rollout of new identity picker controls across the different hubs, in Test hub, we have also enabled the option to search for users when assigning testers to one or more tests (Figure 68). 這在小組成員數目龐大時特別有用,但操作功能表只會顯示有限的項目 *(圖 69)。This is extremely useful in scenarios where the number of team members is large, but the context menu only shows a limited set of entries *(Figure 69).

Search users
(圖 68) 搜尋使用者(Figure 68) Search users
Assign Users
(圖 69) 指派使用者(Figure 69) Assign Users
挑選要測試的組建Pick a build to test with

您現在可以在測試中樞 (圖 70) 中使用 [以選項執行],選擇您想要測試的「組建」並啟動 Web 執行器。You can now pick the “build” you want to test with and then launch the Web runner, using ‘Run with options’ in Test hub (Figure 70). 執行期間所提報的任何 Bug,將會自動與選取的組建產生關聯。Any bug filed during the run will automatically be associated with the build selected. 此外,系統會針對該特定組建發佈測試結果。In addition, the test outcome is published against that specific build.

Pick a build
(圖 70) 挑選組建(Figure 70) Pick a build
從測試中樞使用資料收集器啟動 Microsoft 測試執行器用戶端Launch Microsoft Test Runner client from Test Hub with data collectors

您現在可以選擇要與測試回合 (圖 71) 建立關聯的資料收集器與組建,並從測試中樞以具效能的方式啟動 Microsoft 測試執行器 2017 (用戶端),而不用在 Microsoft Test Manager 用戶端中針對它們加以設定。You can now choose your data collectors & build to associate with the test run (Figure 71), and launch the Microsoft Test Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. Microsoft 測試執行器會在不需開啟整個 Microsoft Test Manager 殼層的情況下啟動,且會在測試執行完成時關閉。The Microsoft Test Runner will be launched without opening the entire Microsoft Test Manager shell and will shut-down on completion of the test execution.

Run with options
(圖 71) 以選項執行(Figure 71) Run with options

如需詳細資訊,請參閱 Run tests for dektop apps (針對傳統應用程式執行測試)。For more information, see Run tests for desktop apps.

選擇資料收集器並從測試中樞啟動 Exploratory Runner 用戶端Choose data collectors and launch Exploratory Runner client from Test hub

您現在可以選擇資料收集器,並從測試中樞以具效能的方式啟動 Exploratory Runner 2017 (用戶端),而不用在 Microsoft Test Manager 用戶端中針對它們加以設定。You can now choose your data collectors and launch the Exploratory Runner 2017 (client) in a performant way from Test hub, without having to configure them in Microsoft Test Manager client. 從操作功能表 (圖 72) 為需求式套件叫用 [以選項執行],然後選擇 Exploratory Runner 以及您所需的資料收集器。Invoke 'Run with options' from the context menu (Figure 72) for a Requirement based suite and choose Exploratory runner and the data collectors you need. 將以上方所述類似 Microsoft 測試執行器的方式啟動 Exploratory Runner。The Exploratory runner will be launched similar to Microsoft Test Runner as described above.

Run with Options - XT
(圖 72) 以選項執行 - XT(Figure 72) Run with Options - XT
跨不同測試套件為測試設定測試結果Configure test outcomes for tests across different test suites

現已新增可在相同測試計劃下為不同測試套件共用的測試設定測試結果的行為 (圖 73)。We have now added the ability to configure the behavior of test outcomes for tests shared across different test suites under the same test plan (Figure 73). 若選取此選項並設定測試的結果 (從測試中樞、Web 執行程式,Microsoft 測試執行器,或工作流程看板上的卡片,將其標示為通過/失敗/已封鎖),該結果會以相同的組態,在相同測試計劃下跨不同測試套件傳播到所有存在的其他測試。If this option is selected, and you set the outcome for a test (mark it as Pass/Fail/Blocked either from the Test hub, Web runner, Microsoft Test Runner, or from cards on Kanban board), that outcome will propagate to all the other tests present across different test suites under the same test plan, with the same configuration. 使用者可從測試中樞測試計劃操作功能表,或從 [常見設定組態] 對話方塊中的工作流程看板測試頁面,設定特定測試計劃的 [設定測試結果] 選項。Users can set the “Configure test outcomes” option for a particular test plan either from the Test hub test plan context menu or from the Kanban board test page in the common settings configuration dialog. 預設會關閉此選項,您必須明確加以啟用才會生效。This option is turned off by default and you will have to explicitly enable it to take effect.

Configure test outcomes
(圖 73) 設定測試結果(Figure 73) Configure test outcomes
驗證工作項目中的 BugVerify bugs from work item

您現在可以重新執行識別 Bug 的測試來驗證 Bug (圖 74)。You can now verify a bug by re-running the tests which identified the bug (Figure 74). 您可以從 Bug 工作項目表單操作功能表叫用 [驗證] 選項,以啟動 Web 執行器中的相關測試案例。You can invoke the Verify option from the bug work item form context menu to launch the relevant test case in the web runner. 請使用 Web 執行器執行驗證,並在 Web 執行器內直接更新 Bug 工作項目。Perform your validation using the web runner and update the bug work item directly within the web runner.

Verify bugs
(圖 74) 驗證 Bug(Figure 74) Verify bugs
用於測試計劃/測試套件複製的 REST APIREST APIs for test plan / test suite clone

我們已新增 REST API 以複製測試計劃和測試套件。We've added REST APIs for cloning of test plans and test suites. 您可以在 Team Services 整合網站的 [測試管理] 區段下找到它們。You can find them under the Test Management section on our Team Services Integrate site.

從工作流程看板卡測試進度Test progress from your Kanban cards

您現在可以直接從工作流程看板上的劇本新增、檢視測試案例,並與之互動。You can now add, view, and interact with test cases directly from your stories on the Kanban board. 使用新的 [新增測試] 功能表選項來建立連結的測試案例,然後直接從作為項目進度的卡片監視狀態 (圖 75)Use the new Add Test menu option to create a linked Test case, and then monitor status directly from the card as things progress (Figure 75).

Inline tests
(圖 75) 內嵌測試(Figure 75) Inline tests

使用這項新功能,您現在可以直接在面板卡上執行下列動作︰With this new capability, you can now perform the following actions directly from a card on your board:

  • 加入測試。Add tests.
  • 開啟測試。Open tests.
  • 在使用者劇本之間拖放測試以重設測試。Reparent a test by dragging/dropping from one user story to another.
  • 使用 CTRL+拖放,將相同的測試複製到另一個使用者劇本 (適用於以同一測試案例測試多個使用者劇本的案例)。Copy the same test to another user story using CTRL+Drag/Drop (for scenarios where the same test case tests more than one user story).
  • 快速標示通過/失敗/等等,以更新測試狀態。Update the test status by quickly marking it Pass/Fail/etc.
  • 在 Web 測試執行器中啟動測試來執行測試,在此可以通過或失敗個別步驟、報告 Bug 等等。Run the test by launching it in the Web Test Runner, from which you can pass or fail individual steps, file bugs, etc.
  • 檢視指出該劇本通過多少測試及保留多少測試的彙總狀態摘要。View a summary of the roll-up status indicating how many tests have passed and how many remain for that story.

如果您需要進階的測試管理功能 (如指派測試人員、指派組態、集中化參數、匯出測試結果等等),您可以再切換至測試中樞,開始使用已自動為您建立的預設測試計劃/需求式套件。If you need advanced test management capabilities (like assign testers, assign configurations, centralized parameters, exporting test results, etc.), you can then switch over to Test Hub and start using the default test plan/requirement-based suites that have been auto-created for you. 如需詳細資訊,請參閱 Add, run, and update inline tests (新增、執行和更新內嵌測試)。For more information, see Add, run, and update inline tests.

從卡片周遊至測試計劃/測試套件Traverse to a test plan/test suite from the card

您現在可以直接從工作流程看板上的卡片,輕鬆地周遊至建立測試的基礎測試計劃/測試套件。You can now easily traverse to the underlying test plan/test suite under which the tests are created, directly from a card on the Kanban board. 按一下此連結 (圖 76) 將會帶您前往測試中樞、開啟正確的測試計劃,然後選取控制那些內嵌測試的特定套件。Clicking on this link (Figure 76) will take you to the Test hub, open the right test plan, and then select the specific suite that controls those inline tests.

Traverse to plan/suite
(圖 76) 周遊至計劃/套件(Figure 76) Traverse to plan/suite
工作流程看板一般設定組態中的測試頁面Test page in common settings configuration of Kanban board

現在,透過使用工作流程看板上一般設定組態對話方塊中的新測試頁面,您將可以控制建立內嵌測試的測試計劃 (圖 77)。Use the new Tests page in common settings configuration dialog on Kanban board to control the test plan where the inline tests are created (Figure 77). 之前,在卡片上建立的所有測試都會自動新增至新建立的測試計劃 (前提是沒有符合該卡片區域與反覆項目路徑的測試計劃)。Previously, any tests created on a card would automatically be added to a newly created test plan, provided no test plans existed that matched the area & iteration paths of the card. 現在,您可以透過設定您選擇的現有測試計劃來覆寫此行為,之後所有的測試將會新增至選取的測試計劃。Now, you can override this behavior by configuring an existing test plan of your choice – all the tests will then be added to the selected test plan going forward. 請注意,此功能僅在測試註釋開啟時啟用。Note that this functionality is only enabled if the Test annotation is turned on.

Common settings
(圖 77) 一般設定(Figure 77) Common settings

Web 執行器增強功能Web runner enhancements

在手動測試期間加入測試步驟附件Add test step attachments during manual testing

我們已增強 Web 測試執行器,讓您能夠在手動測試期間新增測試步驟附件 (圖 78)。We’ve enhanced the Web test runner to give you the ability to add test step attachments during manual testing (Figure 78). 這些步驟的結果附件會自動出現在您於工作階段報告的任何 Bug 中,以及後續的 [測試結果] 窗格中。These step result attachments automatically show up in any bugs you file in the session and subsequently in the Test results pane.

Test Step attachments
(圖 78) 測試步驟附件(Figure 78) Test Step attachments
Web 執行器中支援的螢幕擷取畫面、螢幕錄製、影像動作記錄和系統資訊 (使用 Chrome 瀏覽器)Screenshot, screen recording, image action log and system info support in Web runner (using Chrome browser)

在 Chrome 中使用 Web 執行器時,您現在可以拍攝螢幕擷取畫面,並內嵌標註 (圖 79)。You can now take screenshots and annotate them inline when you use Web runner in Chrome (Figure 79). 您不只可以擷取 Web 應用程式的隨選螢幕錄製,也可以擷取傳統應用程式的隨選螢幕錄製。You can also capture on-demand screen recordings of not just the web apps, but also your desktop apps. 這些螢幕擷取畫面和螢幕錄製都會自動加入目前的測試步驟。These screenshots and screen recordings are automatically added to the current Test step. 除了螢幕擷取畫面與螢幕錄製之外,您也可以從您的 Web 應用程式擷取隨選影像動作記錄。In addition to screenshots & screen recordings, you can also capture on-demand image action log from your web apps. 您需要指定要擷取動作的瀏覽器視窗 - 該視窗上的所有動作 (任何現有或在該視窗開啟的新索引標籤) 或任何您所啟動的新子瀏覽器視窗,將會針對 Web 執行器中正在測試的測試步驟自動擷取並產生關聯。You need to specify the browser window on which to capture your actions – all actions on that window (any existing or new tabs you open in that window) or any new child browser windows you launch, will automatically be captured and correlated against the test steps being tested in the Web runner. 這些螢幕擷取畫面、螢幕錄製和影像動作記錄將會加入您在執行期間所提報的任何 Bug,並會附加至目前的測試結果。These screenshots, screen recordings and image action logs are then added to any bugs you file during the run and attached to the current test result. 同樣地,會自動擷取系統資訊資料,並包含為您從 Web 執行器報告之任何 Bug 的一部分。Similarly, the system information data is automatically captured and included as part of any bugs you file from the Web runner. 全部都會利用 Chrome 型測試與意見反應擴充功能的功能。All these leverage the capability from the Chrome-based Test & Feedback extension.

Web runner using Chrome browser
(圖 79) 使用 Chrome 瀏覽器的 Web 執行器(Figure 79) Web runner using Chrome browser

如需詳細資訊,請參閱 Collect diagnostic data during tests (在測試期間收集診斷資料)。For more information, see Collect diagnostic data during tests.

Bug 回報為子系 - Web 執行器/測試與意見反應延伸模組Bugs filed as children – Web runner/test & feedback extension

在 Web 執行器中執行測試時,從面板卡片或從測試中樞的需求式套件啟動,所有回報的新 Bug 現在都會自動建立為該使用者劇本的子項。When running tests in Web runner, launched either from a card on the board or from a requirement-based suite in Test hub, any new bugs filed will now be automatically created as a child to that user story. 同樣地,如果您從探勘測試擴充功能來探索使用者劇本,您報告的任何新 Bug 也會建立為該使用者劇本的子項。Similarly, if you are exploring a user story from the exploratory testing extension, any new bugs you file will also be created as a child to that user story. 這項新行為讓跨劇本和 Bug 的追蹤更簡單。This new behavior allows for simpler traceability across stories and bugs. 只有在 [一般設定] 之 [組態] 頁面中的 [使用 Bug] 設定設為 [Bug 不會出現在待處理項目或面板上] 或 [Bug 會出現在待處理項目和面板上,並有工作] 時才適用。This is applicable only if the “Working with bugs” settings in the Common Settings Configuration page is set to “Bugs do not appear on backlogs or board” or "Bugs appear on the backlogs and boards with tasks". 針對 [使用 Bug] 選項的所有其他設定,以及在某些其他情況下,例如加入已定義父項的現有 Bug,會改為建立相關的連結。For all other settings for “Working with bugs” option and in certain other scenarios, such as adding to an existing bug that already has a parent defined, a Related link will be created instead.

從 Web 執行器更新現有的 BugUpdate existing bugs from Web runner

除了從 Web 執行器建立新的 Bug 之外,您現在也可以更新現有的 Bug (圖 80)。In addition to creating new bugs from the Web runner, now you can also update an existing bug (Figure 80). 所有收集的診斷資料、重新產生步驟及可從目前工作階段追蹤的連結,都會自動加入現有的 Bug。All the diagnostic data collected, repro steps, and links for traceability from the current session are automatically added to the existing bug.

Add to existing bug
(圖 80) 新增至現有的 Bug(Figure 80) Add to existing bug

測試與意見反應延伸模組 - 增強功能Test & feedback extension - enhancements

以瀏覽器為基礎的測試與意見反應擴充功能可以從 Visual Studio Marketplace 進行安裝。The browser-based Test & Feedback extension can be installed from the Visual Studio Marketplace. 它支援 Visual Studio Team Services 和 Team Foundation Server (2015 或更新版本)。It supports both Visual Studio Team Services and Team Foundation Server (2015 or later).

探索工作項目Explore work items

您現在可以進行特定工作項目的探勘測試 (圖 81)。You can now do exploratory testing for a specific work item (Figure 81). 這讓您能建立所選工作項目與進行中測試工作階段的關聯,以及從延伸模組內檢視驗收準則和描述。This lets you associate the selected work item with your ongoing testing session, and view the acceptance criteria and description, from within the extension. 此功能也會在您對所選工作項目提出的 Bug 或工作之間,產生完整的可追蹤性。It also creates end-to-end traceability between bugs or tasks that you file on the selected work item. 您可以直接從工作項目,或是從延伸模組內,探索工作項目:You can explore the work item either directly from a work item, or from within the extension:

• 直接從工作項目 (圖 81):直接在產品內使用操作功能表中的 [進行探勘測試] 選項,來啟動特定工作項目的探勘測試工作階段。• Directly from a work item (Figure 81): Launch exploratory testing session for a specific work item directly from within the product using the “Do exploratory testing” option in the context menu. 我們在所有的卡片、方格和測試中樞裡都加入了進入點。We’ve added entry points on all cards, grids, and in the Test hub.

• 在延伸模組內 (圖 82):從 XT 工作階段內搜尋工作項目,然後建立它與進行中工作階段的關聯。• Within the extension (Figure 82): Search for a work item from within the XT session and then associate it with the ongoing session.

XT from card
(圖 81) 來自工作項目的 XT(Figure 81) XT from work item
Explore work item
(圖 82) 來自延伸模組的 XT(Figure 82) XT from extension

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

使用測試與意見反應擷取影像動作記錄、螢幕錄製和網頁載入資料Capture image action log, screen recordings and web page load data using test & feedback

影像動作記錄:此延伸模組提供新選項,讓您新增只要按一下即可自動導向 Bug 的步驟。Image Action Log: The extension gives you a new option to add the steps that lead you to the bug automatically with just one click. 選取 [Include image action log](包含影像動作記錄) 選項 (圖 83) 來擷取滑鼠、鍵盤及觸控動作,並直接在 Bug 或工作中新增至相對應的文字和影像。Select the “Include image action log” option (Figure 83) to capture the mouse, keyboard, and touch actions, and add the corresponding text and images directly into the bug or task.

視訊形式的螢幕錄製:您也可以使用擴充功能來擷取隨選螢幕錄製。Screen recording as video: You can also capture on-demand screen recordings using the extension. 這些螢幕錄製不只可從 Web 應用程式擷取,還可從您的桌面應用程式擷取。These screen recordings can be captured not just from the web apps, but also your desktop apps. 您可以設定此擴充功能,以自動停止螢幕錄製,並使用擴充功能的 [選項] 頁面將它們附加至所提報的 Bug。You can configure the extension to automatically stop screen recordings and attach them to a bug being filed using the extension’s “Options” page.

頁面載入資料:我們已將新的背景擷取功能新增至擴充功能 - 可擷取「網頁載入」資料。Page Load Data: We have added a new background capture capability to the extension – capturing of “web page load” data. 就像「映像動作記錄檔」擷取您在探索 Web 應用程式時所執行的動作一樣,「網頁載入」功能也會在背景以映像的形式,自動擷取網頁完成載入作業的詳細資料。Just like the “image action log” captured your actions performed on a web app being explored, in the form of images in the background, the “page load” functionality automatically captures details for a web page to complete the load operation. 相對於仰賴主觀/認知的緩慢網頁載入速度,現在您可以客觀地在 Bug 中量化緩慢的程度。Instead of relying on subjective/perceived slowness of web page load, you can objectively quantify the slowness in the bug now. 提報 Bug 之後,除了並排顯示之外,系統也會在錯誤上附加一份詳細報告,這可協助開發人員進行初始調查。Once the bug is filed, in addition to the tile view, a detailed report is also attached to the bug, which can help the developer with their initial set of investigations.

XT Image Action Log
(圖 83) XT 影像動作記錄(Figure 83) XT Image Action Log
根據影像動作記錄資料建立測試案例Create test cases based on image action log data

當您在探勘工作階段期間建立測試案例時,會自動為您填入附有影像的測試步驟 (圖 84)。When you create test cases during your exploratory session, the test steps with images are automatically filled in for you (Figure 84). 同步的測試設計和測試執行則為真正探勘測試的基礎,而這項新功能則讓它成為現實。Simultaneous test design and test execution is the basis of true exploratory testing, and this new capability makes this a reality. 您可以編輯擷取的文字、加入預期的結果、取消核取不相關的資料列,以及儲存它供即將進行/執行的測試使用。You can edit the text captured, add the expected result, uncheck rows not relevant, and save it for upcoming test passes/runs.

XT Create Test Cases
(圖 84) XT 建立測試案例(Figure 84) XT Create Test Cases

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

探勘測試工作階段深入資訊Exploratory testing session insights

您現在可以在小組或個人層級,使用測試與意見反應擴充功能,檢視於指定時段建立的已完成探勘測試工作階段。You can now view the completed exploratory testing sessions, either at a team or individual level, for a given time period created using the Test & Feedback extension. 您可以按一下 Web 存取中測試中樞群組內執行中樞的 [Recent exploratory sessions] ( 最新的探勘工作階段)連結,取得此深入資訊頁面。You can get to this insights page by clicking the “Recent exploratory sessions” link in the Runs hub within the Test Hub group in web access. 這個新檢視會協助您衍生有意義的深入資訊,包括︰This new view helps you derive meaningful insights, including:

  • 摘要檢視:顯示已探索的工作項目、已建立的工作項目和工作階段擁有者分析,以及這些工作階段耗費的總時間 (圖 85)。The summary view that shows a breakdown of the work items explored, the work items created, and the session owners, along with the total time spent on these sessions (Figure 85).
  • 分組檢視:可依已探索的工作項目、工作階段、工作階段擁有者,或是無來建立樞紐分析表。The group-by view that can be pivoted by either explored work-items, sessions, session owners, or none. 針對任何樞紐分析表,您可以檢視所有已建立的工作項目清單 (Bug、工作、測試案例),或將清單範圍限定到特定的工作項目類型。For any pivot, you can either view the list of all work items (bugs, tasks, test cases) created or scope the list down to a specific work item type.
  • 詳細資料窗格檢視會根據分組檢視中的選取項目顯示資訊。The details pane view that displays information based on selection in the group-by view. 針對選取的樞紐資料列 (假設是已探索的工作項目),您可以在詳細資料窗格中檢視其摘要資訊,例如工作階段總數、這些工作階段耗費的總工時、探索它的工作階段擁有者、針對工作階段建立的 Bug/工作/測試案例,以及它們的狀態和優先權。For a selected pivot row (say explored work items), you can view its summary information in the details pane, such as the total number of sessions, the total time spent across these sessions, the session owners who explored it, and the bugs/tasks/test cases created against it, along with their state and priority. 針對選取的工作項目資料列,您可以檢視其內嵌的工作項目表單,並適當予以變更。For a selected work item row, you can view its work item form inline and make changes as appropriate.
XT Session insights
(圖 85) XT 工作階段深入資訊(Figure 85) XT Session insights

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

探勘測試工作階段:檢視未探索的工作項目Exploratory testing sessions: View unexplored work items

除了在 [最近的探勘工作階段] 檢視中查看所有已探索工作項目的詳細資料 (依照指定日期範圍的全部/我的工作階段進行篩選) 之外,我們也在相同的檢視中新增了查看所有「尚未」探索之工作項目清單的功能 (圖 86)。In addition to seeing the details of all the explored work items in the “recent exploratory sessions” view, filtered by all/my sessions for a given date range, we have now added the ability to also see a list of all work items that have NOT been explored, in the same view (Figure 86). 您可以透過指定您感興趣之工作項目的共用查詢來開始,而工作階段頁面會顯示所有來自查詢的工作項目清單,並在 [摘要] 區段中包含已探索與未探索項目的解析。You start by specifying a shared query for work items that you are interested in and the sessions page shows a list of all the work items from the query, with a breakdown of both explored and unexplored items in the summary section. 此外,依樞紐分析分組使用 [未探索的工作項目],將可以看到尚未探索的項目清單。In addition, using the “Unexplored Work Item” group by pivot, you can see the list of items that have not been explored yet. 這對於追蹤未探索的劇本數量或尚未通過群眾挑錯的劇本特別有用。This is extremely useful to track down how many stories have not been explored or gone through a bug-bash yet.

View unexplored WIT
(圖 86) 檢視未探索的 WIT(Figure 86) View unexplored WIT
端對端專案關係人意見反應流程End to end stakeholder feedback flow
要求意見Request feedback

具有基本存取層級的使用者現在可以使用工作項目功能表中的 [要求意見] 選項,直接向專案關係人要求進行中或已完成功能/劇本的意見 (圖 87)。Users with basic access level can now request feedback from stakeholders directly for ongoing or completed features/stories using the Request Feedback option in the work item menu (Figure 87). 這會開啟 [要求意見] 表單,您可以在此選擇要徵求意見的專案關係人,並選擇性地提供一組簡單的指示,以提示需要意見的產品區域。This opens the Request feedback form where you can choose the stakeholders you want feedback from and optionally provide a simple set of instructions prompting for the areas of the product you’d like input. 這會傳送個別郵件給所選取的專案關係人,並提供指示 (如果有的話)。This will send off individual mails to the selected stakeholders along with the instructions provided, if any.

XT Feedback Flow
(圖 87) XT 意見反應流程(Figure 87) XT Feedback Flow

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

提供意見反應Provide feedback

專案關係人可以按一下所收到之郵件中的 [提供意見反應] 連結來回應意見要求,這會自動設定內含所選取意見要求的測試與意見反應擴充功能 (先前稱為探勘測試擴充功能);如果尚未安裝此擴充功能,則會提示安裝。Stakeholders can respond to the feedback request by clicking the Provide feedback link in the mail they received, which automatically configures the Test & Feedback extension (formerly Exploratory Testing extension) with the selected feedback request (it will prompt to install the extension, if not already installed). 專案關係人接著可以使用此擴充功能的完整擷取功能來擷取結果,並以意見回應/Bug/任務工作項目的格式來送出意見。Stakeholders can then use the full capture capabilities of the extension to capture their findings and submit their feedback in the form of feedback response/bug/task work items. 此外,專案關係人可以巡覽至 [意見要求] 頁面,在一個位置檢視收到的所有意見要求。Additionally, stakeholders can navigate to the “Feedback requests” page to view in one place all feedback requests received by them. 他們可以從清單中選取要提供意見反應的意見要求、管理其「擱置的意見要求」 (圖 88) (將其標示為完成或予以拒絕),也可以按一下所需的選項按鈕 (圖 89) 在不同的意見要求類型之間進行切換。From the list, they can select the feedback request they want to provide feedback on, manage their “Pending feedback requests” (Figure 88) by marking them as complete or by declining them and can switch between different types of feedback requests by clicking on the desired radio button (Figure 89).

Provide feedback link
(圖 88) 提供意見反應連結(Figure 88) Provide feedback link
XT Feedback Flow
(圖 89) XT 意見反應流程(Figure 89) XT Feedback Flow

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

自發意見反應Voluntary feedback

除了上述的要求流程之外,專案關係人也可以使用此延伸模組提供自發意見反應 (圖 90)。In addition to the solicited flow mentioned above, stakeholders can also use the extension to provide voluntary feedback (Figure 90). 他們可以開啟擴充功能、在 [連線設定] 頁面中選取「已連線」模式,並連線到他們想要提供意見反應的帳戶和專案/小組。They can open the extension, select the “Connected” mode in the Connection settings page, and connect to the account and Project/Team to whom they wish to provide feedback. 接著可以使用此擴充功能來擷取結果,並以意見回應/Bug/任務工作項目的格式來送出意見。They can then use the extension to capture their findings and submit their feedback in the form of feedback response/bug/task work items.

Voluntary Feedback
(圖 90) 自發意見反應(Figure 90) Voluntary Feedback

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

自動化測試改善Automated testing improvements

組建的 [測試] 索引標籤/[發行摘要] 中的主控台記錄和測試持續時間Console logs and test duration in tests tab in build/release summary

trx 檔案中所擷取的測試結果主控台記錄會以測試結果附件形式擷取及發佈 (圖 91)。Test result console logs that are captured in .trx files are extracted and published as test result attachments (Figure 91). 您可以選擇在 [測試] 索引標籤中預覽此記錄,而不再需要下載 trx 檔案以檢視此記錄。You have an option to preview them in Tests tab, and don't need to download the trx file to view logs anymore.

Console logs and duration
(圖 91) 主控台記錄和持續時間(Figure 91) Console logs and duration
組建的測試趨勢小工具Test trend widget for builds

我們在小工具程式庫中新增「測試結果趨勢」小工具 (圖 92)。We have added a new 'Test result trend' widget to the Widget Gallery (Figure 92). 使用此 Widget 將最多 30 個特定組建定義的最新組建測試結果趨勢圖表加入儀表板。Use this widget to add a test result trend chart of up to 30 most recent builds for a build definition to the dashboard. Widget 組態選項可協助您自訂圖表,包含通過的測試計數、失敗的測試計數、總測試計數、通過百分比和測試持續時間等樞紐分析表。Widget configuration options can help you customize the chart to include pivots like passed test count, failed test count, total test count, pass percentage, and test duration.

'Test result trend' widget
(圖 92)「測試結果趨勢」小工具(Figure 92) 'Test result trend' widget
發行環境摘要的測試狀態Test status with Release Environment summary

建議您使用發行環境部署應用程式,並對它們執行測試。It’s a recommended practice to use Release Environments to deploy applications and run tests against them. 在此發行中,我們已在 [發行摘要] 頁面的 [環境] 區段中整合發行環境的測試成功率 (圖 93)。With this release, we have integrated test pass rate of Release Environments in the Environments section of the Release summary page (Figure 93). 如螢幕擷取畫面所示,如果某個環境發生失敗,您可以透過查看 [測試] 資料行,來快速推斷失敗是否是因測試失敗所造成。As shown in the screenshot, if an Environment has failed, you can quickly infer if the failure is because of failing tests by looking at the Tests column. 您可以按一下 [成功率] 以巡覽至 [測試] 索引標籤,並調查該環境失敗的測試。You can click on the pass rate to navigate to the Tests tab and investigate the failing tests for that Environment.

Test status with Release Environment summary
(圖 93) 含發行環境摘要的測試狀態(Figure 93) Test status with Release Environment summary
分支與發行環境的自動化測試歷程記錄Automated test history for branches and release environments

個別的測試會在多個分支、環境及組態上執行,這是相當常見的案例。It’s a common scenario for an individual test to run on multiple branches, environments, and configurations. 當這類測試失敗時,識別該失敗是否只發生在開發分支 (例如主要分支),或是也影響到已部署至生產環境的發行分支,是一件非常重要的事情。When such a test fails, it is important to identify if the failure is contained to development branches like the master branch or if failures are also impacting release branches that deploy to production environments. 您現在可以透過查看 [結果] 摘要頁面中的 [歷程記錄] 索引標籤,針對多個正在進行測試的分支,視覺化該測試的歷程記錄 (圖 94)。You can now visualize the history of a test across various branches that it is testing by looking at the History tab in Result summary page (Figure 94). 同樣地,您可以依 [環境] 樞紐分析分組,以視覺化執行測試之不同發行環境上的歷程記錄。Similarly, you group by the Environment pivot to visualize the history of a test across different Release Environments in which its run.

Test status with Release Environment summary
(圖 94) 含發行環境摘要的測試狀態(Figure 94) Test status with Release Environment summary
持續測試的可追蹤性Traceability with continuous testing

使用者現在可以直接在儀表板上追蹤其需求的品質 (圖 95)。Users can now track the quality of their Requirements right on their Dashboard (Figure 95). 我們已針對已規劃測試使用者的需求品質設計出解決方案,並將會提供給追蹤「連續測試」的使用者。We already have a solution for Requirements quality for our Planned testing users and we are bringing it to our users who follow Continuous Testing. 使用者將能夠直接將自動化測試連接至 [需求],然後使用「儀表板」Widget 追蹤您有興趣追蹤的需求品質,並從 [組建] 或 [發行] 提取品質資料。Users will be able to link automated tests directly to Requirements and then use Dashboard widgets to track the quality of Requirements you are interested in tracking, pulling the Quality data from Build or Release.

Requirement Quality Widget
(圖 95) 需求品質小工具(Figure 95) Requirement Quality Widget
遠端測試 - 根據電腦數目散發測試Remote testing – distribute tests based on number of machines

使用者將可以使用 [執行功能測試] 工作以將來自組件內的測試散發至遠端電腦 (圖 96)。We have enabled tests from within an assembly to be distributed to remote machines using the Run Functional Tests task (Figure 96). 在 TFS 2015 中,您僅可以在組件層級散發測試。In TFS 2015, you could distribute tests only at the assembly level. 這可以透過使用工作中的核取方塊來啟用,如下所示。This can be enabled using the check box in the task as below.

Task Setting
(圖 96) 工作設定(Figure 96) Task Setting
SCVMM 與 VMWare 的自動化測試Automated testing for SCVMM and VMWare

使用者可以在雲端中 (透過 Azure) 或是在內部部署上 (使用 SCVMM 或 VMWare) 動態設定測試電腦,然後使用這些電腦以分散的方式執行其測試。Users can dynamically set up test machines in the cloud with Azure, or on premises using SCVMM or VMWare, and use these machines to run their tests in a distributed manner. 使用者可以使用其中一種電腦佈建工作 (Azure、SCVMM 或 VMWare),並接著使用 [執行功能測試] 工作來執行測試。Users can use one of the machine provisioning tasks— Azure, SCVMM, or VMWare—followed by the Run Functional Tests task to run tests.

Maven 和 Gradle 工作中的 SonarQube 分析SonarQube analysis in Maven and Gradle tasks

您現在可以透過選取 [執行 SonarQube 分析],並提供端點、SonarQube 專案名稱、專案金鑰及版本,在 Maven 及 Gradle 建置工作中觸發 SonarQube 分析 (圖 97)You can now trigger a SonarQube analysis in the Maven and Gradle build task by checking 'Run SonarQube Analysis', and providing the endpoint, the SonarQube project name, the project key, and the version (Figure 97).

Run SonarQube Analysis
(圖 97) 執行 SonarQube 分析(Figure 97) Run SonarQube Analysis

您現在也會取得 SonarQube 專案的連結 (圖 98)You will also now get a link on the SonarQube project (Figure 98). 您可以要求完整的分析,查看品質閘門詳細資料,並在不符合的情況下選擇中斷組建。You can request a full analysis to see the quality gates details, and choose to break the build if they are not met.

Run SonarQube Analysis
(圖 98) 執行 SonarQube 分析(Figure 98) Run SonarQube Analysis

如需詳細資訊,請參閱 Gradle 建置工作現已支援 SonarQube 分析For more information, please see The Gradle build task now supports SonarQube analysis.

市集改善 Marketplace Improvements

專案集合系統管理員現在可以從 Team Foundation Server 瀏覽至 Visual Studio Marketplace,並在小組專案集合中安裝免費的擴充功能。Project collection administrators can now browse to the Visual Studio Marketplace from a Team Foundation Server and install free extensions in a team project collection. 延伸模組會自動從 Visual Studio Marketplace 下載、針對 Team Foundation Server 進行上傳,並在選取的小組專案集合中安裝 (圖 99)The extensions are automatically downloaded from the Visual Studio Marketplace, uploaded to the Team Foundation Server, and installed in the selected team project collection (Figure 99).

Install Free Extension
(圖 99) 安裝免費延伸模組(Figure 99) Install Free Extension

購買並安裝付費延伸模組Purchase and install paid extensions

專案集合系統管理員現在可以從 Team Foundation Server 瀏覽至 Visual Studio Marketplace、購買付費延伸模組,並在選取的小組專案集合中加以安裝 (圖 100)。Project collection administrators can now browse to the Visual Studio Marketplace from a Team Foundation Server, buy paid extensions, and install them in a selected team project collection (Figure 100). 系統管理員可以使用 Azure 訂用帳戶支付延伸模組費用,然後選取要指派這些延伸模組的目標使用者數目。The administrator can pay for extensions with an Azure subscription and select the number of users to assign these extensions. 這些延伸模組會自動從 Visual Studio Marketplace 下載、針對 Team Foundation Server 進行上傳,並在選取的小組專案集合中安裝。These extensions are automatically downloaded from the Visual Studio Marketplace, uploaded to the Team Foundation Server, and installed in the selected team project collection.

Purchase Paid Extension
(圖 100) 購買付費延伸模組(Figure 100) Purchase Paid Extension

如需詳細資訊,請參閱 Get extensions for Team Foundation Server (取得 Team Foundation Server 的延伸模組) 文件。For more details, see Get extensions for Team Foundation Server documentation.

系統管理改善 Administration Improvements

Windows 驗證Windows Authentication

在舊版本中,您需要在設定加入網域的 TFS 部署時,決定使用 NTLM 和 Negotiate 安全性支援提供者來進行 Windows 驗證。In previous releases, you needed to decide between NTLM and Negotiate security support providers for Windows Authentication when configuring a domain-joined TFS deployment. 在 2017 中,我們已從組態體驗中移除此設定。In 2017, we removed this setting from the configuration experience. 如果您要在 2017 年繼續使用 NTLM 驗證,則不需要採取任何動作。If you want to continue using NTLM authentication in 2017, you do not need to take any action. 如果您一直都使用 Kerberos 驗證,並且要在 2017 年繼續使用,則不需要採取任何動作。If you had been using Kerberos authentication and want to continue doing so in 2017, you do not need to take any action. TFS 2017 現在一律會設定 Negotiate 和 NTLM 安全性支援提供者 (依此順序)。TFS 2017 now always configures both the Negotiate and NTLM security support providers, in that order. 運用此組態,會在可能時使用 Kerberos 驗證,並提供增強型安全性。With this configuration, Kerberos authentication will be used where possible, providing enhanced security. 無法使用 Kerberos 時,將會使用 NTLM 驗證。When Kerberos cannot be used, NTLM authentication will be used. 我們執行廣泛的測試,確保不會因這項變更而對使用 NTLM 驗證的現有 TFS 部署進行任何影響。We did extensive testing to ensure that there would not be any impact on existing TFS deployments using NTLM authentication due to this change.

現代化的瀏覽體驗A Modern navigation experience

在此發行中,我們啟用了一個全新改進的上方導覽列。In this release, we are enabling a new and improved top navigation bar. 新的巡覽方式有兩個核心目標︰There are two core goals for the new nav:

  • 透過只需按一下便能快速存取任何中樞,進而增加跨產品區域的導覽效率。Increase navigation efficiency across product areas by quickly allowing you access any of the hubs with one click.
  • 為產品帶來新式的視覺美術設計和使用者體驗。Bring a modern visual aesthetics and user experience to the product.

由於這對使用者來說是很大的變更,且我們仍然在對功能進行逐一查看,因此我們決定預設將新的巡覽 UX 關閉。Since this is a big change for our users, and the feature is still being iterated on, we decided to have the new navigation UX off by default. 如果您想要嘗試使用此新功能,請移至 Team Foundation Server 管理區域的 [控制台] 並選擇 [開啟新巡覽]。If you want to play with it, you can enable it by going to the Team Foundation Server admin area Control Panel and choosing to “Turn on new navigation”. 請注意,這將會針對伺服器中的所有使用者啟動此功能。Please note that will enable it for all users in the server.

Team 專案重新命名權限Team project rename permission

控制哪些使用者可以重新命名已變更之 Team 專案的權限。The permission controlling which users can rename a team project has changed. 過去,具有 Team 專案的編輯專案層級資訊權限的使用者才能重新命名專案。Previously, users with Edit project-level information permission for a team project could rename it. 現在,透過新的重新命名 Team 專案權限可以授與或拒絕使用者重新命名 Team 專案的能力。Now users can be granted or denied the ability to rename a team project through the new Rename team project permission.

管理設定工作中樞Admin settings Work hub

我們介紹了將一般設定 (圖 101)、反覆項目和區域結合在單一索引標籤中之 [管理設定] 頁面的新「工作」中樞。透過這項變更,使用者會看到專案層級設定和小組設定之間的明顯差異。We've introduced a new "Work" hub in the Admin settings page that combines general settings (Figure 101), Iterations, and Areas in a single tab. With this change, users will see clear differences between project-level settings and team settings. 針對小組設定,使用者只會看見與小組相關的區域和反覆項目。For team settings, users will only see areas and iterations that are relevant to their team. 在專案層級,設定頁面能讓管理員管理整個專案的區域和反覆項目。At a project level, the settings page will enable admins to manage areas and iterations for the entire project. 此外,專案區域路徑已加入名為「小組」的新資料行,方便管理員快速且輕鬆地分辨哪些小組已選取特定的區域路徑。Additionally, for project area paths, a new column called "Teams" has been added to make it convenient for admins to tell quickly and easily which teams have selected a specific area path.

Admin work hub
(圖 101) 管理工作中樞(Figure 101) Admin work hub

處理序組態 REST APIProcess configuration REST APIs

這個公用 API 可讓使用者取得指定專案的處理序組態。This public API allows users to get the process configuration of a given project. 處理序組態包含下列設定︰The process configuration contains the following settings:

  • __TypeFields:__敏捷式工具所使用的可自訂欄位抽象概念。TypeFields: abstractions of customizable fields that are used in the agile tooling. 例如,「故事點數」欄位的類型是「投入時間」。For example, the type of the "Story points" field is "Effort".
  • __待辦項目定義︰__定義每個待辦項目上的工作項目類型。Backlog definitions: define what work item types are on each of the backlogs. 這是客戶組建擴充功能經常要求的 API。This is a frequently requested API from customers building extensions. 使用這項資料,擴充功能就可以了解如何利用特定處理序的欄位,在敏捷式工具中啟用常見案例 (例如變更工作項目的活動或投入時間、了解指定的待辦項目層級包含哪些工作項目,或判斷由區域路徑或自訂欄位來識別小組)。With this data, an extension can know how to leverage process-specific fields to enable common scenarios in the agile tools (such as changing the activity or effort of a work item, knowing what work items are included at a given backlog level, or determining whether teams are identified by area path or a custom field). 如需詳細資訊,請參閱工作概觀Please refer to Work Overview for more information.

Team Foundation Server 2017 引進了管理群組和群組成員資格的全新體驗。Team Foundation Server 2017 introduces a new experience to manage groups and group membership. 您可以針對使用者/群組名稱使用前置詞型的搜尋準則,來搜尋 Active Directory 或本機電腦使用者/群組。You can search in active directory or local machine users/groups using prefix based search criteria on user/group name(s). 例如 'John D' 及 samaccountname (例如 'businessdomain\johbdnd'),並查看使用者/群組的連絡人卡片。For example, 'John D' as well as samaccountname (e.g. 'businessdomain\johbdnd') and see the contact card of a user/group.

使用者安全性設定User security settings

您可以在新的 [我的安全性] 體驗中管理您的個人存取權杖和 SSH (圖 102)。You can manage your personal access tokens and SSH in the new "My Security" experience (Figure 102). 使用 [我的設定檔] 管理 SSH 的使用者,現在將需要在使用者安全性設定中管理其 SSH 公開金鑰 (圖 103)Users who were using "My Profile" to manage SSH will now need to manage their SSH public keys in the user security settings (Figure 103).

My security
(圖 102) 我的安全性(Figure 102) My security
My profile
(圖 103) 我的設定檔(Figure 103) My profile

整合組態精靈Unified configuration wizard

在舊版中,您會根據您嘗試執行的動作,針對您的 TFS 部署從多個組態精靈中挑選其中一個 - [基本] 和 [完整] 精靈可用來設定新的部署、[升級] 精靈可以用於生產和預先生產的升級,而 [僅限應用程式層] 精靈可用於各種不同的案例,包括相應放大現有部署、使用新的硬體取代應用程式層等。In previous releases, you would pick one of multiple configuration wizards for your TFS deployment depending on what you were trying to do – the Basic and Full wizards could be used to configure a new deployment; the Upgrade wizard could be used for production and pre-production upgrades; and the Application-Tier Only wizard could be used for a variety of scenarios, including scaling out an existing deployment, replacing an application tier with new hardware, and so forth. 在 TFS 2017 中,這些案例都已整合為單一 [伺服器組態精靈],它可透過要求您做出簡單的選擇,以引導您設定各個案例。In TFS 2017, all of these scenarios have been unified into a single Server Configuration Wizard, which guides you toward and then through each of these scenarios by asking you to make simple choices. 此外,預先生產升級與複製現有部署等進階設定,現在會自動化過去需透過 tfsconfig.exe 完成的動作,包括變更伺服器識別碼、重新對應資料庫連接字串,以及移除外部相依性的參考 (過去需透過 tfsconfig.exe 的 PrepareClone 才能完成)。Additionally, advanced configurations like pre-production upgrades and clone existing deployment now automate actions which used to be done via tfsconfig.exe, including changing server IDs, remapping database connection strings, and removing references to external dependencies (which used to be done with tfsconfig.exe PrepareClone).

新的存取層級New access level

新的 Visual Studio Enterprise 群組已新增至 Team Foundation Server 中的存取層級系統管理員入口網站,您現在可以快速識別出哪些人員具有 Visual Studio Enterprise 訂閱。With the new Visual Studio Enterprise group added to the Access Level admin portal in Team Foundation Servers, you can now quickly identify who has a Visual Studio Enterprise subscription. 識別後,這些使用者不需另外付費,即可完整存取自 Visual Studio Marketplace 安裝的所有第一方 TFS 延伸模組。Once identified, these users will gain full access to all first party TFS extensions installed from the Visual Studio Marketplace at no additional charge.

個人存取權杖 Personal Access Tokens

除了 SSH 以外,您現在可以使用個人存取權杖連線到任何 Team Foundation Server (圖 104)。You can now connect to any Team Foundation Server using a personal access token in addition to SSH (Figure 104). 如果您在 Linux 或 Mac 上進行開發並想要使用任何自動化工具與 GIT,這會很有幫助。This is helpful if you develop on Linux or Mac and would like to use in any automation tools and GIT. 您可以從使用者安全性設定頁面管理您的個人存取權杖。You can manage your personal access tokens from the user security settings page.

Personal Access Tokens
(圖 104) 個人存取權杖(Figure 104) Personal Access Tokens

已知問題 Known Issues

這是此發行中已知問題的完整清單。This is a complete list of known issues in this release.

沒有用於 Team Foundation Server 2017 的 Power ToolsThere are no Power Tools for Team Foundation Server 2017

  • 問題:Issue:

    TFS 2017 尚未發行 Power Tools。No Power Tools have been released for TFS 2017.

  • 因應措施:Workaround:

    我們很興奮地宣佈大部分的舊版 Power Tools 都已整合到 TFS 2017。We are excited to let you know that most of the previous Power Tools have been integrated into TFS 2017. Process Template Editor 尚未經過整合,但您可以在 Visual Studio Marketplace 中取得。The Process Template Editor is one that has not been integrated, but you can get it in the Visual Studio Marketplace.

更新自訂控制項延伸模組Updating custom control extensions

匯入工作項目類型定義時發生錯誤Error when importing work item type definition

  • 問題:Issue:

    已安裝工作項目頁面擴充功能的客戶若匯出工作項目類型定義再匯入該定義,就會看到錯誤:「‘LayoutMode’ 屬性未宣告」。Customers with a work item page extension installed, who export a work item type definition then import that definition, will see an error, “The ‘LayoutMode’ attribute is not declared”.

  • 因應措施:Workaround:

    每次當您匯出工作項目類型定義時,PageContribution 元素上都會有額外的 LayoutMode 屬性。There is an extra LayoutMode attribute on the PageContribution element each time you export a work item type definition. 匯入定義之前,請搜尋 PageContribution 模式並移除 LayoutMode 屬性。Before importing the definition, search for the PageContribution mode and remove the LayoutMode attribute. 例如,移除 LayoutMode="FirstColumnWide"。For example, remove LayoutMode="FirstColumnWide".

客戶應更新至 Git LFS 1.3.1 版或更新版本Customers should update to Git LFS version 1.3.1 or higher

  • 問題:Issue:

    1.3.1 之前的 Git LFS 版本不受未來版本支援。Git LFS versions before 1.3.1 will not be supported in future releases.

  • 因應措施:Workaround:

    強烈建議使用 Git LFS 的客戶更新至 Git LFS 1.3.1 版或更新版本。Customers using Git LFS are strongly encouraged to update to Git LFS version 1.3.1 or higher. 舊版的 LFS 用戶端與此版 TFS 中的驗證變更不相容。Older versions of the LFS client are not compatible with authentication changes in this version of TFS. 為了讓客戶有時間進行移轉,我們實作了短期的 RTW 因應措施。In order to give customers time to migrate, we implemented a short-term workaround for RTW. Update 1 中將移除因應措施,屆時 1.3.1 版本以下的 Git LFS 用戶端就無法再運作。The workaround will be removed in Update 1, at which point Git LFS clients below 1.3.1 will no longer work.

NuGet 還原不是尋找位在 的封裝NuGet Restore is not finding packages that exist in

  • 問題:Issue:

    使用 NuGet 3.4.3 或更新版本時,NuGet 還原工作將不會從 還原封裝,除非其為 NuGet.Config 中的明確來源。When using NuGet 3.4.3 or greater, the NuGet Restore task will not restore packages from unless it is an explicit source in the NuGet.Config.

  • 因應措施:Workaround:

    確定 位於 NuGet.Config。Ensure is in NuGet.Config.

NuGet 組建和發行工作不會驗證NuGet build and release tasks do not authenticate

  • 問題:Issue:

    當使用 Team Foundation Server / 封裝管理時,如果組建代理程式是以網路服務使用者的身分執行 (這在代理程式是以服務的形式執行時為預設值),NuGet 組建和發行工作將不會針對摘要進行驗證。When using Team Foundation Server / Package Management, NuGet build and release tasks will not authenticate to feeds if the agent is running as a NETWORK SERVICE user, which is the default when the build agent is run as a service. 這是因為 3.5 之前的 NuGet 版本會使用執行組建代理程式的使用者帳戶認證,而非建置工作所提供的認證。This happens because versions of NuGet before 3.5 use the credentials of the user account running the build agent, not the credentials provided by the build task.

  • 因應措施:Workaround:

    若要搭配使用作為網路服務執行之代理程式的 TFS 摘要來使用 NuGet 組建/版本工作,您必須使用 NuGet 3.5 或更新版本。To use NuGet build/release tasks with TFS feeds using an agent that is running as a NETWORK SERVICE, you must use NuGet 3.5 or higher.

NuGet 組建和版本工作使用代理程式的認證NuGet build and release tasks use agent’s credentials

  • 問題:Issue:

    3.5 之前的 NuGet 版本會使用執行組建代理程式的使用者帳戶認證,而非建置工作所提供的認證。Versions of NuGet before 3.5 use the credentials of the user account running the build agent, not the credentials provided by the build task. 這可能會導致非預期的存取權,或缺少摘要存取權。This may result in unexpected access or lack of access to feeds.

  • 因應措施:Workaround:

    在 TFS 組建代理程式上使用 NuGet 3.5 或更新版本。Use NuGet 3.5 or higher on TFS build agents.

升級 TFS 時,不會自動升級外部擴充功能External extensions do not automatically upgrade when upgrading TFS

  • 問題:Issue:

    如果您從 Visual Studio Marketplace 下載擴充功能、將它發佈至您的 TFS 2015 安裝,然後升級至 TFS 2017,當新版擴充功能發佈至 Marketplace 時,將不會自動更新擴充功能。If you downloaded an extension from the Visual Studio Marketplace, published it to your TFS 2015 installation, and then upgraded to TFS 2017, the extension will not be automatically updated when new versions of the extension are published to the Marketplace.

  • 因應措施:Workaround:

    升級至 TFS 2017 之後,請解除安裝 TFS 2015 中已安裝的擴充功能。After upgrading to TFS 2017, uninstall the extensions you had installed in TFS 2015. 然後重新安裝最新的擴充功能。Then reinstall the latest extensions. 在 TFS 2017 中,我們新增了一項功能,會每天自動檢查一次是否有已更新的外部擴充功能,並進行升級。In TFS 2017 we added a feature to automatically check for updated external extensions once a day and upgrade them.

無法執行發行定義中的「Jenkins 佇列作業」工作The Jenkins Queue Job task cannot be run in release definitions

  • 問題:Issue:

    執行發行定義中的「Jenkins 佇列作業」工作時,客戶收到 500 伺服器錯誤。When running the Jenkins Queue Job task in a release definition, customers get a 500 server error.

  • 因應措施:Workaround:

    目前,「Jenkins 佇列作業」工作可當做 TFS 組建定義的一部分執行,但不能當做發行定義的一部分執行。Currently, the Jenkins Queue Job task can be run as part of TFS build definitions, but not release definitions. 未來版本將新增此功能。This ability will be added in a future release.

必須對 TFS 2017 DLL 重建自訂 TFS 伺服器外掛程式Custom TFS server plugins need to be rebuilt against TFS 2017 DLLs

  • 問題:Issue:

    自訂 TFS 伺服器外掛程式在升級至 TFS 2017 之後無法運作。Custom TFS server plugins do not work after upgrading to TFS 2017.

  • 因應措施:Workaround:

    請對 TFS 2017 組件重建您的自訂伺服器外掛程式。Rebuild your custom server plugins against the TFS 2017 assemblies.

自 TFS 2015 RTM 以來,自訂 TFS 伺服器外掛程式的伺服器物件模型已變更The Server Object Model for Custom TFS server plugins has changed since TFS 2015 RTM

  • 問題:Issue:

    自訂 TFS 伺服器外掛程式未編譯。Custom TFS server plugins do not compile.

  • 因應措施:Workaround:

    請修正原始程式碼,如這篇部落格文章中所述。Fix up source code as described in this blog post.

使用系統管理員動作時,擲回例外狀況When using administrator actions, an exception is thrown

  • 問題:Issue:

    當小組系統管理員在 [警示管理] 頁面中使用 [尋找特定使用者的警示] 搜尋來尋找小組的訂閱時,可能會發生例外狀況。In the Alerts Administration page, when Team Administrators use the Find Alerts for a specific user search to find subscriptions for a team, they might get an exception.

  • 因應措施:Workaround:

    • __選項 1:__按一下 [所有警示] 節點,並設定要顯示的 [我的所有小組警示] 篩選器。Option 1: Click on the All Alerts node and set the All My Teams Alerts filter to show. 這將會顯示使用者可存取之所有群組的所有警示。This will show all alerts for all groups that the user has access to.

    • __選項 2:__如果群組是一個小組,而不是依小組名稱搜尋,請瀏覽至此小組的 [警示管理] 頁面來管理訂閱。Option 2: In case the group is a team, instead of searching by team name, navigate to this team’s Alerts Administration page to manage subscriptions.

使用在 Team Build/Release Management 中執行功能測試之工作的問題Issue using tasks for running functional tests in Team Build / Release Management

  • 問題:Issue:

    使用工作目錄中的 [Visual Studio Test Agent 部署] 和 [執行功能測試] 工作在 Team Build/Release Management 中執行功能測試,目前使用 Agents for Visual Studio 2015 Update 3,而且只能用來執行使用 Visual Studio 2013 和 Visual Studio 2015 所建置的測試。Running functional tests in Team Build / Release Management using ‘Visual Studio Test Agent Deployment’ and ‘Run Functional Tests’ tasks from the task catalog currently uses Agents for Visual Studio 2015 Update 3 and can only be used to run tests built using Visual Studio 2013 and Visual Studio 2015. 這些工作不能用於執行使用 Visual Studio 2017 RC 所建置的測試。These tasks cannot be used for running tests built using Visual Studio 2017 RC. 如需詳細資訊,請參閱此部落格文章For more details, please refer to this blog post.

  • 因應措施:Workaround:

    沒有因應措施。There is no workaround. 在 TFS 2017 Update 1 時間範圍中,新增使用 Test Agent 2017 以及執行使用 Visual Studio 2017 所建置之測試的支援。Support for using Test Agent 2017 and running tests built using Visual Studio 2017 will be added in the TFS 2017 Update 1 timeframe.

延伸模組不會自動更新Extensions are not being auto-updated

  • 問題:Issue:

    如果從舊版的 TFS 升級到 TFS 2017 並在連線模式中執行 TFS 2017,則您的延伸模組不會自動更新成應有的版本。If you upgrade a prior version of TFS to reach TFS 2017 and are running TFS 2017 in connected mode then your extensions will not be auto-updated as they should be.

  • 因應措施:Workaround:

    此問題目前沒有因應措施。There is no workaround at this time. 我們已修正問題,且 TFS 2017 Update 2 中會提供自動更新行為。We have fixed the issue and the auto update behavior will reach you through TFS 2017 Update 2. 如有任何原因無法等待 Update 2,請透過支援通道連絡我們,我們會儘早與您共用修正程式。If for any reason you cannot wait for Update 2 then reach us through the Support channel and we shall share the fix earlier.

如果您遇到問題,而使您無法在生產環境中 (Go-Live) 部署,請連絡 Microsoft 產品支援If you encounter issues that are preventing you from deploying in a production environment (Go-Live), please contact Microsoft product support. (只有英文版) 僅限美國營業時間 (太平洋標準時間週一至周五上午 6 點至下午 6 點),1 個工作天之內回應。(English only) U.S. business hours only (M-F 6a-6p PST), 1 business day response.

Top of Page