共用方式為

Team Foundation Server 2018 Update 2 版本資訊

  • 發行項

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

注意

如果您是從非英文語言版本的頁面存取此頁面，並想查看最新的內容，請瀏覽此版本資訊頁面的英文版本。 若要變更此頁面的語言，請按一下頁尾的地球圖示，然後選取您想要的語言。

您可於本文中找到最新版 Team Foundation Server 2018 的相關資訊。 按一下這個按鈕進行下載。

下載最新版的Team Foundation Server

若要深入了解 Team Foundation Server 2018，請參閱 Team Foundation Server 的需求與相容性 (英文) 頁面。 請前往 visualstudio.com/downloads 頁面來下載其他 TFS 2018 產品。

TFS 2012 和更新版支援直接升級至 Team Foundation Server 2018 Update 2。 如果您的 TFS 部署為 TFS 2010 或更舊版本，則必須先執行一些暫時步驟，才能升級至 TFS 2018 Update 2。 如需詳細資訊，請參閱下圖和 TFS 安裝頁面。

TFS 升級矩陣圖
TFS 升級矩陣圖

重要

您在升級至 TFS 2018 Update 2 前，不需先升級至 TFS 2018 RTM。

版本資訊圖示發行日期：2018 年 5 月 7 日

您現已可升級為 TFS 2018 Update 2，且可繼續連線至 XAML 控制器並執行 XAML 組建。 當我們在 TFS 2018 RTW 和 Update 1 中移除了對 XAML 組建的支援時，你們當中有些人因為具有舊版 XAML 組建而無法升級，因此我們想要將你們解除封鎖。 雖然 TFS 2018 Update 2 支援舊版組建的 XAML 組建，但 XAML 組建已淘汰，而且不會有任何進一步的投資，因此強烈建議您轉換成較新的組建定義格式。

TFS 2018 Update 2 新功能摘要

我們為 Team Foundation Server 2018 Update 2 新增了許多值。 一些重點包括：

TFS 2018 Update 2 新功能詳細資料

您可以尋找每個區域中功能的詳細資料：

代碼

檢視檔案時，您通常會在所選取分支頂端看到版本。 頂端的檔案版本可能會隨著新的認可變更。 如果您是從這個檢視複製連結，則連結可能會變成過時，因為 URL 只會包含分支名稱，而未包含認可 SHA。 您現在可以輕鬆地切換 [檔案] 檢視以更新 URL 來參考認可，而非分支。 如果您按 "y" 鍵，則檢視會切換為最新分支的頂端認可。 您接著可以複製永久連結。

透過 API 復原最近刪除的存放庫

有時，清除原始檔控制中的舊存放庫時，可能會發生錯誤。 30 天內刪除的 Git 存放庫可以透過 REST API 加以復原。 如需詳細資訊，請參閱清單和復原作業的文件。

SSH：支援額外的加密/金鑰，並取代過期加密

為了提升安全性與相容性，我們更新了 SSH 支援的加密清單。 我們依據 OpenSSH 的指示新增了 2 個加密，並即將淘汰 3 個加密。 取代的加密會繼續在此版本中運作。 隨著使用量的減少，未來將會移除它們。

新增：

  • AES128 CTR
  • AES256 CTR

已淘汰：

  • AES128
  • AES192
  • AES256

使用存放庫設定避免覆寫並保護效能

在此更新中，會有兩個新的存放庫設定，有助於 Git 順暢運作。

大小寫強制執行會將伺服器從其預設區分大小寫模式 (其中 "File.txt" 和 "file.txt" 參照相同的檔案) 切換為 Windows 和 macOS 友善模式 (其中 "File.txt" 和 "file.txt" 是相同的檔案)。 這個設定會影響檔案、資料夾、分支和標記。 它也防止參與者意外產生僅限大小寫差異。 大部分的參與者都是執行 Windows 或 macOS 時，建議啟用大小寫強制執行。

限制檔案大小可讓您防止新增或已更新檔案超過您設定的大小限制。 存在於 Git 存放庫歷程記錄的大型檔案數目越多，複製和擷取作業的效能就越差。 此設定可防止意外產生這些檔案。

大小寫強制執行

超過 1000 個檔案之認可的已增強篩選功能已變更

在已修改超過 1000 個檔案的認可或提取要求中搜尋檔案不足；您需要按一下 [載入更多] 連結數次，來尋找您感興趣的檔案。 現在，當您篩選樹狀檢視中的內容時，會對認可中的所有檔案搜尋該檔案，而不是只查看載入的前 1000 個檔案。 修改超過 1000 個檔案時，也會改善認可詳細資料頁面的效能。

尋找因強制推送而遺失的認可

您可以執行 Git 強制推送，並更新遠端 ref，即使其不是本機 ref 的上階也可以。這可能會導致其他項目遺失認可，而且可能很難識別根本原因。 在新的推送檢視中，我們已進行明顯地強制推送，以協助對遺失認可相關問題進行疑難排解。

強制推送

按一下強制推送標記會將您帶往已移除的認可。

已移除的認可

改動者現在都有歷程記錄

改動者檢視適用於識別變更程式碼行的最後一個人。 不過，您有時需要知道誰對程式碼行進行前一個變更。 改動者中的最新改善可能有所幫助 - 檢視這個認可之前的改動者。 顧名思義，此功能可讓您及時跳回變更特定行之版本以前的檔案版本，以及檢視該版本的改動者資訊。 您可以繼續及時往回鑽研，以查看已變更所選取程式碼行之檔案的每個版本。

改動者歷程記錄

切換差異檢視中的自動換行和空白字元

檔案差異檢視器中有兩個新功能：[切換自動換行] 和 [切換空白字元]。 第一個允許在處於差異檢視時套用自動換行設定。 這特別適用於檢閱內含不含頻繁分行符號之檔案的 PR - Markdown 檔案是一個不錯的範例。 只變更程式碼行或檔案中的空白字元時，切換空白字元的選項十分有用。 切換此設定會顯示和醒目提示差異中的空格字元 (點表示空格、箭號表示定位字元等)。

若要管理這些設定，請按一下提取要求編輯器或差異檢視中的編輯器喜好設定齒輪。 在 [檔案] 檢視中，選取滑鼠右鍵功能表上的 [使用者喜好設定] 選項。

編輯器齒輪

選取各種編輯器功能，包含 [Show and diff white space] \(顯示及區分空白字元)、[Enable word wrap] \(啟用自動換行)、[Enable code folding] \(啟用程式碼摺疊功能) 和 [Show minimap] \(顯示迷你地圖)。

編輯器喜好設定

若為 Web 檢視，還會啟用程式碼摺疊功能 (在某些編輯器中稱為「大綱」)。 啟用程式碼摺疊功能時，按一下減號即可摺疊程式碼區段 -- 按一下加號即可展開已摺疊的區段。 F1 命令選擇區也會公開摺疊整個檔案之各種縮排層級的選項，更輕鬆地讀取和檢閱大型檔案。

程式碼摺疊功能

追蹤對建置和發行之 Git 存放庫的程式碼推送

您現在可以在 [推送] 頁面中檢視合併認可的建置和發行狀態。 按一下推送旁邊的狀態，即可找到包含推送的特定組建或版本，以驗證成功或調查失敗。

推送 ci-cd 狀態

電子郵件通知中轉譯的 Markdown

Markdown 適用於在提取要求 (PR) 描述和註解中新增豐富格式、連結和影像。 PR 的電子郵件通知現在會顯示已轉譯的 Markdown，而非未經處理的內容，進而改善可讀性。

內嵌影像未以內嵌形式轉譯 (只顯示為連結)。我們已將此問題加入待辦項目，預計日後會再新增。

PR 通知 Markdown

直接從 Windows 檔案總管執行 TFVC 命令

TFVC Windows Shell 延伸模組在 Windows 檔案總管整合了輕量版控制體驗，現在也支援 TFS 2018。 此工具可讓您方便地存取 Windows 檔案總管操作功能表中的許多 TFVC 命令。

此工具先前是 TFS Power 工具的一部分，已發行為 Visual Studio Marketplace 上的獨立工具。

殼層延伸

控制誰可以提供給提取要求

先前，可以檢視 Git 存放庫的任何人都可以處理其提取要求。 我們已新增稱為 [提供給提取要求] 的新權限，以控制建立和標註提取要求的權限。 根據預設，先前擁有讀取權限的所有使用者與群組，現在也會獲授與此新權限。 引進這個新權限可以將額外的彈性和控制提供給系統管理員。 如果您需要 [讀者] 群組為真正唯讀，則可以拒絕 [提供給提取要求] 權限。

如需詳細資訊，請參閱設定存放庫權限的快速入門文件。

提取要求註解通知包含執行緒內容

提取要求 (PR) 註解的回覆通常會相當簡短，並認可將進行或已進行的變更。 當在 Web 檢視中檢視這些註解時不會有問題；但若是在閱讀電子郵件通知中的註解，原始註解的內容會不見。 簡單的「我將修正此問題」沒有任何意義。

現在，只要回覆 PR 註解，註解電子郵件就會在電子郵件訊息本文中包含先前回覆。 這可讓執行緒參與者從其收件匣立即看到註解的完整內容 - 不需要開啟 Web 檢視。

PR 註解通知執行緒

完成工作項目設定

完成提取要求時完成工作項目的功能現在有新的存放庫設定來控制預設行為。 [記住利用提取要求來完成工作項目的使用者喜好設定] 的新設定預設會予以啟用，而且會在完成存放庫中未來的提取要求時，接受使用者的上次狀態。 如果停用這個新設定，則存放庫中所有提取要求的 [合併之後完成連結的工作項目] 選項，預設都為停用。 使用者仍然可以選擇在完成 PR 時轉換已連結的工作項目，但每次都需要加入。

提取要求狀態擴充性

使用分支原則可能是增加程式碼品質的好方法。 不過，這些原則已經限制為僅限 TFS 原生提供的整合。 使用新的提取要求狀態 API 與對應分支原則時，第三方服務可以像在原生 TFS 功能中一樣，參與提取要求工作流程。

服務在發佈到提取要求的狀態 API 時，會立即出現在新 [狀態] 區段的 [PR 詳細資料] 檢視中。 [狀態] 區段會顯示描述，並建立服務所提供 URL 的連結。 狀態項目也支援動作功能表 (...)，可以為因應 Web 延伸模組新增的動作而加以延伸。

狀態區段

狀態本身不會阻擋 PR 完成，也因此才需要原則。 發佈 PR 狀態之後，即可接著設定原則。 從分支原則經驗中，[Require approval from external services] \(需要來自外部服務的核准) 提供新的原則。 選取 [+ 新增服務] 開始程序。

狀態原則新增

在此對話方塊中，從清單中選取即將發佈狀態的服務，然後選取所需的原則選項。

狀態原則對話方塊

原則生效之後，會視需要將狀態顯示在 [必要] 或 [選擇性] 的 [原則] 區段中，並且會視需要強制 PR 完成。

若要深入了解狀態 API，並自行試用，請參閱文件和範例。

提取要求服務掛勾合併事件

使用提取要求服務掛勾的延伸模組現在具有合併事件的更多詳細資料和篩選選項。 嘗試合併時，不論合併成功或失敗，都會引發事件。 合併嘗試導致失敗時，會包含失敗原因的詳細資料。

PR 服務掛勾合併事件

使用提取要求完成之工作項目的改善錯誤訊息

嘗試完成提取要求的工作項目時，可能無法將相關聯的工作項目轉換為已完成狀態。 例如，可能需要特定欄位，或需要使用者輸入，才能轉換狀態。 我們改進了通知您工作項目無法轉換的方式，讓您可以採取動作，進行必要的變更。

錯誤工作項目 PR

提及提取要求

您現在可以在 PR 註解和工作項目討論中提及提取要求。 提及 PR 的體驗類似工作項目的體驗，但使用驚嘆號 !，而不是雜湊標記 #。

當您要提及 PR 時，只要輸入 !，就會顯示互動式功能，讓您從最近的 PR 清單中挑選 PR。 輸入關鍵字來篩選建議清單，或輸入您想要提及的 PR 識別碼。 PR 一經提及之後，就會使用識別碼與完整標題進行內嵌轉譯，並連結到 PR 詳細資料頁面。

提及提取要求

使用提取要求標籤協助檢閱者

有些時候，將額外資訊傳遞給審核者十分重要。 提取要求有可能是進行中的工作，或者是即將發行版本的 Hotfix。因此您要在標題附加額外的文字，例如在標題的前面加上 "[WIP]" 或 "DO NOT MERGE" (請勿合併)。 標記現在提供一種方法，使用可用來溝通重要詳細資料並協助組織提取要求的額外資訊來標記提取要求。

PR 要求標籤

提取要求註解會追蹤已重新命名的檔案

有時在提取要求作用時，會重新命名或移動檔案。 先前這些重新命名的檔案如有註解，程式碼的最新檢視不會顯示這些註解。 我們現在已改善註解追蹤以追蹤重新命名的檔案，對於已重新命名或移動的檔案顯示最新版本上的註解。

檢視提取要求合併認可

提取要求差異檢視十分適合醒目提示來源分支中所引入的變更。 不過，目標分支的變更可能會導致差異檢視看起來與預期不同。 現在有新的命令可用來檢視提取要求「預覽」合併認可的差異：檢視合併認可。 此合併認可的建立目的是要檢查合併衝突以及與提取要求組建搭配使用，並反映合併認可在提取要求最終完成時的樣子。 目標分支包含未反映在差異中的變更時，合併認可差異可以適用於查看來源和目標分支中的最新變更。

檢視提取要求合併認可

另一個可與檢視合併認可命令一起使用的實用命令是重新啟動合併 (位於同一命令功能表上)。 如果目標分支自一開始建立提取要求之後已變更，則執行此命令會建立新的預覽合併認可，並更新合併認可差異檢視。

最近使用的檢閱者

如果您經常讓相同人員檢閱您的程式碼，便會發現新增檢閱者變得比以往更容易。 當您新增檢閱者至提取要求時，將焦點放在檢閱者輸入方塊，便會自動顯示最近新增的檢閱者清單，而不需要依名稱進行搜尋。 您有任何檢閱者時，請選取它們。

MRU 檢閱者

檢視自動完成提取要求的其餘原則條件

自動完成是使用分支原則之小組的實用功能，但使用選擇性原則時，可能無法確切地知道是什麼封鎖提取要求完成。 現在，設定自動完成提取要求時，圖說文字方塊會清楚地列出自動完成的確切原則條件清單。 符合每個需求時，除非沒有其餘需求並合併提取要求，否則會從清單中移除項目。

PR 自動完成清單

討論提取要求中的數學運算

需要在您的提取要求註解中包含方程式或數學運算式嗎？ 您現在可以使用內嵌和區塊標註，以在註解中包含 KaTeX 函式。 如需詳細資訊，請參閱支援的函式清單。

使用數學的 PR Markdown 註解

分支的提取要求建議

只要更新存放庫中的主題分支，就會顯示建立主題分支新提取要求 (PR) 的「建議」。 這十分適合用於建立新的 PR，而且我們也為分岔存放庫中的 PR 啟用了此功能。 若您更新了分叉中的分支，則當您下次瀏覽分叉或上游存放庫的程式碼中樞時，就會顯示建立提取要求的建議。 如果選取 [建立提取要求] 連結，則會將您導向至建立 PR 體驗，並且預先選取來源和目標分支及存放庫。

分支的 PR 建議

提取要求原則的路徑篩選

單一存放庫經常會包含由多個持續整合 (CI) 管線所建置的程式碼，以驗證組建及執行測試。 整合式建置原則現在支援路徑篩選選項，可輕鬆地設定針對每個 PR 自動觸發的多個必要 PR 組建。 只需要指定每個組建的路徑，視需要要求和設定觸發程序和需求選項。

PR 原則的路徑篩選

除了組建之外，狀態原則也會有路徑篩選選項可用。 這讓所有自訂或第三方原則都能針對特定路徑設定原則加以施行。

工作

工作項目表單中的鍵盤快速鍵

使用鍵盤快速鍵，將工作項目指派給您自己 (Alt + i)、跳至討論 (Ctrl + Alt + d)，並將快速連結複製至工作項目 (Shift + Alt + c)。 如需新快速鍵的完整清單，可在已開啟的工作項目表單中輸入 "?"，或參閱下表。

工作項目表單中的鍵盤快速鍵

現代化資料行選項

用來設定 [待辦項目]、[查詢] 和 [測試] 中樞內工作項目格線之資料行的 [資料行選項] 對話方塊已進行更新，可使用新增的面板設計。 搜尋以尋找欄位、拖放以重新排序資料行，或移除您不再想要的現有資料行。

現代化資料行選項

上次依資訊執行的查詢

隨著專案的共用查詢樹狀結構成長，可能會讓判斷查詢是否已不再使用而能否予刪除變得困難。 為了協助您管理 [共用的查詢]，我們已將兩個新中繼資料片段新增至查詢 REST API (上次執行方式和上次執行日期)，讓您可以撰寫清除指令碼來刪除過時查詢。

工作項目格線中所移除的 HTML 標記

根據客戶意見，我們已更新 Web、Excel 和 Visual Studio IDE 的工作項目查詢結果檢視中多行文字欄位的行為，以移除 HTML 格式。 當成資料行新增至查詢時，多行文字欄位現在會顯示為純文字。 以下是描述中具有 HTML 之功能的範例。

移除 HTML 標記

過去，查詢結果的轉譯類似 <div><b><u>Customer Value</u>...

新增 Not In 查詢運算子支援

支援 "In" 查詢運算子 \(英文\) 的欄位現在支援 "Not In"。 針對 "Not In" (不在) 識別碼清單中的工作項目、"Not In" (不在) 狀態清單中的工作項目等等來撰寫查詢，而全部都不需要建立許多巢狀的 "Or" 子句。

Not In 查詢運算子

@MyRecentActivity 和 @RecentMentions 的查詢

我們已為 [識別碼] 欄位引進兩個新查詢巨集，協助您找到可能對您重要的工作項目。 使用 @RecentMentions 查看過去 30 天內您提到了哪些項目，或使用 @MyRecentActivity 查看您最近檢視或編輯過的工作項目。

工作項目追蹤通知中的自訂欄位和標記篩選

通知現在可以在自訂欄位和標記上使用條件進行定義；不只是其變更時，還有符合特定值時，並允許為工作項目設定一組更健全的通知。

自訂工作項目通知設定

針對我的工作項目頁面提及的支援

我們在 [我的工作項目] 頁面下新增了 [已提及] 樞紐。 在此樞紐內，您可以檢閱已在過去 30 天提及的工作項目。 使用這個新檢視，您可以對需要您輸入的項目採取動作，並隨時獲得與您相關交談的最新消息。

[我的工作項目] 底下提及的工作

這個相同的樞紐也可以透過我們的行動體驗取的，讓行動與桌面之間具有一致性。

已提及工作

計劃的篩選

傳遞計劃延伸模組現在利用通用篩選元件，並且與工作項目和面板 的格線篩選體驗一致。 這個篩選控制項可改善您小組之所有成員的使用性和一致介面。

計劃的篩選

已更新的計劃導覽

您關心許多特定計劃或一組計劃內容，而且使用我的最愛快速存取內容。 首先，我們更新了計劃中樞，讓您可以巡覽到您最近瀏覽過的計劃，而不是目錄頁面。 其次，在之後，您可以使用慣用選擇器快速切換至另一個計劃，或使用階層連結巡覽回目錄頁面。

已更新的計劃導覽

展開/摺疊需求/工作面板上的人員

您現在只要按一下就可以在短期衝刺 [工作面板] 上展開或摺疊所有項目。

展開摺疊工作面板

將 bypassrule 權限授與特定使用者

通常，從另一個來源遷移工作項目時，組織想要保留工作項目的所有原始屬性。 例如，建議您建立可保留原始建立日期以及從來源系統依值建立的 Bug。

更新工作項目的 API 具有 bypassrule 旗標可啟用該情節。 先前，提出該 API 要求的身分識別必須是 Project Collection Administrators 群組的成員。 我們已新增在專案層級執行具有 bypassrule 旗標之 API 的權限。

授與 bypassrule

組建及版本

XAML 組建

在 TFS 2015 中，我們已引進網頁型跨平台組建系統。 TFS 2018 RTW 與 Update 1 中不支援 XAML 組建，但我們在 TFS 2018 Update 2 中重新啟用了 XAML 組建。 我們鼓勵您移轉 XAML 組建。

當您升級至 TFS 2018 Update 2 時：

  • 您的 Team 專案集合中如有任何 XAML 組建資料，將會收到 XAML 組建功能即將淘汰的警告。

  • 您將必須使用 VS 或 Team Explorer 2017 才能編輯 XAML 組建定義，或將新的 XAML 組建加入佇列。

  • 您若要建立新的 XAML 組建代理程式，必須使用 TFS 2015 組建代理程式安裝程式加以安裝。

如需 XAML 組建淘汰計畫的說明，請參閱「TFS/Team Services 建置自動化功能的演變」部落格文章。

多階段建置的增強功能

您已可使用不同的階段來組織建置步驟，並依據每個階段不同的需求來使用不同的代理程式。 我們為建置階段增加了幾項功能，因此，您現在可以：

  • 為每個階段指定不同的代理程式佇列。 例如，這表示您可以：

    • 在 macOS 代理程式上執行建置的一個階段，並在 Windows 代理程式上執行另一個階段。 若要查看這可以是多麼有用的酷炫範例，請參閱此 Connect(); 2017 視訊：行動應用程式和服務的 CI/CD DevOps 管線。
    • 在組建代理程式集區上執行建置步驟，並在測試代理程式集區上執行測試步驟。

  • 平行執行測試，以更快速地執行測試。 任何平行處理原則已設定為「多代理程式」且包含 "VSTest" 工作的階段，現在都會自動平行處理已設定代理程式計數的測試執行。

  • 允許或拒絕指令碼存取每個階段的 OAuth 權杖。 這表示，例如，您現在可以允許在建置階段中執行指令碼，以透過 REST API 與 VSTS 通訊，並在相同的組建定義中封鎖在測試階段中執行指令碼。

  • 只在特定情況下執行階段。 例如，您可以設定階段只在上一個階段成功時執行，或只在主分支中建置程式碼時執行。

若要深入了解，請參閱建置和發行管理的階段。

在存放庫中未進行變更時略過排定的建置

透過常用要求，您現在可以指定當未變更程式碼時，不執行排程的建置。 您可以使用排程的選項來控制這個行為。 如果您上次排定的建置成功 (從相同的排程)，而且未將進一步的變更簽入存放庫，則預設不會排定新的建置。

具有從 GitHub Enterprise 之持續整合的建置

如果您使用 GitHub Enterprise 進行版本控制，則現在會有可執行持續整合 (CI) 建置的較佳整合。 先前，您只能使用外部 Git 連接器輪詢程式碼變更，這可能會增加您伺服器上的負載並導致觸發組建之前的延遲。 現在，使用官方 GitHub Enterprise 支援，會立即觸發小組 CI 建置。 此外，您還可以使用各種驗證方法 (例如 LDAP 或內建帳戶) 來設定連線。

GitHub Enterprise 組建來源選項

在建置或發行期間，可以將安全檔案下載至代理程式

新的下載安全檔案工作支援從 VSTS 安全檔案程式庫下載 (至代理程式電腦) 加密檔案。 下載檔案時，會將檔案進行解密並儲存在代理程式的磁碟上。 建置或發行完成時，會從代理程式中刪除檔案。 這可讓您的建置或發行使用安全地加密和儲存於 VSTS 中的敏感檔案 (例如憑證或私密金鑰)。 如需詳細資訊，請參閱安全檔案文件。

可以從來源存放庫安裝 Apple 佈建設定檔

安裝 Apple 佈建設定檔工作已經支援安裝 (於代理程式電腦上) VSTS 安全檔案程式庫中所儲存的佈建設定檔。 佈建設定檔是供 Xcode 用來簽署和封裝 Apple 應用程式，例如 iOS、macOS、tvOS 和 watchOS。 現在，可以從原始程式碼存放庫安裝佈建設定檔。 建議透過使用安全檔案程式庫來獲得這些檔案的更高安全性，這項改善解決原始檔控制中所儲存的佈建設定檔。

Apple 佈建

追蹤使用組建標記之建置的 GitHub 來源

GitHub 或 GitHub Enterprise 中的組建已連結至相關認可。 能夠追蹤建置認可的組建也同樣重要。 現在可以在 TFS 中啟用來源標記，便能達成此目的。 在組建定義中選擇 GitHub 存放庫時，請選取您要標記的組建類型，以及標記格式。

標記來源選項

然後監看式組建標記會顯示在您的 GitHub 或 GitHub Enterprise 存放庫上。

GitHub 中的標記來源範例

在建置和發行期間可以安裝特定 Java 開發套件 (JDK)

若要建置特定 Java 專案，可能需要特定 JDK 但其無法在代理程式電腦上使用。 例如，專案可能需要較舊或不同版本的 IBM、Oracle 或開放原始碼 JDK。 Java 工具安裝程式工作會在建置或發行期間下載並安裝專案所需的 JDK。 在建置或發行期間，據此設定 JAVA_HOME 環境變數。 使用檔案共用、原始程式碼存放庫或 Azure Blob 儲存體的 Java 工具安裝程式各有其專用的 JDK。

改善的 Xcode 組建組態

Xcode 工作已更新為新的主要版本 (4.*)，以改善 Xcode 建置、測試和封裝的組態。 如果 Xcode 專案具有單一共用配置，則會自動使用此專案。 已新增其他內嵌說明。 已從 Xcode 工作屬性中移除已淘汰功能 (例如 xcrun 封裝)。 現有的組建和發行定義必須修改才能使用這個最新 4.* 版本的 Xcode 工作。 針對新定義，如果您需要舊版 Xcode 工作的已淘汰功能，則可以在定義中選取該版本。

發行閘道

持續監視是 DevOps 管線不可或缺的一部分。 部署是部署流程成功的重要關鍵之後，確定發行中的應用程式健全。 企業現已採用各種工具，自動偵測生產環境中 App 的健康狀態，以及追蹤客戶回報的事件。 到目前為止，核准者必須先從所有系統手動監視應用程式的健康狀態，再提升發行。 不過，Release Management 現在支援將持續監視整合到發行管線。 使用此選項確保系統重複查詢應用程式的所有健康訊號，直到它們全部同時成功，再繼續發行。

您是從在發行定義中定義預先部署或部署後管制開始。 每個管制都可以監視一或多個對應至應用程式監視系統的健康狀態訊號。 有「Azure 監視器 (應用程式見解) 警示」和「工作項目」可用的內建管制。 您可以使用透過 Azure 函式所提供的彈性，以與其他系統整合。

管制的發行

在執行時間，「發行」會開始對所有管制進行取樣，並從所有管制收集健康訊號。 它會依每個間隔重複取樣，直到相同間隔內收集自所有管制的訊號都成功為止。

取樣間隔

監視系統中的初始範例可能不正確，因為新部署的可用資訊不足。 [評估前的延遲] 選項可確保即使所有樣本都成功，也不會在此期間進行發行。

在取樣管制期間，未使用代理程式或管線。 如需詳細資訊，請參閱發行管制文件。

根據觸發發行的成品選擇性地進行部署

多個成品來源可以新增至發行定義並設定成觸發發行。 任一個來源有可用的新組建時，會建立新的發行。 無論由何種來源觸發發行，都會執行相同的部署程序。 您現在可以根據觸發來源來自訂部署流程。 對於自動觸發的發行，現在會填入發行變數 Release.TriggeringArtifact.Alias 以識別觸發發行的成品來源。 這可以用於工作條件、階段條件和工作參數，以動態調整流程。 例如，您只需要部署環境中變更的成品。

管理實體特定安全性

先前，在以角色為基礎的安全性中，設定安全性存取角色時，已為部署群組、變數群組、代理程式佇列和服務端點之中樞層級的使用者或群組設定它們。 您現在可以開啟和關閉特定實體的繼承，讓您可以透過想要的方式設定安全性。

安全性對話方塊

核准多個環境

管理含發行的核准現在更為簡單。 如果管線具有平行部署之多個環境的相同核准者，則核准者目前需要個別處理每個核准。 使用此功能，您現在可以同時完成多個擱置核准。

核准多個環境

發行範本擴充性

發行範本可讓您建立開始定義發行流程的基準。 先前，您可以將新的範本上傳至帳戶，但建立者現在可以在自己的延伸模組中包含發行範本。 您可以在 GitHub 存放庫上找到範例。

條件式發行工作和階段

與條件式建置工作類似，您現在只有在符合特定條件時才能執行工作或階段。 這將協助您模型化復原情節。

若內建條件不符合您的需求，或您需要更精細地控制工作或階段的執行，可以指定自訂條件。 將條件表示為一組巢狀函式。 代理程式會評估最內層函式，並往外運作。 最終結果是決定是否要執行工作的布林值。

條件式發行階段

服務端點的要求歷程記錄

透過服務端點就能夠與外部和遠端服務連線，以執行組建或部署的工作。 端點設定於專案範圍並在多個組建與發行定義之間共用。 服務端點擁有者現在可以透過端點獲取組建與部署的合併檢視，有利於加強稽核及管控。

端點要求歷程記錄

Git 和 GitHub 成品類型的預設屬性現在可供編輯

您現在甚至可以在連結成品之後，編輯 Git 和 GitHub 成品類型的預設屬性。 如果成品穩定版本的分支已變更，而且未來的持續傳遞發行應該使用此分支來取得成品的較新版本，則這特別有用。

啟用成品屬性

從發行檢視手動大量部署環境

您現在可以同時對多個發行環境手動觸發部署動作。 這可讓您在一次發行中選取多個有失敗組態或部署的環境，只要操作一次就能重新部署到所有環境。

大量部署

從 Jenkins 使用專案甚至會更好。

首先，您現在可以使用 Jenkins 多分支管線專案作為發行定義中的成品來源。

其次，雖然您先前只可以從 Jenkins 伺服器根資料夾連結 Jenkins 專案作為成員，但是現在可以在資料夾層級整理時使用 Jenkins 專案。 在您可以從中選取要作為成品來源之專案的來源清單中，您會看到 Jenkins 專案清單和資料夾路徑。

Jenkins 資料夾層級

Docker Hub 或 Azure Container Registry 作為成品來源

這項功能可讓發行使用 Docker Hub 登錄或 Azure Container Registry (ACR) 中所儲存的映像。 這是支援下列情節的第一個步驟：例如使用 ACR 異地複寫功能依區域逐一推出新變更，或從映像只適用於生產環境的容器登錄中部署至環境 (例如生產環境)。

您現在可以設定 Docker Hub 或 ACR，作為發行定義之 [+ 新增] 成品體驗中的第一級成品。 現在必須手動或由其他成品觸發發行，但我們期望根據將新映像推送至登錄的快慢來新增觸發程序。

Dockerhub 成品來源

預設成品版本

現在，將版本控制成品連結至發行定義時，有數個預設版本選項。 您可以設定特定認可/變更集，或只需要設定要從預設分支挑選的最新版本。 您一般會設定它來挑選最新版本，但這特別適用於需要為所有未來持續部署指定最佳成品版本的一些環境。

預設成品版本

發行觸發程序分支增強功能

您現在可以根據組建定義中所指定的預設分支來設定發行觸發篩選。 如果您的預設組建分支變更每個短期衝刺，並且需要更新所有發行定義的發行觸發篩選，則這特別有用。 現在，您只需要變更組建定義中的預設分支，所有發行定義就會自動使用此分支。 例如，如果您的小組會建立每個短期衝刺發行承載的發行分支，則在組建定義中進行更新以指向新的短期衝刺發行分支，發行就會自動反映。

發行觸發程序

套件管理成品的發行觸發程序

您現在可以在發行定義的 [套件管理] 成品上設定觸發程序，因此發佈新版的套件時會自動建立新發行。 如需詳細資訊，請參閱 Release Management 中觸發程序的文件。

將變數群組的範圍設為特定環境

先前，將變數群組新增至發行定義時，其中所含的變數可用於發行中的所有環境。 您現在也可彈性選擇是否要將變數群組限縮在特定環境。 如此一來，相同的發行中，就只有一個環境可以使用這些群組，其他環境則無法使用。 您有環境之間不同的外部服務 (例如 SMTP 電子郵件服務) 時，這十分適合。

連結變數群組

自動從 Azure Container Registry 和 Docker Hub 發行

部署容器化應用程式時，會先將容器映像推送至容器登錄。 推送完成之後，可以將容器映像部署至 Containers 或 Kubernetes 叢集的 Web 應用程式。 您現在可以在 Docker Hub 或 Azure Container Registry 所儲存映像的更新上啟用自動建立發行，方法是將它們新增為成品來源。

Azure Container Registry 作為來源

指定 Jenkins 成品的預設版本

自動觸發具有多個成品的發行時，所有成品都會反映發行定義中所儲存的預設版本。 先前，Jenkins 成品沒有預設版本設定，因此您無法在使用 Jenkins 作為次要成品的發行上設定持續部署觸發程序。

您現在可以使用您熟悉的選項，為 Jenkins 成品指定預設版本：

  • 最新
  • 在建立發行時指定
  • 特定版本

Jenkins 成品的預設版本

參與延伸模組中的發行管制

發行管制可將資訊驅動的核准新增至發行管線。 在部署之前或之後重複收集一組健康狀態訊號，以判斷是否應該將發行升階到下一個階段。 提供一組內建管制，而且「叫用 Azure 函式」到目前為止已建議作為與其他服務整合的方法。 我們現在會簡化與其他服務整合的路由，並透過市集延伸模組新增管制。 您現在可以參與自訂管制工作，並將設定管制的增強體驗提供給發行定義作者。

深入了解授權管制工作。

使用部署群組調整虛擬機器部署規模

您現在已可使用部署群組，提供最新且健全的多電腦部署技術。 有了「部署群組」功能，就可以跨多部伺服器協調部署，並執行輪流更新，同時確保整個應用程式的高可用性。 您也可以部署到內部部署伺服器、Azure 上的虛擬機器或任何雲端，並能針對已經部署的成品版本，端對端地向下追蹤到伺服器層級。

代理程式型部署功能依賴已推出的相同組建和部署代理程式。 您可以在部署群組階段中，於目標電腦上使用完整工作目錄。 以擴充性觀點而言，您還可以針對部署群組和目標使用 REST API，以程式設計方式進行存取。

套件

使用上游來源順暢地使用公用套件

現在提供 nuget.org 和 npmjs.com 的上游來源。 優點包含管理 (未列出、淘汰、解除發佈、刪除等等) 上游來源中所儲存套件的能力，以及保證儲存您使用的每個上游套件。

npmjs 上游

TFS 摘要中的保留原則

截至目前為止，TFS 套件仍未提供任何方法來自動清理較舊未使用的套件版本。 對於常見套件發行者，除非手動刪除一些版本，否則這可能導致 NuGet 套件管理員和其他用戶端中有速度較慢的摘要查詢。

我們現在已啟用 TFS 摘要的保留原則。 只要一到達保留期閾值，保留原則就會自動刪除最舊版本的套件。 提升至檢視的套件會無限期保留，讓您能夠保護用於生產環境或廣泛用於您組織的版本。

若要啟用保留原則，請編輯摘要，並在 [保留原則] 區段的 [Maximum number of versions per package號] \(每個套件的最大版本編) 中輸入值。

retention

套件管理中的篩選

[套件] 頁面已更新成使用標準版面配置、命令列控制和新的標準篩選列。

套件 UX 統一篩選列

使用徽章共用套件

在開放原始碼社群中，常會使用徽章連結到您存放庫之讀我檔案中套件的最新版本。 您現在可以在摘要中建立套件的徽章。 只要核取摘要設定中的 [Enable package badges] \( (啟用套件徽章)) 選項，並選取套件，然後按一下 [Create badge] \(建立徽章)。 您可以直接複製徽章 URL，或複製將徽章重新連結回套件詳細資料頁面的預先產生 Markdown。

建立套件徽章

舊版套件現在是整頁清單

我們收到已更新套件管理體驗的大量意見，其中我們將舊版套件清單移至套件詳細資料頁面上的階層連結選擇器。 我們已新增 [版本] 樞紐，以帶入舊版本相關資訊，並且可更輕鬆地複製版本號碼，或取得舊版本的連結。

版本清單

檢視套件清單中套件版本的品質

在套件清單上，您現在可以看到每個套件版本的檢視，快速判斷其品質。 如需詳細資訊，請參閱發行檢視文件。 如需詳細資訊，請參閱文件。

套件清單中的檢視

Gulp、Yarn 和其他已驗證摘要支援

npm 工作現在與已驗證 npm 摘要密切搭配運作 (在 [套件管理] 或 npm Enterprise 和 Artifactory 等外部登錄中)；但是到目前為止，使用 Gulp 這類工作執行器或 Yarn 這類替代 npm 用戶端十分具挑戰性，除非該工作也支援已驗證摘要。 我們已新增新的 npm 驗證建置工作，可將認證新增至 .npmrc，讓後續工作可以成功使用驗證過的摘要。

驗證摘要

套件摘要預設權限現在包含 Project Administrators

過去，建立摘要時會設定將使用者建立為唯一摘要擁有者，如果該使用者變換小組，或離開組織，則這可能會導致大型組織中的管理挑戰。 為了移除這個單一失敗點，建立摘要時現在會利用使用者的目前專案內容來取得 Project Administrators 群組，同時將它設為摘要擁有者。 與任何權限相同，您可以移除這個群組，並使用摘要設定對話方塊進一步自訂摘要權限。

回收和還原套件

刪除未使用的套件可協助確保乾淨的套件清單，但有時也可能是錯誤所造成。 您現在可以從資源回收筒 還原已刪除的套件。 已刪除的套件會在資源回收筒保留 30 天，讓您有充裕的時間可在需要時還原。

套件資源回收筒

過去您雖然可以將 URL 分配給在套件中樞內找到的套件使用，但因為您必須在 URL 中加入專案，而這未必適用於使用該連結的套件，所以應用上大多有困難。 透過此更新，您現在可以使用 URL 來共用套件，而 URL 將自動選取收件者可存取的專案。

URL 格式為：`https://<TFSserverURL>/_packaging?feed=<feed>&package=<package>&version=<version>&protocolType=<NuGet|Npm|Maven>&_a=package`

除了 `<TFSserverURL>` 以外，所有參數皆非必要，但若是提供套件，就必須提供通訊協定類型。

Test

Visual Studio 測試工作不需要完整 Visual Studio

建置/發行中的 Visual Studio 測試工作需要代理程式上的 Visual Studio 才能執行測試。 請使用新的 Visual Studio 測試平台安裝程式工作，而不是安裝 Visual Studio 以在生產環境中執行測試，或只將測試散發到多個代理程式。 此工作需要 nuget.org 中的測試平台，並將它新增至工具快取。 安裝程式工作滿足 vstest 需求，並且可以執行定義中的後續 Visual Studio 測試工作，而不需要在代理程式上完整安裝 Visual Studio。

從工作目錄中，在定義中新增安裝程式工作。

平台安裝程式工作

設定後續 Visual Studio 測試工作，以使用透過安裝程式所獲得的位元。

測試平台版本

注意

限制：Nuget 上的測試平台套件目前不支援執行自動程式化 UI 測試。 在待辦項目上啟用自動程式化 UI 測試支援。 NuGet 上的測試平台套件是跨平台的，但 VSTest 工作目前不支援執行 .NET 核心測試。 若要執行 .NET 核心測試，請使用 'dot net' 工作。

現在已淘汰執行功能測試和部署測試代理程式工作

去年，我們開始統一建置、發行和測試的代理程式的旅程。 這是要解決與使用 WinRM 型部署測試代理程式和執行功能測試工作建立關聯的各種痛點。 它也可讓您將 Visual Studio 測試 (VSTest) 工作用於所有測試需求，包含：

  • 單元測試
  • 功能 (UI/非 UI) 測試
  • MSTest 型測試
  • 第三方架構型測試
  • 組件型測試規格，或使用測試計劃/測試套件來執行測試
  • 單一代理程式執行測試，以及將測試散發到多個代理程式

統一代理程式的作法，也讓系統管理員可以使用一致的方式管理用於執行 CI/CD 的電腦。

Visual Studio 測試工作

我們已提供數個重要部分來啟用這項功能，包含：

有了上述所有項目之後，我們就準備好淘汰這兩個工作。 使用已淘汰工作的現有定義會繼續運作時，建議您移至使用 VSTest 以善用一段時間的持續增強。

篩選大型測試結果

經過一段時間之後會累積測試資產，而且大型應用程式很容易便形成數千個測試。 小組會尋找更好的方式來巡覽大量測試結果，以在識別測試失敗、相關聯根本原因或擁有權問題時更具生產力。 為了達到此目的，我們已在 [建置及發行] 的 [測試] 索引標籤下新增三個新篩選：[測試名稱]、[容器] \(DLL\) 和 [擁有者] \(容器擁有者\)。

依測試名稱篩選測試

此外，現有的 [結果] 篩選現在可篩選多個結果。 在本質上，篩選準則是累加的。 當使用者想要查看剛才認可的變更，是否出現在測試結果中時，可以篩選容器 (DLL 名稱)、擁有者 (DLL 擁有者)、測試名稱或上述所有項目，獲取與使用者相關的結果。

篩選測試結果

識別不穩定測試

測試有時不穩定 - 它們在某個回合失敗，而在另一個回合成功，而不需要任何變更。 不穩定測試很令人沮喪，並且破壞測試有效性的信心，因而導致忽略失敗並使得錯誤 (bug) 通過測試。 我們在此更新中部署了解決方案的第一個部分，協助解決不穩定測試問題。 您現在可以設定 Visual Studio 測試工作重新執行失敗的測試。 測試結果接著會指出哪些測試一開始就失敗，然後在重新執行時成功。 之後將支援重新執行資料導向和排序的測試。

Visual Studio 測試工作可以設定成控制重新執行失敗測試嘗試次數上限和失敗閾值百分比 (例如，僅限低於所有測試的 20% 失敗時重新執行測試)，避免在廣域分散失敗時重新執行測試。

重新執行失敗測試區段

在 [建置及發行] 的 [測試] 索引標籤下，您可以篩選 [結果] 為 [重新執行時傳遞] 的測試結果，以識別測試回合期間有不穩定行為的測試。 針對重新執行時成功的每個測試，這目前會顯示測試的上次嘗試。 [摘要] 檢視也修改成在 [測試總計] 下顯示 [重新執行時傳遞 (n/m)]，其中 n 是重新執行時的成功測試計數，而 m 是成功測試總計。 所有嘗試的階層檢視都會出現在接下來幾個短期衝刺。

重新執行失敗測試結果

Visual Studio 測試工作所產生之不同記錄類型的預覽增強功能和支援

我們加強 VSTest 工作來發佈不同種類的記錄陳述式所產生的記錄，而這些陳述式對應至失敗測試的標準輸出和標準錯誤。 我們也已改善預覽體驗來支援檢視文字和記錄檔格式，並且可以在記錄檔中進行搜尋。

Wiki

您可以依程式碼和工作項目右側的標題或內容來搜尋最愛的 Wiki 頁面。 您可以深入閱讀 Microsoft DevOps 部落格中的 Wiki 搜尋。

Wiki 可以用於各種內容。 有時可用來列印 Wiki 中要在備用時間讀取的內容、使用筆和紙張新增註解，甚至與 VSTS 專案外部的 PDF 複本共用離線 PDF 複本。 現在，只要按一下頁面的操作功能表，並選取 [列印頁面]。

Wiki 功能表列印頁面選項

注意

Firefox 上目前不支援這項功能。

使用鍵盤快速鍵輕鬆地參與 Wiki 頁面

您現在可以使用快速鍵在 Wiki 中執行常見編輯和檢視動作，其甚至比只使用鍵盤還要快速。

檢視頁面時，您可以新增、編輯或建立子頁面，例如：

Wiki 檢視鍵盤快速鍵快顯視窗

編輯頁面時，您可以快速儲存、儲存並關閉或只關閉。

Wiki 編輯鍵盤快速鍵快顯視窗

這些是標準編輯快速鍵 (例如 Ctrl+B 表示粗體、Ctrl+I 表示斜體、Ctrl+K 表示連結等) 以外的快速鍵。如需詳細資訊，請參閱鍵盤快速鍵的完整清單。

程式碼存放庫 Markdown 中的豐富 Markdown 轉譯

您現在可以在程式碼存放庫中建立豐富的 README.MD 檔案。 程式碼存放庫中 MD 檔案的 Markdown 轉譯現在支援 HTML 標記、區塊引號、Emoji、調整影像大小和數學公式。 在程式碼的 Wiki 和 MD 檔案中，Markdown 轉譯有同位。

Wiki 支援數學公式

如果您的應用程式處理數學公式和方程式，則現在可以使用 LaTeX 格式將它們放入 Wiki。

Wiki 數學

在 Wiki 中參考工作項目

您現在可以按 '#' 鍵取得一份最近存取的工作項目清單，並選取感興趣的工作項目，以在 Wiki 頁面中參考工作項目。 寫入版本資訊、Epic、規格或需要參照工作項目的其他頁面時，這特別有用。

在 Wiki 中參考工作項目

您現在可以將工作項目連結至 Wiki，反之亦然。 您可以連結工作項目與 Wiki，以建立 Epic 頁面與版本資訊，以及規劃內容協助您追蹤 Wiki 頁面所關聯的工作項目，以及驗證 Epic 頁面的完成率。

從工作項目連結 Wiki

已連結工作項目，然後顯示於 Wiki 頁面上。

Wiki 頁面上的已連結工作項目

透過新的 [Wiki 頁面] 連結類型，從工作項目新增 Wiki 頁面的連結。

從工作項目連結至 Wiki

Ctrl+S 可儲存 Wiki 頁面

我們聽到您想要使用更快速且更輕鬆的方法來儲存 Wiki 頁面。 您現在只需要使用 Ctrl+S 鍵盤快速鍵即可使用預設修訂訊息來儲存頁面，並繼續編輯。 若要新增自訂修訂訊息，只須按一下儲存按鈕旁的＞形箭號。

Wiki 儲存

將豐富的 Wiki 內容貼入為 HTML

您現在可以從任何瀏覽器應用程式 (例如 Confluence、OneNote、SharePoint 和 mediawiki) 貼上 Wiki 之 Markdown 編輯器中的豐富文字。 這特別適用於已建立豐富內容 (例如複雜資料表) 並且想要將它顯示於 Wiki 的人員。 只要複製內容，並將它貼入為 HTML。

Wiki 豐富內容作為 HTML

使用鍵盤在 Wiki 中移動頁面

稍早在 Wiki 中，使用者無法使用鍵盤重新排序或重設頁面的父系，而且這會影響偏好進行鍵盤作業的使用者。 您現在可以使用 Ctrl + 向上鍵或 Ctrl + 向下鍵命令來重新排序頁面。 您也可以按一下頁面之操作功能表中的 [移動頁面] 來重新設定頁面的父系，並選取要移動的新父頁面。

移動 Wiki 頁面

移動 Wiki 頁面對話方塊

篩選文字醒目提示

篩選 Wiki 中的瀏覽窗格會顯示整個頁面階層。 例如，如果您篩選標題為 "foobar" 的頁面，則已篩選的瀏覽窗格也會顯示所有父頁面。 這可能會造成混淆，因為標題不是 "foobar" 的頁面也顯示在已篩選的結果集中。 現在，篩選 Wiki 中的內容將會醒目提示所搜尋的文字，以清楚了解已篩選的標題以及未篩選的標題。

篩選 Wiki 中的文字醒目提示

您也可以在所有程式碼瀏覽窗格中觀察到類似行為。 例如，提取要求、認可、變更集和擱置集中的檔案瀏覽窗格。

篩選 PR 中的文字醒目提示

在編輯 Wiki 頁面時預覽內容

資料顯示使用者幾乎一律會在編輯內容時多次預覽 Wiki 頁面。 針對每個頁面編輯，使用者平均會按一下 [預覽] 1-2 次。 這樣會導致較慢和次佳的編輯體驗，而且對於 Markdown 的新編輯特別耗時。 您現在可以在編輯時看到您頁面的預覽。

Wiki 預覽

一般

設定檔卡片

TFS 中有許多區域會顯示特定人員相關的資訊，但不限於特定人員所建立的提取要求，以及指派給特定人員的工作項目。 不過，個人本身的資訊有限，讓您無法取得完整內容。 新的設定檔卡片取代了 TFS 中的現有設定檔卡片。 已更新的設定檔卡片可讓您與 TFS 帳戶內的使用者互動，並深入了解這些使用者。 透過與預設電子郵件和 IM 用戶端的整合，Active Directory (AD) 使用者可以傳送電子郵件，並直接從設定檔卡片開始聊天。 AD 使用者也可以查看設定檔卡片內的組織階層。 設定檔卡片可以在專案首頁內予以啟用 - 小組成員區段、版本控制、工作項目和 Wiki 區段，方法是按一下連絡人卡片圖示、設定檔圖片或註解內的使用者名稱。

設定檔卡片

圓形虛擬人偶

以下是圓形虛擬人偶！ 服務中的所有設定檔圖片現在都顯示在圓形中，而不是正方形。 例如，以下是這項變更的實際提取要求 (請注意循環、非方形虛擬人偶)。

圓形虛擬人偶

專案標記

您現在可以裝飾具有重要關鍵字 (標記) 的專案。 直接從專案首頁 (由系統管理員) 輕鬆地新增和刪除標記，允許使用者快速深入了解專案用途和範圍。 針對如何利用專案標記，我們有更深入的規劃，因此敬請期待更多的消息。

專案標記

重新排序我的最愛群組

您現在可以使用每個群組標頭中的向上鍵和向下鍵，在帳戶 [我的最愛] 頁面上重新排序群組。

重新排序我的最愛群組

意見反應與建議

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

頁首