Team Foundation Server 2018 版本資訊 Team Foundation Server 2018 Release Notes

注意

如果您是從非英文語言版本的頁面存取此頁面,並想查看最新的內容,請瀏覽此版本資訊頁面的英文版本。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.

Download the latest version of Team Foundation Server

若要深入了解 Team Foundation Server 2018,請參閱 Team Foundation Server Requirements and Compatibility (Team Foundation Server 需求和相容性) 頁面。To learn more about Team Foundation Server 2018, see the Team Foundation Server Requirements and Compatibility page.


TFS 2018 中的新功能影片What's New in TFS 2018 video


意見反應Feedback

請提供您的意見!We’d love to hear from you! 您可以透過開發人員社群回報並追蹤問題,並在 Stack Overflow 上取得建議。You can report a problem and track it through Developer Community and get advice on Stack Overflow. 一如往常,如果您對想要看到我們設定優先順序的項目有任何想法,請前往 UserVoice 新增您的想法或對現有想法進行投票。As always, if you have ideas on things you’d like to see us prioritize, head over to UserVoice to add your idea or vote for an existing one.


發行日期:2017 年 11 月 15日Release Date: November 15, 2017

摘要:Team Foundation Server 2018 更新Summary: Team Foundation Server 2018 Updates

我們已為 Team Foundation Server 2018 新增許多新價值。We've added a lot of new value to Team Foundation Server 2018. 一些重點包括:Some of the highlights include:

XAML 組建XAML Build

我們原先在 TFS 2018 RTW 及 Update 1 中將 XAML 組建列為已移除項目。We had originally listed XAML build as removed from TFS 2018 RTW and Update 1. 但是,這使得很多客戶無法升級,或是必須在升級完成後連絡支援人員才能再次加以啟用。However, that resulted in too many customers being unable to upgrade or having to contact support to re-enable it after the upgrade completed. 在 TFS 2018 Update 2 中,XAML 組建已啟用,但已淘汰。In TFS 2018 Update 2, XAML build is enabled but has been deprecated. 這表示我們不會再為 XAML 組建提供支援,且 Microsoft Test Manager (MTM) 也不再支援使用 XAML 組建。This means there is no further investment in XAML Build, and Microsoft Test Manager (MTM) no longer supports using XAML builds. 我們強烈建議您轉換至其中一個較新的組建定義格式。We highly recommend converting to one of the newer build definition formats. 您仍可使用 TFS 2018 Update 2 繼續連線至 XAML 控制器並執行 XAML 組建。You may continue to connect your XAML controllers and run XAML builds with TFS 2018 Update 2. 詳細資訊More info

TFS 2018 RTW 中已移除的功能Features Removed in TFS 2018 RTW


詳細資料:此版本的新功能Details: What's New in this Release

工作項目追蹤 Work Item Tracking

Web 上的專案建立精靈 Project Creation Wizard on the web

我們已改善從 Web 存取建立 Team 專案的體驗。We have improved the experience for creating a Team Project from web access. 現在您能夠使用的功能,幾乎和在 Visual Studio 用戶端中建立 Team 專案時相同。It now includes most of the features available when you create a Team Project in the Visual Studio client. 使用 Web 介面的優點是您不需要相符的 Visual Studio 版本。The benefit of using the web interface is that you don't need a matching Visual Studio version. 使用 Visual Studio 或 Web 版本的差異在於 Web 版本不會在 SSRS 中佈建您的報表。The difference of using Visual Studio or the web version is that the web version doesn’t provision your reports in SSRS. 如果您已使用 Web 版本建立 Team 專案,則可以在應用程式層執行 tfsconfig 命令,以佈建或更新 SSRS 報表。If you used the web version of the Team Project creation, you can run the tfsconfig command on the Application Tier to provision or update the SSRS reports. 如需詳細資料,請參閱新增專案報表See details in add project reports.

Web 上的流程範本管理員Process Template Manager on the web

運用 TFS 2018,您可以使用 Web 存取來上傳流程範本。With TFS 2018, you can use web access to upload your process templates. Web 介面是較簡單的體驗,因為您不需要安裝正確版本的 Visual Studio 即可與流程範本互動。The web interface is a much easier experience because you don't have to install the correct version of Visual Studio to interact with your process templates. Visual Studio 2017 Update 4 和以下版本仍然會顯示 [流程範本管理員] 對話方塊,但是建議使用 Web 介面。Visual Studio 2017 Update 4 and earlier will still show the Process Template Manager dialog, although we recommend using the web interface. Visual Studio 2017 Update 5 和更新版本會自動將您重新導向到 Web。Visual Studio 2017 Update 5 and later will redirect you to the web automatically.

自訂工作項目表單標頭 Customize the work item form header

您現在可以透過取代現有的控制項或隱藏與程序無關的控制項,來自訂工作項目表單頁首區域。You can now customize the work item form header area by replacing the existing controls, or hiding controls, that are not relevant to your process. 這會以自訂的 [小組] 欄位取代區域路徑、隱藏反覆項目 (如果小組多以看板取得焦點),並以自訂的欄位取代 [原因]。This will enable replacing Area path with a custom Team field, hiding Iteration if your teams are more Kanban focused, and replacing Reason with a custom field. [狀態] 欄位無法隱藏或取代。The State field cannot be hidden or replaced.

如需詳細資訊,請參閱WebLayout 和控制項項目文件See the documentation for WebLayout and Control elements for more information.

行動工作項目表單 Mobile work item form

我們擁有完整的端點到端點體驗,包含最佳的工作項目外觀與操作 (圖 1)。We have a full end-to-end experience that includes an optimized look and feel for work items (Figure 1). 這樣的體驗讓您能夠透過手機,輕鬆與指派給您、您正在追蹤,或您近期瀏覽或編輯過的項目互動。It provides an easy way to interact with items that are assigned to you, that you’re following, or that you have visited, or edited recently, from your phone.

Mobile work item query
(圖 1) 行動工作項目查詢(Figure 1) Mobile work item query

除了有不錯的外觀之外,這項體驗還支援所有欄位類型的最佳化控制項 (圖 2)。Along with the good looks, this experience supports optimized controls for all field types (Figure 2).

Mobile work item form
(圖 2) 行動工作項目表單(Figure 2) Mobile work item form

使用新的行動瀏覽 (圖 3) 時,使用者可以到達 TFS 的任何其他行動就緒部分,並在需要與其他中樞互動時回到完整桌面網站。With the new mobile navigation (Figure 3), users can reach any other mobile-ready parts of TFS and get back to the full desktop site in case they need to interact with other hubs.

Mobile navigation
(圖 3) 行動巡覽(Figure 3) Mobile navigation

依待辦項目、工作流程看板、短期衝刺和查詢篩選Filtering on backlogs, Kanban boards, sprints, and queries

所有工作項目追蹤格線體驗 (查詢、待辦項目、工作流程看板、短期衝刺待辦項目和測試案例管理) 現在都會利用通用且一致的篩選元件 (圖 4)。All of our work item tracking grid experiences (queries, backlogs, Kanban boards, sprints backlogs, and test case management) now make use of our common, consistent filtering component (Figure 4). 除了將關鍵字篩選套用至顯示的資料行以及選取標記之外,您也可以依工作項目類型、狀態和指派對象進行篩選,以快速到達您要尋找的工作項目。Beyond applying a keyword filter across displayed columns and selecting tags, you can also filter on work item types, states, and assigned to, in order to quickly get to the work items you are looking for.

Filtering on query
(圖 4) 篩選查詢(Figure 4) Filtering on queries

展開以顯示工作流程看板卡上的空欄位Expand to show empty fields on a Kanban card

您現在可以選擇在卡片中新增其他欄位,然後在面板設定中「隱藏空欄位」(圖 5),以移除板中不必要的混亂。Today, you have the option to add additional fields to a card and then hide empty fields (Figure 5) in board settings to remove unnecessary clutter from the board. 這項功能的缺點是隱藏空欄位之後,更新欄位的唯一方式是開啟工作項目表單。The drawback to this feature was that once an empty field was hidden, the only way to update the field was to open the work item form. 使用工作流程看板卡上的新可用展開選項時,您現在可以受益於隱藏看板中的空欄位,但仍然可以透過按一下存取來更新卡片上的特定欄位。With the newly available expand option on Kanban cards, you can now benefit from hiding empty fields across the board, but still have single click access to update a particular field on a card. 只需要將滑鼠游標暫留在卡片上方,並尋找卡片底部的向下>形箭號,即可更新隱藏欄位。Simply hover over the card and look for the down chevron at the bottom of the card to update the hidden field.

Hidden field
(圖 5) 看板卡片上的隱藏欄位(Figure 5) Hidden field on Kanban card

按一下卡片底部的向下>形箭號,以更新欄位 (圖 6)。Click the down chevron at the bottom of the card to update the field (Figure 6).

Update hidden field
(圖 6) 更新看板卡片上的隱藏欄位(Figure 6) Update hidden field on Kanban card

延伸模組封鎖工作項目儲存Extensions block work item save

工作項目表單自訂控制項、群組和頁面現在可以封鎖工作項目儲存來驗證資料,並確定使用者先填寫任何必要資訊,再儲存工作項目表單。Work item form custom controls, groups, and pages can now block work item save to validate data and ensure the user fills out any required information before saving the work item form.

傳遞計劃的內嵌新增Inline add on Delivery Plans

新功能的想法會隨時出現,因此我們讓您能更輕鬆地直接將新功能新增至傳遞計劃 (圖 7)。New feature ideas can arrive at any moment, so we’ve made it easier to add new features directly to your Delivery Plans (Figure 7). 只要按一下動態顯示取得的 [新增項目] 按鈕、輸入名稱,再按 Enter 鍵即可。Simply click the New item button available on hover, enter a name, and hit enter. 新功能會使用您預期的區域路徑和反覆項目路徑建立。A new feature will be created with the area path and iteration path you’d expect.

Inline add on delivery plans
(圖 7) 傳遞計劃的內嵌新增(Figure 7) Inline add on delivery plans

版本控制 Version Control

分支 Forks

TFS 2018 新增 Git 分支支援 (圖 8)。TFS 2018 adds support for Git forks (Figure 8). 「分支」是存放庫的伺服器端複本。A fork is a server-side copy of a repository. 使用分支,您可以允許更多人參與您的存放庫,而不需授與其直接認可存取權。Using forks, you can allow a broad range of people to contribute to your repository without giving them direct commit access. 相反地,他們會將其工作認可到其在存放庫中的專屬分支。Instead, they commit their work to their own fork of the repository. 這可讓您有機會先在提取要求中檢閱其變更,再將這些變更接受至中央存放庫。This gives you the opportunity to review their changes in a pull request before accepting those changes into the central repository.

Git forks
(圖 8) Git 分支(Figure 8) Git forks

GVFS GVFS

現在支援 Git 虛擬檔案系統 (GVFS)。Git Virtual File System (GVFS) is now supported. GVFS 可透過虛擬化和最佳化 Git 在檔案系統上的運作方式,讓 Git 存放庫放大至數百萬個檔案。GVFS allows Git repositories to scale to millions of files by virtualizing and optimizing how Git operates on the filesystem.

在使用 Web 的存放庫中建立資料夾Create a folder in a repository using web

您現在可以透過 Git 和 TFVC 存放庫中的 Web 建立資料夾 (圖 9)。You can now create folders via the web in your Git and TFVC repositories (Figure 9). 這會取代資料夾管理延伸模組,目前正在進行取代程序。This replaces the Folder Management extension, which will now undergo the process of deprecation.

若要建立資料夾,請在命令列或操作功能表中按一下 [新增] > [資料夾]:To create a folder, click New > Folder in either the command bar or context menu:

New folder option
(圖 9) [新增資料夾] 選項(Figure 9) New folder option

若為 TFVC,您要指定資料夾名稱,然後將它簽入。For TFVC, you’ll specify a folder name and then check it in. 若為 Git,因為不允許空的資料夾,所以您也必須指定檔案名稱,選擇性地編輯檔案,然後認可它。For Git, because empty folders aren’t permitted, you’ll also have to specify a file name, optionally edit the file, then commit it.

此外,[新增檔案] 對話方塊 (圖 10) 已針對 Git 加強來接受斜線以建立子資料夾。Additionally, for Git, The New file dialog (Figure 10) has been enhanced to accept slashes to create subfolders.

New file dialog
(圖 10) [新增檔案] 對話方塊(Figure 10) New file dialog

檔案迷你地圖File minimap

現在當您檢視或編輯檔案時,可以檢視檔案的迷你地圖快速瀏覽程式碼 (圖 11)。You can now view a minimap of a file as you view or edit to give you a quick overview of the code (Figure 11). 若要開啟迷你地圖,請開啟 [命令選擇區](F1 或按一下滑鼠右鍵) 並選取 [Toggle Minimap](切換迷你地圖)。To turn on the minimap, open the Command Palette (F1 or right-click) and select Toggle Minimap.

File minimap
(圖 11) 檔案迷你地圖(Figure 11) File minimap

括弧比對Bracket matching

編輯或檢視檔案時,現在左側有指導方針方便您比對括弧 (圖 12)。When editing or viewing a file, there are now guidelines on the left side to make it easy to match your brackets (Figure 12).

Bracket matching
(圖 12) 括弧比對(Figure 12) Bracket matching

切換空白字元Toggle white space

現在檢視或編輯檔案時,可以切換開啟和關閉空白字元。You can now toggle white space on and off when viewing or editing a file. 我們仍在開發功能,讓您在比對差異時切換空白字元。We are still developing a feature that will allow you to toggle white space when diff’ing. 若要檢視空白字元 (圖 13),請開啟 [命令選擇區](F1 或按一下滑鼠右鍵) 並選取 [切換空白字元],讓您區分空格和定位點。To view white space (Figure 13), open the Command Palette (F1 or right-click) and select Toggle White Space, which allows you to differentiate between spaces and tabs.

Toggle white space
(圖 13) 切換空白字元(Figure 13) Toggle white space

關閉 TFVC 存放庫 Web 編輯的設定Setting to turn off web editing for TFVC repos

使用 TFVC 的小組通常會在 Visual Studio 中使用簽入原則,確保程式碼品質。Teams that use TFVC often use check-in policies in Visual Studio to ensure code quality. 不過,因為簽入原則是在用戶端上強制執行,所以在 Web 上編輯的程式碼不會受限於相同的原則。However, because check-in policies are enforced on the client, code that is edited on the web isn’t subjected to the same policies.

許多人已要求方法來停用 Web 編輯,以保護略過簽入原則的變更。Several people have asked for a way to disable web-editing to protect against changes that bypass check-in policies. 我們可讓您根據專案/存放庫來關閉 TFVC 的 Web 編輯 (新增、刪除、重新命名和編輯)。We’ve enabled a way for you to turn off web-editing (adding, deleting, renaming, and editing) for TFVC on a project/repository basis.

若不允許從 [檔案] 頁面進行 Web 編輯,請依序移至 [設定] 和 [版本控制] (圖 14)。To disallow web-editing from the Files page, go to Settings then Version Control (Figure 14). 按一下樹狀結構中的 TFVC 存放庫,並巡覽至 [選項] 樞紐,然後取消核取 [啟用此 TFVC 存放庫的 Web 編輯]。Click on the TFVC repo in the tree, navigate to the Options pivot, and uncheck Enable web-editing for this TFVC repository. 根據預設,會啟用 Web 編輯。By default, web-editing is enabled.

注意

不會影響從 __[專案概觀] 頁面__編輯讀我檔案。Editing the README from the Project Overview page is unaffected.

Turn off web editing
(圖 14) 關閉 Web 編輯(Figure 14) Turn off web editing

如果您嘗試在已停用 Web 編輯的專案中進行 Web 編輯,則系統會通知您不允許進行 Web 編輯 (圖 15)。If you attempt a web-edit in a project with web-editing disabled, you will be notified that web-editing is not allowed (Figure 15).

Web editing not allowed dialog
(圖 15) [不允許 Web 編輯] 對話方塊(Figure 15) Web editing not allowed dialog

提示

這是根據相關建議進行開發。This has been developed based on a related suggestion.

識別過時分支Identify stale branches

刪除您不再需要的分支來保持乾淨的存放庫,可讓小組尋找他們關心的分支,以及以正確的細微性來設定我的最愛。Keeping your repository clean by deleting branches you no longer need enables teams to find branches they care about and set favorites at the right granularity. 不過,如果您的存放庫中有許多分支,則可能很難找出非使用中且可刪除的項目。However, if you have lots of branches in your repo, it can be hard to figure out which are inactive and can be deleted. 我們現在可以輕鬆地識別「過時」分支 (指向 3 個月以上之認可的分支)。We’ve now made it easier to identify “stale” branches (branches that point to commits older than 3 months). 若要查看您的過時分支,請移至 [分支] 頁面上的 [過時] 樞紐 (圖 16)。To see your stale branches, go to the Stale pivot on the Branches page (Figure 16).

Stale branches
(圖 16) 過時分支(Figure 16) Stale branches

搜尋並重新建立已刪除的分支Search for a deleted branch and re-create it

不小心從伺服器刪除分支時,可能很難找出它發生什麼情況。When a branch is accidentally deleted from the server, it can be difficult to figure out what happened to it. 您現在可以搜尋已刪除的分支、看到誰和何時刪除它,並在需要時重新建立。Now you can search for a deleted branch, see who deleted it and when, and re-create it if you wish.

若要搜尋已刪除的分支,請在分支搜尋方塊中輸入完整分支名稱。To search for a deleted branch, enter the full branch name into the branch search box. 它會傳回符合該文字的任何現有分支。It will return any existing branches that match that text. 您也會看到一個選項,可搜尋已刪除分支清單中的完全相符項目。You will also see an option to search for an exact match in the list of deleted branches. 按一下此連結來搜尋已刪除的分支 (圖 17)。Click the link to search deleted branches (Figure 17).

Search for deleted branches
(圖 17) 搜尋已刪除的分支(Figure 17) Search for deleted branches

如果找到相符項目,您會看到誰和何時刪除它。If a match is found, you will see who deleted it and when. 您也可以還原分支 (圖 18)。You can also restore the branch (Figure 18).

Restore deleted branches
(圖 18) 還原已刪除的分支(Figure 18) Restore deleted branches

還原分支將會在最後指向的認可時重新建立它。Restoring the branch will re-create it at the commit to which is last pointed. 不過,它不會還原原則和權限。However, it will not restore policies and permissions.

在開頭為前置詞的分支中搜尋認可Search for a commit in branches starting with a prefix

如果您有所有分支前面都加上文字之階層格式的分支結構,則這項功能會協助您找到開頭為該前置詞文字之所有分支中的認可。If you have branch structure in a hierarchical format where all branches are prefixed with a text, then this feature will help you to find a commit in all the branches starting with that prefix text. 例如,如果您想要查看是否認可所有前面加上 "dev" 的分支,則只需要在搜尋方塊中鍵入 "dev",然後選取 [在開頭為 "dev" 的分支中搜尋](圖 19)。For example, if you want to see whether a commit made its way to all branches that are prefixed with "dev" then simply type "dev" in the search box and select Search in branches starting with "dev" (Figure 19).

Search for a commit
(圖 19) 搜尋認可(Figure 19) Search for a commit

認可詳細資料頁面上的更豐富提取要求圖說文字Richer pull request callout on commit details page

認可詳細資料頁面上的提取要求圖說文字會顯示更多相關資訊,協助您進行深入診斷 (圖 20)。The pull request callout on the commit details page shows more relevant information to help you diagnose better (Figure 20). 我們現在也會在圖說文字中顯示將認可引進任何分支的第一個提取要求,以及與預設分支建立關聯的提取要求Now we also show the first pull request that introduced the commit to any branch and the pull request associated with the default branch in the callout.

Pull request callout
(圖 20) 提取要求圖說文字(Figure 20) Pull request callout

程式碼中的篩選樹狀檢視Filter tree view in Code

您現在不需要捲動認可可能已修改成只到達檔案的所有檔案。Now you don’t need to scroll through all the files that a commit may have modified to just get to your files. 認可詳細資料、提取要求、擱置集詳細資料,以及變更集詳細資料頁面上的樹狀檢視現在支援檔案和資料夾篩選。The tree view on commit details, pull requests, shelveset details, and changeset details page now supports file and folder filtering. 此智慧篩選會在您依資料夾名稱篩選時顯示資料夾的子檔案,並在您依檔案名稱篩選時顯示檔案的摺疊樹狀檢視,以顯示檔案階層。This is a smart filter that shows child files of a folder when you filter by folder name and shows a collapsed tree view of a file to display the file hierarchy when you filter by file name.

在認可樹狀結構上尋找檔案或資料夾篩選 (圖 21) 和 (圖 22):Find a file or folder filter on commit tree (Figure 21) and (Figure 22):

Find a file or folder
(圖 21) 尋找檔案或資料夾(Figure 21) Find a file or folder
Filtered view
(圖 22) 認可樹狀結構上篩選過的檢視(Figure 22) Filtered view on commit tree

[分支更新] 頁面現在為 [推送]Branch updates page is now Pushes

[分支更新] 頁面具有極大的價值。The Branch Updates page has tremendous value. 不過,它是隱藏為 [歷程記錄] 中樞下的樞紐。However, it was hidden as a pivot under the History hub. 現在,分支更新頁面將會顯示為 [程式碼] 下稱為 [推送] 的中樞 (圖 23),以及 [認可]、[分支]、[標記] 和 [提取要求]。Now the branch updates page will be visible as a hub called Pushes (Figure 23) under Code, alongside Commits, Branches, Tags, and Pull Requests. 推送頁面的新 URL 為:\<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushesThe new URL for the pushes page is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes. 舊的 URL 仍會繼續運作。The old URLs will continue to function.

Pushes page
(圖 23) [推送] 頁面(Figure 23) Pushes page

同時,[記錄] 中樞現在已重新命名為 [認可](圖 24),因為此中樞只會顯示認可。At the same time, the History hub is now renamed to Commits (Figure 24) since the hub only shows commits. 我們已收到來自下列人員的意見反應:因為認可清單檢視僅顯示詳細時間暫留,所以這些人員發現很難對認可相關問題進行疑難排解。We received feedback that people were finding it difficult to troubleshoot commit related issues because the commit list view only showed detailed time on-hover. 執行個體的認可清單檢視現在會以 dd/mm/yy hh:mm 的格式顯示日期和時間。Now the commit list view across your instance will show date and time in dd/mm/yy hh:mm format. 認可頁面的新 URL 為:\<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commitsThe new URL for commits page is: \<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits. 舊的 URL 仍會繼續運作。The old URLs will continue to function.

Commits page
(圖 24) [認可] 頁面(Figure 24) Commits page

從檔案移至認可時保留檔案名稱Retain filename when moving from Files to Commits

我們會聽取來自人員的意見反應,如果他們將目錄篩選至 [程式碼] 中樞之 [檔案] 樞紐中的特定檔案,稍後翻轉至 [記錄] 樞紐,則在認可變更超過 1,000 個檔案時不會持續保存檔案名稱。We heard feedback from people that when they filter the directory to a particular file in the Files pivot of the Code hub and later flip to the History pivot, the filename isn’t persisted if the commit changed more than 1,000 files. 這導致人員必須載入更多檔案,並篩選內容來尋找檔案,因而影響生產力。This resulted in people needing to load more files and filter content to find the file, which was impacting productivity. 開發人員通常會處理相同的目錄,並且想要持續保存到他們追蹤變更時所處理的目錄。Developers normally work in the same directory and want to persist to the directories they work in as they trace changes. 在 [程式碼] 中樞樞紐之間移動時,我們現在都會持續保存檔案名稱,不論認可中變更多少檔案數目。Now, we persist the filename as you move between Code hub pivots regardless of the number of files changed in a commit. 這表示您不需要按一下 [載入更多] 即可找到您想要的檔案。This means that you do not have to click on Load More to find the file you want.

檢視 Git 標記 View Git tags

您可以在 [標記] 頁面 (圖 25) 檢視存放庫中的所有標記。You can view all the tags in your repository on the Tags page (Figure 25). 如果您將所有標記管理為發行,則使用者可以前往 [標記] 頁面,以取得所有產品發行的鳥瞰檢視。If you manage all your tags as releases, then a user can visit the tags page to get a bird’s-eye view of all the product releases.

View Git tags
(圖 25) 檢視 Git 標記(Figure 25) View Git tags

您可以輕易區辨輕量型標記與已標註的標記。You can easily differentiate between a lightweight and an annotated tag. 已標註的標記會顯示標記者和建立日期及相關的認可,而輕量型標記只會顯示認可資訊。Annotated tags show the tagger and the creation date alongside the associated commit, while lightweight tags only show the commit information.

刪除 Git 標記Delete Git tags

您有時可能想要從遠端存放庫中刪除標記。There can be times when you want to delete a tag from your remote repo. 原因可能是標記名稱有錯字,或您可能已標記錯誤認可。It could be due to a typo in the tag name, or you might have tagged the wrong commit. 您可以從 Web UI 輕鬆地刪除標記,方法是在 [標記] 頁面上按一下標記的操作功能表,並選取 [刪除標記](圖 26)。You can easily delete tags from the web UI by clicking the context menu of a tag on the Tags page and selecting Delete tag (Figure 26).

警告

刪除遠端存放庫上的標記時需要特別小心。Deleting tags on remote repos should be exercised with caution.

Delete git tags
(圖 26) 刪除 Git 標記(Figure 26) Delete Git tags

篩選 Git 標記Filtering Git tags

針對舊的存放庫,標記數目可能會隨著時間大幅成長;也會有已在階層中建立標記的存放庫,這讓尋找標記更為困難。For old repositories, the number of tags can grow significantly with time; there can also be repositories that have tags created in hierarchies, which can make finding tags difficult.

如果在 [標記] 頁面上找不到您要尋找的標記,您可以直接在 [標記] 頁面 (圖 27) 頂端使用篩選搜尋標記名稱。If you are unable to find the tag that you were looking for on the Tags page, then you can simply search for the tag name using the filter on top of the Tags page (Figure 27).

Filter Git tags
(圖 27) 篩選 Git 標記(Figure 27) Filter Git tags

Git 標記安全性Git tags security

您現在可以將細微權限授與存放庫使用者以管理標記。Now you can grant granular permissions to users of the repo to manage tags. 您可以將從這個介面 (圖 28) 刪除標記或管理標記的權限授與使用者。You can give users the permission to delete tags or manage tags from this interface (Figure 28).

Git tag security
(圖 28) Git 標記安全性(Figure 28) Git tag security

Microsoft DevOps 部落格深入了解 Git 標記。Read more about Git tags at the Microsoft DevOps blog.

完成提取要求時自動完成工作項目 Automatically complete work items when completing pull requests

如果您要將工作項目連結至 PR,則保持最新資訊會簡單一點。If you’re linking work items to your PRs, keeping everything up to date just got simpler. 現在,當您完成 PR 時,可以選擇在成功合併 PR 之後自動完成連結的工作項目 (圖 29)。Now, when you complete a PR, you’ll have the option to automatically complete the linked work items after the PR has been merged successfully (Figure 29). 如果您要使用原則,並將 PR 設定成自動完成,則會看到相同的選項。If you’re using policies and set PRs to auto-complete, you’ll see the same option. 完成 PR 之後,就不再需要重新瀏覽工作項目來更新狀態。No more remembering to revisit work items to update the state once the PR has completed. 這會自動為您完成。This will be done for you automatically.

Complete linked work items
(圖 29) 完成連結的工作項目(Figure 29) Complete linked work items

重設對推送/反覆項目的投票Reset votes on push/new iteration

PR 中更嚴格核准工作流程的小組選擇現在可以選擇加入,以在推送新變更時重設投票 (圖 30)。Teams opting for a more strict approval workflow in PRs can now opt-in to reset votes when new changes are pushed (Figure 30). 新的設定是 [需要最少數目的檢閱者] 原則下的選項。The new setting is an option under the policy to Require a minimum number of reviewers.

Reset votes setting
(圖 30) 重設投票設定(Figure 30) Reset votes setting

設定時,只要更新 PR 的來源分支,這個選項就會重設來自所有檢閱者的所有投票。When set, this option will cause all votes from all reviewers to be reset any time the source branch of the PR is updated. 只要因這個選項而重設投票,PR 時間軸就會記錄一個項目 (圖 31)。The PR timeline will record an entry any time the votes are reset as a result of this option (Figure 31).

Reset votes in timeline
(圖 31) 重設時間軸中的投票(Figure 31) Reset votes in timeline

依檔案名稱篩選提取要求樹狀結構Filter pull request tree by file name

在提取要求中尋找特定檔案比以往更為容易。Finding a specific file in a pull request is easier than ever. [檔案] 檢視中的新篩選方塊可讓使用者往下篩選樹狀檢視中的檔案清單 (圖 32)。The new filter box in the Files view lets users filter down the list of files in the tree view (Figure 32).

Find file or folder in pull request
(圖 32) 在提取要求中尋找檔案或資料夾(Figure 32) Find file or folder in pull request

此篩選會比對提取要求中檔案路徑的任何部分,因此,您可以依資料夾名稱、部分路徑、檔案名稱或副檔名進行搜尋 (圖 33)。The filter matches any part of the path of the files in the pull request, so you can search by folder names, partial paths, file names, or extensions (Figure 33).

Find results
(圖 33) 尋找結果(Figure 33) Find results

其他提取要求註解篩選選項More pull request comments filtering options

提取要求概觀與檔案檢視中的註解現在都有相同的選項 (圖 34)。Comments in both the pull request overview and the files view now have the same options (Figure 34). 您也可以篩選只查看您已參與的討論。You can also filter to see only the discussions you participated in.

PR comment filtering
(圖 34) PR 註解篩選(Figure 34) PR comment filtering

檢視提取要求詳細資料中程式碼註解的原始差異View original diff for code comments in pull request details

有時候,在 PR 註解參考的程式碼變更多次,或是按要求的變更實作後,該 PR 註解會變得不合理 (圖 35)。Sometimes, it’s hard to make sense out of a PR comment after the code it’s referencing has changed (many times, when a requested change has been made) (Figure 35).

View original diff
(圖 35) 檢視原始差異(Figure 35) View original diff

發生這種情況時,您現在會看到包含更新編號的徽章,而按一下即可看到程式碼註解一開始建立時的樣子 (圖 36)。When this happens, you’ll now see a badge with an update number that you can click to see what the code looked like at the time the comment was originally created (Figure 36).

Update badge
(圖 36) 更新徽章(Figure 36) Update badge

可摺疊的提取要求註解Collapsible pull request comments

檢閱程式碼是提取要求體驗的重要部分,因此我們新增功能讓檢閱者可以更輕鬆地專注於程式碼。Reviewing code is a critical part of the pull request experience, so we’ve added new features to make it easier for reviewers to focus on the code. 第一次檢閱新程式碼時,程式碼檢閱者可以輕鬆隱藏註解,以取得較簡潔的畫面 (圖 37)。Code reviewers can easily hide comments to get them out of the way when reviewing new code for the first time (Figure 37).

Hide comments
(圖 37) 隱藏註解(Figure 37) Hide comments

隱藏註解 (圖 38) 會將其從樹狀檢視中隱藏,並摺疊檔案檢視中的註解討論串:Hiding comments (Figure 38) hides them from the tree view and collapses the comment threads in the file view:

Collapsed comments
(圖 38) 已摺疊的註解(Figure 38) Collapsed comments

註解在摺疊時,只要按一下邊界的圖示即可輕鬆地將之展開,而再按一下就可以再次摺疊。When comments are collapsed, they can be expanded easily by clicking the icon in the margin, and then collapsed again with another click. [工具提示] (圖 39) 可讓您輕鬆查看註解,而不會看到整個討論串。Tooltips (Figure 39) make it easy to peek at a comment without seeing the entire thread.

Collapsed comment tooltip
(圖 39) 已摺疊的註解工具提示(Figure 39) Collapsed comment tooltip

提取要求描述和註解中的工作清單Task lists in pull request descriptions and comments

準備 PR 或註解時,您有時會有想要追蹤但最後編輯文字或新增多個註解的簡短項目清單。When preparing a PR or commenting you sometimes have a short list of things that you want to track but then end up editing the text or adding multiple comments. 輕量型工作清單是不錯的方式,可在待辦事項清單上將進度追蹤為描述或單一合併註解中的 PR 建立者或檢閱者。Lightweight task lists are a great way to track progress on a list of to-dos as either a PR creator or reviewer in the description or a single, consolidated comment. 按一下 Markdown 工具列以開始使用,或將格式套用至選取的文字 (圖 40)。Click on the Markdown toolbar to get started or apply the format to selected text (Figure 40).

Task list toolbar
(圖 40) [工作清單] 工具列(Figure 40) Task list toolbar

新增工作清單後 (圖 41),您只需要選取方塊,即可將項目標記為已完成。Once you’ve added a task list (Figure 41), you can simply check the boxes to mark items as completed. 這些是使用 Markdown 以 [ ][x] 形式表示並儲存在註解內。These are expressed and stored within the comment as [ ] and [x] in Markdown. 如需詳細資訊,請參閱 Markdown guidance (Markdown 指引)。See Markdown guidance for more information.

Task list
(圖 41) 工作清單(Figure 41) Task list

可以對提取要求中的註解「按讚」Ability to “Like” comments in pull requests

只要按一下 [讚] 按鈕,即可表達您對 PR 註解的支持 (圖 42)。Show your support for a PR comment with a single click on the like button (Figure 42). 您可以將滑鼠游標暫留在按鈕上方,以查看對註解按讚的所有人員清單。You can see the list of all people that liked the comment by hovering over the button.

Like pull request comments
(圖 42) 對提取要求註解按讚(Figure 42) Like pull request comments

核准但有建議時的改善工作流程Improved workflow when approving with suggestions

在提取要求使用 [自動完成] 選項 (圖 43) 是提高生產力的有效方法,但與程式碼檢閱者之間進行的討論不應該草率結束。Using the auto-complete option (Figure 43) with pull requests is a great way to improve your productivity, but it shouldn’t cut short any active discussions with code reviewers. 為了進一步簡化這些討論,[核准但有建議] 投票現在會提示將提取要求設定為自動完成時。To better facilitate those discussions, the Approve with suggestions vote will now prompt when a pull request is set to complete automatically. 使用者可以選擇取消自動完成,以讀取其意見反應,或設定自動完成,並允許在滿足所有原則時自動完成提取要求。The user will have the option to cancel the auto-complete so that their feedback can be read, or keep the auto-complete set and allow the pull request to be completed automatically when all policies are fulfilled.

Cancel auto-complete dialog
(圖 43) [取消自動完成] 對話方塊(Figure 43) Cancel auto-complete dialog

Git 通知的路徑篩選支援Path filtering support for Git notifications

您現在可以選擇在小組成員只在所關心資料夾中建立提取要求或推送程式碼時收到通知,而不是收到存放庫中所有資料夾的通知。Instead of getting notifications for all folders in a repo, you can now choose to get notified when team members create pull requests or push code in only the folders that you care about. 建立自訂 Git 推送或 Git 提取要求電子郵件通知訂閱時會顯示新選項,可讓您依資料夾路徑篩選這些通知 (圖 44)。When creating custom Git push or Git pull requests email notification subscriptions, you will see a new option to filter these notifications by folder path (Figure 44).

Path filtering for notifications
(圖 44) 通知的路徑篩選(Figure 44) Path filtering for notifications

已更新提取要求工作流程的電子郵件範本Updated email templates for pull request workflows

提取要求電子郵件警示已經過更新,使其更加清楚、精簡且易於操作 (圖 45)。Pull request email alerts have been refreshed to make them clear, concise, and actionable (Figure 45). 主旨行的開頭是 PR 標題,而次要資訊 (例如存放庫名稱) 和識別碼則會延遲到結尾。The subject line will begin with the PR title and secondary information, like the repo name, and ID will be deferred to the end. 主旨中新增了作者名字,這樣要根據 PR 建立者來套用篩選和規則就變得更容易。The name of the author has been added to the subject to make it simpler to apply rules and filters based on the person that created the PR.

警示電子郵件本文具有已重新整理的範本,而此範本會先摘要說明警示的傳送原因、後面接著重要中繼資料 (標題、分支名稱和描述),以及主要行動信號按鈕。The body of the alert emails has a refreshed template that first summarizes why the alert was sent, followed by the critical metadata (title, branch names, and description), and a main call-to-action button. 檢閱者、檔案和認可這類其他詳細資料隨附於電子郵件下方。Additional details like the reviewers, files, and commits are included further down the email.

Improved email template
(圖 45) 改善的電子郵件範本(Figure 45) Improved email template

對於大部分的警示,行動信號 (圖 46) 會檢視網頁中的提取要求。For most alerts, the call-to-action (Figure 46) will be to view the pull request in the web. 不過,當您收到特定註解的通知時,行動信號會「直接連結至該註解」,讓您可以輕鬆地找到內容的程式碼和前一個交談。However, when you’re notified about a specific comment, the call-to-action will link directly to that comment so you can easily find the code and prior conversation for context.

Email call-to-action
(圖 46) 電子郵件行動信號(Figure 46) Email call-to-action

更新推播通知的電子郵件範本Updated email templates for push notifications

已更新推播通知使符合經過最佳化之清楚、精確且可採取動作的新電子郵件範本 (圖 47)。Push notifications have been updated to match the new email templates that are optimized to be clear, concise, and actionable (Figure 47). 主旨行可協助您清楚分辨發送電子郵件,找出分支、存放庫和作者,並彙總推送所包含的認可數目。The subject line helps you clearly distinguish push emails, identify the branch, repo, and author, and summarize the number of commits included in the push. 這些變更也能讓您更輕鬆建立規則和篩選器,利於管理這些電子郵件通知。These changes also make it easier to create rules and filters to help manage these email notifications.

電子郵件內文與其他電子郵件一致,強調電子郵件的傳送原由、起始動作的使用者以及實際狀況。The email body is consistent with other emails, emphasizing why the email was sent, who initiated the action, and exactly what happened. 推播警示的特定資訊以及存放庫、分支、檔案和認可的詳細資料,全包含在內,以利通知收件者有關變更的範圍。Specific to push alerts, the details about the repo, branch, files, and commits are all included to help inform the recipients about the scope of the changes. 推播警示的主要引導動作是 [檢視推播],這會開啟推播檢視,以查看產生了警示的特定推播。The main call-to-action for push alerts is View Push, which will open the pushes view for the specific push that generated the alert.

Push template
(圖 47) 推送範本(Figure 47) Push template

Wiki Wiki

每個專案現在都支援各自的 Wiki (圖 48)。Each project now supports its own Wiki (Figure 48). 您現在可以更輕鬆地撰寫頁面,協助您的小組成員了解、使用和參與您的專案。Now you can conveniently write pages that help your team members understand, use, and contribute to your project.

Wiki page
(圖 48) PR Wiki 頁面(Figure 48) PR Wiki page

新 Wiki 的一些主要功能包含:Some of the key features of the new Wiki include:

  • 使用 markdown 語法簡化編輯體驗。Simplified editing experience using markdown syntax.
  • 這個新頁面可讓您指定標題並新增內容。The new page allows you to specify a title and add content. (圖 49)(Figure 49)
Title Wiki
(圖 49) PR 標題 Wiki(Figure 49) PR Title Wiki
  • 支援 Markdown 的 HTML 標籤 (圖 50)。Support for HTML tags in markdown (Figure 50).
Wiki HTML tags
(圖 50) PR Wiki HTML 標籤(Figure 50) PR Wiki HTML tags
  • 輕鬆調整 Markdown 資料夾中的影像大小 (圖 51)。Conveniently resize images in the markdown folder (Figure 51).
Image resize
(圖 51) PR 影像大小調整(Figure 51) PR Image resize
  • 功能強大的頁面管理窗格,可讓您重新排列、重設父代以及管理頁面。Powerful page management pane that allows you to reorder, re-parent, and manage pages.
  • 能夠依大型 Wiki 的標題來篩選頁面 (圖 52)。Ability to filter pages by title for large Wikis (Figure 52).
Wiki menu
(圖 52) PR Wiki 功能表(Figure 52) PR Wiki menu

深入了解開始使用 WikiLearn more about getting started with Wiki.

  • 當您進一步使用 Wiki 時,可能會儲存非預期的變更。As you use Wiki more, there is a chance you’ll save unintended changes. 現在,前往修訂詳細資料,然後按一下 [還原] 按鈕,即可將修訂還原為 Wiki 頁面 (圖 53)。Now you can revert a revision to a Wiki page by going to the revision details and clicking on the Revert button (Figure 53).
Wiki revert button
(圖 53) PR Wiki 還原按鈕(Figure 53) PR Wiki revert button

我們在 Wiki 的建立過程中觀察到一種模式,也就是 Wiki 頁面上的目錄包含了不存在的連結 (圖 54)。We observed a pattern during Wiki creation where a table of contents on a Wiki page included non-existent links (Figure 54). 而使用者會按一下這些連結,試圖建立實際頁面。Users would click on these links in an attempt to create an actual page. 我們之前處理這種情況的方式是提出警告,表示連結已中斷或該頁面不存在。We previously handled this scenario by giving a warning suggesting that the link was broken, or that the page did not exist. 我們現在將這種情況視作 Wiki 的主要問題處理,讓您可以改為建立頁面。Now, we are handling this as a mainstream scenario for Wiki, by allowing you to create pages instead.

Create wiki page
(圖 54) PR 建立 Wiki 頁面(Figure 54) PR Create Wiki page

Wiki 頁面深層連結Wiki page deep linking

Wiki 現在支援頁面內和跨頁面的深層連結區段,這對建立目錄十分有幫助。Wiki now supports deep linking sections within a page and across pages, which is really useful for creating a table of contents. 您可以可以使用下列語法,參考相同頁面或其他頁面的標題:You can reference a heading in the same page or another page by using the following syntax:

  • 相同頁面:[text to display](#section-name)Same page: [text to display](#section-name)
  • 其他頁面:[text to display](/page-name#section-name)Another page: [text to display](/page-name#section-name)

現在已取代 Marketplace 上的 Wiki 延伸模組The Wiki extension on the Marketplace is now deprecated. 如果您是現有的 Wiki 延伸模組使用者,則可以使用此移轉工具將 Wiki 頁面移轉至新的 Wiki。If you are an existing Wiki extension user, then you can migrate your Wiki pages to the new Wiki using this migration tool. 深入了解如何將現有的 Wiki 頁面移轉至新 WikiLearn more about how to migrate your existing Wiki pages to the new Wiki.

封裝管理 Package Management

套件管理體驗更新Package Management experience updates

套件 URL 現在使用套件名稱和版本,而不是使用 GUID。Package URLs now work with the package name and version, rather than using GUIDs. 這能夠簡化手動製作套件 URL 的程序 (圖 55)。This makes it easier to hand-craft package URLs (Figure 55). 格式為:\<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=packageThe format is: \<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package.

Package URL
(圖 55) PR 套件 URL(Figure 55) PR Package URL

您現在可以向所有摘要使用者隱藏已刪除的套件版本 (不再顯示刪除套件!) (圖 56),以回應此 UserVoice 建議You can now hide deleted package versions (Figure 56) from all feed users (no more strikethrough packages!), in response to this UserVoice suggestion.

Hide deleted packages
(圖 56) 隱藏刪除的套件(Figure 56) Hide deleted packages

現在可以從套件清單的操作功能表中執行任何您可以對套件詳細資料頁面執行的動作。Any action that you could perform on the package details page can now be performed from the context menu in the list of packages.

套件清單包含新的 [上次推送時間] 欄位 (圖 57),內附人性化的日期,讓您可以輕鬆找到最近更新的套件。The package list contains a new Last pushed column (Figure 57) with humanized dates so you can easily find recently-updated packages.

Last pushed column
(圖 57) [上次推送時間] 欄位(Figure 57) Last pushed column

Maven 套件 Maven packages

我們已在 TFS 2018 中提供裝載 Maven 成品的支援 (圖 58)。We’ve launched support for hosting Maven artifacts in TFS 2018 (Figure 58). Maven 成品可讓 Java 開發人員輕鬆地共用程式碼和元件。Maven artifacts enable Java developers to easily share code and components. 請參閱入門指南,以了解如何使用套件管理來共用 Maven 成品。Check out our getting started guide for how to share Maven artifacts using Package Management.

Maven packages
(圖 58) Maven 套件(Figure 58) Maven packages

新的統一 NuGet 工作New unified NuGet task

我們已將 [NuGet 還原]、[NuGet 封裝程式] 和 [NuGet 發行者] 工作合併為統一的 NuGet 建置工作,更恰當地符合其餘的建置工作程式庫;新的工作預設會使用 NuGet 4.0.0。We’ve combined the NuGet Restore, NuGet Packager, and NuGet Publisher task into a unified NuGet build task to align better with the rest of the build task library; the new task uses NuGet 4.0.0 by default. 因此,我們已取代舊的工作,並且建議您在有時間時移至新的 NuGet 工作。Accordingly, we’ve deprecated the old tasks, and we recommend moving to the new NuGet task as you have time. 這項變更伴隨著如下所述的改善,即您只能使用合併的工作來進行存取。This change coincides with a wave of improvements outlined below that you’ll only be able to access by using the combined task.

作為這項工作的一部分,我們也已經發行新的 [NuGet 工具安裝程式] 工作,以控制 PATH 上可用的以及新 NuGet 工作所使用的 NuGet 版本。As part of this work, we’ve also released a new NuGet Tool Installer task that controls the version of NuGet available on the PATH and used by the new NuGet task. 因此,若要使用新版的 NuGet,只需要在建置開頭新增 [NuGet 工具安裝程式] 工作 (圖 59)。So, to use a newer version of NuGet, just add a NuGet Tool Installer task at the beginning of your build (Figure 59).

Nuget task
(圖 59) NuGet 工作(Figure 59) NuGet task

進一步閱讀 Microsoft DevOps 部落格上於您的建置中使用最新的 NuGetRead more about using the latest NuGet in your build on Microsoft DevOps Blog.

NuGet “Allow duplicates to be skipped” (允許略過重複的項目) 選項NuGet “Allow duplicates to be skipped” option

我們知道許多產生一組套件的 NuGet 客戶,只有其中一些可能有更新 (因此有已更新的版本號碼)。We heard from many NuGet customers that they generate a set of packages, only some of which may have updates (and therefore updated version numbers). NuGet 建置工作有新的 [Allow duplicates to be skipped] (允許略過重複的項目) 選項,以在嘗試將套件推送至已使用該版本的 VSTS/TFS 摘要時,讓工作繼續。The NuGet build task has a new Allow duplicates to be skipped option that will enable the task to continue if it tries to push packages to a VSTS/TFS feed where the version is already in use.

npm 建置工作更新npm build task updates

不論是在 Windows、Linux 還是 Mac 上建置 npm 專案,新的 NPM 建置工作都會順暢地運作。Whether you’re building your npm project on Windows, Linux, or Mac, the new NPM build task will work seamlessly. 我們也已重新組織工作,讓 npm 安裝和 npm 發行更為簡單。We have also reorganized the task to make both npm install and npm publish easier. 針對__安裝__和__發行__,我們簡化了認證擷取,使專案的 .npmrc 檔案中列出的認證得以安全地儲存在服務端點中。For install and publish, we have simplified credential acquisition so that credentials for registries listed in your project’s .npmrc file can be safely stored in a service endpoint. 或者,如果您要使用 VSTS/TFS 摘要,我們會提供選擇器供您選取摘要,並接著使用組建代理程式所使用的必要認證來產生 .npmrcAlternatively, if you’re using a VSTS/TFS feed, we have a picker that will let you select a feed, and then we will generate a .npmrc with requisite credentials that are used by the build agent.

Maven 現在支援已驗證的摘要Maven now supports authenticated feeds

與 NuGet 和 npm 不同,Maven 建置工作先前未使用已驗證的摘要。Unlike NuGet and npm, the Maven build task did not previously work with authenticated feeds. 我們已更新 Maven 工作,讓您能夠輕鬆使用 VSTS/TFS 摘要 (圖 60)。We’ve updated the Maven task so you can work easily with VSTS/TFS feeds (Figure 60).

dotnet task
(圖 60) dotnet 工作(Figure 60) dotnet task

dotnet 工作支援已驗證的摘要、Web 專案dotnet task supports authenticated feeds, web projects

下一個主要版本的 dotnet 工作 (2.x) 解決許多意見反應要求,並修正我們已追蹤一段時間的一組 Bug。The next major version of the dotnet task (2.x) addresses many of your feedback requests and fixes a set of bugs we’ve tracked for a while.

  1. 首先,dotnet 現在支援已驗證的套件來源 (如套件管理),因此,您不需要再使用 NuGet 工作,就能從私用套件來源還原套件。First, dotnet now supports authenticated package sources like Package Management, so you don’t need to use the NuGet task anymore to restore packages from private package sources.
  2. 在 2.0 版的工作中,[專案的路徑] 欄位的行為已變更。The behavior of Path to project(s) field has changed in the 2.0 version of the task. 在舊版工作中,如果找不到符合所指定模式的專案檔,則會使用該工作來記錄警告,然後成功。In previous versions of the task, if the project file(s) matching the specified pattern were not found, the task used to log a warning and then succeed. 在這種情況下,有時可能很難了解為什麼建置成功,但未還原相依性。In such scenarios it can sometimes be challenging to understand why the build succeeded but dependencies were not restored. 現在,如果找不到符合所指定模式的專案檔,則工作會失敗。Now the task will fail if the project file(s) matching the specified pattern are not found. 這與其他工作的行為一致,而且很容易了解和使用。This is in line with the behavior of other tasks and is easy to understand and use.
  3. 在舊版工作的 publish 命令中,該工作已將所有檔案都放在專案檔名稱後面命名的資料夾中來修改輸出路徑,即使您已傳遞明確輸出路徑時也是一樣。In previous versions of the task’s publish command, the task modified the output path by putting all the files in a folder that was named after the project file name, even when you passed an explicit output path. 這樣很難將命令鏈結在一起。This makes it hard to chain commands together. 您現在可以控制輸出路徑檔案。Now you have control over the output path file.

我們也已經發行新的 [dotnet 工具安裝程式] 工作,以控制 PATH 上可用的以及新 dotnet 工作所使用的 dotnet 版本。We’ve also released a new dotnet Tool Installer task that controls the version of dotnet available on the PATH and used by the new dotnet task. 因此,若要使用較新版的 dotnet,只需要在建置開頭新增 [dotnet 工具安裝程式] 工作。So, to use a newer version of dotnet, just add a dotnet Tool Installer task at the beginning of your build.

在帳戶/集合外部工作Working outside your account/collection

現在可以更輕鬆地在 TFS 伺服器或 VSTS 帳戶外部使用摘要 (圖 61),不論它們是另一個 VSTS 帳戶或 TFS 伺服器中的 [套件管理] 摘要,還是 NuGet.org/npmjs.com、Artifactory 或 MyGet 這類非套件管理摘要都一樣 (圖 60)。It’s now easier to work with feeds (Figure 61) outside your TFS server or VSTS account, whether they’re Package Management feeds in another VSTS account or TFS server or non-Package Management feeds like NuGet.org/npmjs.com, Artifactory, or MyGet (Figure 60). NuGet 和 npm 的專用 [服務端點] 類型可以輕鬆地輸入正確的認證,並讓建置工作跨套件下載和套件推送作業順暢地運作。Dedicated Service Endpoint types for NuGet and npm make it easy to enter the correct credentials and enable the build tasks to work seamlessly across package download and package push operations.

Feeds to use
(圖 61) 要使用的摘要(Figure 61) Feed to use

VSTS/TFS 摘要的摘要選擇器Feed picker for VSTS/TFS feeds

一律建議您簽入組態檔 (例如 NuGet.Config、.npmrc 等等),因此,您的來源存放庫會記錄套件來源。We always recommend checking in a configuration file (e.g. NuGet.Config, .npmrc, etc.) so that your source repository has a record of where your packages came from. 不過,我們聽說這在某些案例中並不理想,因此我們新增了 [使用此 VSTS/TFS 摘要中的套件] 選項,可讓您選取摘要,並自動產生將用於該建置步驟的組態檔 (圖 62)。However, we’ve heard a set of scenarios where this isn’t ideal, so we’ve added a new Use packages from this VSTS/TFS feed option that allows you to select a feed and automatically generate a configuration file that will be used for that build step (Figure 62).

Feed picker
(圖 62) 摘要選擇器(Figure 62) Feed picker

建置和發行 Build and Release

XAML 組建 XAML Builds

在 TFS 2015 中,我們已引進網頁型跨平台組建系統。In TFS 2015, we introduced a web-based, cross-platform build system. TFS 2018 RTW 與 Update 1 中不支援 XAML 組建,但我們在 TFS 2018 Update 2 中重新啟用了 XAML 組建。XAML builds are not supported in TFS 2018 RTW or Update 1, but we have re-enabled XAML builds in TFS 2018 Update 2. 我們鼓勵您移轉 XAML 組建We encourage you to migrate your XAML builds. 如果您尚未準備好移轉,並且需要繼續使用 XAML 組建,請升級至 TFS 2018 Update 2。If you're not yet ready to migrate and need to continue using XAML builds, please upgrade to TFS 2018 Update 2.

當您升級至 TFS 2018 RTW 或 Update 1 時:When you upgrade to TFS 2018 RTW or Update 1:

  • 如果您的 Team 專案集合中有任何 XAML 組建資料,則會收到有關移除 XAML 組建功能的警告。If you have any XAML build data in your team project collection, you'll get a warning about the removal of XAML build features.

  • 可以檢視已完成的 XAML 組建,但無法將新的 XAML 組建加入佇列。You'll be able to view completed XAML builds, but you won't be able to queue new ones.

  • TFS 2018 中沒有任何新版的 XAML 組建控制器或代理程式。There's no new version of the XAML build controller or agent in TFS 2018.

當您升級至 TFS 2018 Update 2 時:When you upgrade to TFS 2018 Update 2:

  • 如果您的 Team 專案集合中有任何 XAML 組建資料,則會收到有關淘汰 XAML 組建功能的警告。If you have any XAML build data in your team project collection, you'll get a warning about the deprecation of XAML build features.

  • 您將必須使用 VS 或 Team Explorer 2017 才能編輯 XAML 組建定義,或將新的 XAML 組建加入佇列。You will need to use VS or Team Explorer 2017 to edit XAML build definitions or to queue new XAML builds.

  • 若您需要建立新的 XAML 組建代理程式,則必須使用 TFS 2015 組建代理程式安裝程式加以安裝。If you need to create new XAML build agents, you’ll need to install them using the TFS 2015 build agent installer.

如需 XAML 組建淘汰計畫的說明,請參閱「TFS/Team Services 建置自動化功能的演變」部落格文章For an explanation of our XAML build deprecation plan, see the Evolving TFS/Team Services build automation capabilities blog post.

匯出和匯入組建定義 Export and import build definitions

組建定義在內部實作為 .json 檔案,因此,您可以查看檔案歷程記錄中變更的詳細資料。Build definitions are implemented internally as .json files, so you can see details on changes in the file’s history. 您可以透過組建定義複製和建立範本,但許多使用者想要建立其 CI 組建邏輯的複本,並將它重複用於另一個 Team 專案。You can already clone and make templates from your build definitions, but many users have wanted to take a copy of their CI build logic and reuse it in another team project. 實際上,它已是 UserVoice 的前十個要求In fact it’s been a top-ten request on UserVoice.

我們很高興宣佈,這個功能現在成真了 (圖 63) 與 (圖 64)!We’re pleased to announce that this is now possible (Figure 63) and (Figure 64)!

Export build definition
(圖 63) 匯出組建定義(Figure 63) Export build definition
Import build definition
(圖 64) 匯入組建定義(Figure 64) Import build definition

具有建置範本的延伸模組Extensions with build templates

建置範本可讓您建立使用者開始定義其建置流程的基準。Build templates let you create a baseline for users to get started with defining their build process. 我們現在於盒子中提供一些建置範本,而且將新的建置範本上傳至帳戶時,延伸模組作者絕不可能將新範本包含為延伸模組的一部分。We ship a number of them in the box today and while you could upload new ones to your account, it was never possible for extension authors to include new templates as part of an extension. 您現在可以在延伸模組中包含建置範本。You can now include build templates in your extensions. 例如: For example:

{  "id": "Template1", 
   "type": "ms.vss-build.template", 
   "targets": [ "ms.vss-build.templates" ], 
   "properties": { "name": "Template1" } }

如需完整範例,請參閱 https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension。For the full example, see https://github.com/Microsoft/vsts-extension-samples/tree/master/fabrikam-build-extension.

提示

您可以使用這項功能,跨所有 Team 專案提供和共用相同自訂範本。You can use this capability to offer and share the same custom template across all your team projects.

取代延伸模組中的工作Deprecate a task in an extension

您現在可以取代延伸模組中的工作。You can now deprecate a task in your extension. 為了讓它運作,您必須在工作的最新版本中新增下列變數:To make it work, you must add the following variable to the latest version of your task:

"deprecated": true

使用者搜尋淘汰的工作時 (圖 65),我們會將這些工作推送至結尾,並在預設會摺疊的可摺疊區段下予以分組。When the user searches for deprecated tasks (Figure 65), we push these tasks to the end and group them under a collapsible section that’s collapsed by default. 如果定義已經使用已取代的工作,我們會示範已取代的工作徽章,鼓勵使用者切換至取代。If a definition is already using a deprecated task, we show a deprecated task badge to encourage users to switch to the replacement.

Deprecated task badge
(圖 65) 過時工作徽章(Figure 65) Deprecated task badge

您可以在工作描述中提及取代工作,以協助使用者深入了解 (圖 66)。You can help your users learn about the replacement task by mentioning it in the task description (Figure 66). 描述接著將透過工作目錄和現有建置/發行定義,以正確方向指向使用該工作的分支。The description will then point folks using the task in the right direction from both the task catalog and the existing build/release definitions.

Deprecated task description
(圖 66) 過時工作描述(Figure 66) Deprecated task description

讓參與的建置區段控制區段可見性Let contributed build sections control section visibility

之前,如果您要使用包含組建工作和組建摘要區段的延伸模組,就會看到組建摘要區段,即使您未在該組建中使用組建工作也是一樣。Previously, if you were using an extension that had build tasks and build summary sections, you’d see the build summary section even if you weren’t using the build task in that build. 您現在可以選擇在組建摘要頁面中隱藏或顯示該區段,方法是在延伸模組程式碼中新增下行,並將值設定為 true 或 false:Now, you can choose to hide or show that section in the build summary page by adding the following line in your extension code and setting the value to true or false:

VSS.getConfiguration().setSectionVisibility("$(publisherId).$(extensionId).$(sectionId)", false);

檢視 Microsoft vsts-extension-samples 存放庫中所含的範例。View the sample included in the Microsoft vsts-extension-samples repository.

變數群組支援Variable group support

變數群組已可在發行定義中使用,並且也即將支援在組建定義中使用。Variable groups have been available to use in release definitions, and now they are ready to be used in build definitions, too. 深入了解建立變數群組Learn more about creating a variable group. 這已根據專案層級建置/發行變數組建定義中的變數群組的相關建議進行開發並排定優先順序。This has been developed and prioritized based on related suggestions for project-level build/release variables and variable groups in build definitions.

使用安全檔案 (例如 Apple 憑證)Work with secure files such as Apple certificates

我們已新增一般用途安全檔案程式庫 (圖 67)。We’ve added a general-purpose secure files library (Figure 67).

Secure files library
(圖 67) 安全檔案程式庫(Figure 67) Secure files library

使用安全檔案程式庫將簽署憑證、Apple 佈建設定檔、Android Keystore 檔案和 SSH 金鑰這類檔案儲存至伺服器,而不需要將其認可至來源存放庫。Use the secure files library to store files such as signing certificates, Apple Provisioning Profiles, Android Keystore files, and SSH keys on the server without needing to commit them to your source repository.

安全檔案的內容會進行加密,而且只有從工作進行參考,才能在建置或發行程序期間使用。The contents of secure files are encrypted and can only be used during build or release processes by referencing them from a task. 安全檔案可以根據安全性設定以跨 Team 專案中的多個組建和發行定義使用。Secure files are available across multiple build and release definitions in the team project based on security settings. 安全檔案遵循程式庫安全性模型。Secure files follow the Library security model.

我們也已新增一些利用這項新功能的 Apple 工作:We’ve also added some Apple tasks that leverage this new feature:

暫停組建定義Pause build definitions

您現在可以暫停或停用組建定義。You can now pause or disable build definitions. 如果您打算對組建定義進行變更,而且希望完成前能避免任何新的組建排入佇列,您只需要停用組建定義即可。If you plan to make changes to your build definition and you want to avoid queuing any new builds until you are done, simply disable the build definition. 同樣地,如果您想要升級代理程式電腦,您可以選擇暫停組建定義,讓 VSTS 仍接受新的組建要求,但保留在佇列中不執行,直到您繼續定義。Similarly, if you plan to upgrade agent machines, you can choose to pause a build definition, which enables VSTS to still accept new build requests but hold them in queue without running until you resume the definition.

工作輸入驗證支援Task input validations support

在組建定義工作中鍵入參數,有時候很容易發生錯誤。Typing the parameters in build definition tasks can sometimes be error prone. 使用工作輸入驗證,工作作者可以確保指定適當的值。With task input validation, task authors can ensure appropriate values are specified. 驗證運算式會遵循工作條件所用的熟悉運算式語法,而且可以使用任何受支援的函式,但工作條件支援的一般函式除外,包括 URL、IPV4、電子郵件、數字範圍、sha1、長度或比對。Validation expressions follow the familiar expression syntax used for task conditions and can use any of the supported functions besides the general functions supported by task conditions, including URL, IPV4, email, number range, sha1, length, or match.

深入了解 vsts 工作存放庫頁面上的目標和使用量。Read more about the goals and usage on the vsts-tasks repo page.

新增發行定義編輯器 New Release Definition Editor

基於繼續重新整理組建與版本體驗,我們已重新假設版本定義編輯器以提供更直覺式的體驗、修正一些痛點,並新增新的功能。Continuing on our journey of refreshing the Build and Release experiences, we have re-imagined the release definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. 新編輯器的最強大功能之一,是能夠協助您將環境的部署過程視覺化。One of the most powerful features of the new editor is its ability to help you visualize how deployments to your environments would progress. 除此之外,核准、環境屬性及部署設定現在都包含在內容中,而且可以輕鬆設定。In addition to this, approvals, environment properties, and deployment settings are now in-context and easily configurable.

管線的視覺效果Visualization of the pipeline

編輯器中的管線 (圖 68) 提供圖形化檢視,以顯示版本中的部署會如何進行。The pipeline (Figure 68) in the editor provides a graphical view of how deployments will progress in a release. 發行將使用成品,並將其部署至環境。The artifacts will be consumed by the release and deployed to the environments. 環境的配置和連結會反映針對每個環境所定義的觸發程序設定。The layout and linking of the environments reflects the trigger settings defined for each environment.

Pipeline
(圖 68) 發行管線(Figure 68) Release pipeline
內容中的組態 UIIn context configuration UI

成品、發行觸發程序、部署前和部署後核准、環境屬性以及部署設定現在都包含在內容中,而且可以輕鬆設定 (圖 69)。Artifacts, release triggers, pre-deployment and post-deployment approvals, environment properties, and deployment settings are now in-context and easily configurable (Figure 69).

Release configuration
(圖 69) 發行設定(Figure 69) Release configuration
開始使用部署範本Getting started with deployment templates

所有內建部署範本皆配有流程參數,讓使用者便於指定最重要的參數以開始使用,而不必深入工作 (圖 70)。All in-built deployment templates are equipped with process parameters which makes it easier for users to get started by specifying the most important parameters without needing to go deep into your tasks (Figure 70).

Deployment templates
(圖 70) 部署範本(Figure 70) Deployment templates
版本和環境變數的簡化管理Simplified management of release and environment variables

使用 [清單] 檢視快速新增版本或環境變數,使用 [方格] 檢視來比較及編輯跨範圍並存的變數 (圖 71)。Use the List view to quickly add release or environment variables and the Grid view to compare and edit variables across scopes side-by-side (Figure 71). 此外,您可以使用篩選器和關鍵字搜尋來管理兩個檢視都使用的變數集。Additionally, you can use the filter and keyword search to manage the set of variables to work with in both the views.

Simplified management of variables
(圖 71) 簡化的變數管理(Figure 71) Simplified management of variables
改善的工作和階段編輯器Improved task and phase editor

新組建定義編輯器中的所有增強功能,現在也都在版本定義編輯器中提供使用 (圖 72)。All the enhancements in the new build definition editor are now available in the release definition editor, as well (Figure 72). 您可以搜尋工作,並使用 [新增] 按鈕或使用拖放加以新增。You can search for tasks and add them by either using the Add button or by using drag/drop. 您可以使用拖放來重新排列或複製工作。You can reorder or clone tasks using drag/drop.

Task editor
(圖 72) 工作編輯器(Figure 72) Task editor
變數群組、保留和 [選項] 索引標籤Variable groups, Retention, and Options tabs

您現在可以從 [選項] 索引標籤建立/中斷與變數群組之間的的連結 (圖 73)、設定個別環境的保留原則,以及修改版本定義層級設定,例如版本編號格式。您也可以將環境儲存為部署範本、設定環境層級權限,以及重新排序 [工作] 索引標籤內的階段。You can now link/unlink to variable groups (Figure 73), set retention policy for individual environments, and modify release definition-level settings such as release number format from the Options tab. You can also save an environment as a deployment template, set environment level permissions, and re-order phases within the Tasks tab.

Variable groups
(圖 73) 變數群組(Figure 73) Variable groups

使用環境層級作業,來儲存為範本及設定安全性 (圖 74)。Use environment level operations to save as template and set security (Figure 74).

Environment menu
(圖 74) 環境功能表(Figure 74) Environment menu

如需詳細資訊,請參閱版本定義編輯器文件See the documentation for Release Definition Editor for more information.

使用部署群組的 VM 部署 VM Deployment using Deployment Groups

Release Management 現在支援強固預設多電腦部署。Release Management now supports robust out-of-the-box multi-machine deployment. 您現在可以跨多部電腦組織部署,並執行輪流更新,同時確保整個應用程式的高可用性。You can now orchestrate deployments across multiple machines and perform rolling updates while ensuring high availability of the application throughout.

代理程式型部署功能依賴相同的組建和部署代理程式。Agent-based deployment capability relies on the same build and deployment agents. 不過,不像目前用來在代理程式集區的一組 Proxy 伺服器上安裝組建和部署代理程式以及部署到遠端目標伺服器的方式,您可以直接在每部目標伺服器上安裝代理程式,然後對這些伺服器進行輪流部署。However, unlike the current approach where you install the build and deployment agents on a set of proxy servers in an agent pool and drive deployments to remote target servers, you install the agent on each of your target servers directly and drive rolling deployments to those servers. 您可以在目標電腦上使用完整工作目錄。You can use the full task catalog on your target machines.

部署群組 (圖 75) 是指已安裝代理程式的目標 (電腦) 邏輯群組。A deployment group (Figure 75) is a logical group of targets (machines) with agents installed on each of them. 部署群組代表實體環境,例如單箱開發、多電腦 QA,以及 UAT/生產之電腦的伺服器陣列。它們也會指定您實體環境的安全性內容。Deployment groups represent your physical environments, such as single-box Dev, multi-machine QA, and a farm of machines for UAT/Prod. They also specify the security context for your physical environments.

Deployment groups
(圖 75) 部署群組(Figure 75) Deployment groups

您可以針對向其註冊我們的代理程式的任何 VM 使用這個項目。You can use this against any VM that you register our agent with. 我們也很輕鬆地向 Azure 註冊,並支援在 VM 旋轉時自動安裝代理程式的 Azure VM 延伸模組。We’ve also made it very easy to register with Azure with support for an Azure VM extension that auto-installs the agent when the VM spins up. 註冊 Azure VM 時,我們將會自動繼承其上的標記。We will automatically inherit the tags on the Azure VM when it’s registered.

在您擁有部署群組後,只需要設定您想要我們對該部署群組執行的動作 (圖 76)。Once you have a deployment group, you simply configure what you want us to execute on that deployment group (Figure 76). 您可以控制哪些標記在哪些使用標記的電腦上執行,以及控制首度發行的發生速度快或慢。You can control what gets run on which machines using tags and control how fast or slow the rollout happens.

Configure deployment groups
(圖 76) 設定部署群組(Figure 76) Configure deployment groups

執行部署時,記錄會顯示您設為目標的整個電腦群組進度 (圖 77)。When the deployment is run, the logs show the progression across the entire group of machines you are targeting (Figure 77).

Deployment group progress
(圖 77) 部署群組進度(Figure 77) Deployment group progress

這項功能現在是 Release Management 的整合部分。This feature is now an integrated part of Release Management. 不需要其他授權。No additional licenses are required.

改善的部署群組 UIImproved Deployment Groups UI

繼續重新整理組建版本體驗,我們現在已重新假設部署群組頁面,使其成為更簡潔的直覺式體驗 (圖 78)。Continuing our journey of refreshing the Build and Release experiences, we have now re-imagined our deployment groups pages to make it a more clean and intuitive experience (Figure 78). 您可以從登陸頁面檢視部署群組的目標健康狀態。From the landing page, you can view the health of the targets in the deployment group. 您也可以管理個別部署群組的安全性,或跨部署群組設定預設權限。You can also manage security for an individual deployment group, or set default permissions across deployment groups.

Deployment groups UI
(圖 78) 部署群組 UI(Figure 78) Deployment groups UI

針對部署群組內的目標,您可以檢視摘要、最近的部署和目標的功能 (圖 79)。For a target within a deployment group, you can view a summary, recent deployments, and the target’s capabilities (Figure 79). 您可以在目標上設定標記,並控制每個目標上執行的內容。You can set tags on the target, and control what is run on each target. 我們在未來的版本中會新增部署群組的篩選器支援。We will be adding filter support for deployment groups in upcoming releases.

Deployment groups UI tags
(圖 79) 部署群組 UI 標籤(Figure 79) Deployment groups UI tags

工作群組參考Task group references

工作群組可讓您定義一組新增至組建或版本定義的工作 (圖 80)。Task groups let you define a set of tasks that you can add to your build or release definitions (Figure 80). 如果您需要在多個組建或版本中使用同一組工作,則這十分方便。This is handy if you need to use the same grouping of tasks in multiple builds or releases. 為了協助您追蹤某工作群組的取用者,您現在可以檢視組建定義、版本定義,以及參考您工作群組的工作群組 (圖 79)。To help you track the consumers of a task group, you now have a view into the build definitions, release definitions, and task groups that reference your task group (Figure 79).

Task group references
(圖 80) 工作群組參考(Figure 80) Task group references

當您嘗試刪除仍參考的工作群組時,我們會警告您,並提供此頁面的連結。When you try to delete a task group that’s still referenced, we warn you and give you a link to this page.

工作群組版本控制Task group versioning

變更工作群組時,可能會有風險,因為這項變更會影響所有使用工作群組的定義。When making changes to task groups, it can feel risky because the change is effective to all definitions that use the task group. 使用工作群組版本控制時,您現在可以編寫並預覽工作群組版本,同時仍然提供最重要定義的穩定版本,直到準備好進行切換。With task group versioning, now you can draft and preview task group versions while still offering stable versions to your most important definitions until you are ready to switch. 在進行某個草稿編寫和反覆項目之後,您可以發行穩定版本;而且,在發行時,如果變更在本質上是最新的,則可以選擇將工作群組發行為預覽 (新的主要版本)。After some drafting and iteration, you can publish a stable version and, while publishing, if the changes are breaking in nature, you can choose to publish the task group as preview (a new major version). 或者,您可以直接將其發行為已更新的穩定版本 (圖 81)。Alternatively, you can publish it directly as an updated stable version (Figure 81).

有工作群組的新主要 (或預覽) 版本可用時,定義編輯器會向您建議新版本。When a new major (or preview) version of the task group is available, the definition editor will advise you that there is a new version. 如果該主要版本是預覽版,您甚至會看到「立即試用」訊息。If that major version is preview, you even see a “try it out” message. 當工作群組可供預覽時,使用該群組的定義將會自動更新,並藉由該主要通道推出 (圖 82)。When the task group comes out of preview, definitions using it will be auto-updated, sliding along that major channel (Figure 82).

Save as draft
(圖 81) 將工作群組儲存為草稿(Figure 81) Save task group as draft
Publish task group as preview
(圖 82) 將工作群組發行為預覽(Figure 82) Publish task group as preview

工作群組匯入和匯出Task group import and export

雖然工作群組已在專案內啟用重複使用,但是我們知道跨專案和帳戶重新建立工作群組可能十分麻煩。Although task groups have enabled reuse within a project, we know that recreating a task group across projects and accounts can be painful. 使用工作群組匯入/匯出 (圖 83),與我們對版本定義的做法相同,您現在可以匯出為 JSON 檔案,以及匯入您想要的位置中。With task group import/export (Figure 83), as we’ve done for release definitions, now you can export as a JSON file and import where you want it. 我們也已啟用巢狀工作群組,而巢狀工作群組在匯出時會先展開。We’ve also enabled nested task groups, which first expand when they are exported.

Export task group
(圖 83) 匯出工作群組(Figure 83) Export task group

伺服器端 (無代理程式) 工作中的多重組態支援Multi Configuration support in Server Side (Agentless) tasks

透過指定伺服器端 (無代理程式) 工作 (圖 84) 的變數乘數,您現在可以在多個組態 (平行執行) 的某個階段中執行同一組工作。By specifying variable multipliers for server side (agentless) tasks (Figure 84), you can now run the same set of tasks in a phase on multiple configurations, which run in parallel.

Multi configuration of agentless tasks
(圖 84) 無代理程式工作的多重設定(Figure 84) Multi configuration of agentless tasks

手動操作工作中的變數支援Variables Support in Manual Intervention task

[手動操作] 工作 (圖 85) 現在支援在執行工作時向使用者顯示的指示文字內使用變數,而在此時間點,使用者可以繼續執行發行程序或予以拒絕。The Manual Intervention task (Figure 85) now supports the use of variables within the instruction text shown to users when the task runs, at the point where the user can resume execution of the release process or reject it. 可以包含版本中已定義與可用的所有變數,以及將值用於傳送給使用者的電子郵件與通知中 (圖 86)。Any variables defined and available in the release can be included, and the values will be used in the notifications as well as in the email sent to users (Figure 86).

Manual intervention task
(圖 85) 手動操作工作(Figure 85) Manual intervention task
Manual intevention pending dialog
(圖 86) [正在等待手動操作] 對話方塊(Figure 86) Manual intervention pending dialog

根據來源分支來控制環境的發行Control releases to an environment based on the source branch

發行定義可以設定成在建立新發行時自動觸發部署,通常是在建置來源成功之後。A release definition can be configured to trigger a deployment automatically when a new release is created, typically after a build of the source succeeds. 不過,您可以僅部署來自來源之特定分支的組建,而不是在任何組建成功時。However, you may want to deploy only builds from specific branches of the source, rather than when any build succeeds.

例如,您可能會想要將所有組建都部署至開發和測試環境,但只將特定組建部署至生產環境。For example, you may want all builds to be deployed to Dev and Test environments, but only specific builds deployed to Production. 先前,您針對此目的需要維護兩個發行管線,一個用於開發和測試環境,另一個則用於生產環境。Previously you were required to maintain two release pipelines for this purpose, one for the Dev and Test environments and another for the Production environment.

Release Management 現在支援使用每個環境的成品篩選。Release Management now supports the use of artifact filters for each environment. 這表示您可以指定在符合部署觸發條件 (例如成功以及建立新發行的建置) 時,將部署至每個環境的發行。This means you can specify the releases that will be deployed to each environment when the deployment trigger conditions (such as a build succeeding and creating a new release) are met. 在環境 [部署條件] 對話方塊的 [觸發程序] 區段中 (圖 87),選取成品條件 (例如來源分支) 以及將觸發該環境之新部署組建的標籤。In the Trigger section of the environment Deployment conditions dialog (Figure 87), select the artifact conditions such as the source branch and tags for builds that will trigger a new deployment to that environment.

Deployment conditions dialog
(圖 87) [部署條件] 對話方塊(Figure 87) Deployment conditions dialog

此外,[版本摘要] 頁面 (圖 88) 現在包含快顯工具提示,以指出所有處於該狀態之「未啟動」部署的原因,以及建議開始部署的方式與時間。In addition, the Release Summary page (Figure 88) now contains a pop-up tip that indicates the reason for all “not started” deployments to be in that state, and suggests how or when the deployment will start.

Release summary tip
(圖 88) 發行摘要祕訣(Figure 88) Release summary tip

作為成品來源之 Git 存放庫的發行觸發程序Release Triggers for Git repositories as an artifact source

對於已連結到相同帳戶中任何 Team 專案版本定義的 Git 存放庫,Release Management 現在支援設定其持續部署觸發程序 (圖 89)。Release Management now supports configuring a continuous deployment trigger (Figure 89) for Git repositories linked to a release definition in any of the team projects in the same account. 這可讓您在對存放庫進行新的認可時自動觸發發行。This lets you trigger a release automatically when a new commit is made to the repository. 您也可以指定認可將觸發發行之 Git 存放庫中的分支。You can also specify a branch in the Git repository for which commits will trigger a release.

Release triggers
(圖 89) 發行觸發程序(Figure 89) Release triggers

發行觸發程序:推送至 Git 存放庫之變更的持續部署Release Triggers: Continuous deployment for changes pushed to a Git repository

Release Management 一律提供在建置完成時設定持續部署的功能。Release Management has always provided the capability to configure continuous deployment when a build completes. 不過,您現在也可以設定 Git 推送的持續部署。However, now you can also configure continuous deployment on Git Push. 這表示您可以將 GitHub 和 Team Foundation Git 存放庫連結為發行定義的成品來源,然後自動觸發應用程式 (例如 Node.JS 和 PHP) 的發行,而應用程式不是從建置所產生,因此不需要持續部署的建置動作。This means that you can link GitHub and Team Foundation Git repositories as artifact sources to a release definition, and then trigger releases automatically for applications such as Node.JS and PHP that are not generated from a build and so do not need a build action for continuous deployment.

環境觸發程序的分支篩選器Branch filters in environment triggers

您現在可以在新的版本定義編輯器中,指定特定環境的成品條件。In the new release definition editor you can now specify artifact conditions for a particular environment. 使用這些成品條件,您的控制可以細微到哪些成品要部署到特定的環境。Using these artifact conditions, you will have more granular control on which artifacts should be deployed to a specific environment. 例如,您可能希望確定生產環境部署的組建只出自於主要分支。For example, for a production environment you may want to make sure that builds generated only from the master branch are deployed. 您認為應該符合此準則的所有成品都需要設定此篩選器。This filter needs to be set for all artifacts that you think should meet this criterion.

您也可以為已連結至版本定義的每個成品新增多個篩選器 (圖 90)。You can also add multiple filters for each artifact that is linked to the release definition (Figure 90). 只有所有成品的條件都成功符合時,才會觸發這個環境的部署。Deployment will be triggered to this environment only if all the artifact conditions are successfully met.

Branch filters
(圖 90) 分支篩選(Figure 90) Branch filters

伺服器端工作增強功能Enhancements to server-side tasks

我們已進行伺服器端工作的兩項增強功能 (在伺服器階段內執行的工作)。We have made two enhancements to server-side tasks (tasks that run within a server phase).

我們已新增新的工作,可用來叫用任何泛型 HTTP REST API (圖 91) 以作為自動化管線的一部分。We have added a new task that can be used to invoke any generic HTTP REST API (Figure 91) as part of the automated pipeline. 例如,它可以用來使用 Azure 函式叫用特定處理,並等候它完成。For example, it can be used to invoke specific processing with an Azure function, and wait for it to be completed.

REST API task
(圖 91) REST API 工作(Figure 91) REST API task

我們也已將 [控制選項]\(圖 92) 區段新增至所有伺服器端工作。We have also added a Control options (Figure 92) section to all server-side tasks. 工作行為現在包含設定 [已啟用]、[錯誤時繼續]、[永遠執行] 和 [逾時] 選項。Task behavior now includes setting the Enabled, Continue on error, Always run, and Timeout options.

Task control options
(圖 92) 工作控制選項(Figure 92) Task control options

程式碼中樞中的發行狀態徽章Release status badge in Code hub

現在,如果您想要知道是否將認可部署至客戶生產環境,請先找出哪些建置會使用認可,然後檢查此建置部署所在的所有發行環境。Today, if you want to know whether a commit is deployed to your customer production environment, you first identify which build consumes the commit and then check all the release environments where this build is deployed. 現在,透過整合 [程式碼] 中樞狀態徽章中的部署狀態,來顯示在其中部署程式碼的環境清單,讓這項體驗更為簡單。Now this experience is much easier with the integration of the deployment status in the Code hub status badge to show the list of environments that your code is deployed to. 針對每個部署,會將狀態發佈到為部署一部分的最新認可。For every deployment, status is posted to the latest commit that was part of the deployment. 如果將認可部署至多個版本定義 (含多個環境),則每個認可在徽章中都會有一個項目,並顯示各環境的狀態 (圖 93)。If a commit is deployed to multiple release definitions (with multiple environments) then each has an entry in the badge, with status shown for each environment (Figure 93). 這可改善部署的程式碼認可可追蹤性。This improves the traceability of code commit to deployments.

Release status badge
(圖 93) 發行狀態徽章(Figure 93) Release status badge

根據預設,當您建立發行定義時,會公佈所有環境的部署狀態。By default, when you create a release definition, deployment status is posted for all environments. 不過,您可以挑選應在狀態徽章中顯示部署狀態的環境 (例如,只顯示生產環境) (圖 94)。However, you can selectively choose the environments whose deployment status should be displayed in the status badge (e.g. only show production environments) (Figure 94).

Deployment options dialog
(圖 94) [部署選項] 對話方塊(Figure 94) Deployment options dialog

新增成品時的組建定義功能表增強功能Enhancements to Build definition menu when adding artifacts

將組建成品新增至版本定義時,您現在可以檢視含其資料夾組織資訊的定義,讓選擇想要定義變得更輕鬆 (圖 95)。When adding build artifacts to a release definition, you can now view the definitions with their folder organization information and simplify choosing the desired definition (Figure 95). 這樣可輕鬆區分相同的組建定義名稱,但位於不同的資料夾中。This makes it easy to differentiate the same build definition name but in different folders.

Add artifact
(圖 95) 加入成品(Figure 95) Add artifact

定義清單是根據包含篩選條件的定義進行篩選。The list of definitions is filtered based on those that contain the filter term.

將發行定義還原為較早版本Revert your release definition to older version

現在,如果更新發行定義,則您無法直接還原為舊版本。Today, if a release definition is updated, you can’t directly revert to a previous version. 唯一的方式是查看發行定義歷程記錄,來尋找變更差異,然後手動編輯發行定義。The only way is to look into the release definition history to find the diff of the changes, and then manually edit the release definition. 現在,使用 [還原定義] 功能 (圖 96),您可以從版本定義 [記錄] 索引標籤中選擇並還原為任何舊版的版本定義。Now, using the Revert Definition feature (Figure 96), you can choose, and revert back to any older version of a release definition from the release definition History tab.

Revert release definition
(圖 96) 還原發行定義(Figure 96) Revert release definition

個人化版本通知Personalized notifications for releases

版本通知現已整合 VSTS 通知設定體驗。Release notifications are now integrated with the VSTS notification settings experience. 現在會自動通知所管理版本的暫止動作 (核准或手動介入) 和重要的部署失敗。Those managing releases are now automatically notified of pending actions (approvals or manual interventions) and important deployment failures. 您可以巡覽至 [設定檔] 功能表下的 [通知] 設定,然後關閉 [Release Subscriptions] (版本訂閱),來關閉這些通知。You can turn off these notifications by navigating to the Notification settings under the profile menu and switching off Release Subscriptions. 您也可以建立自訂訂閱來訂閱其他通知。You can also subscribe to additional notifications by creating custom subscriptions. 系統管理員可以從 [小組] 下的 [通知] 設定和 [帳戶] 設定來控制小組和群組的訂閱。Admins can control subscriptions for teams and groups from the Notification settings under Team and Account settings.

版本定義作者不必再手動傳送核准和部署完成的電子郵件。Release definition authors will no longer need to manually send emails for approvals and deployment completions.

這特別適合有多個版本專案關係人的大型帳戶,以及除了核准者、版本建立者和環境擁有者以外,也想要收到通知的帳戶 (圖 97)。This is especially useful for large accounts that have multiple stakeholders for releases, and for those other than the approver, release creator, and environment owner that might want to be notified (Figure 97).

Release notifications
(圖 97) 發行通知(Figure 97) Release notifications

如需詳細資訊,請參閱管理版本通知的貼文See the post for managing release notifications for more information.

測試 Testing

移除 Microsoft Test Manager 中的實驗室中心和自動化測試流程支援 Removing support for Lab Center and automated testing flows in Microsoft Test Manager

隨著組建和發行管理的發展,TFS 2018 不再支援 XAML 組建,因此我們將更新搭配使用 Microsoft Test Manager (MTM) 與 TFS 的支援。With the evolution of Build and Release Management, XAML builds are no longer supported in TFS 2018 and consequently we are updating support for using Microsoft Test Manager (MTM) with TFS. 從 TFS 2018 開始,TFS 不再支援使用 MTM 中的測試中心/實驗室中心進行自動化測試。Using Test Center/Lab Center in MTM for automated testing is no longer supported by TFS, starting with TFS 2018. 如果您還沒有準備好從 XAML 組建和實驗室中心進行移轉,則應該不要升級至 TFS 2018。If you are not ready to migrate away from XAML builds and Lab Center, you should not upgrade to TFS 2018.

請於下方查看升級至 TFS 2018 的影響:Please see the impact of upgrading to TFS 2018 below:

實驗室中心:Lab Center:
  • 不再予以支援:No longer supported:
    • 無法向 TFS 註冊 Test Controller 來建立和管理實驗室環境。Test Controllers cannot be registered with TFS for creating and managing Lab environments.
    • 任何向 TFS 註冊的現有 Test Controller 都會離線,而且現有實驗室環境將會顯示為「未就緒」。Any existing Test Controllers registered with TFS will go offline and existing Lab environments will appear as 'Not Ready'.
  • 建議的替代方案:Recommended alternative:
自動化測試:Automated Testing:
手動測試:Manual Testing:
  • 所有手動測試案例持續受到完整支援。All manual testing scenarios continue to be fully supported. 可以搭配使用 MTM 與 TFS 2018 來執行手動測試時,無法使用實驗室環境來執行手動測試。While manual tests can be run using MTM with TFS 2018, Lab Environments cannot be used to run manual tests.
  • 在所有手動測試案例中,針對 TFS Web 存取,強烈建議使用測試中樞For all manual testing scenarios, we strongly recommend using the Test hub in TFS web access.

根據接收自執行探勘測試之小組的意見反應,我們將改善從 Test & Feedback extension (測試和意見反應延伸模組) 提出 Bug、工作或測試案例時的可追蹤性連結。Based on the feedback we received from teams doing exploratory testing, we are improving traceability links while filing bugs, tasks, or test cases from the Test & Feedback extension. 現在會使用與需求的區域路徑和反覆項目相同的區域路徑和反覆項目來建立探索需求時所建立的 Bug 和工作,而非小組預設值。Bugs and tasks created while exploring requirements will now be created with the same area path and iteration as that of the requirement instead of team defaults. 探索需求時所建立的測試案例現在會連結至 [測試] <-> [測試者] 連結,而不是 [父代] <-> [子系] 連結,以將您所建立的測試案例自動新增至需求型測試套件。Test cases created while exploring requirements will now be linked with a Tests <-> Tested By link instead of the Parent <-> Child link so that the test cases you create are automatically added to requirement based test suites. 最後,未特別探勘任何需求時所建立的工作項目將會歸類於小組的預設反覆項目,而非目前反覆項目;因此,在短期衝刺規劃完成之後,不會有新的工作項目進入目前反覆項目。Finally, work items created while not specifically exploring any requirement will be filed in the team’s default iteration instead of the current iteration so that no new work items come into the current iteration after the sprint planning is complete.

測試中樞內測試計劃和套件中測試案例工作項目的篩選Filters for Test Case work items in Test Plans and Suites in Test Hub

除了依 [測試] 欄位 (例如 [結果]、[組態] 和 [測試者]) 的篩選之外,您現在還可以依測試案例工作項目欄位 (例如 [標題]、[狀態] 和 [指派至]) 的篩選 (圖 98)。In addition to the filters on Test fields like Outcome, Configuration, and Tester, you can now filter on Test Case work item fields like Title, State, and Assigned To (Figure 98).

Test case filters
(圖 98) 測試案例篩選(Figure 98) Test case filters

發行環境和測試回合的測試趨勢圖Test trend charts for Release Environments and Test Runs

我們將在 [測試結果趨勢] 小工具 (圖 99) 中新增 [版本環境] 支援,以在 VSTS 儀表板上追蹤測試環境的狀態。We are adding support for Release Environments in the Test Result Trend widget (Figure 99) so that you can track status of test environments on VSTS dashboards. 就像您針對 [組建] 中測試結果所進行的作業,您現在可以建立趨勢圖,以顯示測試成功率、總計數、成功或失敗測試,以及 [發行環境] 的測試期間。Like the way you to do for test results in Build, you can now create trend charts showing test pass rate, count of total, passed or failed tests, and test duration for Release Environments. 您也可以使用 [測試回合] 標題篩選,將圖表篩選為環境內的特定測試回合。You can also filter the charts to a specific test run within an environment with the Test Run title filter.

Test trend chart
(圖 99) 測試趨勢圖表(Figure 99) Test trend chart

測試回合和測試結果註解的 Markdown 格式支援Markdown formatting support for Test Run and Test Result comments

我們將新增使用 markdown 語法格式化 [測試回合] 和 [測試結果] 註解的支援。We are adding support for formatting Test Run and Test Result comments with markdown syntax. 您可以使用這項功能,在註解中建立 URL 的格式化文字或快速連結。You can use this feature to create formatted text or quick links to URLs in your comments. 您可以將 [結果摘要] 頁面中的 [測試結果] 註解更新為 [更新分析],以及將 [回合摘要] 頁面中的 [測試回合] 註解更新為 [測試] 中樞內的 [更新註解]。You can update Test Result comments in the Result Summary page with Update analysis and Test Run comments in the Run Summary page with Update comments in Test hub.

分析 [組建] 或 [發行] 摘要頁面或 [測試] 中樞內的測試結果時,您現在可以建立現有 Bug 與失敗測試的關聯。While analyzing the test result in the Build or Release summary page or in the Test hub, you can now associate an existing bug to a failed test. 測試因已歸檔 Bug 的已知原因而失敗時,這十分有用。This is helpful when a test is failing for a known reason that has a bug already filed.

上傳測試回合和測試結果的附件Upload attachments to test runs and test results

測試回合或測試結果的螢幕擷取畫面和記錄檔等檔案,現在可以附加為其他資訊。You can now attach files such as screenshots and log files to test runs or test results as additional information. 截至目前為止,此功能只能透過 Microsoft Test Manager (MTM) 用戶端獲得,強制切換 VSTS/TFS 和 MTM 用戶端中的測試中樞內容。Up to this point, this capability was only available through the Microsoft Test Manager (MTM) client, forcing you to switch context between the Test hub in VSTS/TFS and the MTM client.

測試批次Test batching

在組建/版本管理的 Visual Studio 測試工作中,可以選擇如何控制測試分組 (批次) 以進行有效率的執行。In the Visual Studio test task in Build/Release management, options are available to control how tests should be grouped (batched) for efficient execution. 測試分組有兩種方式:Tests can be grouped in two ways:

  1. 以每回合測試及參與代理程式的數目為基礎,只要將測試分組為數個指定大小的批次即可。Based on the number of tests and agents participating in the run, which simply groups tests into a number of batches of a specified size.
  2. 以過去的測試執行時間為基礎,考量過去的執行時間來建立測試批次,讓每個批次都有相近的執行時間 (圖 100)。Based on past running time of tests, which considers past running time to create batches of tests such that each batch has approximately equal running time (Figure 100). 快速執行的測試會成為一個批次,而執行時間較長的測試則屬於另一個批次。Quick running tests get batched together while longer running tests may belong to a separate batch. 這個選項可以結合多代理程式階段設定,將總測試時間減至最低。This option can be combined with the multi-agent phase setting to reduce the total test time to a minimum.
Test batching
(圖 100) 測試批次處理(Figure 100) Test batching

執行使用 VSTest 工作的 WebTestRun webtests using the VSTest task

使用 Visual Studio 測試工作,即 WebTest,也稱為 Web 效能測試,現在可在 CI/CD 管線中執行。Using the Visual Studio test task, webtests, also known as web performance tests, can now be run in the CI/CD pipeline. 在工作組件輸入中指定要執行的測試,即可執行 WebTest。Webtests can be run by specifying the tests to run in the task assembly input. 任何具有 WebTest 「與自動化相關」連結的測試案例工作項目,也可以透過在工作中選取測試計劃/測試套件來執行 (圖 101)。Any test case work item that has an “associated automation” linked to a webtest, can also be run by selecting the test plan/test suite in the task (Figure 101).

Test selection
(圖 101) 測試選取範圍(Figure 101) Test selection

WebTest 結果可以測試結果附件的方式提供 (圖 102)。Webtest results will be available as an attachment to the test result (Figure 102). 這可以下載供 Visual Studio 離線分析。This can be downloaded for offline analysis in Visual Studio.

Test summary
(圖 102) 測試摘要(Figure 102) Test summary

這項功能取決於 Visual Studio 測試平台的變更,需要在組建/版本代理程式上安裝 Visual Studio 2017 Update 4。This capability is dependent on changes in the Visual Studio test platform and requires that Visual Studio 2017 Update 4 be installed on the build/release agent. 使用舊版 Visual Studio 無法執行 WebTest。Webtests cannot be run using prior versions of Visual Studio.

同樣地,使用執行功能測試工作可以執行 WebTest。Similarly, webtests can be run using the Run Functional Test task. 這項功能會隨測試代理程式的變更而異,隨附於 Visual Studio 2017 Update 5。This capability is dependent on changes in the Test Agent, that will be available with the Visual Studio 2017 Update 5.

如需如何使用此功能搭配負載測試的範例,請參閱使用 Visual Studio 和 VSTS 快速入門在雲端中負載測試應用程式See the Load test your app in the cloud using Visual Studio and VSTS quickstart as an example of how you can use this together with load testing.

測試計劃和測試套件的圖表小工具Chart widget for test plans and test suites

從前可以在測試中樞裡建立測試計劃和套件的圖表,並將它們釘選到儀表板。Previously, you could create charts for test plans and suites in Test hub and pin them to dashboard. 現在新增了小工具,可從儀表板的小工具目錄建立測試計劃和套件的圖表。We have now added a widget that enables creating charts for test plans and suites from the widget catalog on the dashboard. 您可以建立測試製作狀態或測試執行狀態的圖表。You can create charts for test authoring status or test execution status. 此外,當您要在圖表上顯示更多資料時,從小工具新增圖表可讓您建立較大的圖表 (圖 103)。Moreover, adding charts from the widget allows you to create larger charts when you have more data to be shown on a chart (Figure 103).

Chart widget
(圖 103) 圖表小工具(Figure 103) Chart widget

桌面應用程式的螢幕擷取畫面和註解支援搭配 Chrome 瀏覽器進行手動測試Screenshot and annotation support for desktop apps with Chrome browser for manual tests

我們要新增手動測試的前幾項建議之一:從測試中樞的 Web 測試執行器中擷取桌面應用程式的螢幕擷取畫面。We are adding support for one of the top suggestions from manual testing - capturing screenshots of desktop applications from the Web Test Runner in Test hub. 截至目前為止,您必須使用 Microsoft Test Manager 中的測試執行器擷取桌面應用程式的螢幕擷取畫面。Until now, you had to use Test Runner in Microsoft Test Manager to capture screenshots of desktop apps. 若要使用這項功能,您需要安裝測試與意見反應延伸模組You need to install the Test & Feedback extension to use this functionality. 我們即將推出對 Chrome 瀏覽器的支援,Firefox 支援亦將於不久之後推出。We are rolling out support for the Chrome browser, and Firefox will follow shortly thereafter.

停止使用適用於 SharePoint 的 TFS 延伸模組 Discontinuing TFS Extension for SharePoint

TFS 2018 和更新版本將不再支援適用於 SharePoint 的 TFS 延伸模組。TFS 2018 and later versions will no longer support the TFS Extension for SharePoint. 此外,已經從 Team Foundation 管理主控台中移除用來設定 TFS 伺服器與 SharePoint 伺服器間之整合的畫面。Additionally, the screens used to configure integration between a TFS Server and a SharePoint server have been removed from the Team Foundation Administration Console.

注意

如果您要從設定與 SharePoint 整合的舊版升級到 TFS 2018,升級後會需要停用 SharePoint 整合,否則無法載入 TFS SharePoint 網站。If you are upgrading to TFS 2018 from a previous version configured to integrate with SharePoint, you will need to disable the SharePoint integration after upgrade, or your TFS SharePoint sites will fail to load.

我們已建立解決方案,讓您停用 SharePoint 伺服器上的整合。We have created a solution that allows you to disable integration on the SharePoint server. 如需詳細資訊,請參閱未來的 TFS/SharePoint 整合文章。For more information, please see the post on the future of our TFS/SharePoint Integration.

停止使用小組室 Discontinuing Team Rooms

現代開發小組大幅取決於共同作業。Modern development teams heavily depend on collaboration. 人員想要 (並需要) 一個位置來監視活動 (通知),並進行討論 (聊天)。People want (and need) a place to monitor activity (notifications) and talk about it (chat). 在幾年前,我們辨識出這個趨勢,並設定來建置小組室以支援這些案例。A few years back, we recognized this trend and set out to build the Team Room to support these scenarios. 自該時間之後,我們已經看到多個方案可共同處理市場中的緊急情況。Since that time, we have seen more solutions to collaborate emerge in the market. 最值得注意的是 Slack 的崛起。Most notably, the rise of Slack. 最近則是 Microsoft Teams 的宣告。And more recently, the announcement of Microsoft Teams.

運用將 TFS 與 Visual Studio Team Services 整合良好的許多可用不錯方案時,我們已在 1 月宣告計畫要移除 TFS 2018 和 Visual Studio Team Services 的小組室功能。With so many good solutions available that integrate well with TFS and Visual Studio Team Services, we announced in January the plans to remove our Team Room feature from both TFS 2018 and Visual Studio Team Services.


頁面頂端
Top of Page