Azure DevOpsServer 2020 Update 1 版本資訊

| 開發人員社群System 需求 | 授權條款 | DevOps部落格 | SHA-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 2020 Update 1.2 發行日期:2022 年 5 月 17 日

Azure DevOps Server 2020 Update 1.2是錯誤修正的匯總。 您可以直接安裝 Azure DevOps Server 2020 Update 1.2 或從 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更新版本升級。

注意

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

此版本包含下列專案的修正:

  • Azure DevOps Server 2020.1.2 會停用 Azure DevOps Server 2020) 中引進的新保留 (模型,以避免 (組建) 遺失管線執行。 這表示系統會:

    • 針對執行 Server 2020 時產生的最近 3 個組建建立租用
    • 針對不含每個管線保留原則的 YAML 管線和傳統管線,組建會根據 集合層級的保留設定上限來保留
    • 針對具有自訂個別管線保留原則的傳統管線,組建會根據管線特定的保留原則來保留
    • 具有租用的組建不會計入 [最小保留] 設定
  • 變更集和擱置集批註連結未正確重新導向。 將批註新增至變更集或擱置集中的檔案時,選取這些批註不會重新導向至檔案檢視中的正確位置。

  • 無法使用 [執行下一步] 按鈕略過建置佇列。 先前,僅針對專案集合管理員啟用 [執行下一步] 按鈕。

  • 停用使用者的 Active Directory 帳戶之後,撤銷所有個人存取權杖。

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

我們已針對 2020.1.1 Azure DevOps Server發行修補程式,其中包含下列專案的修正程式。

  • 使用 @mention 工作專案中的 控制項時,不會傳送電子郵件通知。
  • 在使用者設定檔中未更新慣用的電子郵件地址。 這會導致電子郵件傳送至先前的電子郵件地址。
  • 標頭未顯示在 [Project摘要] 頁面中。 標頭會顯示數毫秒,然後消失。
  • Active Directory 使用者同步的改善。
  • 從 log4j 二進位檔移除 jndilookup 類別,以解決 Elasticsearch 弱點。

安裝步驟

  1. 使用 Patch 4升級伺服器。
  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 4升級伺服器。
  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 雜湊: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 修補程式 3 發行日期:2021 年 12 月 15 日

Azure DevOps Server 2020.1.1的修補程式 3包含下列修正程式。

  • 修正具有「包含文字」之查詢的工作專案宏。 先前,查詢會針對包含分行符號的值傳回不正確的結果。
  • 增加 Maven 套件版本字元長度的限制。
  • 自訂工作專案版面配置狀態的當地語系化問題。
  • 電子郵件通知範本中的當地語系化問題。
  • 針對欄位定義多個 NOTSAMEAS 規則時,NOTSAMEAS 規則評估的問題。

Azure DevOps Server 2020.1.1 修補程式 2 發行日期:2021 年 10 月 26 日

Azure DevOps Server 2020.1.1的修補程式 2包含下列修正程式。

  • 先前,Azure DevOps Server只能建立與 GitHub Enterprise Server 的連線。 透過此修補程式,專案管理員可以在 GitHub.com 上建立 Azure DevOps Server 與存放庫之間的連線。 您可以在[Project 設定] 底下的 [GitHub連線]頁面中找到此設定。
  • 解決測試計劃小工具的問題。 測試執行報告在結果上顯示不正確的使用者。
  • 修正無法載入Project [概觀摘要] 頁面的問題。
  • 修正未傳送電子郵件以確認產品升級的問題。

Azure DevOps Server 2020.1.1 修補程式 1 發行日期:2021 年 9 月 14 日

Azure DevOps Server 2020.1.1的修補程式 1包含下列修正程式。

  • 修正Artifacts下載/上傳失敗。
  • 解決測試結果資料不一致的問題。

Azure DevOps Server 2020 Update 1.1 發行日期:2021 年 8 月 17 日

Azure DevOps Server 2020 Update 1.1是錯誤修正的匯總。 您可以直接安裝 Azure DevOps Server 2020 Update 1.1 或從 Azure DevOps Server 2020 或 Team Foundation Server 2013 或更新版本升級。

注意

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

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

Azure Boards

  • 通知電子郵件中的「檢視工作專案」超連結未使用公用 URL。

Azure Repos

  • 已修正限制合併類型繼承核取方塊顯示,以在設定跨存放庫原則之後啟用修改限制合併類型。

Azure Pipelines

  • 變更代理程式更新的設定時,設定不會傳播至環境中的其他應用層。

一般

  • 已修正伺服器組態精靈中的拼字。
  • 增加擴充功能套件大小,並可讓您變更登錄中的大小。

Azure Test Plans

  • 從歷程記錄回到摘要頁面後,無法流覽回測試結果。

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

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

  • 修正組建定義 UI 錯誤。
  • 已變更流覽歷程記錄以顯示檔案,而不是根存放庫。

Azure DevOps Server 2020.1 Patch 1 發行日期:2021 年 6 月 15 日

我們已發行修正下列專案的 Azure DevOps Server 2020.1 修補程式。

  • 保護用於判斷提示 SameSite=None 之授權流程中的 Cookie。

  • 解決通知 SDK 的問題。 先前,未正確剖析使用區域路徑篩選的通知訂閱。

Azure DevOps Server 2020.1 RTW 發行日期:2021 年 5 月 25 日

Azure DevOps Server 2020.1 RTW 的新功能摘要

Azure DevOps Server 2020.1 RTW 是 Bug 修正的匯總。 其中包含先前發行Azure DevOps Server 2020.1 RC2 中的所有功能。 Azure DevOps Server 2020.1 RTW是 Bug 修正的匯總。 您可以直接安裝 Azure DevOps Server 2020.1 或從 Azure DevOps Server 2020、2019 或 Team Foundation Server 2015 或更新版本升級。

注意

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

Azure DevOps Server 2020.1 RC2 發行日期:2021 年 4 月 13 日

Azure DevOps Server 2020.1 RC2 的新功能摘要

Azure DevOps Server 2020.1 RC2 是 Bug 修正的匯總。 其中包含先前發行Azure DevOps Server 2020.1 RC1 中的所有功能。

Azure DevOps Server 2020.1 RC1 發行日期:2021 年 3 月 23 日

Azure DevOps Server 2020.1 RC1 的新功能摘要

Azure DevOps Server 2020.1 RC1 引進許多新功能。 一些重點包括:

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


Boards

狀態轉換限制規則

我們會繼續關閉託管 XML 與繼承進程模型之間的功能同位間距。 這個新的工作專案類型規則可讓您限制工作專案從某個狀態移到另一個狀態。 例如,您可以將 Bug 從 [新增] 限制為 [已解決]。 相反地,他們必須從 [新增 - > 作用中 - > 已解決]

img

您也可以建立規則,以依群組成員資格限制狀態轉換。 例如,只有「核准者」群組中的使用者可以從 New - > Approved 移動使用者劇本。

複製工作專案以複製子系

Azure Boards的最上層要求功能之一,就是能夠複製也會複製子工作專案的工作專案。 我們已將新的選項新增至 [複製工作專案] 對話方塊的 [包含子工作專案]。 選取時,此選項會複製工作專案,並將所有子工作專案 (最多 100 個) 。

This page shows the new option in Azure Boards to Include child work items in a copied work item.

已改善已啟動和已解析欄位的規則

到目前為止, 啟動者啟動日期已解析日期和 解析日期 的規則都已經是一個老式規則。 它們只會針對系統工作專案類型進行設定,而且專屬於狀態值 「Active」 和 「Resolved」。 我們已變更邏輯,讓這些規則不再適用于特定狀態。 相反地,它們是由狀態所在) (狀態類別 (觸發。 例如,假設您在 [已解決] 類別中有「需要測試」的自訂狀態。 當工作專案從「作用中」變更為「需要測試」時,就會觸發已 解決的 ByResolved Date 規則。

這可讓客戶建立任何自訂狀態值,但仍產生 [ 啟用者]、[ 啟用日期]、[ 解析日期] 和 [ 已解析日期 ] 欄位,而不需要使用自訂規則。

專案關係人可以跨面板資料行移動工作專案

專案關係人一律能夠變更工作專案的狀態。 但是,當他們移至工作流程看板時,就無法將工作專案從一個資料行移到另一個資料行。 相反地,專案關係人必須一次開啟每個工作專案,並更新狀態值。 這一點對客戶而言很長,我們很高興宣佈您現在可以跨面板資料行移動工作專案。

待辦專案和麵板上的系統工作專案類型

現在您可以將系統工作專案類型新增至所選擇的待辦專案層級。 在過去,這些工作專案類型只能從查詢取得。

處理序 工作項目類型
敏捷 問題
Scrum 阻礙
CMMI 變更要求
問題
檢閱
風險

將系統工作專案類型新增至待辦專案層級很簡單。 只要進入您的自訂程式,然後按一下 [待辦專案層級] 索引標籤。選取您選擇的待辦專案層級 (範例:需求待辦專案) 並選擇 編輯選項。 然後新增工作專案類型。

backlogs

引發Azure Boards GitHub應用程式存放庫限制

GitHub市集中Azure Boards應用程式的存放庫限制已從 100 增加到 250。

合併提取要求時自訂工作專案狀態

並非所有工作流程都相同。 有些客戶想要在提取要求完成時關閉其相關工作專案。 其他人想要在關閉之前,將工作專案設定為另一個要驗證的狀態。 我們應該允許這兩者。

我們有一項新功能,可讓您在合併和完成提取要求時,將工作專案設定為所需的狀態。 若要這樣做,我們會掃描提取要求描述,並尋找狀態值,後面接著工作專案 () #mention。 在此範例中,我們會將兩個使用者劇本設定為 [已解決] 和 [關閉兩個工作]。

work-item-state

您現在可以將工作專案連結至組建、在組建中找到或整合建置,輕鬆地追蹤專案之間的組建相依性。

link work items

編輯說明 (系統欄位上的解說文字)

您一律能夠編輯自訂欄位的描述。 但對於優先順序、嚴重性和活動等系統欄位,無法編輯描述。 這是託管 XML 與 Inherited 之間的功能差距,可防止某些客戶移轉至繼承的模型。 您現在可以編輯系統欄位的描述。 編輯的值只會影響進程和該工作專案類型的該欄位。 這可讓您彈性地針對不同工作專案類型上的相同欄位有不同的描述。

edit description

合併提取要求時自訂工作專案狀態

提取要求通常是指多個工作專案。 當您建立或更新提取要求時,您可能會想要關閉其中一些要求、解決其中一些要求,並讓其餘部分保持開啟。 您現在可以使用下圖所示的批註來完成此動作。 如需 詳細資訊,請參閱檔

Customize state

工作面板上的父欄位

由於熱門要求,您現在可以將 [父] 欄位新增至 [工作面板] 上的子卡片和父卡片。

parent field task board

移除 Bug 工作專案類型的「指派給」規則

Agile、Scrum 和 CMMI 中所有不同工作專案類型都有數個隱藏的系統規則。 這些規則已存在 10 年以上,且通常可正常運作,而不需要任何抱怨。 不過,有幾個規則已用盡其歡迎。 其中一項規則特別導致新客戶和現有客戶感到許多困難,我們決定要移除它。 此規則存在於敏捷式程式中的 Bug 工作專案類型上。

「將狀態變更為已解決時,將 [指派的值] 設定為 [建立者]

我們收到關於此規則的許多意見反應。 為了回應,我們繼續進行,並從敏捷式程式中的 Bug 工作專案類型中移除此規則。 這項變更會影響使用繼承的 Agile 或自訂繼承的 Agile 程式的每個專案。 對於喜歡和依賴此目前規則的客戶,請參閱我們的 部落格文章 ,以瞭解您可以使用自訂規則重新新增規則所採取的步驟。

已移除 [工作專案] 頁面上的專案

[ 工作專案] 頁面 是一個很好的位置,可快速尋找您所建立或指派給您的專案,以及其他專案。 它提供數個個人化樞紐和篩選。 「指派給我」樞紐的其中一大抱怨,就是它會顯示 [已移除的工作專案] (,也就是處於 [已移除] 狀態的工作專案) 。 我們同意! 已移除的專案是不再值的工作,因此已從待辦專案中移除,因此在此檢視中包含它並不實用。

您現在可以在 [工作專案] 頁面上,從 [指派給我] 樞紐中隱藏所有已移除的專案。

Repos

預設分支名稱喜好設定

Azure Repos現在提供 Git 的可自訂預設分支名稱。 在存放庫設定中,您可以選擇在初始化存放庫時使用的任何合法分支名稱。 Azure Repos一律支援變更現有存放庫的預設分支名稱。 如需詳細資訊,請造訪 管理分支

 default-branch-name

注意:如果您未啟用此功能,您的存放庫將會以Azure Repos的預設名稱初始化。 現在,該預設值為 master。 為了遵守 Microsoft 的承諾,以及客戶對包容性語言的要求,我們將加入 業界對等, 將這個預設值變更為 main。 此變更將于此年晚發生。 如果您想要繼續使用 圖形,您應該立即開啟此功能,並將它設定為 master

預設分支的組織層級設定

現在有新存放庫慣用初始分支名稱的集合層級設定。 如果專案尚未選擇初始分支名稱,則會使用此組織層級設定。 如果您未在組織設定或專案設定中指定初始分支名稱,則新的存放庫會使用已定義的Azure DevOps預設值。

branch setting for org level

新增用於參與 PR 批註的新驗證範圍

此版本新增了讀取/寫入提取要求批註的新 OAuth 範圍。 如果您有只需要與批註互動的 Bot 或自動化,您可以只提供具有此範圍的 PAT。 如果自動化有 Bug 或權杖遭到入侵,此程式就會減少快射半徑。

提取要求體驗改善

已使用下列專案改善新的提取要求體驗:

  • 讓選擇性檢查更可見

客戶會使用選擇性檢查來吸引開發人員注意潛在問題。 在先前的體驗中,這些檢查失敗時會很明顯。 不過,這不是預覽體驗中的案例。 必要檢查上的大綠色核取記號會遮罩選擇性檢查中的失敗。 使用者只能藉由開啟檢查面板來發現選擇性檢查失敗。 當沒有問題指示時,開發人員通常不會這麼做。 在此部署中,我們已在摘要中顯示選擇性檢查的狀態。


show the optional checks


  • 在功能表項目上按一下 Ctrl 鍵

PR 上的索引標籤功能表不支援按 Ctrl 鍵。 使用者通常會在檢閱提取要求時開啟新的瀏覽器索引標籤。 這個問題已經修正。

  • [+] 批註的位置

PR 中的檔案樹狀結構清單會顯示注釋 [+],以協助作者和檢閱者識別新的檔案。 由於批註是在省略號之後,因此通常不會顯示較長的檔案名。


show locations of annotations

  • PR 更新下拉式清單重新取得計時資訊

選取更新和比較 PR 中檔案的下拉式清單遺失預覽體驗中的重要元素。 未顯示該更新的時機。 這個問題已經修正。


PR updates dropdown missing timing information

  • **改善的批註篩選配置 **

篩選提取要求的摘要頁面上的批註時,下拉式清單位於右側,但文字靠左對齊。 這個問題已經修正。


Improved comment filter layout

  • 流覽至父系認可

在 [認可] 頁面底下,您可以比較特定認可中所做的變更與其父認可。 不過,您可能想要巡覽至父認可,並進一步瞭解該認可與自己的父系有何不同。 當您想要瞭解版本中的所有變更時,通常需要這樣做。 我們已將父 () 卡片新增至認可,以協助您達成此目的。


Navigation to parent commits

  • PR 檔案索引標籤中具有長名稱的資料夾和檔案更多空間

因為檔案樹狀結構中沒有水準間距,所以已截斷名稱很長的資料夾和檔案。 我們已藉由修改樹狀結構縮排來比對根節點,並從頁面隱藏省略號按鈕,以復原樹狀結構中的一些額外空間,但暫留除外。

新檔案樹狀結構的影像:


More space for folders and files

將滑鼠停留在目錄上方時的檔案樹狀結構影像:


Name display

  • 在 PR 檔案索引標籤中調整大小差異窗格時保留捲動位置

在 [PR 檔案] 索引標籤中調整並存差異窗格的大小時,使用者的捲動位置將會遺失。 此問題已修正;使用者捲動位置現在會保留在差異窗格調整大小上。

  • 在行動裝置上搜尋認可

在行動裝置上檢視 [認可] 頁面時,新體驗中遺漏搜尋方塊。 因此,您很難依其雜湊尋找認可,並加以開啟。 現在已修正此問題。


Search for a commit on a mobile device

  • 已改善新 PR 檔案差異行動檢視的空間使用量

我們已更新此頁面以充分利用空間,讓使用者可以在行動檢視中看到更多檔案,而不是讓標頭佔用 40% 的螢幕。


Improved usage of space new PR filename

  • PR 摘要檢視中的增強影像

在 PR 中編輯的影像未顯示在 PR 摘要檢視中,但已在 PR 檔案檢視中正確顯示。 這個問題已經解決。

  • 建立新 PR 時的增強分支體驗

在此更新之前,此體驗並不理想,因為它會比較變更與存放庫的預設分支,而不是比較分支。


branch experience enhancement

Pipelines

其他代理程式平臺:ARM64

我們已將 Linux/ARM64 新增至 Azure Pipelines 代理程式支援的平臺清單。 雖然程式碼變更很小,但許多幕後工作必須先完成,而且我們很高興地宣佈其發行!

管線資源的標籤篩選支援

我們現在已在 YAML 管線中新增 「標記」。 您可以使用標記來設定要執行的 CI 管線,或何時自動觸發。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: master
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

上述程式碼片段顯示標籤可用來判斷當 CD (持續部署) 管線執行時,某些其他來源/資源或排程的執行觸發程式不會觸發 CD (持續部署時,要執行的 CI (持續整合) 管線的預設版本。

例如,如果您的 CD 管線已設定已排程觸發程式,且只有在 CI 具有生產標籤時才會執行,則 triggers 區段中的標籤可確保只有在 CI 完成事件符合標記條件時才會觸發 CD 管線。

控制管線中允許的工作

您現在可以停用 Marketplace 工作。 有些您可能允許 Marketplace 擴充功能,但不允許它們所帶來Pipelines工作。 為了進一步控制,我們也可讓您獨立停用所有現成工作 (,但簽出除外,這是特殊動作) 。 啟用這兩個設定後,唯一允許在管線中執行的工作就是使用 tfx上傳的工作。 請流覽 https://dev.azure.com/<your_org>/_settings/pipelinessettings 並尋找稱為「工作限制」的區段以開始使用。

獨佔部署鎖定原則

透過此更新,您可以確保一次只有單一執行部署至環境。 藉由在環境中選擇「獨佔鎖定」檢查,只會繼續執行一次。 後續要部署至該環境的後續執行將會暫停。 一旦執行完成獨佔鎖定,最新的執行將會繼續。 任何中繼執行都會取消。

In the Add check page, select Exclusive Lock to ensure that only a single run deploys to an environment at a time.

管線資源觸發程式的階段篩選

我們已新增 「階段」的支援,作為 YAML 中管線資源的篩選。 使用此篩選準則時,您不需要等待整個 CI 管線完成以觸發 CD 管線。 您現在可以選擇在 CI 管線中完成特定階段時觸發 CD 管線。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

當您的 CI 管線中順利完成觸發程式篩選中所提供的階段時,就會為您的 CD 管線自動觸發新的回合。

YAML 管線的一般 Webhook 型觸發程式

目前,我們有各種資源 (,例如管線、容器、建置和套件) ,您可以透過這些資源取用成品並啟用自動化觸發程式。 不過,到目前為止,您無法根據其他外來事件或服務自動執行部署程式。 在此版本中,我們將介紹 YAML 管線中的 Webhook 觸發程式支援,以啟用管線自動化與任何外部服務的整合。 您可以透過其 Webhook 訂閱任何外來事件, (Github、Github Enterprise、Nexus、Aritfactory 等 ) ,並觸發管線。

以下是設定 Webhook 觸發程式的步驟:

  1. 在您的外部服務上設定 Webhook。 建立 Webhook 時,您需要提供下列資訊:

    • 要求 URL - 「 https://dev.azure.com/< ADO 集合 > /_apis/public/distributedtask/webhooks/ <WebHook Name> ?api-version=6.0-preview」
    • 秘密 - 這是選擇性的。 如果您需要保護 JSON 承載,請提供 秘密
  2. 建立新的「傳入 Webhook」服務連線。 這是新引進的服務連線類型,可讓您定義三個重要資訊片段:

    • Webhook 名稱:Webhook的名稱應該符合在外部服務中建立的 Webhook。
    • HTTP 標頭 - 要求中包含要求驗證承載雜湊值之 HTTP 標頭的名稱。 例如,在GitHub的情況下,要求標頭會是 「X-Hub-Signature
    • 秘密 - 秘密是用來剖析用於驗證傳入要求之承載雜湊, (這是選擇性) 。 如果您在建立 Webhook 時使用了秘密,則必須提供相同的秘密金鑰

    In the Edit service connection page, configure webhook triggers.

  3. YAML 管線中引進名為 webhooks 的新資源類型。 若要訂閱 Webhook 事件,您必須在管線中定義 Webhook 資源,並將其指向傳入 Webhook 服務連線。 您也可以根據 JSON 承載資料在 Webhook 資源上定義其他篩選,以進一步自訂每個管線的觸發程式,並以作業中的變數形式取用承載資料。

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. 每當傳入 Webhook 服務連線收到 Webhook 事件時,所有訂閱 Webhook 事件的管線都會觸發新的執行。

YAML 資源觸發程式問題支援和可追蹤性

當管線觸發程式無法如預期般執行時,可能會造成混淆。 為了協助進一步瞭解,我們已在管線定義頁面中新增名為「觸發程式問題」的新功能表項目,其中會顯示有關觸發程式執行原因的資訊。

資源觸發程式可能會因為兩個原因而無法執行。

  1. 如果所提供的服務連線來源無效,或觸發程式中有任何語法錯誤,則完全不會設定觸發程式。 這些會顯示為錯誤。

  2. 如果觸發條件不相符,則不會執行觸發程式。 每當發生這種情況時,就會顯示警告,讓您瞭解條件未相符的原因。

    This pipeline definition page called Trigger Issues displays information regarding why triggers are not running.

多重存放庫觸發程式

您可以在一個 YAML 檔案中指定多個存放庫,並透過更新任何存放庫來觸發管線。 例如,在下列案例中,這項功能很有用:

  • 您可以從不同的存放庫取用工具或程式庫。 每當工具或程式庫更新時,您想要執行應用程式的測試。
  • 您會將 YAML 檔案保留在與應用程式程式碼不同的存放庫中。 您想要在每次將更新推送至應用程式存放庫時觸發管線。

透過此更新,多存放庫觸發程式僅適用于 Azure Repos 中的 Git 存放庫。 它們不適用於GitHub或 BitBucket 存放庫資源。

以下範例示範如何在管線中定義多個存放庫資源,以及如何在所有存放庫上設定觸發程式。

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

如果有任何更新,將會觸發此範例中的管線:

  • mainself存放庫中包含 YAML 檔案的分支
  • mainrelease 存放庫中的 tools 分支

如需詳細資訊,請參閱 管線中的多個存放庫

代理程式記錄上傳已改善

當代理程式停止與Azure Pipelines伺服器通訊時,執行中的作業就會遭到放棄。 如果您剛好查看串流主控台記錄,您可能已經取得代理程式在停止回應之前已啟動的一些線索。 但如果您不是,或重新整理頁面,這些主控台記錄就會消失。 在此版本中,如果代理程式在傳送完整記錄之前停止回應,我們會將主控台記錄保留為下一個最佳專案。 主控台記錄每行限制為 1000 個字元,有時可能不完整,但比不顯示任何專案更實用! 檢查這些記錄可協助您針對自己的管線進行疑難排解,而且當支援工程師協助進行疑難排解時,它當然會協助我們的支援工程師。

選擇性地掛接容器磁片區唯讀

當您在 Azure Pipelines 中執行容器作業時,包含工作區、工作和其他材質的數個磁片區會對應為磁片區。 這些磁片區預設為讀取/寫入存取權。 為了提高安全性,您可以在 YAML 中變更容器規格,以唯讀方式掛接磁片區。 下方 mountReadOnly 的每個金鑰都可以針對 true 唯讀 (預設值 false 設為) 。

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

對容器啟動/停止的細微控制

一般而言,我們建議您允許Azure Pipelines管理作業和服務容器的生命週期。 不過,在某些不常見的案例中,您可能會想要自行啟動和停止它們。 在此版本中,我們已將該功能建置至 Docker 工作。

以下是使用新功能的範例管線:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

此外,我們也在管線變數中包含容器清單。 Agent.ContainerMapping 如果您想要檢查腳本中的容器清單,例如,您可以使用此功能。 它包含字串化的 JSON 物件,會將上述範例中的資源名稱 (「builder」) 對應至代理程式所管理的容器識別碼。

解壓縮每個步驟的工作配套

當代理程式執行作業時,會先下載作業步驟所需的所有工作配套。 一般而言,為了達到效能,即使工作用於多個步驟,也會針對每個作業解壓縮一次工作。 如果您擔心未受信任的程式碼改變解壓縮的內容,您可以藉由讓代理程式在每個使用量上解壓縮工作,來取捨一些效能。 若要啟用此模式,請在設定代理程式時傳遞 --alwaysextracttask

藉由限制存取權杖的範圍來改善發行安全性

根據我們的計畫來增強Azure Pipelines的安全性設定,我們現在支援限制發行的存取權杖範圍。

在版本中執行的每個作業都會取得存取權杖。 存取權杖是由工作和腳本用來回呼Azure DevOps。 例如,我們使用存取權杖來取得原始程式碼、下載成品、上傳記錄、測試結果,或對Azure DevOps進行 REST 呼叫。 系統會為每個作業產生新的存取權杖,並在作業完成之後到期。

透過此更新,我們會藉由限制存取權杖的範圍,並將相同的擴充至傳統版本,以改善管線安全性。

新專案和集合預設會開啟這項功能。 對於現有的集合,您必須在集合設定 >> Pipelines設定中加以啟用。 >將作業授權範圍限制為發行管線的目前專案在此深入了解。

YAML 預覽 API 增強功能

您現在可以預覽管線的完整 YAML ,而不需執行它。 此外,我們已建立預覽功能的專用新 URL。 現在您可以 POST 至 https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview 以擷取完成的 YAML 主體。 這個新的 API 會採用與佇列執行相同的參數,但不再需要「佇列組建」許可權。

接下來執行此作業

您是否曾經有一個錯誤檔,您必須 立即 部署,但必須等候 CI 和 PR 作業? 在此版本中,我們現在可讓您提升佇列作業的優先順序。 具有集區 「管理」許可權的使用者, 通常是集區系統管理員 , 會在作業詳細資料頁面上看到新的 [執行下一步] 按鈕。 按一下按鈕會設定儘快執行作業。 (您仍然需要可用的平行處理原則和適當的代理程式,當然。)

YAML resources 區塊中允許的範本運算式

先前,Azure Pipelines YAML 檔案的 區段中不允許 resources (${{ }}) 編譯時期運算式。 在此版本中,我們已針對容器提高這項限制。 這可讓您在資源內使用 執行時間參數 內容,例如在佇列時間挑選容器。 我們計畫將這項支援延伸至一段時間的其他資源。

從 Marketplace 控制自動化工作更新

當您撰寫 YAML 管線時,通常只會指定內含工作的主要版本號碼。 這可讓您的管線自動取得最新的功能新增和 Bug 修正。 有時候,您可能需要回復到先前的工作點版本,而透過此更新,我們新增了您這麼做的能力。 您現在可以在 YAML 管線中指定完整的 major.minor.patch 工作版本。

我們不建議您定期執行這項操作,而且只有在發現較新的工作中斷管線時,才將其作為暫時的因應措施。 此外,這不會從 Marketplace 安裝較舊的工作版本。 它必須已存在於您的集合中,否則您的管線將會失敗。

範例:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

代理程式和工作的節點 10 支援

由於不再支援 Node 6,因此我們會移轉工作以使用 Node 10。 針對此更新,我們已將幾乎 50% 的內建工作移轉至節點 10。 代理程式現在可以同時執行節點 6 和節點 10 工作。 在未來的更新中,我們會從代理程式完全移除 Node 6。 為了準備從代理程式移除 Node 6,我們要求您更新內部延伸模組和自訂工作,以便儘快使用 Node 10。 若要將 Node 10 用於您的工作,請在 task.json 的 下 execution ,從 Node 更新為 Node10

改善傳統組建設計工具中的 YAML 轉換

在此版本中,我們會為設計工具建置管線引進新的「匯出至 YAML」功能。 儲存管線定義,然後在功能表上尋找 [匯出至 YAML ... ]。

新的匯出函式會取代先前在傳統組建設計工具中找到的「檢視為 YAML」函式。 該函式不完整,因為它只能檢查 Web UI 知道有關組建的內容,這有時會導致產生不正確的 YAML。 新的匯出函式會確切考慮管線的處理方式,並產生具有設計工具管線完整精確度的 YAML。

新的 Web 平臺轉換 – 存放庫設定

我們已將這兩個存放庫設定頁面轉換成升級至新 Web 平臺的單一體驗。 此升級不僅讓體驗更快速且更現代化,也會為專案層級到分支層級的所有原則提供單一進入點。

New web platform conversion.

有了這個新體驗,具有大量存放庫的專案流覽會變得更容易,因為載入時間和新增的搜尋篩選。 您也可以在 [原則] 索引標籤下檢視專案層級原則和跨存放庫原則的清單。

View cross-repo policies under the Policies tab.

如果您按一下存放庫,您可以檢視存放庫層級所設定的原則和許可權。 在 [原則] 索引標籤內,您可以檢視原則設定的每個分支清單。 現在,按一下分支即可查看所有原則,而永遠不要離開 [存放庫設定] 頁面。

Select branch to see the policies.

現在,當原則繼承自比您使用範圍更高的範圍時,我們會向您顯示原則繼承自每個個別原則旁的位置。 您也可以按一下範圍名稱,流覽至已設定較高層級原則的頁面。

Show where the policy was inherited from.

原則頁面本身也已升級至具有可折迭區段的新 Web 平臺! 為了改善尋找特定組建驗證、狀態檢查或自動檢閱者原則的體驗,我們已為每個區段新增搜尋篩選。

Search filters for each section.

ServiceNow 變更管理與 YAML 管線整合

ServiceNow Azure Pipelines應用程式可協助您整合 Azure Pipelines 和 ServiceNow 變更管理。 透過這項更新,我們會開始讓Azure Pipelines瞭解在 ServiceNow 中管理的變更管理程式,進一步瞭解 YAML 管線。

藉由在資源上設定「ServiceNow 變更管理」檢查,您現在可以暫停變更以供核准,再將組建部署至該資源。 您可以為階段自動建立新的變更,或等候現有的變更要求。


ServiceNow Change Management Integration

您也可以在伺服器作業中新增工作 UpdateServiceNowChangeRequest ,以使用部署狀態、附注等更新變更要求。

Artifacts

能夠從 UI 建立組織範圍的摘要

我們讓客戶能夠透過內部部署和託管服務的 Web UI 來建立和管理集合範圍的摘要。

您現在可以透過 UI 建立組織範圍的摘要,方法是移至 [Artifacts - > 建立摘要],然後選擇 [範圍] 內的摘要類型。

Create collection-scoped feeds by selecting Artifacts, then Create Feed, and selecting a type of feed within Scope.

雖然我們建議使用專案範圍的摘要與其余Azure DevOps供應專案一致,但您可以再次透過 UI 和各種 REST API 來建立、管理和使用集合範圍摘要。 如需詳細資訊,請參閱我們的摘要檔。

更新套件版本 REST API 現在適用于 Maven 套件

您現在可以使用Azure Artifacts「更新套件版本」REST API 來更新 Maven 套件版本。 先前,您可以使用 REST API 來更新 NuGet、Maven、npm 和通用套件的套件版本,但不能更新 Maven 套件。

若要更新 Maven 套件,請使用 HTTP PATCH 命令,如下所示。

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

您可以設定下列專案:

URI 參數

名稱 位置 必要 型別 說明
artifactId path true 字串 封裝的成品識別碼
饋送 path true 字串 摘要的名稱或識別碼
groupId path true 字串 封裝的群組識別碼
collection path true 字串 Azure DevOps集合的名稱
version path true 字串 套件的版本
project path 字串 Project識別碼或專案名稱
api-version 查詢 true 字串 要使用的 API 版本。 這應該設定為 '5.1-preview.1' 以使用此版本的 API

要求本文

名稱 型別 說明
檢視 JsonPatchOperation 將新增套件版本的檢視

如需詳細資訊,請參閱 REST API 檔 ,因為檔已更新。

意見反應

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


頁面頂端