通过

适用于 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

GitHub 高级安全扫描，无需构建即可扫描 C# 和 Java 项目代码

使用 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 个代理。

团队可以使用包含与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

  • Last updated on