設定為停用建立 TFVC 存放庫
透過此更新,我們引進了新的設定,以停用建立 TFVC 存放庫。 這項變更著重於新專案,同時確保現有的 TFVC 存放庫不會受到影響。
此外,我們很高興地宣佈,在 Azure Pipelines 中,有新的 REST API 端點可供要求 OIDC 令牌! 這可讓工作開發人員產生idTokens以進行 EntraID驗證,增強安全性和使用便利性。
最後,在 Azure Boards 中,只有不再與任何工作專案建立關聯時,才能刪除區域和反覆專案。 這項改進可防止中斷,並確保小組能夠存取其面板和待辦專案。
如需詳細資訊,請參閱版本資訊。
適用於 Azure DevOps 的 GitHub Advanced Security
Azure Boards:
Azure Repos
Azure Pipelines
- 使用 Microsoft Entra ID 驗證從管線存取 Azure 服務匯流排
- 管線和工作會填入變數,以自定義工作負載身分識別同盟驗證
- 重試伺服器工作
- 使用生命週期結束節點執行器版本來執行發出警告的工作
- DockerCompose0 在 v1 兼容性模式中使用 Docker Compose v2
Azure Test Plans:
適用於 Azure DevOps 的 GitHub Advanced Security
安全性概觀 API 檔現已推出
API 提供進階安全性概觀風險索引標籤的檔現已可供使用。 使用端點 /{organization}/_apis/reporting/summary/alerts
來檢視所有已啟用進階安全性之存放庫的警示嚴重性摘要。 請確定您的 ADO PAT 具有 vso.advsec
許可權,以授與讀取警示、結果實例和分析結果實例的能力。
Azure Boards
刪除區域和反覆專案路徑的變更
刪除區域或反覆項目路徑可能會造成干擾。 它可以將工作專案移至新的路徑,並可能導致小組無法存取其面板和待辦專案。 儘管有警告和提示,但有時候會刪除路徑,而不會完全了解後果。 為了解決這個問題,我們變更了行為:區域和反覆專案路徑現在只能在任何工作專案不再使用時刪除。
Azure Repos
停用建立 TFVC 存放庫的新設定
近年來,Team Foundation 版本控制 (TFVC) 未新增任何新功能,因為 Git 已成為 Azure Repos 中慣用的版本控制系統。 安全性、效能和可存取性的所有最近改進都是專門針對 Git 存放庫的,這導致 TFVC 使用量持續下降。 雖然有些人仍然依賴 TFVC,我們並不打算移除此功能集,但我們計劃針對新專案和組織以及目前不使用 TFVC 的專案逐步淘汰 TFVC。
在此轉換中,我們引進了新設定以「停用 TFVC 存放庫的建立」,這僅會影響新 TFVC 存放庫的建立,不會影響現有的存放庫。
Azure Pipelines
使用 Microsoft Entra ID 驗證從管線存取 Azure 服務匯流排
您現在可以使用 Microsoft Entra ID 驗證,從 Azure Pipelines 存取 Azure 服務匯流排。 這可讓您利用工作負載身分識別同盟來移除秘密管理和 Azure RBAC,以進行更細緻的訪問控制。
存取 Azure 服務匯流排 的身分識別必須授與其中一個 Azure 內建角色,才能在存取 服務匯流排 上授與 Azure 服務匯流排。
PublishToAzureServiceBus@2工作
您可以使用 Azure 服務連線來設定新的PublishToAzureServiceBus@2工作。 建立 Azure 服務連線 ,並填入 serviceBusQueueName
新工作的 和 serviceBusNamespace
屬性:
- task: PublishToAzureServiceBus@2
inputs:
azureSubscription: my-azure-service-connection
serviceBusQueueName: my-service-bus-queue
serviceBusNamespace: my-service-bus-namespace
useDataContractSerializer: false
messageBody: |
{
"foo": "bar"
}
伺服器工作
使用 ServiceBus
執行的自訂伺服器(無代理程式)工作可以將 Azure 服務連線指定為 EndpointId
,並省略 ConnectionString
。 請參閱 伺服器工作撰寫。
管線和工作會填入變數,以自定義工作負載身分識別同盟驗證
用於要求 OIDC 令牌的 System.OidcRequestUri
REST API 端點現在可在管線變數中使用。 工作開發人員可以利用此變數來產生idToken,以使用 Entra ID 進行驗證。
如果您使用 Marketplace 工作或自定義工作來部署至 Azure,請注意,這些工作可能尚未支援工作負載身分識別同盟。 我們建議工作開發人員啟用工作負載身分識別同盟,以改善安全性措施。
connectedService:AzureRM
您可以遵循下列步驟,更新task.json中輸入的工作以支援工作負載身分識別同盟:
- 利用 Oidctoken REST API 來要求 idToken(上圖中的箭號 1)。
- 使用 OAuth API 的同盟認證流程交換 idToken 作為存取令牌,並將 idToken 指定為
client_assertion
(上圖中的箭號 2 和 4):
or: - 對於做為執行驗證本身之工具包裝函式的工作,請使用工具的驗證方法來指定同盟令牌。
節點工作可以使用 azure-pipelines-tasks-artifacts-common npm 套件來取得 idToken。 如需實作詳細數據,請參閱程式 碼範例 。
要求全新的idToken
System.OidcRequestUri
和 工作中公開的AzureCLI@2
AzurePowerShell@5
管線變數和AZURESUBSCRIPTION_SERVICE_CONNECTION_ID
環境變數可讓管線作者從自己的腳本進行驗證:
PowerShell Az
- task: AzurePowerShell@5
inputs:
azureSubscription: 'my-azure-subscription'
scriptType: inlineScript
inline: |
# Request fresh idToken
Invoke-RestMethod -Headers @{
Authorization = "Bearer $(System.AccessToken)"
'Content-Type' = 'application/json'
} `
-Uri "${env:SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${env:AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}" `
-Method Post `
| Select-Object -ExpandProperty oidcToken
| Set-Variable idToken
# Fetch current context
$azContext = Get-AzContext
# Start new Az session
Connect-AzAccount -ApplicationId $azContext.Account.Id `
-TenantId $azContext.Tenant.Id `
-SubscriptionId $azContext.Subscription.Id `
-FederatedToken $idToken
Azure CLI
- task: AzureCLI@2
inputs:
addSpnToEnvironment: true
azureSubscription: 'my-azure-subscription'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
# Request fresh idToken
OIDC_REQUEST_URL="${SYSTEM_OIDCREQUESTURI}?api-version=7.1&serviceConnectionId=${AZURESUBSCRIPTION_SERVICE_CONNECTION_ID}"
ARM_OIDC_TOKEN=$(curl -s -H "Content-Length: 0" -H "Content-Type: application/json" -H "Authorization: Bearer $(System.AccessToken)" -X POST $OIDC_REQUEST_URL | jq -r '.oidcToken')
# Save subscription context
ARM_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
# New az-cli session
az login --service-principal -u $servicePrincipalId --tenant $tenantId --allow-no-subscriptions --federated-token $ARM_OIDC_TOKEN
az account set --subscription $ARM_SUBSCRIPTION_ID
重試伺服器工作
呼叫 外部系統,例如 AzureFunction
或 InvokeRESTAPI
的伺服器工作偶爾會因為計算資源耗盡等暫時性錯誤而失敗。 先前,這類失敗會導致整個作業,以及可能讓管線失敗。
為了改善暫時性錯誤的復原能力,我們引進了伺服器工作中 屬性的支援 retryCountOnTaskFailure
。 假設您在管線中有下列 YAML 程式代碼:
- stage: deploy
jobs:
- job:
pool: server
steps:
- task: AzureFunction@1
retryCountOnTaskFailure: 2
inputs:
function: 'https://api.fabrikamfiber.com'
key: $(functionKey)
method: 'POST'
waitForCompletion: 'false'
如果 https://api.fabrikamfiber.com
發生暫時性錯誤,Azure Pipelines 將重試要求最多三次(初始嘗試加上 指定的 retryCountOnTaskFailure
兩次重試)。 每次重試都會包含增加的等候期間。 允許的重試次數上限為10。
retryCountOnTaskFailure
不適用於ManualValidation
工作和其他未涉及外部系統呼叫的工作。
使用生命週期結束節點執行器版本來執行發出警告的工作
不再 維護 依賴 Node 版本的管線工作將會開始收到警告:
工作
TaskName
版本<version>
相依於生命週期結束的節點版本 (10)。 請連絡延伸模組擁有者以取得工作的更新版本。 工作維護人員應檢閱節點升級指引: https://aka.ms/node-runner-guidance
若要隱藏這些警告,您可以在管線(作業)或工作層級設定環境或管線變數。 例如:
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false
DockerCompose@0在 v1 相容性模式中使用 Docker Compose v2
Docker Compose v1 將達到其生命周期結束,並將於 2024 年 7 月 24 日從託管代理程式中移除。 我們已更新 DockerCompose@0 工作,以在 v1 相容性模式中使用 Docker Compose v2,如果代理程式上無法使用 Docker Compose v1。
不過,並非所有相容性問題都可以用相容性模式解決。 請參閱<移轉至 Compose V2>(英文)。 部分使用者需要更多時間才能更新 Docker Compose 專案來實現 Docker Compose v2 相容性。 在這些情況下,請依照這些指示搭配 docker-compose v1 使用 DockerComposeV0 工作。
注意:本指南是以 Install Compose 獨立 文件為基礎
在 Windows 上使用 docker-compose v1
將 powershell 步驟新增至您的管線,以下載 docker-Compose v1.29.2,並將其與 Windows 上的 DockerComposeV0 工作搭配使用:
variables:
dockerComposePath: C:\docker-compose
steps:
- powershell: |
mkdir -f $(dockerComposePath)
# GitHub now requires TLS1.2. In PowerShell, run the following
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: '**/docker-compose.yml'
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)\docker-compose.exe
在 Linux 上使用 docker-compose v1
將 bash 步驟新增至管線以下載 Docker-Compose v1.29.2,並將其與 Linux 上的 DockerComposeV0 工作搭配使用:
variables:
dockerComposePath: /tmp/docker-compose
steps:
- bash: |
sudo mkdir $(dockerComposePath)
sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
sudo chmod 755 $(dockerComposePath)/docker-compose
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)/docker-compose
Azure Test Plans
指令清單 V3 中的測試和意見反應擴充功能
我們很高興宣佈 Azure DevOps 測試和意見反應延伸模組的新更新! 此升級會將我們的實作從指令清單第 2 版轉換為第 3 版,與 Google 的指令清單 V2 淘汰排程一致。
雖然延伸模組的核心功能保持不變,但此更新可改善安全性和效能。 更新的延伸模組將在未來幾周內逐漸推出至 Chrome 和 Edge 瀏覽器。 我們會監視效能和意見反應,以確保在根據結果擴充推出之前順暢轉換。
如需詳細資訊,請參閱我們最近關於此更新的部落格文章。 指令清單 V3 中的測試與意見反應延伸模組
下一步
注意
這些功能將在未來兩到三周內推出。
前往 Azure DevOps 並查看。
如何提供意見反應
我們很樂意聽到您對於這些功能的看法。 使用說明功能表來回報問題或提供建議。
您也可以在 Stack Overflow 上的社群取得建議和您的問題。
感謝您!
Silviu Andrica