设置为禁用创建 TFVC 存储库
通过此更新,我们将引入一个新设置来禁用创建 TFVC 存储库。 此更改侧重于新项目,同时确保现有 TFVC 存储库不受影响。
此外,我们很高兴地宣布,在 Azure Pipelines 中,新的 REST API 终结点可用于请求 OIDC 令牌! 这样,任务开发人员就可以为 Entra ID 身份验证生成 idTokens,从而提高安全性和易用性。
最后,在 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 存储库的创建,不会影响现有存储库。
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 令牌的 REST API 终结点现在在管道变量中 System.OidcRequestUri
可用。 任务开发人员可以利用此变量生成 idToken,以便使用 Entra ID 进行身份验证。
如果使用市场任务或自定义任务部署到 Azure,请注意,这些任务可能尚不支持工作负荷标识联合。 我们建议任务开发人员启用工作负荷标识联合,以提高安全措施。
connectedService:AzureRM
可以通过以下步骤更新采用task.json输入的任务以支持工作负荷标识联合:
- 利用 Oidctoken REST API 请求 idToken(上图中的箭头 1)。
- 使用 OAuth API 的联合凭据流交换 idToken 作为访问令牌,并将 idToken 指定为
client_assertion
(上图中的箭头 2 和 4):
或: - 对于充当执行身份验证本身的工具的包装器的任务,请使用工具的身份验证方法指定联合令牌。
节点任务可以使用 azure-pipelines-tasks-artifacts-common npm 包来获取 idToken。 有关实现详细信息, 请参阅代码示例 。
请求新的 idToken
System.OidcRequestUri
管道变量和AZURESUBSCRIPTION_SERVICE_CONNECTION_ID
任务中AzureCLI@2
AzurePowerShell@5
公开的环境变量允许管道作者从其自己的脚本进行身份验证:
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。
ManualValidation
该retryCountOnTaskFailure
任务不适用于不涉及外部系统调用的任务和其他任务。
使用生命周期结束节点运行程序版本执行的任务发出警告
不再 维护 依赖于 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 日从托管代理中删除其生命周期结束。 如果 Docker Compose v1 在代理上不可用,我们已更新 了DockerCompose@0 任务,以在 v1 兼容模式下使用 Docker Compose v2。
但是,兼容性模式不能解决所有兼容性问题。 请参阅 “迁移到 Compose V2”。 某些用户需要更多的时间来更新其 Docker Compose 项目,以便实现 Docker Compose v2 兼容性。 在这些情况下,请按照这些说明将 DockerComposeV0 任务与 docker-compose v1 配合使用。
注意:本指南基于 安装 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