Azure DevOps Server 2019 版本資訊

| 開發人員社群System RequirementsLicense | 條款 | DevOpsBlogSHA-1 | 雜湊

在本文中,您將找到最新版Azure DevOps Server的相關資訊。

若要深入瞭解如何安裝或升級Azure DevOps Server部署,請參閱Azure DevOps Server需求。 若要下載Azure DevOps產品,請流覽Azure DevOps Server下載頁面

Azure DevOps Server 2019 或 Team Foundation Server 2015 或更新版本支援直接升級至 Azure DevOps Server 2020。 如果您的 TFS 部署是在 TFS 2010 或更早版本上,您必須先執行一些過渡步驟,再升級至 Azure DevOps Server 2019。 若要深入瞭解,請參閱安裝和設定內部部署Azure DevOps


安全地從 Azure DevOps Server 2019 升級到 Azure DevOps Server 2020

Azure DevOps Server 2020 引進新的管線執行, (建置) 保留模型,以專案層級設定為基礎。

Azure DevOps Server 2020 會根據管線層級保留原則,以不同的方式處理組建保留。 某些原則設定會導致在升級後刪除管線執行。 升級之後,不會刪除已手動保留或由發行保留的管線執行。

如需如何安全地從 2019 Azure DevOps Server 升級至 Azure DevOps Server 2020 的詳細資訊,請參閱我們的部落格文章

Azure DevOps Server 2019.0.1 修補程式 12 發行日期:2022 年 1 月 26 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行修補程式

  • 從 log4j 二進位檔移除 jndilookup 類別,以解決 Elasticsearch 弱點。

安裝步驟

  1. 使用 Patch 12升級伺服器。
  2. 檢查 位於 的 HKLM:\Software\Elasticsearch\Version 登錄值。 如果登錄值不存在,請新增字串值,並將 Version 設定為 5.4.1 (Name = Version,Value = 5.4.1) 。
  3. 執行讀我檔案中所述的更新命令 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update 。 它可能會傳回警告,例如: 無法連線到遠端伺服器。 請勿關閉視窗,因為更新正在執行重試,直到完成為止。

注意

如果Azure DevOps Server和 Elasticsearch 安裝在不同的電腦上,請遵循下列步驟。

  1. 使用 Patch 12升級伺服器。
  2. 檢查 位於 的 HKLM:\Software\Elasticsearch\Version 登錄值。 如果登錄值不存在,請新增字串值,並將 Version 設定為 5.4.1 (Name = Version,Value = 5.4.1) 。
  3. 將名為 zip C:\Program Files\{TFS Version Folder}\Search\zip 的資料夾內容複寫到 Elasticsearch 遠端檔案資料夾。
  4. 在 Elasticsearch 伺服器電腦上執行 Configure-TFSSearch.ps1 -Operation update

SHA-256 雜湊: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 修補程式 11 發行日期:2021 年 8 月 10 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行修補程式

  • 修正組建定義 UI 錯誤。

Azure DevOps Server 2019.0.1 修補程式 10 發行日期:2021 年 4 月 13 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行修補程式。

若要套用修補程式 10,您必須安裝工作 AzureResourceGroupDeploymentV2

AzureResourceGroupDeploymentV2 工作安裝

注意

下列所有步驟都必須在Windows電腦上執行

安裝

  1. AzureResourceGroupDeploymentV2.zip 套件解壓縮到電腦上的新資料夾。 例如: AzureResourceGroupDeploymentV2

  2. 下載並安裝Node.js 14.15.1 和 npm (,Node.js根據您的電腦下載) 。

  3. 在系統管理員模式中開啟命令提示字元,然後執行下列命令來安裝 tfx-cli。

npm install -g tfx-cli
  1. 建立具有 完整存取權限的個人存取 權杖,並加以複製。 執行 tfx 登入 命令時,將會使用此個人存取權杖。

  2. 從命令提示字元執行下列命令。 出現提示時,請輸入服務 URL 和個人存取權杖。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 執行下列命令,在伺服器上上傳工作。 使用從步驟 1 擷取.zip檔案的路徑。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 修補程式 9 發行日期:2020 年 12 月 8 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行修補程式。 如需詳細資訊,請參閱部落格文章

  • CVE-2020-1325:Azure DevOps Server詐騙弱點
  • CVE-2020-17135:Azure DevOps Server詐騙弱點
  • CVE-2020-17145:Azure DevOps Server和Team Foundation Server詐騙弱點
  • 修正 TFVC 未處理所有結果的問題

重要

請先閱讀以下提供的完整指示,再安裝此修補程式。

一般修補程式安裝

如果您有Azure DevOps Server 2019.0.1,您應該安裝Azure DevOps Server 2019.0.1 修補程式 9

驗證安裝

  • 選項 1:執行 devops2019.0.1patch9.exe CheckInstall ,devops2019.0.1patch9.exe是從上述連結下載的檔案。 命令的輸出會說已安裝修補程式,或未安裝。

  • 選項 2:檢查下列檔案的版本: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll 。 預設會安裝 c:\Program Files\Azure DevOps Server 2019 Azure DevOps Server 2019。 安裝 Azure DevOps Server 2019.0.1 Patch 9 之後,版本將會是 17.143.30723.4 。

AzurePowerShellV4 工作安裝

注意

下列所有步驟都必須在Windows電腦上執行

必要條件

  1. 在私人代理程式電腦上安裝Azure PowerShell Az 模組 Azure Powershell

  2. 使用 AzurePowerShellV4 工作建立管線。 您只會在工作中看到一個 「標準錯誤失敗 」。

安裝

  1. AzurePowerShellV4.zip 套件解壓縮至名為 AzurePowerShellV4的資料夾。

  2. 下載並安裝Node.js 14.15.1 和 npm (,Node.js根據您的電腦下載) 。

  3. 在系統管理員模式中開啟命令提示字元,然後執行下列命令來安裝 tfx-cli。

npm install -g tfx-cli
  1. 建立具有 完整存取權限的個人存取 權杖,並加以複製。 執行 tfx 登入 命令時,將會使用此個人存取權杖。

  2. 從命令提示字元執行下列命令。 出現提示時,請輸入服務 URL 和個人存取權杖。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 執行下列命令,在伺服器上上傳工作。 擷取套件的路徑將是 D:\tasks (1) \AzurePowerShellv4
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 修補程式 8 發行日期:2020 年 9 月 8 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行安全性修補程式。 如需詳細資訊,請參閱部落格文章

  • DTS 1713492 - 將 AD 群組新增至安全性許可權時發生非預期的行為。

Azure DevOps Server 2019.0.1 修補程式 7 發行日期:2020 年 7 月 14 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行安全性修補程式。 如需詳細資訊,請參閱部落格文章

  • CVE-2020-1326:跨網站腳本弱點
  • 選取 [其他 Git 來源] 時,組建管線會顯示未經授權使用者的連線不正確。
  • 修正在 XAML 組建定義中將繼承變更為開啟或關閉時的錯誤。

Azure DevOps Server 2019.0.1 修補程式 6 版本日期:2020 年 6 月 10 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行安全性修補程式。 如需詳細資訊,請參閱部落格文章

  • CVE-2020-1327:確定Azure DevOps Server可清理使用者輸入
  • 在 SSH 中新增對 AZURE DEVOPS 的 SHA2 支援

Azure DevOps Server 2019.0.1 修補程式 5 發行日期:2020 年 3 月 10 日

我們已針對修正下列各項的 Azure DevOps Server 2019.0.1 發行安全性修補程式。 如需詳細資訊,請參閱部落格文章

Azure DevOps Server 2019.0.1 修補程式 3 發行日期:2019 年 9 月 10 日

我們為 Azure DevOps Server 2019.0.1 發行了安全性修補程式,其修正了下列 Bug。 如需詳細資訊,請參閱部落格文章


Azure DevOps Server 2019.0.1 修補程式 2 發行日期:2019 年 8 月 13 日

我們為 Azure DevOps Server 2019.0.1 發行了安全性修補程式,其修正了下列 Bug。 如需詳細資訊,請參閱部落格文章

  • 我們已將資訊新增至服務連線,以厘清它們預設已獲得所有管線的授權。

Azure DevOps Server 2019.0.1 修補程式 1 發行日期:2019 年 7 月 9 日

我們為 Azure DevOps Server 2019.0.1 發行了安全性修補程式,其修正了下列 Bug。 如需詳細資訊,請參閱部落格文章

  • CVE-2019-1072 :工作項目追蹤中的遠端程式碼執行弱點
  • CVE-2019-1076 :提取要求中的跨網站指令碼 (XSS) 弱點

Azure DevOps Server 2019.0.1 發行日期:2019 年 5 月 21 日

Azure DevOps Server 2019.0.1是錯誤修正的匯總。 其中包含先前發行的 Azure DevOps Server 2019 修補程式中的所有修正程式。 您可以直接安裝 Azure DevOps Server 2019.0.1 或從 Azure DevOps Server 2019 或 Team Foundation Server 2012 或更新版本升級。

注意

此版本之後,資料移轉工具將可供Azure DevOps Server 2019.0.1 約三周使用。 您可以在這裡查看我們目前支援匯入的版本清單。

此版本包含下列 Bug 的修正:

Azure Boards

  • 設定方案時,「此計畫的欄位準則發生錯誤」。 透過開發人員社群回報。
  • apiwitcontroller.executequery 會在查詢多次具有相同資料行時擲回例外狀況。
  • 在用戶端物件模型中,使用 vso.work_full oauth 範圍,WorkItemServer.DownloadFile () 會失敗。
  • 將內嵌影像從工作專案欄位複製到不同專案中的另一個工作專案欄位,可能會建立中斷的影像。

Azure Repos

  • 「TF401019: GitRepositoryNotFoundException」。

Azure Pipelines

  • [測試分析] 索引標籤具有星號 (*) ,表示預覽,即使此功能不在預覽狀態也一樣。
  • 在 [ 發行] 索引 標籤上,管理安全性的動作現在會顯示給所有使用者,不論他們是否可以變更許可權。
  • 在發行登陸頁面上,開始草稿發行動作正在建立新版本,但現在會啟動草稿版本。

Azure Test Plans

  • TestRuns 和 TestResults CompletedDate 上的 1 小時篩選太細微。
  • [測試案例 ] 工作專案類型中,不應該當地語系化類型 「Test Case」。
  • 測試案例不會顯示在 MTM 或瀏覽器中。
  • 「驗證階段:從測試計劃執行自動化測試時,您沒有觸發相關聯發行管線發行的許可權」錯誤。 透過開發人員社群回報。
  • 使用 刪除測試案例 API,即可從其他專案刪除測試案例。 透過開發人員社群回報。
  • 在測試執行器中按一下工作專案連結,會在測試執行器內開啟工作專案 URL,而不是預設瀏覽器。
  • 已登出測試執行器的使用者不會更新測試案例狀態。
  • 使用者名稱和電子郵件地址不會顯示在測試執行器的使用者下拉式清單中。

Azure Artifacts

  • 移和 下移 不會當地語系化在上游。

分析

  • 分析報告可能會顯示不完整的資料,因為模型在實際完成之前標示為「就緒」。
  • 速度、待用和待用小工具會針對不同時區的使用者顯示不同的計劃性工作。
  • 保留可能會放在分析資料擷取上,同時執行維護可能會導致過時的報告。

一般

  • 當空間不足時,左側導覽專案會在 IE 上產生壓力。

系統管理

  • 新增至集合升級的其他記錄,以協助偵錯問題。
  • 當 TfsConfig offlineDetach 失敗時,錯誤訊息無法採取動作。
  • TfsJobAgent 服務當機。
  • 完成設定之後,不會安裝搜尋延伸模組。
  • 當組態資料庫損毀時,管理主控台會變成沒有回應。
  • 服務勾點可能無法正確處理通知。
  • 設定搜尋之後,程式碼搜尋索引不會啟動。
  • 搜尋頁面結果上有未分配的字串。

此版本包含下列更新:

支援 Visual Studio 測試工作中Visual Studio 2019 (VS2019)

我們已將 Visual Studio 2019 的支援新增至管線中的Visual Studio測試工作。 若要使用測試平臺執行Visual Studio 2019 的測試,請從 [測試平臺版本] 下拉式清單中選取[最新] 或[Visual Studio 2019] 選項。

Screenshot of the Execution options section showing the Test platform version dropdown list selected with the Latest Visual Studio 2019 option selected.


Azure DevOps Server 2019 修補程式 2 發行日期:2019 年 5 月 14 日

我們已針對 2019 Azure DevOps Server 發行安全性修補程式,以修正下列 Bug。 如需詳細資訊,請參閱部落格文章


Azure DevOps Server 2019 修補程式 1 發行日期:2019 年 4 月 9 日

我們已針對 2019 Azure DevOps Server 發行安全性修補程式,以修正下列 Bug。 如需詳細資訊,請參閱部落格文章


Azure DevOps Server 2019 年 3 月 5 日發行日期:2019 年 3 月 5 日

注意

此版本之後,資料移轉工具將可供Azure DevOps Server 2019 年約三周使用。 您可以在這裡查看我們目前支援匯入的版本清單。


RC2 發行日期:2019 年 1 月 22 日

Azure DevOps Server 2019 RC2 的新功能摘要

我們已將下列功能新增至 RC2:


RC1 發行日期:2018 年 11 月 19 日

Azure DevOps Server 2019 RC1 的新功能摘要

Azure DevOps Server 2019 引進了新的導覽體驗和許多新功能。 一些重點包括:

您也可以跳至個別區段,以查看新功能:


一般

宣佈Azure DevOps Server

在 9 月 10 日,我們宣佈Azure DevOps成為Visual Studio Team Services和Team Foundation Server的演進。 Azure DevOps Server 2019 是我們使用此新品牌的第一個內部部署版本。 您可以在我們的 部落格文章中找到詳細資訊。

新的流覽體驗

我們引進了新的導覽,以現代化使用者體驗。 這個新的導覽已推出至 Azure DevOps 服務,現在可在 Azure DevOps Server 2019 中使用。 如需詳細資訊,請參閱 我們的部落格

New nav

Artifacts和Release Management部署管線授權的變更

根據使用者的意見反應,我們會在 2019 年Azure DevOps Server對授權進行兩個主要變更。 首先,客戶不再需要購買成品延伸模組,才能使用Artifacts。 Artifacts授權使用現在會包含在基本授權中。 指派基本授權的所有使用者現在都可以使用Artifacts。 其次,客戶不再需要購買Release Management部署Pipelines。 就像組建Pipelines一樣,Release Management部署Pipelines現在隨附于 Azure DevOps Server 2019。

支援Azure SQL Database

為了簡化在 Azure 中執行 Azure DevOps 2019 的體驗,我們已支援 Azure SQL Database (常規用途 S3 和更新版本) 。 這可讓您利用廣泛的備份功能和調整選項,以符合您的需求,同時減少執行服務的系統管理負荷。 請注意,您的主機 VM 必須位於與資料庫相同的 Azure 區域,才能保持低延遲。 如需詳細資訊,請參閱 文件

未來版本中的工作專案 & 測試用戶端物件模型 SOAP API

Azure DevOps Server 2019 會繼續支援工作專案追蹤 SOAP API 和用戶端物件模型。 不過,未來版本的 Azure DevOps Server 將會將其標示為已被取代。 您可以在 我們的檔中找到詳細資訊。

新集合上的進程繼承

程式繼承現在可在新的集合上使用。 使用者必須在建立新的集合時,對程式模型做出決策。 請參閱 我們的檔 ,以瞭解繼承模型是什麼,以及其與 XML 有何不同。

Process inheritance

我們瞭解搜尋的重要性,並帶回產品標頭上的展開搜尋方塊。 此外,您現在可以在Azure DevOps的任何服務頁面上按一下 「/」 來叫用搜尋方塊。

以下是預設搜尋方塊:

Default search box

輸入 「/」 之後,您會看到展開的搜尋方塊:

Expanded search box

我的工作飛出視窗

我們很高興介紹的新功能是 我的工作 飛出視窗。 我們聽到了意見反應,指出當您位於產品的某個部分,並想要從另一個部分取得一些資訊時,您不想遺失您的內容。 透過這項新功能,您可以從產品中的任何位置存取此飛出視窗,並可讓您快速查看重要資訊,包括您的工作專案、提取要求和所有我的最愛。 有了這個新的飛出視窗,如果您在程式碼中Repos往下往下,但想要快速檢查下一個應該處理的工作專案,您可以直接按一下飛出視窗並查看指派給您的工作專案,然後挑選下一個專案。

您可以在下方看到 [我的工作 ] 飛出視窗,其中顯示指派給我的工作專案:

My work flyout

在這裡,您可以看到第二個樞紐,其中顯示指派給我的 PR。 在飛出視窗中,您也有一鍵存取權可檢視更多提取要求:

My work flyout PR

您可以在這裡看到最後一個樞紐,這是您最愛的所有專案。 這包括您最愛的小組、儀表板、面板、待辦專案、查詢和存放庫:

My work flyout favorites

Boards

Teams針對程式碼使用GitHub Enterprise,而且想要豐富的專案管理功能現在可以將其存放庫與Azure Boards整合。 藉由連接GitHub和Azure Boards,您可以取得所有功能,例如待辦專案、面板、短期衝刺規劃工具、多個工作專案類型,而且仍然具有與開發人員工作流程整合的工作流程GitHub。

將認可和提取要求連結至工作專案很容易。 使用下列語法提及工作專案:

AB#{work item ID}

在認可訊息、提取要求標題或提取要求描述中提及工作專案,Azure Boards將會建立該成品的連結。 例如,請考慮認可訊息,如下所示:

Adds support for deleting connections. Fixes AB#20.

這會從工作專案 #20 建立連結至GitHub的認可,這會出現在工作專案的 [開發] 區段中。 ​

Screenshot of Azure DevOps with the Development section called out.

如果 「fix」、「fix」 或 「fixed」 字在工作專案前面提及 (,如上述) 所示,工作專案將會在認可合併至預設分支時移至已完成的狀態。

使用 Azure Pipelines 在 GitHub 中建置程式碼的Teams也會在組建摘要中看到連結到其GitHub認可的工作專案。

新增工作專案中樞

工作專案中樞是我們新的中樞,可做為工作專案的主資料夾! 在這裡,您有許多不同的工作專案清單檢視,這些檢視範圍已縮小。 您可以檢視 [指派給我 ] 以快速查看指派給您的所有工作,或 [最近更新 ],其中顯示專案中最近更新的所有工作專案。 以下可以看到您的所有清單選項:

Work items hub

如果您想要進一步縮小清單的範圍,您可以篩選類型、指派給、狀態、區域、標籤和關鍵字。 擁有所需的清單檢視之後,只要按一下資料行的標頭即可排序工作專案。 如果某個資料行太窄,無法檢視資料行的完整內容,您可以輕鬆地調整標題區域中的資料行大小。 以下可看到這些體驗:

Work items hub list

新的Boards、待辦專案和短期衝刺中樞

待辦專案中樞分成三個不同的中樞,以改善使用者體驗。 雖然功能強大,但舊的待辦專案中樞擁有太多功能。 這通常很難找到使用者正在尋找的功能。 為了解決此問題,我們已將待辦專案中樞分割成:

  • 待辦專案中樞現在只位於專案的待辦專案。 待辦專案是小組工作的優先順序清單。 待辦專案提供規劃工具,例如工作專案階層、預測和新的短期衝刺規劃體驗。
  • 新的Boards中樞是專案的所有 Kanban Boards首頁。 Boards可用來傳達狀態和流程。 卡片 (工作專案,) 從左至右跨小組定義的資料行移動。
  • 新的 短期衝刺 中樞是用來規劃和執行工作增量功能的主處。 每個短期衝刺都包含短期衝刺待辦專案、工作面板,以及管理及設定小組容量的檢視。

Boards hub

新增查詢中樞

新的查詢中樞可簡化舊中樞的許多常設查詢功能,其外觀和風格更新,並提供新功能,讓您更輕鬆地取得對您而言很重要的查詢。 新體驗的一些重點包括:

  • 資訊上次修改的目錄頁面,以及搜尋查詢的能力
  • 具有資料夾唯一 URL 的階層連結,以將重要查詢群組加入書簽
  • 從結果頁面快速存取您最愛的查詢

在我們的DevOps部落格上深入瞭解這些令人興奮的更新。

將工作專案移至另一個專案並變更工作專案類型

您現在可以 變更工作專案類型 ,或 將工作專案移至 專案集合內的另一個專案。 這些功能需要停用資料倉儲。 停用資料倉儲後,您可以使用 Analytics Service 來支援報告需求。 若要深入瞭解如何停用資料倉儲,請參閱 停用資料倉儲和 Cube

短期衝刺規劃功能

新的短期衝刺規劃功能有助於加速和改善短期衝刺規劃體驗。

  • 直接從 Sprints 中樞建立下一個短期衝刺或訂閱現有的 短期衝刺 排程。
  • 使用待辦專案中的新 [規劃 ] 窗格,將工作專案拖放到未來的短期衝刺中。 [規劃]窗格包含短期衝刺日期、工作專案計數和計劃性工作。
  • 將需求新增至 Taskboard 頂端,或使用快速建立,將新增至短期衝刺待辦專案上所選的頂端、底部或資料列。
  • 使用 [被指派者]、[工作專案類型]、[狀態] 和 [標籤] 的篩選,根據您的需求量身打造檢視。

Sprint planning

新增目錄頁面

所有新的中樞,包括待辦專案Boards短期衝刺,現在都有以下列各節組織的新目錄頁面:

  • 繼續您離開的位置 本節提供直接連結至最後一個 (面板|待辦專案|您已開啟) 短期衝刺。
  • 收藏 夾 所有小組中您最愛的面板、短期衝刺和待辦專案。
  • 您所屬小組的所有面板、待辦專案和短期衝刺。
  • 所有 所有面板、待辦專案和短期衝刺的完整清單。

Directory pages

新增檢視選項功能表

新的中樞包括待辦專案Boards短期衝刺,都有新的 [檢視選項] 功能表。 這是自訂版面配置和頁面內容之所有動作的新首頁。 使用 [檢視選項 ] 啟用其他檢視,例如在待辦專案中顯示階層,或變更工作面板上的 [群組 依據] 選項、開啟側邊面板以進行對應和規劃短期衝刺,或探索工作詳細資料圖表。

View options

請在我們的DevOps部落格上深入瞭解這些令人興奮的更新、新的 [小組設定檔] 窗格和 [我的最愛]。

卡片批註包括 Bug 和自訂工作專案類型

卡片注釋對於其直覺式檢查清單檢視和互動很愛。 先前,卡片批註僅限於預設待辦專案層級類型,而且不支援 Bug 或自訂類型。 使用新版本時,我們已移除工作專案類型的限制,並新增將 Bug 和任何自訂工作專案類型顯示為卡片批註的功能。

卡片批註的面板設定已展開,以包含該待辦專案層級可用的所有工作專案類型。

Annotation settings

啟用工作專案的注釋時,該工作專案類型的計數會以個別的檢查清單的形式包含在卡片上。

Annotation work item

您也可以透過卡片操作功能表快速建立已啟用的工作專案類型。

Annotation quick create

使用建議的區域和反復專案移動工作

在相同的區域或反復專案中工作,並在移動工作專案時重複流覽階層,可能會很常見。 [區域] 和[反復專案路徑] 控制項現在包含最近使用的值清單作為[建議],讓您快速存取設定並繼續進行。

Area drop down list

此外, 反覆運算 日期會包含在名稱右邊,以便您可以快速判斷何時應該傳遞工作專案。

Iteration drop down list

使用 +/- 在反復專案排程之間查詢工作 @CurrentIteration

協助您 @CurrentIteration 小組根據反復專案排程追蹤工作的宏現在支援整數位移。 輕鬆地在未使用 @CurrentIteration 關閉的工作上保留索引標籤 - 1,或查看計畫在未來使用 @CurrentIteration + 1 反復專案的工作。 如需詳細資訊,請參閱 Microsoft DevOps 部落格上的@CurrentIteration文章

使用 @CurrentIteration Team 參數厘清查詢反復專案排程

如果您過去已在 @CurrentIteration 查詢中使用宏,您可能會注意到,如果 Team 內容在具有不同反復專案排程的Teams變更,結果可能會有所不同。 現在,當您使用 @CurrentIteration 宏建立或修改查詢時,也必須選取與查詢相關的反復專案排程的 Team。 使用 Team 參數,您可以在 @CurrentIteration 相同的查詢中使用宏,但跨小組使用。 其中一個範例可能是使用不同反復專案名稱,甚至是排程,在兩個不同的小組專案中查詢工作專案。 這表示不再需要在短期衝刺變更時更新查詢! 如需詳細資訊,請參閱 Microsoft DevOps 部落格上的@CurrentIteration文章

Team parameter

使用新 @TeamAreas 宏在 Team 的區域路徑中查詢工作

在小組的設定中,您可以建立一或多個區域路徑的關聯,這可協助您將待辦專案Boards方案,甚至是儀表板放在該小組的工作。 不過,如果您想要撰寫 Team 的查詢,則必須在查詢子句中列出該小組的特定區域路徑。 現在,新的 @TeamAreas 宏可供您輕鬆參考指定小組所擁有的區域路徑。

team areas macro in query editor

查詢空白 RTF 欄位

使用新的 IsEmpty 查詢運算子,尋找具有空白 RTF 欄位的工作專案,例如 Description。

輕鬆尋找連結和提及體驗中的現有工作專案

當您想要將兩個現有的工作專案連結在一起時,您現在可以使用我們的新工作專案搜尋控制項,輕鬆地找到對您很重要的專案。 查詢選取器已根據您最近存取的工作專案,以及依識別碼或標題搜尋特定工作專案的進入點,以內嵌建議取代。

Work item linking

先前,如果工作專案預覽窗格已關閉,就無法從搜尋結果頁面開啟工作專案。 這會使您難以深入探索您的搜尋結果。 現在您可以按一下工作專案標題,在強制回應視窗中開啟工作專案。

Repos

改善的分支選擇器

Azure Repos中的大部分體驗都需要您選取存放庫,然後選取該存放庫中的分支。 為了改善具有大量分支的組織體驗,我們推出新的分支選擇器。 選擇器現在可讓您選取您最愛的分支,或快速搜尋分支。

Branch picker

略過提取要求原則時接收通知

對於使用提取要求 (PR) 和 分支原則的小組,有時候可能需要覆寫並略過這些原則,例如,在午夜將 Hotfix 部署到生產問題時。 信任開發人員能夠執行正確的動作,並謹慎使用覆寫功能。 同時,小組需要一種方式來驗證這些原則覆寫是否在正確的情況下使用。 為了支援這項功能,我們新增了新的通知篩選器,以允許使用者和小組在略過原則時收到電子郵件警示。 從 建立或更新提取要求開始, 然後從篩選清單中選取 [ 原則略過 ]。 選取 [已略過 原則] 作為值,且每當 PR 完成時,您都會收到通知,並略過原則。

Bypass policy notification

允許略過分支原則而不放棄推送保護

在許多情況下,您偶爾需要略過分支原則 - 還原造成建置中斷的變更、在夜間套用 Hotfix 等等。先前,我們已提供許可權 (「豁免原則強制執行」) ,協助小組管理哪些使用者在完成提取要求時能夠略過分支原則。 不過,該許可權也授與直接推送至分支的能力,完全略過 PR 程式。

為了改善此體驗,我們已分割舊的許可權,為授與略過許可權的小組提供更多控制權。 有兩個新的許可權可取代舊的許可權:

  1. 完成提取要求時略過原則。 具有此許可權的使用者將能夠使用提取要求的「覆寫」體驗。
  2. 推送時略過原則。 具有此許可權的使用者將能夠直接推送至已設定必要原則的分支。

藉由授與第一個許可權並拒絕第二個許可權,使用者就能夠在必要時使用略過選項,但仍會有保護,防止意外推送至具有原則的分支。

注意

這項變更不會引入任何行為變更。 先前被授與 「豁免原則強制執行」的使用者會被授與[允許這兩個新許可權],因此他們可以在 PR 上覆寫完成,並直接推送至具有原則的分支。

如需詳細資訊,請參閱 設定分支許可權 檔。

使用認可訊息快速描述提取要求

撰寫描述性認可訊息會將值新增至任何 Git 存放庫的歷程記錄。 為了鼓勵品質認可訊息,新的提取要求 (具有多個認可的 PR) 將需要參與者手動輸入標題。

提取要求描述預設會繼續空白,但新功能可讓您更輕鬆地將 PR 認可的認可訊息併入 PR 描述中。 若要新增認可訊息,只要按一下 [ 新增認可訊息 ] 即可將認可訊息附加至 PR 描述文字的結尾。

建立沒有預設小組作為檢閱者的提取要求

當我們第一次啟動提取要求 (PR) 體驗時,我們認為將所有 PR 指派給您在建立 PR 時選取的小組內容會很合理。 此行為是一個挫折點,因為許多人未注意到小組內容與 PR 指派之間的連線。

在新的流覽變更過程中,我們有機會變更此預設與小組的關聯。 您會注意到兩項變更:

  1. 建立 PR 時,預設不會新增檢閱者。 檢閱者清單有一項功能,可讓您更輕鬆地新增最近新增至 PR 的個人和群組。 必要的檢閱者原則也可以協助想要確保新增特定檢閱者以檢閱其程式碼的小組。
  2. 提取要求中樞有新的可自訂區段。 根據預設,本節會顯示「指派給我的小組」的 PR,並提供與舊區段相等的功能。 不過,如果您屬於多個小組,本節會顯示指派給任何小組的 PR。 區段也是可自訂的 - 只要按一下區段標頭附近的 [自訂此檢視] 動作即可。

使用範本標準化提取要求描述

撰寫良好的提取要求描述是協助檢閱者瞭解檢閱程式碼時預期狀況的絕佳方式。 它們也是協助追蹤每個變更應完成之事項的絕佳方式,例如測試、新增單元測試,以及更新檔。 許多您都要求我們新增提取要求範本,讓小組更容易撰寫絕佳的描述,而我們現在已新增該功能。

除了支援預設 PR 描述範本之外,小組還可以在 [建立 PR] 頁面上的功能表中新增多個範本。 只要按一下 [ 新增範本] 按鈕,即可從存放庫中的任何範本中選擇,以將其附加至 PR 描述。

Add template for PR

如果您想要將 PR 的不同範本套用至特定分支或分支資料夾,也支援分支特定的範本。 例如,如果您想要擁有所有開頭為 「Hotfix/」的分支特定的範本,您可以將將用於所有 PR 的範本新增至這些分支。

若要深入瞭解如何建立和使用範本,請參閱 提取要求範本 檔。

變更提取要求的目標分支

對於大部分小組而言,幾乎所有提取要求都以相同的分支為目標,例如 maindevelop 。 不過,在您需要以不同的分支為目標的情況下,很容易忘記從預設值變更目標分支。 透過新功能來變更作用中提取要求的目標分支,現在是簡單的動作。 只要按一下提取要求標頭中目標分支名稱附近的鉛筆圖示即可。

Change target branch

除了更正錯誤之外,變更目標分支的功能也可讓您在目標分支已合併或刪除時,輕鬆地「重設目標」提取要求。 假設您有以功能分支為目標的 PR,其中包含您變更相依的某些功能。 您想要檢閱相依變更,使其與功能分支中的其他變更隔離,因此您一開始會以 features/new-feature 為目標。 檢閱者接著只會看到您的變更,並留下適當的批註。

現在,請考慮如果功能分支也具有使用中 PR,並在變更之前合併到 main 中,會發生什麼事? 之前,您必須放棄您的變更,並將新的 PR 建立至 main ,或將 PR 合併至 features/new-feature ,然後從 features/new-feature 建立另一個 PR 到 main 。 透過這個新動作來更新目標分支,您可以直接將 PR 的目標分支從 features/new-feature 變更為 main ,並保留所有內容和批註。 變更目標分支甚至會建立 PR 的新更新,以便輕鬆地在目標分支變更之前查看先前的差異。

Target branch update

擴充功能作者可以查詢目前存放庫的相關內容

版本控制延伸模組作者的其中一項挑戰是取得向使用者顯示存放庫的內容,例如名稱、識別碼和 URL。 為了協助解決此問題,我們新增 VersionControlRepositoryService 作為可存取的延伸模組服務。 因此,擴充功能作者可以查詢 Web UI 中目前 Git 存放庫內容的相關資訊。 它目前有一種方法:getCurrentGitRepository () 。

  • 如果選取 Git 存放庫,則會傳回 GitRepository 物件,其中包含存放庫的基本資料 (名稱、識別碼和 URL)
  • 如果選取了 TFVC 存放庫,或服務是在Azure Repos頁面外部存取,則會傳回 null。

以下是使用此服務的 範例擴充功能

Pipelines

使用新的組建頁面管理組建管線

我們正在進行數項改進,並推出新版本的 [ 組建 ] 頁面。 這個新版本結合了所有組建管線的目錄和目前組建的清單,以便您可以快速流覽專案的組建,以查看其狀態。 它也包含所選管線的測試分析預覽。

New Builds page

使用改良的格式管理組建和部署完成電子郵件

建置和部署完成電子郵件已更新為可透過電子郵件規則篩選。 現在主旨行包含更相關的資訊一目了然,本文包含更多詳細資料,且其樣式已以最新的品牌重新整理。

新格式的元素包括:

  • [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
  • [Deployment result] [pipeline name] > [release name] : [stage name]

以下是一些範例:

  • [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
  • [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

遵循新的統一Azure Pipelines術語

在整個組建和版本中,已針對類似的概念使用不同的詞彙。 在其他情況下,詞彙的意義是模糊的。 例如,告知 代理程式組件區代理程式佇列之間的差異。

術語已統一Azure Pipelines,以厘清其概念。 您現在會看到下列統一詞彙:

上一個字詞 整合詞彙 意義
裝載的代理程式 Microsoft 裝載的代理程式 建置/發行代理程式,可在由 Microsoft 管理的雲端裝載基礎結構上執行。
私人代理程式 自我裝載的代理程式 建置/發行代理程式,可在您提供和管理的電腦上執行。
代理程式組件區 代理程式組件區 可執行組建或發行的組織層級代理程式機器集。
代理程式佇列 代理程式組件區 可執行組建或發行的代理程式機器專案層級集合。 它會連結到組織層級的代理程式組件區。
組建定義 建置管線 應用程式的端對端建置步驟集。
Build Build 正在執行或已執行的組建管線實例。
階段 工作 (Job) 一系列在代理程式上循序或平行執行的工作。 組建或發行管線可以包含一個作業或多個作業的圖表。
發行定義 發行管線 一組端對端發行步驟,可讓應用程式跨各種階段部署。
版本 版本 執行或已執行之發行管線的實例。
環境 階段 邏輯和獨立實體,代表您想要部署從發行管線產生之發行的位置。
並行作業/管線 平行作業 平行作業可讓您在組織中一次執行單一組建或發行作業。 使用更多可用的平行作業,您可以同時執行更多建置和發行作業。
服務端點 服務連線 一組設定,例如認證,用來連線到外部服務,以在組建或版本中執行工作。

如需詳細資訊 ,請參閱概念 檔。

使用新版本頁面管理發行管線

發行登陸頁面提供全新且完全重新設計的使用者體驗。 查看您經常在左側發行的發行管線清單。 您也可以搜尋管線並將它們加入我的最愛。

Release landing page

變更為資料夾檢視,以建立組織和安全性的資料夾。 安全性可以在資料夾層級設定。

Release folders

將發行進度視覺化

新的發行進度檢視可讓您即時更新部署進度,然後按一下存取以取得進一步的詳細資料。 新的檢視會將發行管線視覺化,讓您更輕鬆地瞭解發生的情況,並在發行的不同階段呈現適當的詳細資料和動作。

Release Pipeline view

管線、發行詳細資料和環境

[ 管線 ] 檢視會顯示發行的成品及其部署所在的環境。 [ 發行 ] 區域提供發行詳細資料,例如發行觸發程式、成品版本和標記。

環境會以一種方式建立模型,以協助瞭解其狀態,以及詳細的進度。 您可以隨時按一下環境內的狀態連結來取得記錄。

Environments

部署前和部署後

如果已針對環境設定部署前或部署後條件,則會在具有核准和閘道的環境中指出。 核准和閘道的進度也會顯示在環境的狀態中。 您可以按一下環境條件圖示停在環境右側或左側,以採取動作或檢視進一步的詳細資料。

Release environment actions

認可和工作專案

透過每個新版本,您可以按一下環境,分別查看每個環境的相關認可和工作專案清單。 如果清單很長,請使用篩選來尋找您感興趣的認可或工作專案。

Release commits and work items

部署進度和記錄

環境會顯示進行中部署的即時更新,包括完成的階段和工作數目和執行時間。 按一下環境狀態會開啟包含記錄的檢視,並將焦點放在目前作用中的專案。

您可以按一下記錄以輸入焦點檢視。

Release log details

升級至 2019 Azure DevOps Server對工作的影響:Windows目的電腦上的電腦檔案複製和 PoweShell

測試中樞下的機器群組在 TFS 2017 RTM 中 已被取代 。 使用 Azure DevOps Server 2019 時,電腦群組服務將無法再使用。 這會影響「Windows電腦檔案複製」工作 1.* 版和「目的機器上的 PowerShell」工作版本 1.*的使用者。 若要讓管線繼續運作,

  • 您必須切換至 [Windows電腦檔案複製] 工作 2.* 版,並提供目的電腦的完整 fqdn,而不只是電腦名稱稱。
  • 然後切換至 [目的機器上的 Powershell] 工作 2.* 版或更新版本,並提供電腦或電腦名稱稱的完整 fqdn,後面接著Windows遠端系統管理埠, (HTTP/HTTPs) 。 例如,targetMachine:5985 或 targetMachine:5986

測試結果和擴充性

測試執行的結果也會針對每個環境呈現。 按一下測試結果會開啟包含測試詳細資料的檢視,包括參與程式之其他延伸模組的結果。

Release test results

現有的延伸模組可在這個新檢視中運作,再加上新的擴充點,可讓延伸模組開發以呈現環境的詳細資訊。 如需詳細資訊 ,請參閱參與和延伸模組 檔。

使用 YAML 設定組建

YAML 建置管線可在您的Azure DevOps Server中使用。 使用簽入存放庫的 YAML 檔案,將您的持續整合管線自動化。 您可以 在這裡找到 YAML 架構的完整參考。

為了更順暢地支援 YAML 型建置管線,我們已變更您所建立 (之所有新資源的預設行為,例如服務連線、變數群組、代理程式組件區和安全檔案,) 可在該專案的所有管線中使用。 如果您想要更緊密地控制資源,您可以停用預設授權模型, (請參閱下圖) 。 當您這樣做時,具有使用資源許可權的人員必須在將資源參考新增至 YAML 檔案之後,明確地將管線儲存在 Web 編輯器中。

YAML

大型產品有數個彼此相依的元件。 這些元件通常會獨立建置。 當上游元件 (程式庫時,例如) 變更時,必須重建並重新驗證下游相依性。 Teams通常會手動管理這些相依性。

現在,您可以在成功完成另一個組建時觸發組建。 上游組建所產生的Artifacts可以下載並用於稍後的組建,您也可以從下列變數取得資料:Build.TriggeredBy.BuildId、Build.TriggeredBy.DefinitionId、Build.TriggeredBy.BuildDefinitionName。 如需詳細資訊 ,請參閱組建觸發 程式檔。

Setup build chaining

請記住,在某些情況下,單一 多階段建置 可能符合您的需求。 不過,如果您的需求包含不同的組態設定、選項或不同的小組來擁有相依程式,建置完成觸發程式就很有用。

在本機更新代理程式

您從資源庫安裝的工作有時需要較新版本的管線代理程式。 如果您的Azure DevOps Server可以連線到網際網路,則會自動下載較新版本。 如果沒有,則您必須手動升級每個代理程式。 從此版本開始,您可以設定Azure DevOps Server,以在其本機磁片上尋找代理程式封裝檔案,而不是從網際網路尋找。 這可讓您彈性和控制您提供的代理程式版本,而不需要向網際網路公開您的Azure DevOps Server。

新增組建狀態徽章 URL

內嵌在存放庫首頁的組建徽章是顯示存放庫健康情況的常見方式。 雖然我們已經有組建徽章,但有一些問題:

  • URL 不是直覺式
  • 徽章不是分支特有的
  • 使用者無法按一下徽章,讓使用者前往該定義的最新組建

我們現在推出適用于建置徽章的新 API,以解決這些問題。 新的 API 可讓使用者發佈每個分支的狀態,並可讓使用者前往所選分支的最新組建。 您可以在新的組建頁面中選取 [狀態徽章] 功能表動作,以取得新狀態徽章 URL 的 Markdown。

為了回溯相容性,我們也會繼續接受較舊的組建徽章 URL。

將自訂群組建計數器新增至您的組建

組建計數器提供唯一編號和標籤組建的方式。 先前,您可以使用 $ (rev:r) 特殊變數來完成此作業。 現在,您可以在每次執行組建時自動遞增的組建定義中定義自己的計數器變數。 您可以在定義的 [變數] 索引標籤上執行此動作。 這項新功能可讓您以下列方式提供更多功能:

  • 您可以定義自訂計數器並設定其種子值。 例如,您可以在 100 啟動計數器。 $ (rev:r) 一律從 0 開始。
  • 您可以使用自己的自訂邏輯來重設計數器。 $ (rev:r) 系結至組建編號產生,而且每當組建編號中有新的前置詞時,就會自動重設。
  • 您可以為每個定義定義定義多個計數器。
  • 您可以在組建外部查詢計數器的值。 例如,您可以使用計數器計算自上次重設後已執行的組建數目。

如需組建計數器的詳細資訊,請參閱 使用者定義變數 的相關檔。

在 Pipelines 中Azure 原則合規性和安全性驗證

我們想要確保軟體在開發程式中的穩定性和安全性,同時將開發、安全性和作業整合在一起。 為了這樣做,我們已新增對Azure 原則的支援。

Azure 原則可協助您進行管理,同時透過原則定義讓您的資源強制執行規則並產生效果,避免發生 IT 問題。 當您使用Azure 原則時,資源會符合公司標準和服務等級協定的規範。

為了在發行過程中遵守合規性和安全性指導方針,我們已增強 Azure 資源群組部署體驗。 現在,在部署 ARM 範本時發生任何違規時,我們失敗了與相關原則相關的原則相關錯誤。

Azure Policy

此外,我們已新增Azure 原則發行定義範本。 這可讓使用者建立 Azure 原則,並從發行定義本身將這些原則指派給資源、訂用帳戶或管理群組。

Azure Policy template

在 Linux/ARM 和 Windows 32 位平臺上建置

64 位 (x64) Windows、macOS 和 Linux 上一律支援Azure Pipelines 開放原始碼、跨平臺代理程式。 在此版本中,我們引進了兩個新的支援平臺:Linux/ARM 和 Windows/32 位。 這些新平臺可讓您以較不常見的平臺為基礎建置,但不重要,例如 Raspberry Pi、Linux/ARM 電腦。

改善Pipelines中測試的體驗

[測試] 索引標籤現在有新式體驗,可提供您豐富的內容內Pipelines測試資訊。 新的體驗提供進行中測試檢視、完整頁面偵錯體驗、內容測試歷程記錄、報告中止的測試執行,以及執行層級摘要。

New Test hub

檢視進行中的測試執行

整合和功能測試等測試可以長時間執行,因此請務必在任何指定時間查看測試執行。 使用 [In-Progress測試檢視],您不再需要等待測試執行完成,才能知道測試結果。 結果會在執行時以近乎即時的方式提供,協助您更快採取動作。 您可以偵錯失敗或中止、提出 Bug 或中止管線。 此功能目前適用于在多代理程式中使用 VS 測試工作的建 置和發行管線,使用 發佈測試結果工作 ,或使用 API () 發佈測試結果。 未來,我們計畫使用單一代理程式擴充此體驗以進行測試執行。

下列檢視顯示新發行進度檢視中的In-Progress測試摘要、報告指定時間點的測試失敗總數和測試失敗數目。

In-progress test view

按一下上述In-Progress測試摘要,即可檢視詳細的測試摘要,以及Test Plans中失敗或中止的測試資訊。 根據新結果的可用性,測試摘要會定期重新整理,並能夠視需要重新整理詳細資料檢視。

Detailed test summary

在完整頁面中檢視測試回合偵錯詳細資料

錯誤訊息和堆疊追蹤本質上很冗長,而且需要足夠的房地產,才能在偵錯期間檢視詳細資料。 若要擁有沉浸式偵錯體驗,您現在可以將測試或測試回合檢視展開至完整頁面檢視,同時仍能夠在內容作業中執行所需的 ,例如錯誤建立或目前測試結果的需求關聯。

Full page debugging

檢視內容中的測試歷程記錄

在過去,小組必須移至 [ 執行 ] 中樞,才能檢視測試結果的歷程記錄。 有了新的體驗,我們會將測試歷程記錄直接放在建置和發行Test Plans索引標籤的內容中。 測試歷程記錄資訊是以漸進方式提供,從目前所選測試的組建定義或環境開始,接著分別提供組建和發行的其他分支和環境。

In-context test history

檢視中止的測試

測試執行可能會因為多種原因而中止,例如錯誤的測試程式碼、測試中的來源,以及環境變數。 不論中止的原因為何,請務必診斷行為並識別根本原因。 您現在可以在Test Plans中檢視中止的測試與測試回合,以及已完成的執行。 此功能目前適用于在多代理程式中使用 VS 測試 工作的組建和發行管線,或使用 API (s) 發佈測試結果。 未來,我們計畫使用單一代理程式擴充此體驗以進行測試執行。

View aborted tests

測試歷程記錄中的測試可追蹤性和發行環境支援

我們新增了檢視自動化測試歷程記錄的支援,這些測試會依執行測試的各種發行環境分組。 如果您要將發行環境模型化為發行管線或測試環境,並在這類環境中執行測試,則可以瞭解測試是否在開發環境中通過,但在整合環境中失敗。 您可以瞭解其是否傳入英文地區設定,但在具有土耳其文地區設定的環境中失敗。 針對每個環境,您將找到最新測試結果的狀態,如果測試在該環境上失敗,您也會發現版本,因為測試失敗。

檢閱摘要測試結果

在測試執行期間,測試可能會繁衍對整體結果造成多個測試實例。 一些範例包括: 由於失敗而重新執行的測試、由其他測試排序組合所組成的測試 (,例如已排序的測試) ,或根據所提供的輸入參數 (資料驅動測試) ,擁有不同實例的測試。 因為這些測試是相關的,所以必須一起報告,以及根據個別測試結果衍生的整體結果。 透過此更新,我們會在發行的 [ 測試 ] 索引標籤中引進一個改善版本的測試結果,以階層形式呈現。 讓我們看看下列範例。

稍早,我們引進了在VS 測試工作中重新執行失敗測試的能力。 不過,我們只會報告測試的最後一次嘗試,這稍微限制此功能的實用性。 我們現在已擴充這項功能,以嘗試報告測試執行的每個實例。 此外,測試管理 API 現在支援發佈和查詢階層式測試結果的功能。 如需詳細資訊,請參閱 測試結果 API 檔。

Test summary debug

注意

測試摘要區段中的計量 (例如總測試、通過等) ,會使用階層的根層級來計算,而不是測試的每個個別反復專案。

在 Pipelines 中檢視測試分析

追蹤一段時間的測試品質並改善測試附隨品是維護狀況良好管線的關鍵。 測試分析功能可讓您近乎即時地查看組建和發行管線的測試資料。 它可藉由識別重複、高影響品質的問題,來協助改善管線的效率。

您可以依各種元素分組測試結果、識別分支或測試檔案的關鍵測試,或向下切入至特定測試,以檢視趨勢並瞭解品質問題,例如 flakiness。

檢視 組建發行的測試分析,預覽如下:

Test analytics

如需詳細資訊,請參閱文件

使用多個無代理程式工作簡化定義

無代理程式階段中的工作是由 伺服器協調並執行。 無代理程式階段不需要代理程式或任何目的電腦。 不同于代理程式階段,定義中的每個無代理程式階段只能新增一項工作。 這表示當進程中有多個無代理程式工作時,必須新增多個階段,讓定義變得大量。 我們已放寬這項限制,可讓您在無代理程式階段中維護多個工作。 相同階段的工作會循序執行,就像它們針對代理程式階段所做的一樣。 如需詳細資訊 ,請參閱伺服器階段 檔。

使用發行閘道漸進式揭露和階段部署

使用發行閘道,您可以指定在發行升級至下一個環境之前必須符合的應用程式健康情況準則。 所有指定的閘道都會在任何部署之前或之後定期評估,直到它們全部成功為止。 現有四種類型的閘道可供使用,您可以從 Marketplace新增更多閘道。 您將能夠稽核已符合部署的所有必要準則。 如需詳細資訊,請參閱發行管制文件

Release gates panel

保留部署,直到閘道持續成功

發行閘道會在發行升級至下一個環境之前,啟用健康情況準則的自動評估。 根據預設,發行會在收到所有閘道的一個成功範例之後進行。 即使閘道不穩定且成功收到的樣本是雜訊,發行仍會進行。 若要避免這些類型的問題,您現在可以設定發行,在進行之前先確認健全狀況的一致性。 在執行時間,發行可確保閘道的連續評估成功,再允許升級。 評估的總時間取決於「重新評估之間的時間」,而且通常大於設定的最小持續時間。 如需詳細資訊,請參閱 使用閘道發行部署控制 檔。

Gates hold setting

自動部署到部署群組中的新目標

之前,當新的目標新增至部署群組時,需要手動部署,以確保所有目標都有相同的版本。 您現在可以將環境設定為自動將最後一次成功發行部署到新目標。 如需詳細資訊,請參閱 部署群組 檔。

Deployment groups

持續部署建置後處理所標記的組建

持續部署觸發程式會在建置完成時建立發行。 不過,有時候會後續處理組建,而且該處理完成之後,才應該釋出組建。 現在,您可以在發行的觸發程式篩選中,利用在後續處理期間指派的組建標籤。

build tag trigger

在發行時間設定變數

在發行定義中,您現在可以選擇建立發行時想要設定的變數。

Release variable

建立發行時,為變數提供的值只會用於該版本。 這項功能可協助您避免建立草稿中的多個步驟、更新草稿中的變數,以及使用 變數觸發發行。

Release variable in release

將環境變數傳遞至工作

CI/CD 工作作者可以在 task.json 中設定新的屬性 showEnvironmentVariables,以將環境變數傳遞至工作。 當您這樣做時,會在建置編輯器中的工作上轉譯額外的控制項。 這適用于 PowershellCmdBash 工作。

Pass environment variables

這可啟用兩種案例:

  • 工作需要環境變數,並在變數名稱中保留大小寫。 例如,在上述範例中,傳遞至工作的環境變數會是 「foo」,而不是 「FOO」。
  • 它可讓秘密值以安全的方式傳遞至腳本。 這是偏好將秘密當做引數傳遞至腳本,因為代理程式上的作業系統可能會記錄進程的叫用,包括其引數。

複製變數群組

我們已新增複製變數群組的支援。 每當您想要複寫變數群組並只更新幾個變數時,就不需要逐一新增變數的繁瑣程式。 您現在可以快速建立變數群組的複本、適當地更新值,並將它儲存為新的變數群組。

Clone variable group

注意

當您複製變數群組時,不會複製秘密變數值。 您需要更新加密的變數,然後儲存複製的變數群組。

忽略部署的發行閘道

發行閘道會在發行升級至下一個環境之前,啟用健康情況準則的自動評估。 根據預設,只有在所有閘道同時狀況良好時,發行管線才會進行。 在某些情況下,例如在快速編輯發行或手動檢查健康情況之後,核准者可能會想要忽略閘道,並允許該閘道進行,即使該閘道尚未評估為狀況良好也一樣。 如需詳細資訊,請參閱 發行閘道 檔。

Ignore gates

使用提取要求發行觸發程式執行其他測試

您能夠根據提取要求 (PR) 觸發建置,並在合併一段時間之前取得該快速意見反應。 現在您也可以設定發行的 PR 觸發程式。 發行的狀態會張貼回程序代碼存放庫,並可直接在 PR 頁面中看到。 如果您想要在 PR 工作流程中執行其他功能或手動測試,這會很有説明。

PR trigger in Release

使用憑證驗證的服務主體建立 Azure 服務連線

您現在可以使用服務主體和憑證來定義 Azure 服務連線以進行驗證。 使用 Azure 服務連線現在支援使用憑證進行驗證的服務主體,您現在可以部署至使用AD FS設定的Azure Stack。 若要使用憑證驗證建立服務主體,請參閱 有關如何建立使用憑證進行驗證的服務主體一文。

Connect with service principal

從部署Azure App 服務支援的套件執行

Azure App 服務部署工作 (4.*) 版本現在支援先前稱為 RunFromZip 的 RunFromPackage (。

App Service支援數種不同的技術來部署您的檔案,例如 msdeploy (也稱為 WebDeploy) 、git、ARM 等等。 但所有這些技術都有限制。 您的檔案會部署在 wwwroot 資料夾底下, (特別 d:\home\site\wwwroot) ,然後執行時間會從該處執行檔案。

使用 [從封裝執行] 時,不再有將個別檔案複製到 wwwroot 的部署步驟。 相反地,您只需將它指向 zip 檔案,zip 會掛接在 wwwroot 上做為唯讀檔案系統。 這有幾項優點:

  • 減少檔案複製鎖定問題的風險。
  • 可以部署到生產應用程式 (透過重新啟動)。
  • 您可以確定在應用程式中執行的檔案。
  • 改善Azure App 服務部署的效能。
  • 可縮短冷啟動時間,特別是針對具有大型 npm 套件樹狀結構的 JavaScript 函式。

使用 App Server Deploy 工作部署 Linux 容器

Azure App 服務部署工作的 4.* 版本現在支援將您自己的自訂容器部署至Linux 上的Azure Functions

適用于 Azure Functions 的 Linux 裝載模型是以 Docker 容器為基礎,可針對封裝及運用應用程式特定相依性帶來更大的彈性。 Linux 上的函式可以裝載于 2 種不同的模式:

  1. 內建容器映射: 您帶入函式應用程式程式碼,Azure 會提供和管理容器 (內建映射模式) ,因此不需要任何特定的 Docker 相關知識。 現有版本的 App Service 部署工作支援此功能。
  2. 自訂容器映射:我們已增強App Service部署工作,以支援將自訂容器映射部署至 Linux 上的Azure Functions。 當您的函式需要特定語言版本,或需要內建映射中未提供的特定相依性或組態時,您可以使用 Azure Pipelines,在 Linux 上建置自訂映射並將其部署至 Azure Function。

Xcode 工作支援新發行的 Xcode 10

透過 Apple 的 Xcode 10 版本,您現在可以將專案設定為建置,或特別使用 Xcode 10 進行測試。 您的管線也可以使用 Xcode 版本的 矩陣 平行執行作業。 您可以使用 Microsoft 裝載的 macOS 代理程式組件區來執行這些組建。 請參閱在 Azure Pipelines 中使用 Xcode 的指引

Xcode 10

使用 Helm 簡化 Kubernetes 的部署

Helm 是簡化安裝和管理 Kubernetes 應用程式的工具。 它在去年也獲得許多熱門度和社群支援。 發行中的 Helm 工作現在可用於封裝 Helm 圖表,並將其部署至Azure Container Service (AKS) 或任何其他 Kubernetes 叢集。

新增此 Helm 工作後,您現在可以設定 Helm 型 CI/CD 管線,以將容器傳遞至 Kubernetes 叢集。 如需詳細資訊,請參閱 使用 Kubernetes 部署至 Azure Container Service 檔。

helm tasks

控制發行中使用的 Helm 版本

Helm 工具安裝程式工作會從網際網路或工具快取取得特定版本的 Helm,並將它新增至代理程式 (裝載或私人) 的 PATH。 使用此工作來變更後續工作中使用的 Helm 版本,例如 .NET Core cli 工作。 在組建或發行定義中的 Helm 部署 工作之前新增此工作,可確保您使用正確的 Helm 版本來封裝和部署應用程式。 這項工作也有助於選擇性地安裝 kubectl 工具,這是 Helm 運作的必要條件。

持續部署至適用於 MySQL 的 Azure 資料庫

您現在可以持續部署到適用於 MySQL 的 Azure 資料庫- Azure 的 MySQL 資料庫即服務。 在版本控制中管理 MySQL 腳本檔案,並使用原生工作而非 PowerShell 腳本,持續部署為發行管線的一部分。

使用改良Windows遠端 PowerShell 型工作

有新的和改良Windows遠端 PowerShell 型工作可供使用。 這些改進包括數個效能修正,並支援即時記錄和主控台輸出命令,例如Write-Host和 Write-Output。

目標工作上的 PowerShell (版本:3.*) :您可以新增內嵌腳本、修改 PSSession 選項、控制 「ErrorActionPreference」,並在標準錯誤時失敗。

Azure 檔案複製工作 (版本:2.*) :隨附最新的 AzCopy (v7.1.0) ,以解決GitHub問題

篩選GitHub Enterprise或外部 Git 成品的分支

從 GitHub Enterprise 或外部 Git 存放庫發行時,現在您可以設定將發行的特定分支。 例如,您可能只想將來自特定分支的組建部署到生產環境。

branch filters

建置以 Go 撰寫的應用程式

使用 Go 工具安裝程式 工作,即時安裝一或多個 Go 工具版本。 此工作會取得專案所需的特定 Go 工具版本,並將它新增至組建代理程式的 PATH。 如果代理程式上已安裝目標 Go 工具版本,此工作將會略過下載並再次安裝的程式。

Go工作可協助您下載相依性、建置或測試應用程式。 您也可以使用此工作來執行您選擇的自訂 Go 命令。

在管線中執行內嵌或以檔案為基礎的 Python 腳本

新的 Python 腳本 工作可簡化在管線中執行 Python 腳本。 此工作會從您存放庫中的 Python 檔案 (.py) 執行腳本,或者您可以在工作的設定中手動輸入腳本,以儲存為管線的一部分。 此工作將使用路徑中的 Python 版本,或者您可以指定要使用的 Python 解譯器絕對路徑。

利用 xcpretty 改善的 Xcode 建置和測試輸出

xcpretty 可增強 xcodebuild 輸出的可讀性,並以 JUnit 格式產生測試結果。 Xcode 建置工作現在會在代理程式電腦上使用時自動使用 xcpretty,因為它位於託管的 macOS 代理程式上。 雖然 xcpretty 輸出可能不同且比 xcodebuild 輸出更不詳細,但我們讓每個組建都能使用完整的 xcodebuild 記錄。

Test Plans

測試執行器 (Azure Test Plans) 用戶端執行傳統型應用程式的手動測試

您現在可以使用測試執行器 (Azure Test Plans) 用戶端來執行傳統型應用程式的手動測試。 這可協助您從 Microsoft Test Manager 移至 Azure Test Plans。 請參閱 這裡的指引。 使用測試執行器用戶端,您可以執行手動測試,並記錄每個測試步驟的測試結果。 您也有資料收集功能,例如螢幕擷取畫面、影像動作記錄和音訊視訊錄製。 如果您在測試時發現問題,請使用測試執行器來建立 Bug,其中包含自動包含在 Bug 中的測試步驟、螢幕擷取畫面和批註。

測試執行器 (Azure Test Plans) 需要一次性下載並安裝執行器。 選取 [針對傳統型應用程式執行 ],如下所示。

Azure Test Runner

Azure Test Runner install

Artifacts

上游來源

Azure DevOps Server 2019 為Azure Artifacts摘要上可用的上游來源帶來大量更新:

  • 您可以將 nuget.org 上游來源新增至在舊版 TFS 中建立的現有摘要。 尋找摘要套件上方的橫幅以取得詳細資訊,包括升級之前應該注意的行為變更。
  • 您可以將其他Azure DevOps Server摘要新增為摘要的上游來源,這表示您可以透過摘要使用這些摘要中的NuGet和 npm 套件。

我們也在Azure Artifacts中引進了新的角色:「共同作業者」。 共同作業者可以從上游來源儲存套件,但無法直接將套件套件發佈至摘要 (,例如使用 nuget 發佈) 。 這可讓您限制套件發佈至受信任的使用者或組建系統,同時讓您的工程師能夠從上游來源使用新的套件。

遵循套件

我們已讓您更輕鬆地在每個套件上直接使用新的 [ 追蹤] 按鈕來設定通知。 [遵循]按鈕也與發行檢視相容。 如果您在檢視套件時追蹤套件,則只會取得升級至該檢視之新版本的更新。

變更摘要設定,而不需手動儲存

摘要設定頁面上的一些互動已改善。 現在,您所做的變更,例如新增上游或許可權,會立即儲存。 這表示當您在設定樞紐之間切換時,不需要擔心遺失變更。

Simplify authentication using the new cross-platform Credential Provider for NuGet (使用適用於 NuGet 的全新跨平台認證提供者來簡化驗證)

與已驗證的NuGet摘要互動只會變得更好。 新的 .NET Core 型Azure Artifacts認證提供者可在 Windows、macOS 和 Linux 上使用 msbuild、dotnet 和 nuget (.exe) 。 每當您想要從Azure Artifacts摘要使用套件時,認證提供者會自動取得並儲存權杖,代表您使用的NuGet用戶端。 您不再需要在組態檔中手動儲存和管理權杖。

若要取得新的提供者,請前往GitHub,並遵循用戶端和平臺的指示。

Compress symbols when publishing to a file share (在對檔案共用進行發佈時壓縮符號)

我們已更新 [索引 & 發佈符號] 工作 ,以支援將符號發佈至檔案共用時壓縮符號。

Compress symbols

Wiki

將 Markdown 檔案從 Git 存放庫發佈為 Wiki

開發人員會在程式碼存放庫中建立「API」、「SDK」和「說明程式碼的說明文件」檔。 接著,讀者必須篩選程式代碼,才能尋找正確的檔。 現在,您只要從程式碼存放庫發佈 Markdown 檔案,並將其裝載在 Wiki 中即可。

public code as wiki action

從 Wiki 中,從按一下 [ 發佈程式碼為 Wiki] 開始。 接下來,您可以在應該升級的 Git 存放庫中指定資料夾。

publish pages dialog

按一下 [ 發佈] 之後,選取資料夾下的所有 Markdown 檔案都會發佈為 Wiki。 這也會將分支的前端對應至 Wiki,以便立即反映您對 Git 存放庫所做的任何變更。

如需詳細資訊,請參閱 產品檔部落格文章

現在,您可以按一下 Wiki 頁面中任何區段標題旁的連結圖示,直接產生該區段的 URL。 然後,您可以複製該 URL,並與小組成員共用,以將它們直接連結到該區段。

Wiki heading URL

在資料夾中附加檔案和影像

在離線編輯 Wiki 頁面時,在與 Wiki 頁面相同的目錄中新增檔案附件和影像會比較容易。 現在,您可以在 Wiki 中的任何資料夾中新增附件或影像,並將其連結至您的頁面。

Wiki image in git repo folder

Embed a video in wiki (在 Wiki 中內嵌影片)

現在您可以從 Microsoft Stream 和 YouTube 等線上服務將影片內嵌在 wiki 頁面中。 您可以使用下列語法來新增內嵌影片 URL:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Embed video in wiki

Rename a wiki (重新命名 Wiki)

現在您可以在 Wiki 使用者介面中重新命名 Wiki,並使用 REST API。 從 [更多] 功能表中,按一下 [重新命名 wiki ],為您的 Wiki 提供易記的名稱。

Rename wiki

在新索引標籤中開啟頁面

現在您可以以滑鼠右鍵按一下 Wiki 頁面,然後在新的索引標籤中開啟它,或直接按 CTRL + 在 Wiki 頁面上按一下滑鼠右鍵,以在新索引標籤中開啟它。

Wiki new tab

在 Wiki 頁面標題中保留特殊字元

您現在可以建立具有特殊字元的 Wiki 頁面,例如 : < > * ? | - 。 現在有標題的頁面,例如 「FAQ?」 或在 Wiki 中建立「設定指南」。 下列字元會轉譯為其 UTF-8 編碼字串:

字元 編碼字串
: %3A
< %3C
> %3E
* %2A
? %3F
| %7C
- %2D

Wiki 中未正確連結的所有連結都會以不同的紅色和中斷的連結圖示顯示,讓您在 Wiki 頁面中顯示所有中斷連結的視覺線索。

Wiki broken links

分頁連結是任何檔解決方案中頁面品質不佳的其中一個前置原因。 先前在 Wiki中,當您在樹狀結構內移動頁面或重新命名頁面時,可能會中斷與其他頁面和工作專案之頁面的連結。 現在,您可以在連結中斷之前先檢查並修正連結。

重要

請記得使用 []() 頁面連結的 Markdown 語法,以及工作專案中的 Wiki 頁面 連結類型,以允許 Wiki 尋找並修正這些可能中斷的連結。 此功能不會挑選工作專案中的純文字 URL 和超連結。

當您重新命名或移動頁面時,系統會提示您檢查受影響的絕對或相對連結。

Move page dialog

然後,您會在採取動作之前,顯示頁面 連結 和受影響的 工作專案 清單。

Move page links

建立 Wiki 頁面的目錄

有時候 Wiki 頁面可能會很長,內容會組織成數個標題。 現在,您可以使用 語法,將目錄新增至至少有一個標題 [[_TOC_]] 的任何頁面。

Wiki table of contents

您也可以在編輯頁面時按一下格式窗格中的適當按鈕來插入目錄。

Insert wiki TOC

如需在 Azure DevOps中使用 Markdown 的詳細資訊,請參閱Markdown 指引檔。

使用 YAML 標籤的 Wiki 頁面和程式碼預覽的 Surface 中繼資料

將中繼資料新增至檔可協助讀者和搜尋索引挑選並呈現有意義的內容。 在此更新中,檔案開頭包含 YAML 區塊的任何檔案都會轉換成一個前端和一個資料列的中繼資料資料表。 YAML 區塊必須採用三虛線之間的有效 YAML 設定形式。 它支援所有基本資料類型、清單、物件做為值。 Wiki和程式碼檔案預覽支援語法。

YAML 標記範例:

---
tag: post
title: Hello world
---

YAML table

YAML 標記範例與清單:

---
tags:
- post
- code
- web
title: Hello world
---

YAML table with list

使用參與許可權將程式碼發佈為 Wiki

稍早,只有擁有 Git 存放 建立存放庫許可權的使用者才能將程式碼發佈為 Wiki。 這讓存放庫管理員或建立者成為任何要求將裝載于 git 存放庫中的 Markdown 檔案發佈為 Wiki 的瓶頸。 現在,如果您剛擁有程式碼存放庫的「參與」許可權,就可以將程式碼發佈為 wiki

報告

報表的分析市集擴充功能現已推出

Analytics Marketplace 擴充功能現在可供Azure DevOps Server使用。 分析是報告Azure DevOps和Azure DevOps Server的未來。 安裝 Analytics 擴充功能可提供進階小工具Power BI整合OData 存取

如需詳細資訊,請參閱什麼是分析和報告藍圖。 分析處於公開預覽狀態。 它目前包含透過Pipelines Boards和自動化測試結果的資料。 請參閱 Analytics Service 中可用的資料

透過新的組建儀表板小工具調查組建歷程記錄

我們有新的和改良的建置歷程記錄小工具,您可以新增至儀表板。 透過此小工具,您現在可以檢視儀表板上特定分支的組建歷程記錄,並在匿名訪客的公用專案上進行設定。

重要

如果您要尋找 XAML 組建的深入解析,請繼續使用較舊的小工具,並閱讀 從 XAML 組建移轉至新組建的相關資訊。 否則,建議您移至較新的小工具。


意見反應

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


頁面頂端