通过

适用于 Azure DevOps 的托管 DevOps 池（预览版）

  • 项目

我们很高兴地宣布托管 DevOps 池预览版，旨在帮助开发和平台工程团队快速设置和管理自定义 DevOps 池。

此外，我们还增强了 GitHub 高级安全性的计量使用情况估算 API，提供有助于识别用户的新功能。

有关详细信息，请查看发行说明。

适用于 Azure DevOps 的 GitHub Advanced Security

Azure Pipelines

适用于 Azure DevOps 的 GitHub Advanced Security

高级安全计量使用情况 API 现在返回用户标识

为了帮助你识别高级安全用户，计量使用情况估计 API 现在返回每个用户的 Azure DevOps 标识，包括其显示名称、CUID、电子邮件标识符和标识描述符。 此功能在组织、项目和存储库级别可用。 若要使用此新终结点，语法类似于现有计量使用情况 API 终结点，追加 /details 到终结点：

  • 在组织级别：GET https://advsec.dev.azure.com/{organization}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • 在项目级别：GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/meterUsageEstimate/details?api-version=7.2-preview.1
  • 在存储库级别：GET https://advsec.dev.azure.com/{organization}/{project}/_apis/management/repositories/{repository}/meterUsageEstimate/details?api-version=7.2-preview.1

无需生成即可扫描 C# 和 Java 项目的 GitHub 高级安全代码

使用 CodeQL 进行代码扫描涉及对代表单个语言存储库中的代码的数据库运行查询。 对于 C/C++、C#、Go、Java 和 Swift 等已编译语言，通常需要先生成代码。

但是，GitHub Advanced Security for Azure DevOps 背后的静态分析引擎 CodeQL 现在可以扫描 C# 和 Java 项目，而无需生成。 当生成模式设置为 “无” 时，CodeQL 数据库直接从代码库生成，绕过生成步骤。

对于所有已编译语言，默认生成模式为 “手动”。 但是，对于 C# 和 Java，可以将生成模式更改为 “none”。

可以在 AdvancedSecurity-Codeql-Init@1 设置期间配置生成模式。 有关使用 Azure DevOps 在 GitHub 高级安全性中配置代码扫描的详细说明，请参阅设置 代码扫描

考虑：

  • 如果选择 了“none” ，并且所选语言不是受支持的符合语言 C# 或 Java 的语言，则管道任务可能无法按预期工作。

  • 生成模式 “none” 当前与其他解释语言（例如 JavaScript、Python、Ruby）结合使用。

  • 有效示例：将生成模式设置为 “none”的 C# 和 JavaScript。 （用解释的语言编写的 JavaScript）

  • 无效示例：C#、JavaScript 和 Swift，生成模式设置为 “none” （生成模式 “none”不支持 Swift）。

AdvancedSecurity-Codeql 的屏幕截图。

Azure Pipelines

托管 DevOps 池（预览版）

当工程团队能够专注于编写代码来为用户开发应用程序和服务时，他们表现得非常出色。 但是，在实践中，通常花费大量时间来管理其他任务，例如维护 DevOps 基础结构。

我们很高兴地宣布托管 DevOps 池（MDP）的公共预览版，这是一项新的 Azure DevOps 功能，旨在帮助开发和平台工程团队部署专为其独特需求定制的自定义 DevOps 池。 MDP 将规模集代理的灵活性与与Microsoft托管的代理关联的轻松维护相结合，使团队能够建立一致性和最佳做法，同时优化性能、安全性、合规性和成本效益。

托管 DevOps 池的主要优势包括：

  • 代你托管： MDP 由Microsoft托管和管理，虚拟机支持在Microsoft拥有的 Azure 订阅中创建和维护代理。
  • 在管理中花费的时间： MDP 显著减少了管理代理所用的时间，尤其是基于本地基础结构或手动维护的系统的时间。
  • 特定池： 由于可以轻松创建新池，组织可以轻松创建多个特定于团队的池或特定于工作负荷的池。
  • DevOps 计费： MDP 通过许多功能帮助优化团队的 DevOps 帐单。 这使得团队可以轻松在池的 QoS/性能和成本之间找到最佳平衡。
  • 可缩放： MDP 在单个池中扩展到 1000 个代理。

Teams 可以使用包含Microsoft托管代理中存在的相同软件的快速启动映像创建池，或者团队创建的映像具有特定于其方案的先决条件。

阅读我们的 博客文章 或其 文档，详细了解托管 DevOps 池。

Azure 管道任务使用 Node 20

大多数管道任务使用 Node 作为运行程序。 使用 NodeJS 作为运行程序的 Azure 管道任务现在都使用 NodeJS 20。 任务扩展的作者应将其任务更新为使用 Node 20。 有关如何升级的指南， 请参阅如何将自定义任务升级到最新的 Node？。

创建生成管道权限

为了提高管道安全性，我们在管道级别引入了新的权限 Create build pipeline。

创建生成管道权限的屏幕截图。

以前， Edit build pipeline 创建或编辑管道所需的权限。 这会带来安全风险，因为它允许所有能够创建管道的用户也编辑他们未创建的管道。 防止这种情况非常耗时。

为了在不损害安全性的情况下增强管道体验，拥有该权限的 Edit build pipeline 所有用户和组现在也将获得 Create build pipeline 权限。

创建管道时，为其创建者授予 Edit build pipeline 权限。

为了提高管道安全性，可以选择从用户组（如参与者和读者）中删除Edit build pipeline权限。 这可确保默认情况下，只有管道的创建者才能对其进行编辑。

注意

“编辑生成管道”权限不会阻止其他人编辑 YAML 管道;它只会保护管道的属性不被编辑。

对于新项目，具有 Edit build pipeline 权限的用户和组也具有 Create build pipeline 该权限。 将来可能会发生变化。

阶段级别的独占锁检查

某些用例要求管道在任何给定时间仅访问特定资源一次。 为了支持这种情况，我们有 独占锁 检查。

当只有一个管道运行应该在任何时间点访问某个阶段时，会出现类似的情况。 例如，如果有部署到 Azure 资源组的阶段，可能需要阻止多个管道运行同时更新同一资源组。 目前，实现此要求使用代理资源（例如环境），并在该环境中放置独占锁检查。 这种方法可能非常耗时，增加了复杂性，并增加了维护工作量。

在此冲刺中，我们引入了在阶段级别指定独占锁的支持。 如果你有一个具有 ID 的阶段并指定其 lockBehavior 属性，则会自动为该阶段创建锁。 资源 sequential 级锁和阶段级锁的行为保持一致。 但是，行为 runLatest 有所不同，因为它只取消 runLatest 同一分支的生成，而不是针对管道的所有分支。

管道运行中的模板信息

我们更新了 管道运行 - 获取 REST API，其中包含有关管道运行中扩展和包含的模板的信息。

例如，请考虑使用以下 YAML 管道代码：

extends:
  template: template-stages.yml@templates
  parameters:
    stages:
    - stage: deploy
      jobs:
      - job:
        steps:
        - template: template-step.yml

新的 REST API 具有以下新属性：

"yamlDetails":
    {
        "extendedTemplates":
        [
            {
                "yamlFile": "template-stages.yml",
                "repoAlias": "templates"
            }
        ],
        "includedTemplates":
        [
            {
                "yamlFile": "template-step.yml",
                "repoAlias": "templates"
            }
        ],
        "rootYamlFile":
        {
            "ref": "refs/heads/main",
            "yamlFile": "azure-pipelines.yml",
            "repoAlias": "self"
        },
        "expandedYamlUrl": "https://dev.azure.com/fabrikamfiber/161cfeeb-d9fd-395c-917b-fec46db44fbb/_apis/build/builds/39224/logs/1"
    }

手动触发的 YAML 管道阶段

我们经常收到有关手动触发的 YAML 管道阶段的请求。 如果想要统一管道，但并不总是希望管道运行到完成，这些管道非常有用。

例如，管道可能包括生成、测试、部署到过渡环境以及部署到生产环境的阶段。 你可能希望所有阶段都自动运行，但生产部署除外，你希望在准备就绪时手动触发生产部署。

使用此冲刺，我们将添加对手动触发的 YAML 管道阶段的支持。 若要使用此功能，需要将 trigger: manual 属性添加到阶段。

请考虑以下 YAML 管道示例：

stages:
- stage: stage_WUS1
  displayName: Deploy WUS1
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''     
- stage: stage_WUS2
  displayName: Deploy WUS2
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureWIF'
        scriptType: 'ps'
        scriptLocation: 'inlineScript'
        inlineScript: 'Write-host ''hello, world'''

运行此管道时，体验如下所示：

手动触发的 YAML 管道阶段的屏幕截图。

手动触发的阶段没有依赖项，可以随时运行。 当只有手动触发的阶段需要执行时，管道运行就会完成。

后续步骤

注意

这些功能将在未来两到三周内推出。

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

提出建议

你还可以在 Stack Overflow 上获得社区的建议和问题的答案。

此致

Silviu Andrica