Team Foundation Server 2017 Update 2 版本資訊Team Foundation Server 2017 Update 2 Release Notes

上次更新日期 2018/1/31

在本文中,您將找到最新版 Team Foundation Server 2017 Update 2 的相關資訊。In this article, you will find information regarding the newest release for Team Foundation Server 2017 Update 2. 按一下這個按鈕進行下載。Click the button to download.

Download the latest version of Team Foundation Server

如需其他格式或語言,請參閱下載網站For other formats or languages, please see the download site.

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


意見反應Feedback

請提供您的意見!We’d love to hear from you! 您可以透過開發人員社群入口網站回報及追蹤問題。You can report a problem and track it through the Developer Community portal. 請透過 Visual Studio Team Services 產品更新網站將您的建議傳送給我們。Send us your suggestions through the Visual Studio Team Services Product Updates site.


發行日期︰2017 年 7 月 24 日Release Date: July 24, 2017

TFS 2017 Update 2 的更新摘要Summary of Updates in TFS 2017 Update 2

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

您可以依功能範圍檢視改進,來查看所有新功能的詳細資料:You can see the details of all the new features by viewing the improvements by feature area:


本版新功能What's New in this Release

工作項目追蹤改進 Work Item Tracking Improvements

工作項目類型圖示 Work item type icons

我們做出了全球承諾,確保客戶能夠完全無障礙地存取產品。We have made a global commitment to make our products fully accessible to our customers. 在做出該承諾的過程中,我們努力找出並解決許多協助工具問題,從鍵盤模式到視覺化設計和配置。As part of that commitment, we have been working to find and address many accessibility issues – anywhere from keyboard patterns to visual design and layout.

工作項目追蹤在許多體驗中向來是單憑色彩來傳達工作項目類型。Work item tracking has relied solely on color in many experiences to convey work item type. 不過,這對色盲或弱視使用者會造成問題,這些人可能由於色彩相似而無法區分項目。However, this is problematic for our color blind or low vision users who may not be able to distinguish between items due to similarities in color. 為了讓所有客戶能夠更加區分工作項目類型,我們引進了以視覺表達工作項目類型的圖示。To increase the scanability of work item type for all our customers, we have introduced icons to the visual language of work item type. 您可以從我們精選的圖示庫中選擇,以自訂您的工作項目類型You can customize your work item types by choosing from a selection of our icon library.

用於傳達待處理項目和查詢方格上類型的色軸,已取代為彩色圖示 (圖 1)Color bars conveying type on the backlog and queries grids have been replaced with colored icons (Figure 1).

Wit icons in query

(圖 1) 查詢中的彩色圖示
Wit icons in query
(Figure 1) Colored icons in query

面板上的卡片現在包含類型圖示 (圖 2)Cards on the board now include a type icon (Figure 2).

Board with icon type

(圖 2) 顯示圖示類型的面板
Board with icon type
(Figure 2) Board with icon type

傳遞計劃 Delivery Plans

傳遞計劃是組織工具,藉由追蹤以反覆項目為基礎之行事曆上的工作狀態,來協助您改進小組間的可見度和校準。Delivery Plans is an organizational tool that helps you drive cross-team visibility and alignment by tracking work status on an iteration-based calendar. 您可以調整計劃,從帳戶中的不同專案加入任何小組或待處理項目層級。You can tailor your plan to include any team or backlog level from across projects in the account. 此外,計劃上的__欄位準則__讓您進一步自訂檢視,而__標記__可反白顯示重要日期。Furthermore, Field Criteria on Plans enables you to further customize your view, while Markers highlight important dates.

請參閱 Marketplace 的 Delivery Plans (傳遞計劃) 頁面,以深入了解及安裝延伸模組。Check out the marketplace page for Delivery Plans to learn more and install the extension.

如果使用者具有與網際網路中斷連線的 TFS 執行個體,則直接透過 Web 存取的 [管理延伸模組] 選項即可使用傳遞計劃,而不需要巡覽至 VSTS Marketplace。For users with a TFS instance that is disconnected from the Internet, Delivery Plans will be available directly from the Manage extensions option in web access, without navigating to the VSTS Marketplace. 從 [管理延伸模組] 中,按一下 [瀏覽本機的延伸模組],並選取 [傳遞計劃],然後按一下 [安裝]。From Manage extensions, click on Browse local extensions, then select Delivery Plans and click Install. 如需詳細資訊,請參閱預先安裝的延伸模組的文件。See the documentation on pre installed extensions for more information.

從工作項目自動連結至組建Automatic linking from work items to builds

透過組建定義中的這項新設定,您可以追蹤併入工作的組建,而不需要手動搜尋大型組建集。With this new setting in the build definition, you can track the builds that have incorporated your work without having to search through a large set of builds manually. 與工作項目建立關聯的所有成功組建,都會自動出現在工作項目表單的開發區段。Each successful build associated with the work item automatically appears in the development section of the work item form.

若要啟用這項功能,請切換您組建定義中 [選項] 下的設定 (圖 3)To enable this feature, toggle the setting under Options in your build definition (Figure 3).

WIT build linking

(圖 3) WIT 組建連結
WIT build linking
(Figure 3) WIT build linking

取代舊的工作項目表單Deprecation of old work item form

新工作項目表單的整體意見反應向來很正面,我們的裝載帳戶現在有 100% 採用。Overall feedback for the new work item form has been positive and we now have 100% adoption on our hosted accounts. 我們希望內部部署客戶享有 VSTS 使用者樂見的相同價值,因此決定取代舊的工作項目表單和舊的擴充性模型。We want on-premises customers to tap into the same value that has delighted our VSTS users and so we have made the decision to deprecate the old work item form and old extensibility model. 若要深入了解我們的計劃,請參閱 Microsoft 應用程式生命週期管理頁面。Read more about our plans on the Microsoft Application Lifecycle Management page.

工作項目搜尋 Work Item Search

工作項目搜尋可快速彈性地搜尋集合中所有專案的所有工作項目 (圖 4)。Work Item Search provides fast and flexible search across all your work items over all projects in a collection (Figure 4). 您可以使用工作項目搜尋的全文檢索搜尋引擎,輕鬆地跨所有工作項目欄位搜尋字詞,並有效率地找到相關的工作項目。You can use the Work Item Search full text search engine to easily search for terms across all work item fields and efficiently locate relevant work items. 在任何工作項目欄位上使用內嵌搜尋篩選,將範圍快速縮小到工作項目清單。Use in-line search filters, on any work item field, to quickly narrow down to a list of work items.

在 TFS 中設定搜尋服務之後,您可以開始搜尋,而不需要安裝任何其他項目。Once the Search service is configured in TFS, you can get searching without the need to install anything else. 使用工作項目搜尋,您可以:By using Work Item Search you can:

  • 搜尋您所有的專案:__在您自己及夥伴小組的待處理項目中搜尋。__Search over all your projects: Search in your own and your partner teams' backlog. 在所有工作項目上使用跨專案搜尋,以便搜尋您組織的所有工作項目。Use cross-project searches over all the work items to search across your organization's entire work items. 使用專案和區域路徑篩選來縮小您的搜尋範圍。Narrow your search by using project and area path filters.
  • 搜尋所有工作項目欄位:__藉由搜尋所有工作項目欄位 (包括之前的欄位),輕鬆快速地找到相關的工作項目。__Search across all work item fields: Quickly and easily find relevant work items by searching across all work item fields (including ere fields). 跨所有欄位使用全文檢索搜尋,以有效率地找到相關的工作項目。Use a full text search across all fields to efficiently locate relevant work items. 程式碼片段檢視指出找到相符項目的位置。The snippet view indicates where matches were found.
  • 在特定欄位中搜尋:__在任何工作項目欄位上使用快速的內嵌搜尋篩選,幾秒內就將範圍縮小到工作項目清單。__Search in specific fields: Use the quick in-line search filters, on any work item field, to narrow down to a list of work items in seconds. 下拉式建議清單可協助您更快完成搜尋。The dropdown list of suggestions helps complete your search faster. 例如,AssignedTo:Chris WorkItemType:Bug State:Active 等搜尋會尋找指派給名為 Chris 之使用者的所有作用中 Bug。For example, a search such as AssignedTo:Chris WorkItemType:Bug State:Active finds all active bugs assigned to a user named Chris.
  • 利用與工作項目追蹤的整合: 工作項目搜尋介面與工作中樞內熟悉的控制項整合,讓您檢視、編輯、註解、共用及執行其他許多工作。Take advantage of integration with work item tracking: The Work Item Search interface integrates with familiar controls in the Work hub, letting you view, edit, comment, share, and much more.

Workitem search

(圖 4) 工作項目搜尋
Workitem search
(Figure 4) Workitem search

版本控制改善 Version Control Improvements

新的分支原則設定體驗 New branch policies configuration experience

我們重新設計了分支原則設定體驗,並新增一些很棒的功能 (圖 5)。We’ve redesigned the branch policies configuration experience and added some great new capabilities (Figure 5). 其中一項最強大的功能是能夠設定分支資料夾的原則。One of the most powerful features is the ability to configure policies for branch folders. 您可以從 [分支] 檢視選取分支資料夾,然後從操作功能表選擇 [分支原則] 來執行這項操作。You can do this from the Branches view by selecting a branch folder and choosing Branch policies from the context menu.

Configure branch policies

(圖 5) 設定分支原則
Configure branch policies
(Figure 5) Configure branch policies

這會開啟新的原則設定 UX,您可以在其中設定要套用至分支資料夾中所有分支的原則 (圖 6)This will open the new policies configuration UX, where you can configure policies that apply to all of the branches in the branch folder (Figure 6).

Policies page

(圖 6) 原則頁面
Policies page
(Figure 6) Policies page

如果您使用建置原則,您現在可以為單一分支設定多個組建。If you’re using the build policy, you can now configure multiple builds for a single branch. 還提供新的選項,讓您指定自動或手動觸發程序 (圖 7)。There are also new options to specify an automatic or manual trigger (Figure 7). 手動觸發程序適用於可能需要長時間執行的自動化測試回合等項目,而且您在完成提取要求之前,實際上只需要執行一次。Manual triggers are useful for things like automated test runs that might take a long time to run, and you only really need to run once before completing the pull request. 建置原則也有顯示名稱,這在設定多個組建時會很有用。The build policy also has a display name that is useful if you’re configuring multiple builds.

Manual build

(圖 7) 手動建置
Manual build
(Figure 7) Manual build

設定手動觸發的原則之後,您可以在提取要求的 [原則] 區段中選取 [佇列組建] 選項來執行此原則 (圖 8)Once you’ve configured a manually triggered policy, you can run it by selecting the Queue build option in the Policies section for the pull request (Figure 8).

Manual build queue

(圖 8) 手動建置佇列
Manual build queue
(Figure 8) Manual build queue

針對必要檢閱者原則 (圖 9),我們新增了功能,讓系統管理員指定原則套用時將附加至提取要求時間表的備註 (圖 10)For required reviewer policies (Figure 9), we added the ability for administrators to specify a note that will be appended to the pull request timeline when the policy applies (Figure 10).

Required reviewer dialog

(圖 9) 必要檢閱者對話方塊
Required reviewer dialog
(Figure 9) Required reviewer dialog

Required reviewer note

(圖 10) 必要檢閱者備註
Required reviewer note
(Figure 10) Required reviewer note

非作用中註解的新原則New policy for no active comments

透過新的 [註解] 原則,確保找到您提取要求中的所有註解。Ensure that all comments in your pull requests are being addressed with the new Comments policy. 啟用此原則時,作用中的註解會讓 PR 無法完成,並強制解決所有註解。With this policy enabled, active comments will block completion of the PR, forcing all comments to be resolved. 留下註解給 PR 作者但樂觀地核准提取要求的檢閱者,可確保急切合併的作者不會錯過任何註解。Reviewers that leave comments for the PR author but optimistically approve the pull request can be sure that an author that’s eager to merge won’t miss any comments.

檔案中樞改進Files hub improvements

我們對 [檔案] 中樞做了幾項更新,以改進檢視和編輯體驗。We’ve made several updates to the Files hub to improve the viewing and editing experiences.

針對檢視,我們新增了樞紐分析表,讓您檢視目前資料夾中的讀我檔案 (圖 11)、預覽 Markdown 檔案、比較檔案與舊版 (圖 12),以及檢視改動者。For viewing, we’ve added pivots that let you view the README in the current folder (Figure 11), preview Markdown files, compare a file to a previous version (Figure 12), and view blame.

Files viewing

(圖 11) 檔案檢視
Files viewing
(Figure 11) Files viewing

Files compare

(圖 12) 檔案比較
Files compare
(Figure 12) Files compare

針對編輯,您現在可以預覽變更、輕鬆地新增註解、認可到新分支,以及連結工作項目 (圖 13)For editing, you can now preview your changes, easily add a comment, commit to a new branch, and link work items (Figure 13).

Files editing

(圖 13) 檔案編輯
Files editing
(Figure 13) Files editing

視覺化您的 Git 存放庫 Visualize your git repository

您現在會在顯示存放庫或檔案的認可歷程記錄時看到一個圖表。You can now see a graph while showing commit history for repositories or files. 這可讓您輕鬆地使用 Git 圖表,為您的 Git 存放庫建立所有分支和認可的心智模型 (圖 14)。This allows you to easily create a mental model of all your branches and commits for your git repositories using git graph (Figure 14). 此圖表會依拓撲順序顯示您所有的認可。The graph shows all your commits in topological order.

Git graph

(圖 14) Git 圖表
Git graph
(Figure 14) Git graph

Git 圖表的主要項目包括 (圖 15)The key elements of the git graph include (Figure 15):

  1. Git 圖表會靠右對齊,因此與預設分支或選取的分支建立關聯的認可會出現在右側,而圖表的其餘部分則出現在左側。the git graph is right-aligned, so commits associated with the default branch or the selected branch appear on the right while the rest of the graph grows on the left.
  2. 合併認可會以連接到第一個父代和第二個父代的灰點表示。merge commits are represented by grey dots connected to their first parent and second parent.
  3. 一般認可會以藍點表示。normal commits are represented by blue dots.
  4. 如果在接下來 50 個認可的檢視區中看不到認可的父認可,則會執行認可連接。if the parent commit of a commit is not visible in the view port on the next 50 commits, then we excise the commit connection. 按一下箭號之後,認可會連接到其父認可。Once you click the arrow, the commit is connected to its parent commit.

Git graph elements

(圖 15) Git 圖表元素
Git graph elements
(Figure 15) Git graph elements

檢視認可上的 Git 標記 View git tags on commits

如果您的小組使用了 Git 標記來標示存放庫歷程記錄中的特定時間點,則您的認可現在會顯示您所建立的標記。If your team has been using Git tags to mark a specific point in the history of your repository, then your commits will now show the tags that you have created. 您將能夠在__認可清單__檢視和__詳細資料__頁面中,檢視特定認可的標記 (圖 16)You will be able view tags (Figure 16) for a specific commit in the commit list view and the details page.

Show tags

(圖 16) 顯示標籤
Show tags
(Figure 16) Show tags

將標記新增至認可Add tags to commits

您現在可以直接移至認可並新增標記,而不是從命令列建立標記,然後將標記推送到存放庫 (圖 17)。Instead of creating tags from the command line and pushing the tags to the repository, you can now simply go to a commit and add a tag (Figure 17). [標記建立] 對話方塊也可讓您標記存放庫中的任何其他參考。The tag creation dialog will also let you tag any other ref on the repo.

Create tag details

(圖 17) 建立標籤詳細資料
Create tag details
(Figure 17) Create tag details

認可清單檢視也支援操作功能表 (圖 18)The commit list view also supports a context menu (Figure 18). 不需要移至__認可詳細資料__頁面,即可建立標記並建立新分支 (圖 19)No need to go to the commit details page to create tags and create new branches (Figure 19).

Create tag history

(圖 18) 建立標籤歷程記錄
Create tag history
(Figure 18) Create tag history

Tag branch

(圖 19) 標籤分支
Tag branch
(Figure 19) Tag branch

更新的變更集和擱置集頁面Updated changeset and shelveset pages

我們已將 TFVC 中的變更集和擱置集頁面現代化。We have modernized the changeset and shelveset pages in TFVC. 使用輔助技術的人員可更輕鬆地存取這兩個頁面。Both pages are made more accessible for those of you who use assistive technologies. 這些新頁面也有新頁首,其中包含變更集標題和變更集的相關資訊,例如作者詳細資料 (圖 20)The new pages also have a new header that contains the changeset title and associated information about the changeset, such as author details (Figure 20).

Changeset page

(圖 20) 變更集頁面
Changeset page
(Figure 20) Changeset page

變更集和擱置集頁面也裝載新的 Markdown 討論控制項 (圖 21),以允許在 Markdown 中鍵入註解、@mention 使用者、使用 # 關聯工作項目,以及輕鬆地附加檔案和影像。Both changeset and shelveset pages also host the a new markdown discussion control (Figure 21) that will allow to type comments in markdown, @mention users, associate work items using #, and easily attach files and images.

Changeset discussion

(圖 21) 變更集討論
Changeset discussion
(Figure 21) Changeset discussion

改進的認可篩選Improved commit filtering

您現在可以透過進階篩選選項篩選認可歷程記錄結果 (圖 22)。You can now filter the commit history results (Figure 22) by advanced filtering options. 您可以依下列項目篩選認可:You can filter commits by:

  • 完整歷程記錄。full history.
  • 已簡化合併的完整歷程記錄。full history with simplified merges.
  • 第一個父代。first parent.
  • 簡單歷程記錄 (這是預設篩選設定)。simple history (this is the default filter setting).

Improved commit filtering

(圖 22) 認可篩選改進
Improved commit filtering
(Figure 22) Improved commit filtering

將存放庫從 TFVC 匯入 GitImport repositories from TFVC to Git

您可以將 TFVC 存放庫中的程式碼遷移到相同帳戶中的 Git 存放庫。You can migrate code from your TFVC repositories to Git repositories in the same account. 若要開始移轉,請從存放庫選取器下拉式清單選取 [匯入存放庫](圖 23)To start migration, select import repository from the repository selector drop-down (Figure 23).

Repository selector drop-down

(圖 23) 存放庫選取器下拉式清單
Repository selector drop-down
(Figure 23) Repository selector drop-down

您可以將個別資料夾或分支匯入 Git 存放庫,也可以匯入整個 TFVC 存放庫 (但不包括分支) (圖 24)Individual folders or branches can be imported to the Git repository, or the entire TFVC repository can be imported (minus the branches) (Figure 24). 您也可以匯入最多 180 天的歷程記錄。You can also import up to 180 days of history.

Import repo complete

(圖 24) 匯入完整的存放庫
Import repo complete
(Figure 24) Import repo complete

Git LFS 檔案鎖定Git LFS file locking

我們新增了 Git LFS 檔案鎖定功能。We have added the Git LFS file locking feature. 這可讓小組處理大量相同的檔案,以免在兩個人或更多人嘗試同時編輯相同的檔案時遺失工作。This allows teams working with large, undiffable files to avoid losing work when two or more people attempt to edit the same file at once. 在任何人可以開始編輯檔案之前,他們會取得鎖定,而這會通知伺服器。Before anyone can begin editing the file, they take a lock, which notifies the server. 當其他人嘗試取得鎖定時,伺服器會拒絕要求,讓第二個人知道其他人已在使用該檔案。When anyone else attempts to take a lock, the server rejects the request, letting the second person know that someone else is already working on that file. 請升級為 Git LFS 2.1 或更新版本,以便使用這項功能。Please upgrade to Git LFS 2.1 or higher to use this feature.

Git 認可註解使用新的討論控制項Git commit comments use the new discussion control

在 Git 認可上留下簡單的註解,已更新為使用新的討論控制項。Lightweight comments left on Git commits has been updated to use the new discussion control. 這會將對 Markdown 的支援整合到這些註解,使網路上的所有程式碼註解功能更完美,讓 Git 和 TFVC 可以使用最新體驗。This brings support for Markdown in those comments, and rounds out all of the code-commenting features in the web for both Git and TFVC to use the latest experience.

新的樹狀檢視控制項New tree view control

提取要求檔案檢視、Git 認可詳細資料、Git 推送詳細資料、TFVC 擱置集詳細資料、TFVC 變更集詳細資料、TFVC 變更集中樞和 Git 歷程記錄中樞已更新為新的樹狀檢視控制項 (圖 25)。The Pull Request Files view, Git commit details, Git push details, TFVC Shelveset details, TFVC Changeset details, TFVC Changesets hub and Git history hub have been updated with a new tree view control (Figure 25). 樹狀檢視有一些可用性的改進。The tree view has a few usability improvements. 首先,我們變更了檢視,顯示自動摺疊空資料夾節點的壓縮樹狀檢視,並增加檢視中的檔案數目。First, we’ve changed the view to show a condensed tree view that automatically collapses empty folder nodes, maximizing the number of files that are in view.

此樹狀也會以更精簡的方式來顯示註解。The tree also shows comments in a more compact way. 含有註解的檔案會顯示代表每個註解討論串的子項目,並提供表示已建立討論串之使用者的顯示圖片。Files with comments show a child item for each comment thread, with the avatar indicating the user that created the thread. 新的及含有回覆的註解討論串會以藍點表示,而回覆計數會合計成一個計數。New comment threads and those with replies are indicated by the blue dot, and the count of replies is summarized with a count.

New tree view

(圖 25) 新款樹狀檢視
New tree view
(Figure 25) New tree view

提取要求改進 Pull Request Improvements

改進 PR 作者和檢閱者的 CTAImproved CTAs for PR author and reviewers

對於使用分支原則的小組,有時候很難確切了解您檢視提取要求時所需的動作。For teams using branch policies, it can sometimes be hard to know exactly what action is required when you view a pull request. 如果主要行動是 [完成] 按鈕,是否表示準備完成?If the main call to action is the Complete button, does that mean it’s ready to complete? PR 檢視使用檢視已設定分支原則之頁面和狀態的人員相關資訊,現在會呈現最適合該使用者的行動。Using information about the person viewing the page and the state of configured branch policies, the PR view will now present the call to action that makes the most sense for that user.

當原則已設定但尚未通過時,[完成] 按鈕 (圖 26) 現在會建議使用 [自動完成] 功能。When policies are configured, but aren’t yet passing, the Complete button (Figure 26) will now encourage the use of the Auto-complete feature. 如果原則正被封鎖,您將無法順利完成 PR,因此我們提供選項,在這些原則最後通過時完成 PR。It’s not likely that you’ll be able to complete the PR successfully if policies are blocking, so we offer an option that will complete the PR when those policies eventually pass.

 Auto-complete feature

(圖 26) 自動完成功能
 Auto-complete feature
(Figure 26) Auto-complete feature

對於檢閱者,您比較需要核准 PR 而不是完成 PR,因此如果您尚未核准,檢閱者將會看到 [核准] 按鈕 (圖 27) 反白顯示為主要 CTA。For reviewers, it’s more likely that you’ll want to approve a PR than complete it, so reviewers will see the Approve button (Figure 27) highlighted as the main CTA if you haven’t approved yet.

CTA approve

(圖 27) CTA 核准
CTA approve
(Figure 27) CTA approve

核准後,如果檢閱者同時是完成 PR 的人員,檢閱者將會看到 [完成] (或 [自動完成]) 按鈕反白顯示為 CTA。Once approved, reviewers will see the Complete (or Auto-complete) button highlighted as the CTA for those cases where a reviewer is also the person completing the PR.

可執行動作的註解Actionable comments

在含有多個註解的 PR 中,可能很難追蹤所有交談。In a PR with more than a few comments, it can be hard to keep track of all of the conversations. 為了協助您更有效地管理註解,我們透過一些增強功能來簡化解決所找到項目的程序:To help you better manage comments, we’ve simplified the process of resolving items that have been addressed with a number of enhancements:

  • 在每個 PR 的標頭中,您現在會看到已解決的註解計數 (圖 28)In the header for every PR, you’ll now see a count of the comments that have been resolved (Figure 28).

PR header

(圖 28) PR 標頭
PR header
(Figure 28) PR header

  • 找到註解時,您可以按一下來解決註解 (圖 29)When a comment has been addressed, you can resolve it with a single click (Figure 29).

Resolve button

(圖 29) 解決按鈕
Resolve button
(Figure 29) Resolve button

  • 如果在解決時有新的註解加入,您可以按一下來回覆並解決 (圖 30)If you have comments to add while you’re resolving, you can reply and resolve in a single gesture (Figure 30).

Reply and resolve

(圖 30) 回覆並解決
Reply and resolve
(Figure 30) Reply and resolve

  • 解決註解之後,您會看到計數增加,直到解決所有註解為止 (圖 31)As comments are resolved, you’ll see the count go up until everything has been addressed (Figure 31).

Comment count address rate

(圖 31) 解決註解計數速度
Comment count address rate
(Figure 31) Comment count address rate

  • [概觀] 中的篩選已經過改進,可依各種註解狀態篩選,並顯示每個篩選選項的註解計數 (圖 32)The filter in the Overview has been improved to enable filtering by various comment states and to show the count of comments for each filter option (Figure 32).

Filter improvements

(圖 32) 篩選改進
Filter improvements
(Figure 32) Filter improvements

更新檢視顯示重訂基底和強制推送Updates view shows rebase and force push

在 [提取要求詳細資料] 檢視中,[更新] 索引標籤已經過改進,會顯示何時發生強制推送,以及基底認可是否已變更 (圖 33)。In the Pull Request details view, the Updates tab has been improved to show when a force push has occurred and if the base commit has changed (Figure 33). 如果您在完成 PR 之前將主題分支中的變更重訂基底,這兩項功能會非常有用。These two features are really useful if you rebase changes in your topic branches before completing your PRs. 檢閱者現在會有足以掌控確切狀況的資訊。Reviewers will now have enough info to know exactly what’s happened.

Updates views

(圖 33) 更新檢視
Updates views
(Figure 33) Updates views

依人員篩選提取要求Pull request filtering by people

現在更容易尋找提取要求!It’s now easier to find pull requests! 我們新增了篩選選項,可讓您尋找特定作者所建立或指派給特定檢閱者的 PR (圖 34)。We’ve added new filtering options to allow you to find PRs created by a specific author or assigned to a specific reviewer (Figure 34). 只要從作者或檢閱者篩選選取一位使用者,即會更新清單,只顯示符合篩選的 PR。Simply select a user from the author or reviewer filter, and the list will be updated to show only the PRs that match the filter.

Filtering by people

(圖 34) 依人員篩選
Filtering by people
(Figure 34) Filtering by people

略過提取要求原則時需要原因Reason required when bypassing pull request policies

當您略過提取要求原則時,您必須指定原因。When you are bypassing a pull request policies, you are required to specify a reason. 在 [完成提取要求] 對話方塊中,如果選擇略過,則會看到新的 [原因] 欄位 (圖 35)In the Complete pull request dialog, you will see a new Reason field, if they choose to bypass (Figure 35).

Bypass dialog

(圖 35) 略過對話方塊
Bypass dialog
(Figure 35) Bypass dialog

輸入原因並完成提取要求之後,訊息將會顯示在 [概觀] 中 (圖 36)After entering the reason and completing the pull request, the message will be displayed in the Overview (Figure 36).

Bypass message

(圖 36) 略過訊息
Bypass message
(Figure 36) Bypass message

與小組共用提取要求Share pull requests with teams

[共用提取要求] 是通知檢閱者的便利方式 (圖 37)。The Share Pull Request action is a handy way to notify reviewers (Figure 37). 在此版本中,我們新增了對小組和群組的支援,讓您可以透過一個步驟來通知與提取要求相關的所有人。In this release, we’ve added support for teams and groups, so you can notify everyone involved the pull request in a single step.

Share PR with teams

(圖 37) 與小組共用 PR
Share PR with teams
(Figure 37) Share PR with teams

小組的提取要求改進Pull request improvements for teams

如果您是多個小組的成員,您現在會看到指派給這些小組的所有 PR 列於 [我的提取要求] 檢視中 (圖 38)。If you’re a member of multiple teams, you will now see all of the PRs assigned to those teams listed in the My Pull Requests view (Figure 38). 這讓 [我的提取要求] 檢視成為您查看所有待處理 PR 唯一需要瀏覽的位置。This makes the My Pull Requests view the one stop you need to visit to see all the PRs on your plate.

PR improvements for teams

(圖 38) 小組的 PR 改進
PR improvements for teams
(Figure 38) PR improvements for teams

在未來版本中,我們會將小組新增至 [程式碼] 下的 [提取要求] 中樞,讓您更輕鬆地查看單一專案的所有 PR。In a future release, we’ll add teams to the Pull Requests hub under Code to make it easier to see all of your PRs for a single project.

提取要求註解的預設通知Default notifications for pull request comments

透過新的註解通知,隨時掌握 PR 中發生的最新交談 (圖 39)。Stay up to date with the conversations happening in your PRs with the new comment notifications (Figure 39). 針對您已建立的 PR,每當使用者新增註解討論串或回覆現有討論串時,您將會自動收到通知。For PRs that you've created, you will automatically be notified any time a user adds a new comment thread or replies to an existing thread. 當您對其他使用者的 PR 加上註解時,未來如有您建立或回覆之註解討論串的任何回覆,您將會收到通知。When you comment on another user's PR, you'll be notified about any future replies to comment threads that you create or reply to.

Default PR notifications

(圖 39) 預設 PR 通知
Default PR notifications
(Figure 39) Default PR notifications

這些通知會當作現成訂閱的一部分來提供,並可在 [通知] 設定頁面上設定。These notifications are available as part of the out of the box subscriptions, and are configurable on the Notifications settings page.

套件管理改進 Package Management Improvements

更新的套件管理體驗 Updated Package Management experience

我們更新了套件管理使用者體驗,更快速地解決使用者經常回報的問題,並有機會推出套件生命週期功能 (圖 40)。We've updated the Package Management user experience to make it faster, address common user-reported issues, and make room for upcoming package lifecycle features (Figure 40). 若要深入了解此更新,請參閱更新體驗頁面。Learn more about the update on the Updated experience page.

Package Management

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

套件管理新增 npm 讀我檔案和下載按鈕Package Management adds npm READMEs and download button

您現在可以看到任何 npm 套件 (其中包含 README.md) 的讀我檔案 (圖 41)。You can now see the README of any npm package that includes a README.md in the package (Figure 41). 讀我檔案可協助您的小組記錄並分享套件的相關資訊。READMEs can help your team document and share knowledge about your packages.

您也可以使用命令列中的 [下載] 按鈕來下載任何 npm 套件。You can also download any npm package using the Download button in the command bar.

Package Management npm README

(圖 41) 套件管理 npm 讀我檔案
Package Management npm README
(Figure 41) Package Management npm README

NuGet Restore 及 NuGet Command 建置工作NuGet Restore and NuGet Command build tasks

我們對 NuGet 安裝程式 (現在稱為 NuGet Restore) 工作進行了重大更新,且新增一項 NuGet 工作:NuGet CommandWe’ve made major updates to the NuGet Installer (now called NuGet Restore) task, and added a new NuGet task: NuGet Command. 最值得注意的是,[NuGet 命令] 和 [NuGet 還原] 工作現在預設會使用 nuget.exe 4.0.0。Most notably, the NuGet Command and NuGet Restore tasks now use nuget.exe 4.0.0 by default.

[NuGet 還原] 現在已針對在某個 Visual Studio 建置步驟之前還原套件的最常見情節最佳化。NuGet Restore is now optimized for the most common scenario of restoring packages before a Visual Studio Build step. 它對共用單一 NuGet 摘要的小型專案也有更佳支援:您現在可以選取 Team Services 摘要,並將它新增至自動產生的 NuGet.Config。It also has better support for small projects that share a single NuGet feed: you can now pick a Team Services feed and have it added to an auto-generated NuGet.Config.

[NuGet 命令] 工作讓更複雜的 NuGet 作業可彈性地指定任何命令和引數集 (圖 42)For more complex NuGet operations, the NuGet Command task provides the flexibility to specify any command and set of arguments (Figure 42).

NuGet command

(圖 42) NuGet 命令
NuGet command
(Figure 42) NuGet command

建置及發行改進 Build and Release Improvements

新的組建定義編輯器 New build definition editor

我們重新設計了組建定義編輯器,提供更直覺的體驗、修正一些痛點並新增功能。We’ve redesigned our build definition editor to provide a more intuitive experience, fix some pain points, and add new capabilities. 希望您覺得比較容易使用範本、新增工作及變更設定。We hope that you’ll find it easier to use templates, add tasks, and change settings. 而且您現在可以使用流程參數,更輕鬆地指定最重要的資料,而不需要深入探索您的工作。And now you can use process parameters to make it easier to specify the most important bits of data without having to go deep into your tasks.

搜尋範本Search for a templates

搜尋您想要的範本,然後加以套用;或開始使用空白流程 (圖 43)Search for the template you want and then apply it, or start with an empty process (Figure 43).

Build template search

(圖 43) 建置範本搜尋
Build template search
(Figure 43) Build template search

快速找出工作並新增至您想要的位置Quickly find and add a task right where you want it

搜尋您要使用的工作,找到後,您可以將它新增至左側目前選取的工作之後,或將它拖放到您想要的位置 (圖 44)Search for the task you want to use, and then after you’ve found it, you can add it after the currently selected task on the left side, or drag and drop it where you want it to go (Figure 44).

Build task search

(圖 44) 建置工作搜尋
Build task search
(Figure 44) Build task search

您也可以拖放來移動工作,或按住 Ctrl 鍵並同時拖放來複製工作。You can also drag and drop a task to move it, or drag and drop while holding the Ctrl key to copy the task.

使用流程參數將主要引數傳遞至您的工作Use process parameters to pass key arguments to your tasks

您現在可以使用流程參數 (圖 45),讓使用您組建定義或範本的人員更輕鬆地指定最重要的資料,而不需要深入探索您的工作。You can now use process parameters (Figure 45 to make it easier for those who use your build definition or template to specify the most important bits of data without having to go deep into your tasks.

Process parameters

(圖 45) 流程參數
Process parameters
(Figure 45) Process parameters

如果您從其中一些內建範本 (例如 Visual StudioMaven) 建立新的組建,您可以查看這些範本的運作方式範例。If you create a new build from some of the built-in templates (for example Visual Studio and Maven) you can see examples of how these work.

新編輯器包含一些其他增強功能,例如讓您更快速地存取來源設定。The new editor includes a few other enhancements, such as giving you quicker access to your sources settings.

如需使用新編輯器建立第一個組建定義的逐步解說,請參閱 CI/CD for newbies (CI/CD 入門)。For a walkthrough of creating your first build definition using the new editor, see CI/CD for newbies.

如需詳細資訊,請參閱 2017 年使用者體驗頁面。Learn more on the 2017 user experience page.

多重版本延伸模組工作Multiple versions of Extension tasks

延伸模組作者現已可建立包含多重版本指定工作的延伸模組,如此他們即可為生產環境中的每個主要版本傳送修補程式。Extension authors can now create extensions with multiple versions of a given task, which enables them to ship patches for each major version they have in production.

請參閱在延伸模組內建立自訂建置工作的參考See Reference for creating custom build tasks within extensions.

條件式建置工作 Conditional build tasks

如果您想要更充分掌控建置工作 (例如在發生錯誤時清除項目或傳送訊息等工作),我們現在提供您四個內建選項,讓您在執行工作時進行控制 (圖 46)If you’re looking for more control over your build tasks, such as a task to clean things up or send a message when something goes wrong, we’re now offering four built-in choices for you to control when a task is run (Figure 46).

Conditional build tasks

(圖 46) 條件式建置工作
Conditional build tasks
(Figure 46) Conditional build tasks

如果您需要更多彈性 (例如僅針對特定分支、使用特定觸發程序、在特定條件下執行的工作),您可以陳述自己的自訂條件If you are looking for more flexibility, such as a task to run only for certain branches, with certain triggers, under certain conditions, you can express your own custom conditions:

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

請參閱 Specify conditions for running a task (指定執行工作的條件) 頁面。See Specify conditions for running a task page.

建置並部署容器架構應用程式的內建工作 Built-in tasks for building and deploying container based applications

在此版本中,預設已將 Docker 延伸模組中大多數工作提取到產品中、加以改進,並引進一組新的工作和範本,讓一組容器情節更容易進行。With this release we have pulled most of the tasks in our Docker extension into the product by default, improved them, and introduced a set of new tasks and templates for making a set of container scenarios easier.

  • Docker:__建置、推送或執行 Docker 映像,或是執行 Docker 命令。__Docker: Build, push, or run Docker images, or run a Docker command. 此工作可搭配 Docker 或 Azure Container Registry 使用。This task can be used with Docker or Azure Container registry. 您現在可以搭配 ACR 使用我們的內建服務主體驗證,以更輕鬆地使用驗證。You can now use our built-in service principal authentication with ACR to make it even easier to use.
  • Docker-Compose:__建置、推送或執行多容器 Docker 應用程式。__Docker-Compose: Build, push, or run multi-container Docker applications. 此工作可搭配 Docker 或 Azure Container Registry 使用。This task can be used with Docker or Azure Container registry.
  • Kubernetes:__執行 kubectl 命令以在 Azure Container Service 中部署、設定或更新 Kubernetes 叢集。__Kubernetes: Deploy, configure, or update your Kubernetes cluster in Azure Container Service by running kubectl commands.
  • Service Fabric:__將容器部署到 Service Fabric 叢集。__Service Fabric: Deploy containers to a Service Fabric Cluster. Service Fabric 是今日在雲端中執行 Windows 容器的最佳選擇。Service Fabric is the best choice today for running Windows Containers in the cloud.

Azure Web 應用程式部署更新 Azure Web App deployment updates

我們針對 Azure Web 應用程式提供了許多增強功能:We have made many enhancements for Azure Web Applications:

  • Azure App Service 部署工作支援部署 Java WAR 檔案、Node.js、Python 和 PHP 應用程式。Azure App Service deployment task supports Java WAR files, Node.js, Python, and PHP applications to be deployed.
  • Azure App Service 部署工作支援使用容器部署到適用於 Linux 的 Azure Web 應用程式。Azure App Service deployment task supports deploying to Azure Web App for Linux using containers.
  • Azure 入口網站的持續傳遞功能已擴充,現在支援 Node 應用程式。Azure portal Continuous Delivery is expanded now support Node applications.
  • 新增 Azure App Service 管理工作,可進行 Azure App Service 的啟動、停止、重新啟動或位置交換。Azure App Service manage task is added to Start, Stop, Restart or Slot swap for an Azure App Service. 它也支援安裝網站延伸模組以啟用必要 PHP 或 Python 版本的安裝,或是安裝 IIS Manager 或 Application Insights。It also supports installing site extensions to enable installation of the required PHP or Python version or installing IIS Manager or Application Insights.

我們也將 CI/CD 支援引入最新版 Azure CLI,以設定 CI/CD。We have also introduced CI/CD support into the latest version of the Azure CLI for configuring CI/CD. 請看以下範例:Here is an example:

az appservice web source-control config --name mywebapp --resource-group mywebapp_rg --repo-url https://myaccount.visualstudio.com/myproject/_git/myrepo --cd-provider vsts --cd-app-type AspNetCore

.NET Core 工作支援專案檔.NET Core tasks support project files

在目前更新中,我們將增強 .NET Core 工作,除了 project.json,也支援 *.csproj 檔案。With the current update, we are enhancing .NET core tasks to support *.csproj files in addition to project.json. 您現在可以在組建代理程式上使用 Visual Studio 2017,透過 csproj 檔案建置 .NET Core 應用程式。You can now use Visual Studio 2017 on your build agents to build .NET core applications using csproj files.

SSH 部署改進SSH deployment improvements

[透過 SSH 複製檔案] 建置/發行工作現在支援在目的路徑中使用波狀符號 (~),以簡化複製檔案到遠端使用者主目錄的作業。The Copy Files Over SSH build/release task now supports tildes(~) in the destination path to simplify copying files to a remote user’s home directory. 此外還提供新選項,以在找不到可複製的檔案時使建置/發行失敗。Also, a new option allows causing the build/release to fail when no files are found to copy.

SSH 建置/發行工作現在支援在 Linux 或 macOS 遠端電腦上,執行具有 Windows 行尾結束符號的指令碼。The SSH build/release task now supports running scripts with Windows line endings on remote Linux or macOS machines.

在建置或發行期間安裝 SSH 金鑰Install an SSH key during a build or release

新的預覽工作 [安裝 SSH 金鑰 (預覽)] 會在建置或發行之前安裝 SSH 金鑰,並在建置或發行完成時從代理程式移除金鑰。A new preview task, Install SSH Key (Preview), installs an SSH key prior to a build or release and removes it from the agent when the build or release completes. 所安裝的金鑰可用於從 Git 存放庫或子模組擷取程式碼、執行部署指令碼或其他需要 SSH 驗證的活動。The installed key can be used for fetching code from a Git repository or submodules, running deployment scripts, or other activities that require SSH authentication. 未來將改進以支援複雜密碼和其他功能。It will be improved in the future to support passphrases and other capabilities.

如果指定了 Visual Studio 2017 但該產品不在代理程式上,工作會失敗Tasks fail if Visual Studio 2017 is specified but not present on agent

Visual Studio 建置MSBuild 工作可讓您選取 Visual Studio 特定版本。The Visual Studio Build and MSBuild tasks enable you to select a specific version of Visual Studio. 截至目前為止,如果 Visual Studio 2017 版本無法使用,這些工作會自動選取下一個可用的版本。Until now, if the Visual Studio 2017 version was not available, these tasks would automatically pick the next available version.

我們將變更此行為。We’re changing this behavior. 現在,如果您選取 Visual Studio 2017 但該產品不在代理程式上,建置將會失敗。Now the build will fail if you select Visual Studio 2017 but it is not present on the agent.

此變更的原因如下:We made this change for the following reasons:

  • 較新的應用程式類型 (例如 .NET Core) 不會以較舊的建置工具編譯。Newer app types such as .NET Core do not compile with older build tools. 這些類型明確需要 Visual Studio 2017 或更新版本。They explicitly require Visual Studio 2017 or newer.

  • 當您使用完全相同的 Visual Studio 版本時,您會得到更一致且可預測的結果。You get more consistent and predictable results when you use the same exact version of Visual Studio.

  • 每當建置工作回復時,您可能會得到難以了解的編譯錯誤。Whenever build tasks fall back, you may get compilation errors that are difficult to understand.

提示

請確定所使用的佇列連線到具有 Visual Studio 2017 代理程式 (而不是只有舊版 Visual Studio 代理程式) 的集區。Make sure to use a queue connected with a pool that has agents with Visual Studio 2017, and no agents that have only earlier versions of Visual Studio.

私人代理程式自動工作區清除Private agent automatic workspace cleanup

您現在可以設定代理程式集區,定期清除過時的工作目錄和存放庫 (圖 47)。You can now configure an agent pool to periodically clean up stale working directories and repositories (Figure 47). 例如,此集區將會刪除已刪除的組建和發行定義所留下的工作區。For example, the pool will delete workspaces left behind by deleted build and release definitions.

Agent maintenance

(圖 47) 代理程式維護
Agent maintenance
(Figure 47) Agent maintenance

使用此選項應該會降低私人組建和發行代理程式用盡磁碟空間的可能性。Using this option should reduce the potential for your private build and release agents to run out of disk space. 此維護工作是針對每個代理程式 (而不是每部電腦) 來執行,因此如果您在單一電腦上有多個代理程式,您仍然可能會遇到磁碟空間問題。The maintenance is done per agent (not per machine), so if you have multiple agents on a single machine you could still run into disk space issues.

組建代理程式升級狀態Build agent upgrade status

升級代理程式時,現在會在佇列和集區管理入口網站中指出升級的狀態。When an agent is being upgraded, it now indicates the status of the upgrade in the queue and pool management portal.

選取非使用中電腦上的私人代理程式Selection of private agents on machines not in use

系統現在會使用電腦名稱作為將組建或發行配置給私人代理程式時的因素。The system now uses machine name as a factor when allocating a build or a release to a private agent. 因此,系統在配置作業時,會優先使用閒置電腦上的代理程式,而不是忙碌電腦上的代理程式。As a result, the system will prefer an agent on an idle machine over an agent on a busy machine when it allocates the job.

管線佇列Pipelines queue

我們現已從依據代理程式定價的模式改為依據管線定價的模式We have now moved from the agent-based pricing model to pipeline-based pricing model. 在此新模式中,使用者可同時執行與其帳戶中設定的管線數一樣多的建置或發行。In this new model, users can run as many builds or releases concurrently as the number of pipelines configured in their account. 超額的建置與發行會排入佇列,並等候較早的建置與發行完成。Additional builds and releases beyond this limit are queued and wait for earlier builds and releases to complete. 管線佇列__功能可讓使用者更加清楚其建置或發行的情況。The __Pipelines queue feature provides users with more visibility into where their builds or releases are.

在啟動__管線佇列__時,可看到下列資訊:On launching the Pipelines queue, you can see the following information:

  1. 建置與發行正在等候管線執行,以及其在等候佇列中的位置。Builds and releases waiting for a pipeline to execute and their position in the waiting queue.
  2. 建置與發行目前正在使用可用的管線執行。Builds and releases currently running using available pipelines.

當您的建置/發行正在等候管線時,您也可以從建置/發行記錄頁面內直接啟動此檢視,並尋找其目前在管線佇列中的位置與其他詳細資料。While your build/release is waiting for a pipeline, you can also directly launch this view from inside the build/release logs page and find its current position in the pipeline queue and other details.

建置摘要中的發行動作Release action in Build summary

我們現已支援__發行__動作,其位於__建置__摘要動作列中,您可利用該動作輕鬆地建立建置之發行。We are now supporting a Release action, available in the Build summary action bar, so it is easy for you to create a release for a build.

變數群組的安全性Security for variable groups

變數群組的安全性現在係透過一組角色進行管理,例如__建立者__與__系統管理員__。Security for variable groups is now governed through a set of roles such as Creator and Administrator.

根據預設會指派以下角色。By default, the below roles are assigned.

  • 建立者角色指派給參與者Creator role to Contributors
  • 系統管理員角色指派給專案集合系統管理員、專案系統管理員、組建系統管理員與發行系統管理員Administrator role to Project Collection Administrators, Project Administrators, Build Administrators, and Release Administrators
  • 讀取者角色指派給有效的專案使用者Reader role to Valid Project Users

所有變數群組或特定變數群組的預設值皆可覆寫。The defaults can be overridden for all variable groups or for a specific one.

iOS DevOps 增強功能iOS DevOps enhancements

Apple App Store 延伸模組現在支援雙步驟驗證 (雙因素驗證),以及將組建發行給外部測試人員 (圖 48)The Apple App Store extension now supports two-step verification (two-factor authentication) and releasing builds to external testers (Figure 48).

Apple App Store connection

(圖 48) Apple App Store 連線
Apple App Store connection
(Figure 48) Apple App Store connection

[安裝 Apple 憑證 (預覽)] 是新的建置工作,它會在代理程式上安裝 P12 簽署憑證,以供後續 Xcode 或 Xamarin.iOS 組建使用。Install Apple Certificate (Preview) is a new build task that installs a P12 signing certificate on the agent for use by a subsequent Xcode or Xamarin.iOS build.

[安裝 Apple 佈建設定檔 (預覽)] 是新的建置工作,它會在代理程式上安裝佈建設定檔,以供後續 Xcode 或 Xamarin.iOS 組建使用。Install Apple Profile (Preview) is a new build task for installing provisioning profiles on the agent for use by a subsequent Xcode or Xamarin.iOS build.

MSBuild、Xamarin.Android 和 Xamarin.iOS 建置工作現在支援使用 Visual Studio for Mac 工具組來建置。MSBuild, Xamarin.Android, and Xamarin.iOS build tasks now support building with the Visual Studio for Mac tool set.

Java 程式碼涵蓋範圍增強功能Java code coverage enhancements

[發行程式碼涵蓋範圍結果] 建置工作會在建置過程中報告 Cobertura 或 JaCoCo 程式碼涵蓋範圍。The Publish Code Coverage Results build task reports Cobertura or JaCoCo code coverage as part of a build. 它現在支援在 [摘要檔] 和 [報告目錄] 欄位中指定萬用字元和 minimatch 模式,如此可在路徑因不同組建而變更時,解析每個組建的檔案和目錄。It now supports specifying wildcards and minimatch patterns in Summary File and Report Directory fields, allowing the files and directories to be resolved on a per-build basis for paths that change between builds.

Maven 和 SonarQube 改進Maven and SonarQube improvements

Maven 建置工作現在允許在 SonarQube 專案與 Maven pom.xml 檔案中指定的專案不同時,指定 SonarQube 專案用於分析結果。The Maven build task now allows specifying a SonarQube project for analysis results in cases where it differs from what is specified in the Maven pom.xml file.

改進的 Jenkins 整合Improved Jenkins integration

[Jenkins 佇列作業] 建置/發行工作現在支援執行 Jenkins 多分支管線作業,同時在 Team Services 中顯示 Jenkins 主控台輸出 (圖 49)。The Jenkins Queue Job build/release task now supports running Jenkins multibranch pipeline jobs while displaying the Jenkins console output in Team Services (Figure 49). 管線結果會發行至 Team Services 組建摘要。Pipeline results are published to the Team Services build summary.

Improved Jenkins integration

(圖 49) Jenkins 整合改進
Improved Jenkins integration
(Figure 49) Improved Jenkins integration

Azure 虛擬機器擴展集部署Azure virtual machine scale set deployment

部署的常用模式是為每個應用程式版本建立完整的電腦映像,然後部署該映像。A common pattern being used for deployment is to create a full machine image for each version of the application and then deploy that. 為了簡化部署,我們新增了 [建置不可變的電腦映像] 工作。To make that easier we have a new Build immutable machine image task. 此工作使用 Packer,在部署應用程式及所有必要條件之後產生電腦映像。This task uses Packer to generate a machine image after deploying applications and all the required prerequisites. 此工作使用部署指令碼或 Packer 設定範本來建立電腦映像,然後將它儲存在 Azure 儲存體帳戶中。The task takes either the deployment script or the packer configuration template to create the machine image and stores it in an Azure Storage account. 適用於這種不可變之映像部署類型的 Azure 虛擬機器擴展集部署接著可以使用此映像。This image can then be used for Azure virtual machine scale set deployments that work well with this type of immutable image deployment.

在 Azure 資源群組部署中覆寫範本參數Override template parameters in Azure resource group deployments

目前在 Azure 資源群組部署工作中,使用者可以選取 template.json 和 parameters.json,然後在文字方塊中提供覆寫參數值,後面接著特定語法。Currently in Azure resource group deployment tasks, users select the template.json and the parameters.json and provide the override parameter values in a text box, following a specific syntax. 現在已增強此體驗,在方格內呈現範本參數以供編輯和覆寫 (圖 50)。This experience is now enhanced so the template parameters are rendered in a grid which allows them to be edited and overridden (Figure 50). 您可以按一下 [覆寫參數] 欄位旁的 [...] 來存取這項功能,這會開啟一個對話方塊,其中包含範本參數,以及其預設值和允許的值 (如果範本和參數的 .json 檔案中已定義)。You can access this feature by clicking the ... next to the override parameters field, which opens a dialog with the template parameters along with their default values and allowed values (if defined in the template and parameter .json files). 這項功能需要啟用來源端的 CORS 規則。This feature requires that CORS rules are enabled at the source. 如果範本和參數的 JSON 檔案位於 Azure 儲存體 Blob 中,請參閱 Azure 儲存體服務文件以啟用 CORS。If template and parameter json files are in Azure storage blob, refer to the Azure Storage Services documentation to enable CORS.

Azure RG parameters

(圖 50) Azure RG 參數
Azure RG parameters
(Figure 50) Azure RG parameters

多個含有分支和標記篩選的發行觸發程序Multiple release triggers with branch and tag filters

發行管理現在支援在「組建」類型的多個成品來源中設定 CD 觸發程序。Release management now supports setting up CD triggers on multiple artifact sources of type “Build”. 新增時,如果任何指定的成品來源有新的成品版本可用,則會自動建立新發行。When added, a new release is created automatically when a new artifact version is available for any of the specified artifact sources. 您也可以指定新組建要觸發發行的來源分支。You can also specify the source branch that the new build should be from to trigger a release. 此外,您可以設定標記篩選,以進一步篩選應該觸發發行的組建。Additionally, Tag filters can be set to further filter the builds that should trigger a release.

為發行中的成品來源設定預設值Set defaults for artifact sources in a release

使用者可以定義在連結定義中的成品來源時,要在發行中部署的預設成品版本 (圖 51)。Users can define the default artifact version to deploy in a release when linking an artifact source in a definition (Figure 51). 自動建立發行之後,就會部署所有成品來源的預設版本。When a release is created automatically, the default version for all the artifact sources would be deployed.

Default artifact version

(圖 51) 預設成品版本
Default artifact version
(Figure 51) Default artifact version

部署要求者與核准者的職責區分Separation of duties for deployment requester and approvers

先前,環境擁有者可以限制發行建立者核准環境的發行部署。Previously, environment owners could restrict release creators from approving deployments of the release to an environment. 不過,您可以手動開始部署另一個使用者建立的發行,並親自核准發行。You could, however, manually start deployment of a release created by another user, and approve it yourself.

我們現在填補了這個間隙,並將部署建立者視為個別的部署使用者角色。We have now filled this gap by considering the deployment creator as a separate user role for deployments. 如此即可同時限制發行建立者或部署建立者核准部署。Either the release creator or deployment creator can be restricted from approving the deployments.

發行層級核准Release level approvals

您現在可以選擇自動核准在成功部署到另一個環境之後自動觸發的部署 (圖 52)。You can now choose to automatically approve deployments that were automatically triggered after successful deployment to another environment (Figure 52). 如果您選擇不要核准每個部署,您可以一次核准一連串具有相同核准者的部署。Approving a chain of deployments (which have the same approvers) can be done at one go if you choose to not approve every deployment.

假設有「開發」和「測試」這兩個環境,並將前置部署核准者設定為「使用者 A」和「使用者 B」,這兩位使用者都必須核准部署。Let’s say you have two environments Dev and Test, with the predeployment approvers set to “userA” and “userB,” with both of them required to approve the deployment. 如果「測試」的相關原則設定如下,使用者 A 和使用者 B 在部署時只要核准「開發」即可。If the policy on Test is set as shown below, during deployment time it will be sufficient for userA and userB to approve only Dev. 系統將會自動核准「測試」部署。Deployment to Test will get auto-approved. 如果手動觸發「測試」部署,為了確保正確核准,必須在部署前核准。If the deployment to Test is triggered manually, the approvals will be required before deployment to ensure correct approvals.

Release level approvals

(圖 52) 發行層級核准
Release level approvals
(Figure 52) Release level approvals

部署到 Azure Government 雲端Deploy to Azure Government Cloud

在 Government 雲端中具有 Azure 訂用帳戶的客戶現在可以設定 Azure Resource Manager 服務端點以國內雲端為目標。Customers with Azure subscriptions in Government Clouds can now configure Azure Resource Manager service endpoint to target national clouds.

有了這項設定,您現在可以透過相同的部署工作,使用 Release Management 將任何應用程式部署到裝載於 Government 雲端中的 Azure 資源 (圖 53)With this, you can now use Release Management to deploy any application to Azure resources hosted in government clouds, using the same deployment tasks (Figure 53).

Government cloud

(圖 53) Government 雲端
Government cloud
(Figure 53) Government cloud

設定平行部署數上限Set maximum number of parallel deployments

這項功能可讓您控制如何將多個擱置中的發行部署到指定的環境 (圖 54)。This feature gives you control on how multiple pending releases are deployed into a given environment (Figure 54). 例如,如果您的發行管線在 QA 環境中執行組建的驗證,而且產生組建的速度比部署完成的速度更快,您可以設定多個代理程式,以及可平行驗證的最多組建數目。For example, if your release pipeline performs validation of builds in a QA environment and the rate of generation of builds is faster than the rate of completion of the deployments, you may configure multiple agents and as many builds to get validated in parallel. 這表示每個產生的組建都會經過驗證,而且等候時間與可用的代理程式數目相關。That means each of the builds generated gets validated, and the wait time is dependent in the number of available agents. 有了這項功能,您就可以在 n 個最新的組建上平行執行驗證,並取消較舊的部署要求,以便將驗證功能發揮到最大。With this feature, we let you optimize validations by enabling you to perform validation on the n most recent builds in parallel and cancel the older deployment requests.

Parallel deployments

(圖 54) 平行部署
Parallel deployments
(Figure 54) Parallel deployments

手動操作工作的逾時增強功能Timeout enhancements for the Manual Intervention task

您現在可以在 [手動操作] 工作擱置超過指定的逾時或 60 天後 (以較早的時間為準) 自動拒絕或繼續。The Manual Intervention task can now be automatically rejected or resumed after it is pending for the specified timeout or 60 days, whichever is earlier. 您可以在工作的控制選項區段中指定逾時值。The timeout value can be specified in the control options section of the task.

Release Management 平行執行Release Management parallel execution

Release Management 現在支援階段的平行執行選項 (圖 55)。Release Management now supports a parallel execution option for a phase (Figure 55). 選取此選項可使用 [多重設定] 或 [多重代理程式] 作為階段乘數選項,來展開傳送階段。Select this option to fan out a phase by using either Multi-configuration or Multi-agent as a phase multiplier option.

Parallel execution support

(圖 55) 平行執行支援
Parallel execution support
(Figure 55) Parallel execution support

多重設定:選取此選項可對每個多重設定值執行階段。Multi-configuration: Select this option to run the phase for each multi-configuration value. 例如,如果您想要同時部署到兩個不同的地區,使用定義於 [變數] 索引標籤的變數 ReleasePlatform 並提供 [美國東部] 和 [美國西部] 值會平行執行階段,一個使用 [美國東部] 值,另一個使用 [美國西部] 值。For example, if you wanted to deploy to two different geos at the same time, using a variable ReleasePlatform defined on the Variables tab with values "east-US, west-US" would run the phase in parallel, one with a value of "east-US" and the other "west-US”. 多重代理程式:選取此選項可在多個代理程式上平行執行具有一或多個工作的階段。Multi-agent: Select this option to run the phase with one or more tasks on multiple agents in parallel.

Azure 入口網站中的 Web 應用程式部署歷程記錄Web app deployment history in Azure portal

Release Management 現在已更新使用 Azure App Service 部署工作完成部署時的 App Service 部署記錄。Release management now updates the deployment logs of Azure App Service when a deployment is done by using the App Service deployment task. 您可以選取 [App Service] 刀鋒視窗中的 [持續傳遞] 選項,以檢視 Azure 入口網站中的部署歷程記錄。You can view deployment history in the Azure portal by selecting the Continuous delivery option in the App Service blade.

測試改進 Testing Improvements

使用代理程式階段執行測試Run tests using agent phases

透過 Visual Studio 測試工作,您現在可以使用代理程式階段執行自動化測試 (圖 56)。Using the Visual Studio Test task, you can now run automated tests using agent phases (Figure 56).

我們現在有跨建置、發行和測試的整合自動化代理程式。We now have a unified automation agent across build, release and test. 這帶來下列優點:This brings in the following benefits:

  1. 您可以針對測試需求,有效率的調控代理程式集區。You can leverage an agent pool for your testing needs.
  2. 根據您的需求,使用相同的 Visual Studio 測試工作__在不同的模式中執行測試,—單一代理程式型回合、多重代理程式型分散式測試回合或多重設定回合,以在不同的瀏覽器上執行測試。Run tests in different modes using the same __Visual Studio Test task, based on your needs—single agent–based run, multi-agent–based distributed test run or a multi-configuration run to run tests on, say, different browsers.

Run tests using Agent Phases

(圖 56) 使用代理程式階段執行測式
Run tests using Agent Phases
(Figure 56) Run tests using Agent Phases

如需詳細資訊,請參閱這篇 Microsoft 應用程式生命週期管理文章。For more information, refer to this Microsoft Application Lifecycle Management post.

依需求觸發自動化測試On-demand triggering of automated tests

[測試] 中樞現在支援從測試計劃和測試套件觸發自動化測試案例 (圖 57)。The Test hub now supports triggering automated test cases from test plans and test suites (Figure 57). 從 [測試] 中樞執行自動化測試,需要進行類似於您在發行環境中依照排程執行測試的設定。Running automated tests from the Test hub will need a setup similar to the way you run tests in a scheduled fashion in release environments. 您需要使用 [Run automated tests from test plans] (從測試計劃執行自動化測試) 範本在發行定義中設定環境,並與測試計劃建立關聯以執行自動化測試。You will need to setup an environment in the release definition using the Run automated tests from test plans template and associate the test plan to run the automated tests. 如需如何從 [測試] 中樞設定環境及執行自動化測試的逐步指導,請參閱此文件See the documentation for the step by step guidance on how to setup environments and run automated tests from the Test hub.

On-demand automated tests trigger

(圖 57) 隨選自動化測試觸發程序
On-demand automated tests trigger
(Figure 57) On-demand automated tests trigger

倉儲功能改進 Warehouse Improvements

改進 Analysis Services 處理 Cube 的效能Performance improvements in Analysis Services cube processing

我們已改進 vDimWorkItemTreeOverlay 檢視的效能,這個檢視的功能是依據連結建立__工作項目樹狀階層__維度。We’ve made performance improvements to the vDimWorkItemTreeOverlay view, which is used to create Work Item Tree Hierarchy dimension based on the links. 雖然是以 System.LinkTypes.Hierarchy 連結為依據,但我們觀察到其他連結也會影響處理時間 (例如 System.LinkTypes.Related)。Although it depends on System.LinkTypes.Hierarchy links, we observed that the processing duration was affected by other links as well (e.g. System.LinkTypes.Related). 我們已將檢視最佳化,以跳過限制資料讀取量的其他連結。We optimized the view to skip addition link types which limits the amount of data read. 這項變更大幅縮短了某些倉儲的處理時間。This change significantly decreases processing time for certain warehouses.

不區分大小寫的結構描述重新調整Case-insensitive schema reconciliation

倉儲資料庫的結構描述是在結構描述重新調整程序中,將所有附加的集合資料庫欄位合併建立而成。The schema of the warehouse database is created by merging fields from all the attached collection databases in the schema reconciliation process. 之前,所有的比較都會區分大小寫,而且系統管理員必須確認欄位的參考名稱完全相符。Previously, all comparisons were case-sensitive and administrators had to make sure there is an exact match on field reference names. 這在大小寫有輕微差異時會造成問題。This led to problems where there were subtle differences in casing. 在此版本中,我們放寬了對這類不一致的限制。With this release we make the process more tolerant to such discrepancies.

系統管理改善 Administration Improvements

已合併通知的電子郵件收件者Combined email recipients for notifications

相同電子郵件通知的所有收件者現在會併入 [收件者:] 行並傳送一封電子郵件。Recipients for the same email notification are now included together on the to: line and sent a single email. 之前會傳送個別電子郵件給每個收件者。Previously, individual emails were sent to each recipient. 這會很難了解還有誰收到通知,並透過電子郵件與其討論該事件。This made it difficult to know who else received the notification and to have a conversation about the event over email. 這項功能會套用至能夠以多個收件者為目標的現成訂閱及小組訂閱。This feature applies to out-of-the-box as well as team subscriptions that are capable of targeting multiple recipients. 例如,提取要求的所有檢閱者現在會在提取要求變更時收到一封相同的電子郵件。For example, all reviewers of a pull request are now sent a single email when a change is made to the pull request.

深入了解如何合併電子郵件收件者Learn more about combining email recipients.

立即可用的通知Out-of-the-box notifications

使用者和小組現在會在帳戶中有直接相關的活動時,自動收到電子郵件通知,例如:Users and teams are now automatically notified via email when there is activity in the account directly relevant to them, such as:

  • 當工作項目指派給使用者時。when a work item is assigned to a user.
  • 當使用者或小組新增為提取要求的檢閱者時。when a user or team is added as a reviewer to a pull request.
  • 當使用者或小組是已更新之提取要求的檢閱者時。when a user or team is a reviewer on a pull request that is updated.
  • 當其他使用者回覆提取要求註解時。when another user responds to a pull request comment.
  • 當使用者要求的組建完成時。when a build requested by a user completes.
  • 當安裝或要求延伸模組時 (僅限系統管理員)。when an extension is installed or requested (admins only).

使用者可以取消上述任何訂閱,方法是移至使用者設定檔功能表下的 [通知] 設定,然後關閉適當的切換開關。Users can unsubscribe from any of these subscriptions by going to Notification settings under the user profile menu and then switching off the appropriate toggle(s).

帳戶管理員可以停用上述一或多個自動訂閱,方法是巡覽至設定齒輪下的集合層級 [通知] 中樞。An account admin can disable one or more of these automatic subscriptions by navigating to the collection-level Notifications hub under the settings gear. 上述任何訂閱都可以透過按一下 […] 動作下的 [停用] 來停用。Any of these subscriptions can be disabled by clicking Disable under the "..." action. 停用訂閱之後,使用者在其個人通知設定頁面中將不會再看到此訂閱。Once a subscription is disabled, it will no longer appear for users in their personal notification settings page.

深入了解立即可用的通知Learn more about out-of-the-box notifications.

延伸模組管理權限Extension management permissions

系統管理員現在可以授與其他使用者和群組管理集合之延伸模組的權限 (圖 58)。An admin can now grant other users and groups permission to manage extensions for the collection (Figure 58). 先前只有集合管理員 (也就是 Project Collection Administrators 群組的成員) 才能檢閱延伸模組要求,或是安裝、停用或解除安裝延伸模組。Previously only collection administrators (i.e. members of the Project Collection Administrators group) could review extension requests, install, disable, or uninstall extensions.

若要授與此權限,系統管理員可以開啟 [Marketplace] 功能表、選取 [管理延伸模組],然後按一下 [安全性] 按鈕,以巡覽至 [延伸模組] 管理中樞:To grant this permission, an administrator can navigate to the Extensions admin hub by opening the Marketplace menu, selecting Manage extensions, and then click the Security button:

Extension management permissions

(圖 58) 延伸模組管理權限
Extension management permissions
(Figure 58) Extension management permissions

在安裝延伸模組、延伸模組需要注意及其他情況下取得通知Getting notified when extensions are installed, require attention, and more

系統管理員 (或能夠管理延伸模組的人員) 現在會在安裝、解除安裝、啟用、停用延伸模組,或延伸模組需要注意時,自動收到通知。Admins, or those with the ability to manage extensions, are now automatically notified when an extension is installed, uninstalled, enabled, disabled, or requires attention. 這特別適用於多人負責管理延伸模組的較大型部署。This is especially useful in larger deployments where multiple people have the responsibility of managing extensions. 系統管理員可以巡覽至設定檔功能表下的 [通知] 設定,然後關閉延伸模組切換開關,來關閉這些通知。Admins can turn off these notifications by navigating to Notification settings under the profile menu and switching off the extensions toggle.

系統管理員也可以定義延伸模組相關事件的自訂訂閱。Admins can also define custom subscriptions for extension-related events. 例如,系統管理員可以在每次更新任何延伸模組時收到通知。For example, an admin can get notified whenever any extension is updated.

使用者現在也可以關閉有關其延伸模組要求的自動通知。Users can also now turn off automatic notifications about their extension requests.

允許 TFS 系統管理員將訂閱者新增至進階存取層級Allowing TFS admins to add subscribers to the advanced access level

Team Foundation Server 的未來版本將移除 [進階] 存取層級。The Advanced access level will be removed from future versions of Team Foundation Server. 不過在這之前,TFS 系統管理員可以透過 Update 2,將 MSDN Platform和 Visual Studio Test Professional 訂閱者新增至 [進階] 存取層級。However, until that happens, TFS admins will have the ability to add MSDN Platform and Visual Studio Test Professional subscribers to the Advanced access level with Update 2.

Visual Studio Enterprise 訂閱者應該新增至 Visual Studio Enterprise 存取層級,而不是 [進階]。Visual Studio Enterprise subscribers should be added to the Visual Studio Enterprise access level instead of Advanced. 如果您已購買 Test Manager 延伸模組,請在您所購買之 Team 專案內的使用者中樞,繼續管理此延伸模組。If you have purchased the Test Manager extension, please continue to manage this in the Users hub within the Team Project that you made the purchase.

Microsoft Teams 整合 Microsoft Teams Integration

使用 Microsoft Teams 共同作業的組織現在能夠在小組頻道中,查看 TFS 專案的活動。Organizations using Microsoft Teams to collaborate can now see activity from their TFS projects within their team’s channels. 這讓小組在運用 Microsoft Teams 時,能夠隨時獲悉相關的工作項目變更、提取要求、組建與版本以及其他項目。This allows teams to stay informed about relevant work item changes, pull requests, builds, and releases and more as they are working in Microsoft Teams. 如需詳細資訊,請參閱文件For more information see our documentation.


已知問題Known Issues

無法在網頁中正確呈現工作項目表單Work item forms do not render correctly in the web

  • 問題:Issue:

    如果您為 Visual Studio 用戶端安裝了自訂控制項 (例如多重值控制項),但網頁用戶端未安裝,網頁中的工作項目表單將無法呈現。If you have a custom control, such as the multi-value control, installed for the Visual Studio client but not the web client, work item forms in the web fail to render.

  • 因應措施:Workaround:

    您需要更新為最新版的控制項。You will need to update to the latest version of your control. 您必須新增不包含遺漏控制項目的網頁版面配置。It is necessary to add a web layout that doesn’t contain the missing control element. 您可以在 Custom Controls for TFS Work Item Tracking (TFS 工作項目追蹤的自訂控制項) 頁面上,找到 TFS 2017 Update 的最新多重值控制項。You can find the latest multi-value control for TFS 2017 Update on the Custom Controls for TFS Work Item Tracking page. 如需此版面配置的詳細資訊,請參閱 All FORM XML elements reference (TFS 2015) (所有 FORM XML 元素參考 (TFS 2015)) 頁面。For more information on the layout, see All FORM XML elements reference (TFS 2015) page.

TFS 版本是 RC2,而非最終版本TFS version is RC2 instead of the final release

  • 問題:Issue:

    在 2017 年 8 月 1 日前下載並安裝 TFS 2017 Update 2 之後,版本是 RC2。After downloading TFS 2017 Update 2 before August 1, 2017, and installing, you have an RC2 version.

  • 因應措施:Workaround:

    這是已在 2017 年 8 月 1 日修正的安裝連結間歇性問題所造成。This was due to an intermittent issue in the installation links that was fixed on August 1, 2017. 請重新下載 TFS 2017 Update 2,並安裝這個最終版本。Please redownload TFS 2017 Update 2 and install this final release.


The Developer Community Portal 請參閱客戶針對 Team Foundation Server 2017 所回報的問題。The Developer Community Portal See customer-reported issues reported for Team Foundation Server 2017.


頁首
Top of Page