共用方式為


Team Foundation Server 2018 版本資訊


開發人員社群 | 系統需求與相容性 | 授權條款 | 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 安裝頁面。


版本資訊圖示 發行日期:2017年11月15日

TFS 2018 新功能摘要

我們已為 Team Foundation Server 2018 新增許多新價值。 一些重點包括:

TFS 2018 中的新功能影片

XAML 組建

我們原先在 TFS 2018 RTW 及 Update 1 中將 XAML 組建列為已移除項目。 但是,這使得很多客戶無法升級,或是必須在升級完成後連絡支援人員才能再次加以啟用。 在 TFS 2018 Update 2 中,XAML 組建已啟用,但已淘汰。 這表示我們不會再為 XAML 組建提供支援,且 Microsoft Test Manager (MTM) 也不再支援使用 XAML 組建。 我們強烈建議您轉換至其中一個較新的組建定義格式。 您仍可使用 TFS 2018 Update 2 繼續連線至 XAML 控制器並執行 XAML 組建。 詳細資訊

TFS 2018 RTW 中已移除的功能


TFS 2018 新功能詳細資料

工作項目追蹤

Web 上的專案建立精靈

我們已改善從 Web 存取建立 Team 專案的體驗。 現在,它包含大多數功能,就像您在 Visual Studio 客戶端中建立 Team Project 時所能使用的功能一樣。 使用 Web 介面的優點是您不需要相符的 Visual Studio 版本。 使用 Visual Studio 或 Web 版本的差異在於 Web 版本不會在 SSRS 中佈建您的報表。 如果您已使用 Web 版本建立 Team 專案,則可以在應用程式層執行 tfsconfig 命令,以佈建或更新 SSRS 報表。

Web 上的流程範本管理員

運用 TFS 2018,您可以使用 Web 存取來上傳流程範本。 Web 介面是較簡單的體驗,因為您不需要安裝正確版本的 Visual Studio 即可與流程範本互動。 Visual Studio 2017 Update 4 和以下版本仍然會顯示 [流程範本管理員] 對話方塊,但是建議使用 Web 介面。 Visual Studio 2017 Update 5 和更新版本會自動將您重新導向到 Web。

自訂工作項目表單標頭

您現在可以透過取代現有的控制項或隱藏與程序無關的控制項,來自訂工作項目表單頁首區域。 您可以將「區域路徑」替換為自訂的「小組」欄位,如果您的小組更偏向看板方法,可以隱藏「反覆項目」,並將「原因」替換為自訂欄位。 [狀態] 欄位無法隱藏或取代。

提示

如需詳細資訊,請參閱WebLayout 和控制項項目文件

行動工作項目表單

我們擁有完整的端到端體驗,包含為工作項目最佳化的外觀和使用感 (圖 1)。 它提供了一種簡單的方式,讓您能夠透過手機輕鬆與指派給您的項目互動,包括您正在追蹤的、最近瀏覽過的或編輯過的項目。

行動工作項目查詢
(圖 1) 行動工作項目查詢

除了有不錯的外觀之外,這項體驗還支援所有欄位類型的最佳化控制項 (圖 2)

行動工作項目表單
(圖 2) 行動工作項目表單

使用新的行動裝置導航 (圖 3) 時,使用者可以造訪 TFS 的任何其他行動可用部分,並在需要與其他中樞互動時回到完整的桌面網站。

行動流覽
(圖 3) 行動巡覽

依待辦項目、工作流程看板、短期衝刺和查詢篩選

所有工作項目追蹤格線體驗 (查詢、待辦項目、工作流程看板、短期衝刺待辦項目和測試案例管理) 現在都會利用通用且一致的篩選元件 (圖 4)。 除了將關鍵字篩選套用至顯示的資料行以及選取標記之外,您也可以依工作項目類型、狀態和指派對象進行篩選,以快速到達您要尋找的工作項目。

對查詢進行篩選
圖 4 查詢篩選

展開以顯示看板卡片上的空白欄位

您現在可以選擇在卡片中新增其他欄位,然後在面板設定中「隱藏空欄位」(圖 5),以移除板中不必要的混亂。 這項功能的缺點是隱藏空的欄位之後,更新欄位的唯一方式就是開啟工作項目表單。 使用看板卡片的新展開選項,您現在可以受益於在整個看板中隱藏空欄位,但仍然可以透過一次點擊快速更新卡片上的特定欄位。 只需要將滑鼠游標暫留在卡片上方,並尋找卡片底部的向下>形箭號,即可更新隱藏欄位。

隱藏欄位
(圖 5) 看板卡片上的隱藏欄位

按一下卡片底部的向下山形箭號,以更新欄位 (圖 6)

更新隱藏欄位
(圖 6) 更新看板卡片上的隱藏欄位

擴充套件封鎖工作項目儲存

工作項目表單自訂控制項、群組和頁面現在可以封鎖工作項目儲存來驗證資料,並確定使用者先填寫任何必要資訊,再儲存工作項目表單。

即時添加於交付計劃

新功能的想法會隨時出現,因此我們讓您能更輕鬆地直接將新功能新增至傳遞計劃 (圖 7)。 只要按一下動態顯示取得的 [新增項目] 按鈕、輸入名稱,再按 Enter 鍵即可。 建立了一項新功能,並具備您所預期的區域路徑和迭代路徑。

傳遞方案的內嵌附加元件
(圖 7) 內嵌新增功能於傳遞計劃

版本控制

分支

TFS 2018 新增 Git 分支支援 (圖 8)。 「分支」是存放庫的伺服器端複本。 使用分支,您可以允許更多人參與您的存放庫,而不需授與其直接認可存取權。 相反地,他們會將其工作認可到其在存放庫中的專屬分支。 這可讓您有機會先在提取要求中檢閱其變更,再將這些變更接受至中央存放庫。

Git 派生
(圖 8) Git 分支

GVFS

現在支援 Git 虛擬檔案系統 (GVFS)。 GVFS 可透過虛擬化和最佳化 Git 在檔案系統上的運作方式,讓 Git 存放庫放大至數百萬個檔案。

在使用 Web 的存放庫中建立資料夾

您現在可以透過 Git 和 TFVC 存放庫中的 Web 建立資料夾 (圖 9)。 這會取代資料夾管理延伸模組,目前正在進行淘汰程序。

若要建立資料夾,請按下 命令行或操作功能表中的 [新增 > 資料夾 ]:

[新增資料夾] 選項
(圖 9) [新增資料夾] 選項

若為 TFVC,您要指定資料夾名稱,然後將它簽入。 若是使用 Git,因為不允許空的資料夾,所以您必須指定檔案名稱,可以選擇性地編輯檔案,然後提交。

此外,[新增檔案] 對話方塊 (圖 10) 已針對 Git 改進,以接受斜線來創建子資料夾。

[新增檔案] 對話方塊
(圖 10) [新增檔案] 對話方塊

檔案縮圖

現在,您可以在檢視或編輯檔案時查看它的迷你地圖,以快速了解程式碼概覽 (圖 11)。 若要開啟迷你地圖,請開啟 [命令選擇區](F1 或按一下滑鼠右鍵) 並選取 [Toggle Minimap] (切換迷你地圖)

檔案縮略圖
(圖 11) 檔案迷你地圖

括弧比對

編輯或檢視檔案時,現在左側有指導方針方便您比對括弧 (圖 12)

括弧比對
(圖 12) 括弧比對

切換空白

現在檢視或編輯檔案時,可以切換開啟和關閉空白字元。 我們仍在開發一項功能,讓您在比對差異時切換顯示空白字元。 若要檢視空白字元 (圖 13),請開啟 [命令選擇區]\(F1 或按一下滑鼠右鍵) 並選取 [切換空白字元],讓您區分空格和定位點。

切換空格
(圖 13) 切換空白區域

關閉 TFVC 存放庫 Web 編輯的設定

使用 TFVC 的小組通常會在 Visual Studio 中使用簽入原則,確保程式碼品質。 不過,因為簽入原則是在用戶端上強制執行,所以在 Web 上編輯的程式碼不會受限於相同的原則。

有許多人要求提供一種方法來停用網頁編輯功能,以防止略過檢查原則的變更。 我們已提供一種方式,讓您能夠根據專案/存放庫來停用 TFVC 的 Web 編輯功能(包括新增、刪除、重新命名和編輯)。

若不允許從 [檔案] 頁面進行 Web 編輯,請依序前往 [設定] 和 [版本控制] (圖 14)。 按一下樹狀檢視中的 TFVC 存放庫,瀏覽至 [選項窗格],然後取消勾選 [啟用此 TFVC 存放庫的 Web 編輯]。 根據預設,會啟用 Web 編輯。

注意

[專案概觀] 頁面 編輯 README 檔案不會受到影響。

關閉 Web 編輯
(圖 14) 關閉 Web 編輯

如果您嘗試在已停用 Web 編輯的專案中進行 Web 編輯,則系統會通知您不允許進行 Web 編輯 (圖 15)

不允許網頁編輯對話框
(圖 15) [不允許 Web 編輯] 對話方塊

識別過時分支

刪除您不再需要的分支來保持乾淨的存放庫,可讓小組尋找他們關心的分支,以及以正確的細微性來設定我的最愛。 不過,如果您的存放庫中有許多分支,則可能很難找出非使用中且可刪除的項目。 我們現在可以輕鬆地識別「過時」分支 (指向 3 個月以上之認可的分支)。 若要查看您的過時分支,請移至 [分支] 頁面上的 [過時] 樞紐 (圖 16)

過時的分支
(圖 16) 過時分支

搜尋並重新建立已刪除的分支

不小心從伺服器刪除分支時,可能很難找出它發生什麼情況。 您現在可以搜尋已刪除的分支、看到誰和何時刪除它,並在需要時重新建立。

若要搜尋已刪除的分支,請在分支搜尋方塊中輸入完整分支名稱。 這會傳回與該文字匹配的任何現有分支。 您也會看到一個選項,可以在已刪除的分支清單中搜尋完全相符的項目。 按一下此連結來搜尋已刪除的分支 (圖 17)

搜尋已刪除的分支
(圖 17) 搜尋已刪除的分支

如果找到相符項目,您會看到誰和何時刪除它。 您也可以還原分支 (圖 18)

還原已刪除的分支
(圖 18) 還原已刪除的分支

還原分支會在最後一個指向的認可處加以重新建立。 不過,它不會還原原則和權限。

在字首符合特定前綴的分支中搜尋提交

如果您有階層格式的分支架構,且所有分支的開頭都加上了一些文字,這個功能將協助您在所有這些以該文字為開頭的分支中找到提交。 例如,如果您想查看一個提交是否已到達所有以 "dev" 為前綴的分支,只需要在搜尋方塊中輸入 "dev",然後選取 在開頭為 "dev" 的分支中搜尋 (圖 19)

搜尋提交
(圖 19) 搜尋提交

提交詳情頁面的更豐富拉取請求說明

提交詳細資料頁面上的註解會顯示更多相關資訊,以便更深入地診斷 (圖 20)。 我們現在也會在說明中顯示將提交引入任何分支的第一個合併請求,以及與預設分支相關的合併請求

合併請求註標
(圖 20) 提取要求圖說文字

程式碼中的篩選樹狀檢視

現在,您不需要捲動所有可能因認可而修改的檔案,才能找到您自己的檔案。 認可詳細資料、提取要求、擱置集詳細資料,以及變更集詳細資料頁面上的樹狀檢視現在支援檔案和資料夾篩選。 此智慧篩選會在您依資料夾名稱篩選時顯示資料夾的子檔案,並在您依檔案名稱篩選時顯示檔案的摺疊樹狀檢視,以顯示檔案階層。

在提交樹上尋找檔案或資料夾篩選 (圖 21) 和 (圖 22)

尋找檔案或資料夾
(圖 21) 尋找檔案或資料夾
篩選的檢視
(圖 22) 提交樹的篩選檢視

分支更新頁面現在變為推送頁面

分支更新頁面具有極大的價值。 不過,它被隱藏在「歷程記錄」中心作為轉折點。 現在,分支更新頁面將會顯示在 程式碼 下,稱為 推送 的中樞(圖 23),以及 提交分支標籤拉取請求。 推送頁面的新 URL 為:\<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/pushes。 舊的 URL 仍會繼續運作。

切換頁面
(圖 23) 推送頁面

同時,[記錄] 頁面現在已重新命名為 [提交] (圖 24),因為此頁面只會顯示提交。 我們已收到來自下列人員的意見反應:因為認可清單檢視僅顯示詳細時間暫留,所以這些人員發現很難對認可相關問題進行疑難排解。 現在,實例的提交清單檢視將以 dd/mm/yy hh:mm 格式顯示日期和時間。 提交頁面的新 URL 為:\<tfsserverurl\>/\<projectname\>/_git/\<reponame\>/commits。 舊的 URL 仍會繼續運作。

提交頁面
(圖 24) 提交頁面

從檔案移至提交紀錄時保留檔案名稱

有些人的意見反應是:當他們將目錄篩選至 [Code] 中樞的 [檔案] 分頁中的特定檔案,然後翻至 [歷史] 分頁時,如果提交變更超過 1,000 個檔案,檔案名稱並不會保持。 這導致人員必須載入更多檔案,並篩選內容來尋找檔案,因而影響生產力。 開發人員通常在相同的目錄中工作,並希望在追蹤變更時能保持所工作的目錄持續有效。 在 [程式碼] 中樞樞紐之間移動時,我們現在都會持續保存檔案名稱,不論認可中變更多少檔案數目。 這表示您不需要按一下 [載入更多] 即可找到您想要的檔案。

檢視 Git 標記

您可以在 [標記] 頁面 (圖 25) 檢視存放庫中的所有標記。 如果您將所有標記管理為發行,則使用者可以前往 [標記] 頁面,以取得所有產品發行的鳥瞰檢視。

檢視 Git 標記
(圖 25) 檢視 Git 標記

您可以輕鬆區分輕量標記和註釋標記。 已標註的標記會顯示標記者和建立日期及相關提交的資訊,而輕量標記只會顯示提交資訊。

刪除 Git 標記

您有時可能想要從遠端存放庫中刪除標記。 原因可能是標記名稱有錯字,或您可能已標記錯誤認可。 您可以從 Web UI 輕鬆刪除標記,方法是在 [標記] 頁面上按一下標記的操作功能表,並選取 [刪除標記] (圖 26)

警告

刪除遠端存放庫上的標記時需要特別小心。

刪除 git 標籤
(圖 26) 刪除 Git 標記

篩選 Git 標記

針對舊的存放庫,標記數目可能會隨著時間大幅成長;也會有已在階層中建立標記的存放庫,這讓尋找標記更為困難。

如果在 [標記] 頁面上找不到您要尋找的標記,您可以直接在 [標記] 頁面 (圖 27) 頂端使用篩選搜尋標記名稱。

篩選 Git 標籤
(圖 27) 篩選 Git 標記

Git 標記安全性

您現在可以將細微權限授與存放庫使用者以管理標記。 您可以將從這個介面 (圖 28) 刪除標記或管理標記的權限授與使用者。

Git 標籤安全性
(圖 28) Git 標記安全性

提示

Microsoft DevOps 部落格深入了解 Git 標記。

完成提取要求時自動完成工作項目

如果您要將工作項目連結至提取要求,則保持最新資訊會簡單一點。 現在,當您完成 PR 時,您將有選擇可以在成功合併 PR 之後自動完成已連結的工作項目(圖 29)。 如果您要使用原則,並將提取要求設定成自動完成,則會看到相同的選項。 完成提取要求之後,就不再需要重新瀏覽工作項目來更新狀態。 這會自動為您完成。

完成連結的工作專案
(圖 29) 完成連結的工作項目

重設對推送/反覆項目的投票

現在,選擇採用更嚴格核准工作流程的小組可以選擇在推送新變更時重設投票 (圖 30)。 新的設定是 [需要最少數目的檢閱者] 原則下的選項。

重設投票設定
(圖 30) 重設投票設定

設定時,只要更新 PR 的來源分支,這個選項就會重設來自所有檢閱者的所有投票。 只要因這個選項而重設投票,PR 時間軸就會記錄一個項目 (圖 31)

在時間軸中重設投票
(圖 31) 在時間軸中重置投票

以檔案名稱篩選拉取請求樹狀結構

在提取要求中尋找特定檔案比以往更為容易。 [檔案] 檢視中的新篩選方塊可讓使用者往下篩選樹狀檢視中的檔案清單 (圖 32)

在提取要求中尋找檔案或資料夾
(圖 32) 在提取要求中尋找檔案或資料夾

此篩選會比對提取要求中檔案路徑的任何部分,因此,您可以依資料夾名稱、部分路徑、檔案名稱或副檔名進行搜尋 (圖 33)

尋找結果
(圖 33) 尋找結果

其他提取要求註解篩選選項

提取要求概觀與檔案檢視中的註解現在都有相同的選項 (圖 34)。 您也可以篩選只查看您已參與的討論。

PR 批注篩選
(圖 34) PR 註解篩選

檢視提取要求詳細資料中程式碼註解的原始差異

有時候,當 PR 註解所參考的程式碼發生變更後(尤其是在執行了所要求的變更之後),就很難理解這些 PR 註解 (圖 35)

檢視原始差異
(圖 35) 檢視原始差異

發生這種情況時,您現在會看到包含更新編號的徽章,而按一下即可看到程式碼在註解一開始建立時的樣子 (圖 36)

更新徽章
(圖 36) 更新徽章

可摺疊的提取要求註解

檢閱程式碼是提取要求體驗的重要部分,因此我們新增功能讓檢閱者可以更輕鬆地專注於程式碼。 在第一次檢閱新程式碼時,程式碼檢閱者可以輕鬆隱藏註解,以便更清晰地查看 (圖 37)。

隱藏批注
(圖 37) 隱藏註解

隱藏註解 (圖 38) 會將其從樹狀檢視中隱藏,並摺疊檔案檢視中的註解討論串:

折疊的批注
(圖 38) 已摺疊的註解

註解在摺疊時,只要按一下邊緣的圖示即可輕鬆地展開,然後再按一下即可再次摺疊。 [工具提示] (圖 39) 可供輕鬆查看註解,而不會看到整個討論串。

折疊的批註工具提示
(圖 39) 已摺疊的註解提醒視窗

提取要求描述和註解中的工作清單

在準備 PR 或撰寫註解時,您有時會有一份想要追蹤的簡短項目清單,但最後卻變成編輯文字或新增多個註解。 輕量型工作清單是一個絕佳方式,可以在待辦事項清單中追蹤進度,無論是作為 PR 的建立者還是檢閱者,並且可在描述或合併的註解中進行追蹤。 按一下 Markdown 工具列以開始使用,或將格式套用至選取的文字 (圖 40)

工作清單工具列
(圖 40) [工作清單] 工具列

新增工作清單後 (圖 41),您只需要選取方塊,即可將項目標記為已完成。 這些是使用 Markdown 以 [ ][x] 形式表示並儲存在註解內。 如需詳細資訊,請參閱 Markdown guidance (Markdown 指引)。

工作清單
(圖 41) 工作清單

可以對拉取請求中的評論「按讚」

只要按一下 [讚] 按鈕,即可表達您對 PR 註解的支持 (圖 42)。 您可以將滑鼠游標暫留在按鈕上方,以查看對註解按讚的所有人員清單。

喜歡合併請求評論
(圖 42) 對提取要求註解按讚

改善核准建議時的工作流程

在提取要求使用 [自動完成] 選項 (圖 43) 是提高生產力的有效方法,但與程式碼檢閱者之間進行的討論不應該草率結束。 為了更好地促進這些討論,「附建議的批准」投票現在會在設定拉取請求為自動完成時提示。 使用者可以選擇取消自動完成,以讀取其意見反應,或設定自動完成,並允許在滿足所有原則時自動完成提取要求。

取消自動完成對話框
(圖 43) 取消自動完成對話方塊

Git 通知的路徑篩選支援

您現在可以選擇在小組成員只在所關心資料夾中建立提取要求或推送程式碼時收到通知,而不是收到存放庫中所有資料夾的通知。 建立自訂 Git 推送或 Git 提取要求電子郵件通知訂閱時會顯示新選項,可讓您依資料夾路徑篩選這些通知 (圖 44)

通知的路徑篩選
(圖 44) 通知的路徑篩選

已更新提取要求工作流程的電子郵件範本

提取要求電子郵件警示已經過更新,使其更加清楚、精簡且易於操作 (圖 45)。 主旨行的開頭現在是 PR 標題,而次要資訊 (例如存放庫名稱) 和識別碼則會延遲到結尾。 主旨中新增了作者名字,這樣要根據 PR 建立者來套用篩選和規則就變得更容易。

警示電子郵件的主體使用更新過的範本,先摘要說明警示的傳送原因,接著提供重要的中繼資料(標題、分支名稱及描述),以及主要行動呼籲按鈕。 電子郵件下方包含檢閱者、檔案和提交等其他詳細資料。

已改善的電子郵件範本
(圖 45) 改善的電子郵件範本

對於大部分的警示,行動信號 (圖 46) 會檢視網頁中的提取要求。 不過,當您收到特定註解的通知時,通知會「直接連結至該註解」,讓您可以輕鬆地找到相關的程式碼和之前的討論內容以便了解背景。

電子郵件來電動作
(圖 46) 電子郵件行動呼籲

更新推播通知的電子郵件範本

已更新推播通知使符合經過最佳化之清楚、精確且可採取動作的新電子郵件範本 (圖 47)。 主旨行可協助您清楚分辨推送通知電子郵件,找出分支、存放庫和作者,並彙總推送所包含的提交數目。 這些變更也能讓您更輕鬆建立規則和篩選器,利於管理這些電子郵件通知。

電子郵件內文與其他電子郵件一致,強調電子郵件的傳送原由、起始動作的使用者以及實際狀況。 與推播警示相關的特定資訊,包括儲存庫、分支、檔案和提交的詳細資料皆有包含,以便通知接收者有關變更的範圍。 推播警示的主要引導動作是 檢視推播,這會開啟推播檢視,以查看產生了警示的特定推播。

維基

每個專案現在都支援各自的 Wiki (圖 48)。 您現在可以更輕鬆地撰寫頁面,協助您的小組成員了解、使用和參與您的專案。

Wiki 頁面
(圖 48) PR Wiki 頁面

新 Wiki 的一些主要功能包含:

  • 使用 markdown 語法簡化編輯體驗。
  • 這個新頁面可讓您指定標題並新增內容。 (圖 49)
標題Wiki
(圖 49) PR 標題 Wiki
  • 支援 Markdown 的 HTML 標記 (圖 50)
Wiki HTML 標記
(圖 50) PR Wiki HTML 標籤
  • 輕鬆調整 Markdown 資料夾中的影像大小 (圖 51)
影像調整大小
(圖 51) PR 影像大小調整
  • 功能強大的頁面管理窗格,可讓您重新排列、重設父代以及管理頁面。
  • 能夠依大型 Wiki 的標題來篩選頁面 (圖 52)
Wiki 功能表
(圖 52) PR Wiki 功能表
  • Wiki 離線更新,適用於進階使用者。

提示

深入了解如何開始使用 Wiki

當您進一步使用 Wiki 時,可能會儲存非預期的變更。 現在,前往修訂詳細資料,然後按一下 [還原] 按鈕,即可將修訂還原為 Wiki 頁面 (圖 53)

Wiki 還原按鈕
(圖 53) PR Wiki 還原按鈕

我們在 Wiki 的建立過程中觀察到一種模式,也就是 Wiki 頁面上的目錄包含了不存在的連結 (圖 54)。 而使用者會按一下這些連結,試圖建立實際頁面。 我們之前處理這種情況的方式是提出警告,表示連結已中斷或該頁面不存在。 我們現在將這種情況視作 Wiki 的主流情境,並讓您有機會改為建立頁面。

建立Wiki頁面
(圖 54) PR 建立 Wiki 頁面

Wiki 頁面深層連結

Wiki 現在支援頁面內和跨頁面的深層連結區段,這對建立目錄十分有幫助。 您可以可以使用下列語法,參考相同頁面或其他頁面的標題:

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

Marketplace 上的 Wiki 延伸模組現在已被棄用。 如果您是現有的 Wiki 延伸模組使用者,則可以使用此移轉工具將 Wiki 頁面移轉至新的 Wiki。 深入了解如何將現有 Wiki 頁面移轉至新的 Wiki

封裝管理

套件管理體驗更新

套件 URL 現在以套件名稱和版本來運作,而非使用 GUID。 這使得手動打造套件 URL 更加容易 (圖 55)。 格式為:\<tfsserverurl\>/\<project|team\>/_packaging?feed=\<feed\>&package=\<package\>&version=\<version\>&protocolType=\<NuGet|Npm|Maven\>&_a=package

封裝 URL
(圖55) PR套件 URL

您現在可以向所有資料流使用者隱藏已刪除的套件版本 (圖 56) (不再顯示刪除線套件!)。

隱藏已刪除的套件
(圖 56) 隱藏刪除的套件

現在,您可以從套件清單的右鍵選單中執行任何您可以在套件詳細資料頁面上執行的操作。

套件清單包含新的 [上次推送時間] 欄位 (圖 57),內附人性化的日期,讓您可以輕鬆找到最近更新的套件。

最後推送的欄位
(圖 57) [上次推送時間] 欄位

Maven 套件

我們已在 TFS 2018 中推出支援 Maven 成品存放的功能 (圖 58)。 Maven 成品可讓 Java 開發人員順暢地共用程式碼和元件。 請參閱入門指南,以了解如何使用套件管理來共用 Maven 成品。

Maven 套裝
(圖 58) Maven 套件

新的統一 NuGet 任務

我們已將 [NuGet 還原]、[NuGet 封裝程式] 和 [NuGet 發行者] 工作合併為統一的 NuGet 建置工作,更恰當地符合其餘的建置工作程式庫;新的工作預設會使用 NuGet 4.0.0。 因此,我們已取代舊的工作,並且建議您在有時間時移至新的 NuGet 工作。 這項變更伴隨下文所述的一波改善,您只能透過使用結合的任務來進行存取。

作為這項工作的其中一部分,我們還推出了一個新的 NuGet 工具安裝程式功能,用來控制在 PATH 中可用的 NuGet 版本及新 NuGet 功能所使用的版本。 因此,若要使用新版的 NuGet,只需要在建置開頭新增 [NuGet 工具安裝程式] 工作 (圖 59)

Nuget 工作
(圖 59) NuGet 工作

提示

進一步閱讀 Microsoft DevOps 部落格上於您的建置中使用最新的 NuGet

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

我們聽到許多 NuGet 用戶表示,他們會產生一組套件,其中只有一些可能有更新(因此有更新的版本號碼)。 NuGet 建置工作有一個新選項「允許略過重複項目」,如果嘗試將套件推送到已使用該版本的 VSTS/TFS 專案摘要,這個選項允許工作繼續執行。

npm 建置任務更新

不論是在 Windows、Linux 還是 Mac 上建置 npm 專案,新的 NPM 建置工作都會順暢地運作。 我們也已重新組織工作,讓 npm 安裝和 npm 發行更為簡單。 針對安裝發佈,我們簡化了認證擷取,使專案之 .npmrc 檔案中列出的登錄認證安全地儲存在服務端點中。 或者,如果您要使用 VSTS/TFS 摘要,我們會提供選擇器讓您選取摘要,並接著使用組建代理程式所使用的必要認證來產生 .npmrc

Maven 現在支援已驗證的資訊來源

與 NuGet 和 npm 不同,Maven 構建任務先前無法處理經認證的饋送。 我們已更新 Maven 任務,以便您能夠輕鬆地使用 VSTS/TFS 的資料源(圖 60)

dotnet 工作
(圖 60) dotnet 工作

dotnet 工作支援已驗證的摘要、Web 專案

下一個主要版本的 dotnet 工作 (2.x) 解決許多回饋建議,並修正了一段時間以來我們所追蹤的一系列錯誤。 這包括下列項目:

  1. 首先,dotnet 現在支援已驗證的套件來源 (如套件管理),因此,您不需要再使用 NuGet 工作,就能從私用套件來源還原套件。
  2. 在 2.0 版的工作中,[專案的路徑] 欄位的行為已變更。 在舊版工作中,如果找不到符合所指定模式的專案檔,則會使用該工作來記錄警告,然後成功。 在這種情況下,有時可能很難了解為什麼建置成功,但未還原相依性。 現在,如果找不到符合所指定模式的專案檔,則工作會失敗。 這與其他工作的行為一致,而且很容易了解和使用。
  3. 在過去版本的工作發佈命令中,任務會將所有檔案放入一個以專案檔案名稱命名的資料夾中,以此修改輸出路徑,即使您指定了明確的輸出路徑也是如此。 這樣很難將命令鏈結在一起。 您現在可以控制輸出路徑檔案。

我們也發佈了新的 dotnet 工具安裝程式 工作,用於控制 PATH 上可用的 dotnet 版本,並且此版本將被新 dotnet 任務使用。 因此,若要使用較新版的 dotnet,只需要在建置開頭新增 [dotnet 工具安裝程式] 工作。

在帳戶/資料集外部工作

現在可以更輕鬆地在您的 TFS 伺服器或 VSTS 帳戶外部使用饋送 (圖 61),不論它們是來自另一個 VSTS 帳戶或 TFS 伺服器中的 [套件管理] 饋送,還是像 NuGet.org/npmjs.com、Artifactory 或 MyGet 這類非套件管理饋送 (圖 60)。 NuGet 和 npm 的專用 [服務端點] 類型可以輕鬆地輸入正確的認證,並讓建置工作跨套件下載和套件推送作業順暢地運作。

要使用的資料來源
(圖 61) 要使用的摘要

VSTS/TFS 摘要的摘要選擇器

一律建議您簽入組態檔 (例如 NuGet.Config、.npmrc 等等),因此,您的來源存放庫會記錄套件來源。 不過,我們聽說這在某些案例中並不理想,因此我們新增了 [使用此 VSTS/TFS 摘要中的套件] 選項,可讓您選取摘要,並自動產生將用於該建置步驟的組態檔 (圖 62)

摘要選擇器
(圖 62) 信息選擇器

建置和發布

XAML 組建

在 TFS 2015 中,我們已引進網頁型跨平台組建系統。 TFS 2018 RTW 與 Update 1 中不支援 XAML 組建,但我們在 TFS 2018 Update 2 中重新啟用了 XAML 組建。 我們鼓勵您移轉 XAML 組建。 如果您尚未準備好移轉,並且需要繼續使用 XAML 組建,請升級至 TFS 2018 Update 2。

當您升級至 TFS 2018 RTW 或 Update 1 時:

  • 如果您的 Team 專案集合中有任何 XAML 組建資料,則會收到有關移除 XAML 組建功能的警告。

  • 您可以檢視已完成的 XAML 組建,但無法將新的 XAML 組建排入佇列。

  • TFS 2018 中沒有任何新版的 XAML 組建控制器或代理程式。

當您升級至 TFS 2018 Update 2 時:

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

  • 您必須使用 Visual Studio 或 Team Explorer 2017 才能編輯 XAML 組建定義,或將新的 XAML 組建排入佇列。

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

提示

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

匯出和匯入組建定義

組建定義在內部實作為 .json 檔案,因此,您可以查看檔案歷程記錄中變更的詳細資料。 您可以透過組建定義複製和建立範本,但許多使用者想要建立其 CI 組建邏輯的複本,並將它重複用於另一個 Team 專案。 這是在 UserVoice 平台上的熱門請求之一。

我們很高興宣佈,這個功能現在成真了 (圖 63) 與 (圖 64)

匯出組建定義
(圖 63) 匯出組建定義
匯入組建定義
(圖 64) 匯入組建定義

具有建置範本的延伸模組

建置範本可讓您建立使用者開始定義其建置流程的基準。 我們今天在包裝中隨附一些範本,雖然你可以將新的範本上傳到你的帳戶,但過去延伸模組作者從未能將新範本作為延伸模組的一部分。 您現在可以在延伸模組中包含建置範本。 例如:

{  "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

提示

您可以使用這項功能,跨所有 Team 專案提供和共用相同自訂範本。

取代延伸模組中的工作

您現在可以取代延伸模組中的工作。 為了讓它運作,您必須在工作的最新版本中新增下列變數:

"deprecated": true

使用者搜尋已棄用的工作時 (圖 65),我們會將這些工作移到結尾,並將它們分組至一個預設摺疊的可摺疊區段。 如果定義已經使用已取代的工作,我們會示範已取代的工作徽章,鼓勵使用者切換至取代。

已淘汰的工作徽章
(圖 65) 過時工作徽章

您可以在工作描述中提及取代工作,以協助使用者深入了解 (圖 66)。 描述接著將透過工作列表和現有的建置/發行定義,指引使用該工作的使用者往正確方向前進。

已淘汰的工作描述
(圖 66) 過時工作描述

讓參與的建置區段控制區段可見性

之前,如果您要使用包含組建工作和組建摘要區段的延伸模組,就會看到組建摘要區段,即使您未在該組建中使用組建工作也是一樣。 您現在可以選擇在組建摘要頁面中隱藏或顯示該區段,方法是在延伸模組程式碼中新增下行,並將值設定為 true 或 false:

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

檢視 Microsoft vsts-extension-samples 存放庫中所含的範例。

變數群組支援

變數群組已可在發行定義中使用,並且也即將支援在組建定義中使用。 深入了解建立變數群組。 這已根據專案層級建置/發行變數和組建定義中的變數群組的相關建議進行開發並排定優先順序。

使用安全檔案 (例如 Apple 憑證)

我們已新增一般用途安全檔案程式庫 (英文) (圖 67)

保護檔案庫
(圖 67) 安全檔案程式庫

使用安全檔案程式庫將簽署憑證、Apple 佈建設定檔、Android Keystore 檔案和 SSH 金鑰這類檔案儲存至伺服器,而不需要將其認可至來源存放庫。

安全檔案的內容已加密,且只能在建置或發行程序中,透過工作來加以引用和使用。 安全檔案可以依據安全設定在團隊專案中的多個組建和發行定義中使用。 安全檔案遵循程式庫安全性模型。

我們也已新增一些利用這項新功能的 Apple 工作:

暫停組建定義

您現在可以暫停或停用組建定義。 如果您打算對組建定義進行變更,而且希望完成前能避免任何新的組建排入佇列,您只需要停用組建定義即可。 同樣地,如果您想要升級代理程式電腦,您可以選擇暫停組建定義,讓 VSTS 仍接受新的組建要求,但保留在佇列中不執行,直到您繼續定義。

工作輸入驗證支援

在組建定義工作中鍵入參數,有時候很容易發生錯誤。 使用工作輸入驗證,工作作者可以確保指定適當的值。 驗證運算式遵循用於工作條件的熟悉運算式語法,並且除了工作條件支援的一般函式之外,還可以使用任何受支援的函式,包括 URL、IPV4、電子郵件、數字範圍、sha1、長度或匹配。

小提示

深入了解 vsts 工作存放庫頁面上的目標和使用量。

新版本定義編輯器

基於繼續重新整理組建與版本體驗,我們已重新假設版本定義編輯器以提供更直覺式的體驗、修正一些痛點,並新增新的功能。 新編輯器的最強大功能之一,是能夠協助您將環境的部署過程視覺化。 除此之外,核准、環境屬性及部署設定現在都包含在內容中,而且可以輕鬆設定。

管線的視覺效果

編輯器中的管線 (圖 68) 提供圖形化檢視,以顯示在發行中部署如何進行。 釋出過程中會使用產出物,並將其部署到各個環境中。 環境的配置和連結會反映針對每個環境所定義的觸發程序設定。

管線
(圖 68) 發行管線
上下文配置介面

產物、發佈觸發器、部署前與部署後核准、環境屬性以及部署設定現在都在上下文中,而且可以輕鬆配置 (圖 69)

發行組態
(圖 69) 發行設定
開始使用部署範本

所有內建部署範本皆配有流程參數,讓使用者指定最重要的參數以開始使用,而不必深入工作 (圖 70) 即可簡化流程。

部署範本
(圖 70) 部署範本
版本和環境變數的簡化管理

使用 [清單] 檢視快速新增版本或環境變數,使用 [方格] 檢視來比較及編輯跨範圍並存的變數。 此外,您可以使用篩選器和關鍵字搜尋來管理兩個檢視都使用的變數集。

改良的任務與步驟編輯器

新組建定義編輯器中的所有增強功能,現在也都在版本定義編輯器中提供使用 (圖 72)。 您可以搜尋工作,並使用 [新增] 按鈕或使用拖放加以新增。 您可以使用拖曳來重新排列或複製任務。

工作編輯器
(圖 72) 工作編輯器
變數群組、保留和 [選項] 索引標籤

您現在可以連結/取消連結至變數群組(圖 73)、設定個別環境的保留原則,以及從 [選項] 索引標籤修改發行定義層級設定,例如發行編號格式。您也可以將環境儲存為部署範本、設定環境層級許可權,以及 [工作] 索引標籤標的重新排序階段。

變數群組
(圖 73) 變數群組

使用環境層級作業,來儲存為範本及設定安全性 (圖 74)

環境功能表
(圖 74) 環境功能表

使用部署群組的虛擬機器部署

Release Management 現在支援強大的內建多臺機器部署。 您現在可以跨多部電腦組織部署,並執行輪流更新,同時確保整個應用程式的高可用性。

代理程式型部署功能依賴相同的組建和部署代理程式。 不過,不同於目前的做法,您需要將組建代理程式和部署代理程式安裝在代理程式集區中的一組 Proxy 伺服器上,並推送部署至遠端目標伺服器,您可以將代理程式直接安裝在每部目標伺服器上,然後對那些伺服器進行滾動部署。 您可以在目標電腦上使用完整工作目錄。

部署群組 (圖 75) 是指包含已安裝代理程式的目標 (電腦) 的邏輯群組。 部署群組代表您的實體環境,例如單箱開發、多機器 QA,以及 UAT/Prod 的機器伺服器陣列。它們也會指定實體環境的安全性內容。

部署群組
(圖 75) 部署群組

您可以針對向其註冊我們的代理程式的任何虛擬機器使用這個項目。 我們已經使得註冊 Azure 變得非常容易,並支援 Azure 虛擬機器延伸模組,這在虛擬機器啟動時會自動安裝代理程式。 註冊 Azure 虛擬機器時,將會自動繼承其上的標記。

在您擁有部署群組後,只需要設定您想要我們對該部署群組執行的動作 (圖 76)。 您可以使用標記來控制哪些程序在特定的機器上執行,並控制部署的速度快或慢。

設定部署群組
(圖 76) 設定部署群組

執行部署時,記錄會顯示您設為目標的整個電腦群組進度 (圖 77)

部署群組進度
(圖 77) 部署群組進度

這項功能現在是 Release Management 的整合部分。 不需要其他授權。

改善的部署群組 UI

繼續我們重新構思組建版本體驗的旅程,我們已經重新構想了部署群組頁面,使其成為更整潔而且直覺化的體驗 (圖 78)。 您可以從登陸頁面檢視部署群組的目標健康狀態。 您也可以管理個別部署群組的安全性,或跨部署群組設定預設權限。

部署群組UI
(圖 78) 部署群組 UI

對於部署群組內的目標,您可以檢視摘要、最近的部署與目標的功能 (圖 79)。 您可以在目標上設定標籤,並控制每個目標上執行的內容。 我們在未來的版本中會新增部署群組的篩選器支援。

部署群組 UI 標籤
(圖 79) 部署群組 UI 標籤

工作群組參考

工作群組可讓您定義一組新增至組建或版本定義的工作 (圖 80)。 如果您需要在多個組建或版本中使用同一組工作,則這十分方便。 為了協助您追蹤某工作群組的取用者,您現在可以檢視組建定義、版本定義,以及參考您工作群組的工作群組 (圖 79)

工作群組參考
(圖 80) 工作群組參考

當您嘗試刪除仍參考的工作群組時,我們會警告您,並提供此頁面的連結。

工作群組版本控制

變更工作群組時,可能會有風險,因為這項變更會影響所有使用工作群組的定義。 使用工作群組版本控制時,您現在可以編寫並預覽工作群組版本,同時仍然提供最重要定義的穩定版本,直到準備好進行切換。 在進行某個草稿編寫和反覆項目之後,您可以發行穩定版本;而且,在發行時,如果變更在本質上是最新的,則可以選擇將工作群組發行為預覽 (新的主要版本)。 或者,您可以直接將其發行為已更新的穩定版本 (圖 81)

有工作群組的新主要 (或預覽) 版本可用時,定義編輯器會向您建議新版本。 如果該主要版本是預覽版,您甚至會看到「歡迎試用」訊息。 當工作群組結束預覽階段時,使用該群組的定義將會自動更新,並沿著那主要通道滑動 (圖 82)

儲存為草稿
(圖 81) 將工作群組儲存為草稿
將工作組發佈為預覽
(圖 82) 將任務組發佈為預覽

工作群組匯入和匯出

雖然工作群組已在專案內啟用重複使用,但是我們知道跨專案和帳戶重新建立工作群組可能十分麻煩。 使用工作群組匯入/匯出 (圖 83),如同版本定義一樣,您現在可以將其匯出為 JSON 檔案,並匯入至您想要的位置。 我們也已啟用巢狀工作群組,而巢狀工作群組在匯出時會先展開。

匯出工作組
(圖 83) 匯出工作群組

伺服器端無代理程式任務的多重組態支援

透過指定伺服器端 (無代理程式) 工作 (圖 84) 的變數乘數,您現在可以在多個組態 (平行執行) 的某個階段中執行同一組工作。

無代理程式工作的多重設定
(圖 84) 無代理程式工作的多重設定

手動干預任務中的變數支持

手動操作 工作 (圖 85) 現已支援在執行工作時向使用者顯示的指示文字內使用變數,而在此時間點,使用者可以繼續執行發行程序或予以拒絕。 可以包含版本中已定義與可用的所有變數,以及將值用於傳送給使用者的電子郵件與通知中 (圖 86)

手動介入工作
(圖 85) 手動操作工作
手動介入待處理對話方塊
(圖 86) [正在等待手動操作] 對話方塊

根據來源分支來管理環境中的發行

發行定義可以設定成在建立新發行時自動觸發部署,通常是在建置來源成功之後。 不過,您可以僅部署特定來源分支的建置,而不是在任何建置成功時進行部署。

例如,您可能會想要將所有組建都部署至開發和測試環境,但只將特定組建部署至生產環境。 您先前需要為此目的維護兩個發行管線,一個用於開發和測試環境,另一個則用於生產環境。

Release Management 現在支援在每個環境中使用工件篩選器。 這表示您可以指定要部署到各個環境的發行版本,當部署觸發條件(例如建置成功並建立新版本)得到滿足時。 在環境 [部署條件] 對話方塊的 [觸發程序] 區段中 (圖 87),選取成品條件 (例如來源分支) 以及將觸發該環境之新部署組建的標籤。

[部署條件] 對話框
(圖 87) [部署條件] 對話方塊

此外,[版本摘要] 頁面 (圖 88) 現在包含快顯工具提示,指出所有處於該狀態之「未啟動」部署的原因,以及建議開始部署的方式與時間。

版本摘要提示
(圖 88) 發行摘要祕訣

將 Git 存放庫作為工件來源的發行觸發器

對於連結到相同帳戶中所有 Team 專案內版本定義的 Git 存放庫來說,Release Management 現已支援設定持續部署觸發程序 (圖 89)。 您如此即可在對存放庫進行新的認可時,自動觸發發行。 您也可以指定認可將觸發發行之 Git 存放庫中的分支。

發行觸發程序
(圖 89) 發動觸發條件

發行觸發程序:推送至 Git 存放庫之變更的持續部署

Release Management 一律提供在建置完成時設定持續部署的功能。 不過,您現在也可以設定 Git 推送的持續部署。 這表示您可以將 GitHub 和 Team Foundation Git 存放庫連結為發行定義的成品來源,然後自動觸發應用程式 (例如 Node.JS 和 PHP) 的發行,而應用程式不是從建置所產生,因此不需要持續部署的建置動作。

環境觸發程序的分支篩選器

您現在可以在新的版本定義編輯器中,為特定環境指定工件條件。 使用這些構件條件,您將能更細緻地控制哪些構件應該部署到特定的環境。 例如,在生產環境中,您可能希望確保只部署由主分支產生的組建。 您認為應該符合此準則的所有成品都需要設定此篩選器。

您也可以為每個連結至發行定義的工件新增多個篩選器 (圖 90)。 只有在所有工件的條件都成功達成時,才會觸發這個環境的部署。

分支篩選
(圖 90) 分支篩選

伺服器端任務強化

我們已對伺服器端任務(在伺服器階段運行的任務)進行了兩項改進。

我們已新增一項新的任務,用來叫用任何泛型 HTTP REST API (圖 91) 作為自動化流程的一部分。 例如,它可以用來使用 Azure 函式叫用特定處理,並等候它完成。

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

我們也已將 [控制選項] (圖 92) 區段新增至所有伺服器端工作。 工作行為現在包含設定 [已啟用]、[錯誤時繼續]、[永遠執行] 和 [逾時] 選項。

工作控制選項
(圖 92) 工作控制選項

程式碼中樞中的發行狀態徽章

現在,如果您想知道某個提交是否已部署到客戶的生產環境,請先找出哪些建置包含此提交,然後檢查該建置部署的所有發布環境。 現在的體驗更為簡單,因為已將部署狀態整合至 [程式碼] 中樞的狀態徽章中,可顯示您的程式碼已部署至的環境清單。 對每次部署來說,狀態會更新到此次部署包含的最新提交。 如果提交部署到多個版本定義(每個版本定義包含多個環境),那麼每個提交在徽章中都會有一個項目,並分別顯示各個環境的狀態(圖 93)。 這可改善程式碼提交到部署的追蹤性。

發行狀態徽章
(圖 93) 發行狀態徽章

根據預設,當您建立發行定義時,會公佈所有環境的部署狀態。 不過,您可以挑選應在狀態徽章中顯示部署狀態的環境 (例如,只顯示生產環境) (圖 94)

[部署選項] 對話框
(圖 94) [部署選項] 對話方塊

新增工件時的建置定義選單強化功能

將組建成品新增至版本定義時,您現在可以檢視含其資料夾組織資訊的定義,讓選擇想要定義變得更輕鬆 (圖 95)。 這樣可輕鬆區分相同的組建定義名稱,但位於不同的資料夾中。

新增工件
(圖 95) 加入人工製品

定義清單是根據包含篩選條件的定義進行篩選。

將發行定義還原為較早版本

現在,如果更新發行定義,則您無法直接還原為舊版本。 唯一的方式是查看發行定義歷程記錄,來尋找變更差異,然後手動編輯發行定義。 現在,使用 [還原定義] 功能 (圖 96),您可以從版本定義 [記錄] 索引標籤中選擇並還原為任何舊版的版本定義。

回復發佈定義
(圖 96) 還原版本定義

個人化發佈通知

版本通知現已整合 VSTS 通知設定體驗。 現在,負責版本管理的人員會自動收到通知,提醒待決的操作(核准或手動介入)以及重要的部署失敗。 您可以巡覽至設定檔功能表下的 [通知] 設定,然後關閉 [版本訂閱] ,以關閉這些通知。 您也可以建立自訂訂閱來訂閱其他通知。 系統管理員可以從 [小組] 下的 [通知] 設定和 [帳戶] 設定來控制小組和群組的訂閱。

版本定義作者不必再手動傳送核准和部署完成的電子郵件。

這特別適合有多個版本專案關係人的大型客戶,以及除了核准者、版本建立者和環境擁有者以外,也想要收到通知的客戶 (圖 97)

發行通知
(圖 97) 發行通知

提示

如需詳細資訊,請參閱管理版本通知的貼文

測試

移除 Microsoft Test Manager 中的實驗室中心和自動化測試流程功能

隨著組建和發行管理的發展,TFS 2018 不再支援 XAML 組建,因此我們將更新搭配使用 Microsoft Test Manager (MTM) 與 TFS 的支援。 從 TFS 2018 開始,TFS 不再支援使用 MTM 中的測試中心/實驗室中心進行自動化測試。 如果您還沒有準備好從 XAML 組建和實驗室中心進行移轉,則應該不要升級至 TFS 2018。

請於下方查看升級至 TFS 2018 的影響:

實驗室中心:
  • 不再支援:
    • 無法將 Test Controllers 註冊到 TFS 以便建立和管理 Lab 環境。
    • 任何向 TFS 註冊的現有 Test Controller 都會離線,而且現有實驗室環境將會顯示為「未就緒」。
  • 建議的替代方案:
自動化測試:
手動測試:
  • 所有手動測試案例持續受到完整支援。 使用 MTM 搭配 TFS 2018 可以執行手動測試,但無法使用實驗室環境來執行手動測試。
  • 在所有手動測試案例中,針對 TFS Web 存取,強烈建議使用測試中樞

根據我們接收到正在進行探勘測試之小組的意見反應,當從 Test & Feedback extension (測試和意見反應延伸模組) 提出 Bug、工作或測試案例時,我們將改善可追蹤性連結。 探索需求時所建立的 Bug 與工作,現在會使用與需求相同的區域路徑和迭代來建立,而非依小組預設值建立。 探索需求時所建立的測試案例現在會以測試<->測試者連結,而不是父<->子連結,讓您所建立的測試案例自動新增至以需求為基礎的測試套件。 最後,未特別探勘任何需求時所建立的工作項目將會歸類於小組的預設反覆項目,而非目前反覆項目;因此,在短期衝刺規劃完成之後,不會有新的工作項目進入目前反覆項目。

測試中心中的測試計劃和套件內測試案例工作項目的篩選器

除了依 [測試] 欄位 (例如 [結果]、[組態] 和 [測試者]) 的篩選之外,現在還可以依測試案例工作項目欄位 (例如 [標題]、[狀態] 和 [指派至]) 來篩選 (圖 98)

測試案例篩選
(圖 98) 測試案例篩選

發行環境和測試回合的測試趨勢圖

我們正在 [測試結果趨勢] 小工具 (圖 99) 中新增對 [版本環境] 的支援,以便您能在 VSTS 儀表板上追蹤測試環境的狀態。 就像您針對 [組建] 中測試結果所進行的作業,您現在可以建立趨勢圖,以顯示測試成功率、總計數、成功或失敗測試,以及 [發行環境] 的測試期間。 您也可以使用 [測試回合] 標題篩選,將圖表篩選為環境內的特定測試回合。

測試趨勢圖
(圖 99) 測試趨勢圖表

測試回合和測試結果註解的 Markdown 格式支援

我們將新增使用 markdown 語法格式化 [測試回合] 和 [測試結果] 註解的支援。 您可以使用這項功能,在註解中建立 URL 的格式化文字或快速連結。 您可以將 [結果摘要] 頁面中的 [測試結果] 註解更新為 [更新分析],以及將 [回合摘要] 頁面中的 [測試回合] 註解更新為 [測試] 中樞內的 [更新註解]

分析 [組建] 或 [發行] 摘要頁面或 [測試] 中樞內的測試結果時,您現在可以將現有的 Bug 與失敗的測試關聯起來。 測試因已歸檔 Bug 的已知原因而失敗時,這十分有用。

上傳測試回合和測試結果的附件

測試回合或測試結果的螢幕擷取畫面和記錄檔等檔案,現在可以附加為其他資訊。 截至目前為止,這項功能只能透過 Microsoft Test Manager (MTM) 用戶端獲得,您需要在 VSTS/TFS 中的測試中樞與 MTM 用戶端之間切換內容。

測試批次

在組建/版本管理的 Visual Studio 測試工作中,可以選擇如何控制測試分組 (批次) 以進行有效率的執行。 測試分組有兩種方式:

  1. 以每回合測試及參與代理程式的數目為基礎,只要將測試分組為數個指定大小的批次即可。
  2. 以過去的測試執行時間為基礎,考量過去的執行時間來建立測試批次,讓每個批次都有相近的執行時間 (圖 100)。 快速執行的測試會成為一個批次,而執行時間較長的測試則屬於另一個批次。 這個選項可以結合多代理程式階段設定,將總測試時間減至最低。
測試分批
(圖 100) 測試批次處理

使用 VSTest 工作來執行網路測試

使用 Visual Studio 測試工作,即 WebTest,也稱為 Web 效能測試,現在可在 CI/CD 管線中執行。 在工作組件輸入中指定要執行的測試,即可執行 WebTest。 任何具有 WebTest 「與自動化相關」連結的測試案例工作項目,也可以透過在工作中選取測試計劃/測試套件來執行 (圖 101)

測試選擇
(圖 101) 測試選取範圍

WebTest 結果可以測試結果附件的方式提供 (圖 102)。 這可以下載供 Visual Studio 離線分析。

測試摘要
(圖 102) 測試摘要

這項功能取決於 Visual Studio 測試平台的變更,需要在組建/版本代理程式上安裝 Visual Studio 2017 Update 4。 使用舊版 Visual Studio 無法執行 WebTest。

同樣地,可以使用執行功能測試工作來運行網頁測試。 這項功能會隨測試代理程式的變更而異,隨附於 Visual Studio 2017 Update 5。

提示

如需如何使用此功能搭配負載測試的範例,請參閱使用 Visual Studio 和 VSTS 快速入門在雲端中負載測試應用程式

測試計劃和測試套件的圖表組件

從前可以在測試中樞裡建立測試計劃和套件的圖表,並將它們釘選到儀表板。 現在新增了小工具,可從儀表板的小工具目錄建立測試計劃和套件的圖表。 您可以建立測試製作狀態或測試執行狀態的圖表。 此外,當您要在圖表上顯示更多資料時,從小工具新增圖表可讓您建立較大的圖表 (圖 103)

圖表小工具
(圖 103) 圖表小工具

提供螢幕擷取畫面及註解功能,支援使用 Chrome 瀏覽器進行桌面應用程式的手動測試。

我們正在新增手動測試中最受歡迎的建議之一——在測試中樞中使用Web 測試執行器擷取桌面應用程式的螢幕截圖。 截至目前為止,您必須使用 Microsoft Test Manager 中的測試執行器擷取桌面應用程式的螢幕擷取畫面。 若要使用這項功能,您需要安裝測試與意見反應延伸模組。 我們即將推出對 Chrome 瀏覽器的支援,Firefox 支援亦將於不久之後推出。

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

TFS 2018 和更新版本將不再支援適用於 SharePoint 的 TFS 延伸模組。 此外,已經從 Team Foundation 管理主控台中移除用來設定 TFS 伺服器與 SharePoint 伺服器間之整合的畫面。

注意

如果您要從設定與 SharePoint 整合的舊版升級到 TFS 2018,升級後會需要停用 SharePoint 整合,否則無法載入 TFS SharePoint 網站。

我們已建立解決方案,讓您停用 SharePoint 伺服器上的整合。 如需詳細資訊,請參閱未來的 TFS/SharePoint 整合文章。

停止使用小組室

現代開發小組大幅取決於共同作業。 人員想要 (並需要) 一個位置來監視活動 (通知),並進行討論 (聊天)。 在幾年前,我們辨識出這個趨勢,並著手建造小組室以支援這些情境。 自那時起,我們看到市場中出現了更多協作解決方案。 最值得注意的是 Slack 的崛起。 最近則是 Microsoft Teams 的宣告。

我們〈c0〉已在 1 月宣佈〈/c0〉,由於有許多與 TFS 和 Visual Studio Team Services 整合良好的優秀解決方案可用,我們計畫從 TFS 2018 和 Visual Studio Team Services 中移除小組討論室功能。


目前情況如何?

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


頁首