通过

Azure Pipelines 中的 YAML 改进 - Sprint 142 更新

  • 项目

在 Azure DevOps 的 Sprint 142 更新 中，对 YAML 进行了多项改进，例如 将自定义计数器添加到生成、 指定要为拉取请求生成的分支，以及 使用内联模板。 我们还为所有用户启用了新的导航，引入了深色主题，并改进了Azure Boards中的链接和附件体验。

有关详细信息，请查看下面的 功能 列表。

功能

常规：

Azure Boards：

Azure Repos：

Azure Pipelines：

Azure Test Plans：

Azure Artifacts：

Wiki：

管理：

常规

所有用户都启用了新导航

我们已为所有用户打开新的导航！ 这是推出新产品设计的重要里程碑。 虽然我们将使用此版本将所有人迁移到新的导航模型，但用户仍然可以选择退出并使用旧导航，直到 2019 年 1 月 16 日。 可以通过从每个页面右上角的头像下方的菜单中选择 “预览功能 ”来选择退出。

有关详细信息，请参阅 导航更新 博客文章。

深色主题

我们长期存在的功能请求之一是提供深色主题。 我们很高兴地告知你，这现已作为新导航的一部分提供。 可以通过从每个页面右上角的头像下方的菜单中选择“ 主题 ”来打开深色主题。

深色主题

Azure Boards

使用更丰富的工作项附件整理参考资料

通过将文件附加到工作项，你和你的团队可以集中参考资料，以便在需要时始终靠近它们。 现在只需将文件拖放到工作项窗体上的任意位置，即可更轻松地添加新附件。 可以继续以列表形式查看附件，或切换到网格视图以显示缩略图预览。 双击文件以打开预览，并循环浏览它们以快速找到所需的信息。

工作项附件

通过链接整个组织的工作项来管理依赖项

链接相关工作或依赖性工作可为你提供更广泛的上下文，让你能够跟踪的工作，并帮助你管理与其他团队的依赖关系。 借助远程工作链接，现在可以跟踪公司内组织的工作。 只需复制现有工作项的 URL，转到另一个工作项，然后使用三种新链接类型之一创建链接：使用来源、生成者和远程相关。 有关Azure Boards中的可跟踪性的详细信息，请参阅工作项链接文档。

注意

两个 Azure DevOps 组织都尊重权限，这两个组织都必须由同一 Azure AD 租户提供支持。

远程链接

开始管理多个依赖项时，请使用“查询”中的新“远程链接计数”字段列出项目中具有远程依赖项的工作项，或考虑安装依赖项跟踪器扩展。 此扩展是由 Microsoft 的 Windows 组为满足其缩放需求而创建的，它基于远程链接构建，以显示依赖项的丰富层次结构和图形表示形式。

以前，如果工作项预览窗格已关闭，则无法从搜索结果页面打开工作项。 这样便难以深入了解搜索结果。 现在你可以单击工作项标题以在模式窗口中打开工作项。 此功能通过 UserVoice设置了优先级。

Azure Repos

扩展创建者可以查询有关当前存储库的上下文

版本控制扩展创建者面临的一个挑战是获取向用户显示的存储库上下文，如名称、ID 和 URL。 为了帮助应对此挑战，我们添加了 VersionControlRepositoryService 作为扩展可访问的服务。 扩展创建者使用此服务可以查询有关 Web UI 中当前 Git 存储库上下文的信息。 它当前具有一个方法，即 getCurrentGitRepository()。

  • 如果选择了 Git 存储库，则会返回 GitRepository 对象以及有关该存储库的基本数据（名称、ID 和 URL）
  • 如果选择了 TFVC 存储库或在 Azure Repos 页面外部访问该服务，则会返回 null。

下面是使用此服务 的示例扩展 。

Azure Pipelines

将自定义生成计数器添加到生成

生成计数器提供对生成进行唯一编号和标记的方法。 以前可以使用 $(rev:r) 特殊变量来实现此目的。 现在可以在生成定义中定义自己的计数器变量，这些变量在每次运行生成时自动递增。 可在定义的变量选项卡上执行此操作。 这一新功能在以下方面为你提供更强大的功能：

  • 可以定义自定义计数器并设置其种子值。 例如，可以在 100 处启动计数器。 $ (rev：r) 始终从 0 开始。
  • 可以使用自己的自定义逻辑来重置计数器。 $ (rev：r) 与生成号相关联，每当生成号中存在新前缀时，它会自动重置。
  • 对每个定义可以定义多个计数器。
  • 可以查询生成之外的计数器值。 例如，可以使用计数器对自上次重置以来运行的生成数进行计数。

有关生成计数器的详细信息，请参阅有关 用户定义的变量 的文档。

使用 YAML 指定要为拉取请求生成的分支

YAML 管道可以指定要为 PR 生成的分支 (拉取请求) 。 可以选择要包括和排除的分支。 此功能以前在 Web UI 中可用。 通过将其移动到 YAML 文件，它将成为配置即代码工作流的一部分。

使用 PR 触发器的示例可能如下所示：

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

使用内联 YAML 模板表达式

YAML 模板是重复使用部分管道的强大方法。 除了分解常见代码外，模板表达式还允许更改值并控制包含的 YAML。 到目前为止，模板表达式必须占用 YAML 表达式中的整个值。 此示例将起作用，因为表达式是 解决方案 属性的整个值。

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

现在，我们放宽了限制，允许内联模板，如以下示例所示。

- script: echo The solution file is ${{ parameters.solution }}

使用管道初始化日志改进故障排除

管道运行时，Azure Pipelines 必须确保管道定义正确、确定要计划哪些作业、请求代理运行作业等。 到目前为止，此过程是完全不透明的，因此当出现问题时，客户几乎不可能解决问题。 我们将引入一种称为管道初始化日志的新型日志，它使这些详细信息可见。 可以通过在已完成的生成中选择 “下载所有日志 ”选项来访问管道初始化日志。

YAML 管道的默认保留期

我们正在努力为用户配置 YAML 管道的保留策略。 在此新功能推出之前，我们已将所有 YAML 版本的默认保留期增加到 30 天，因为许多用户希望将其内部版本保留时间比我们以前的 10 天默认保留期更长。 我们删除了 YAML 管道编辑器中的保留选项卡，直到新模型就位。

Linux/ARM 和 Windows 32 位平台上的生成

64 位 (x64) Windows、macOS 和 Linux 始终支持 Azure Pipelines 开放源代码跨平台代理。 此次冲刺，我们将引入两个新的受支持平台： Linux/ARM 和 Windows/32 位。 这些新平台使你可以在不太常见，但并不是不重要的平台（如 Raspberry Pi、Linux/ARM 计算机）上进行生成。

克隆变量组

我们添加了对克隆变量组的支持。 每当要复制变量组并且只更新少数变量时，无需完成逐个添加变量的冗长过程。 现在可以快速复制变量组，相应地更新值，然后将它保存为新变量组。

克隆变量组

注意

在克隆变量组时不会复制机密变量值。 需要更新加密变量，然后保存克隆的变量组。

查看所有链接源的提交和工作项

我们将继续致力于提高可跟踪性，我们很高兴地宣布，客户现在可以查看链接到管道的所有项目的提交和工作项详细信息。 默认情况下，将提交和工作项与最后一个部署到同一阶段进行比较。 但是，如果需要，可以与任何其他以前的部署进行比较。

链接源

从 Azure 应用服务部署中支持的包运行

Azure 应用服务部署任务 (4.*) 版本现在支持 RunFromPackage (以前称为 RunFromZip。

应用服务支持多种不同的技术来部署文件，如 msdeploy（又称为 WebDeploy）、git、ARM 等。 但所有这些技术都有一个限制。 文件部署在 wwwroot 文件夹（具体而言是 d:\home\site\wwwroot）下，运行时随后从其中运行文件。

借助“从包运行”功能，不再需要将各个文件复制到 wwwroot 的部署步骤。 而是只需将它指向到一个 zip 文件，该 zip 会作为只读文件系统装载在 wwwroot 上。 这样做有以下几个好处：

  • 减少文件副本锁定问题的风险。
  • 可部署到生产应用（需重启）。
  • 可以确定哪些文件在应用中运行。
  • 提高 Azure 应用服务部署的性能。
  • 可以减少冷启动时间，特别是对于具有大型 npm 包树的 JavaScript 函数。

使用应用服务器部署任务部署 Linux 容器

4.* 版本的 Azure 应用服务部署任务现在支持将自己的自定义容器部署到 Linux 上的 Azure Functions。

Azure Functions 的 Linux 托管模型基于 Docker 容器，这些容器在打包和利用应用特定依赖项方面可提供更高灵活性。 Linux 上的 Functions 可以采用 2 种不同模式进行托管：

  1. 内置容器映像： 你带来了函数应用代码，Azure (内置映像模式) 提供和管理容器，因此不需要与 Docker 相关的特定知识。 这在现有版本的应用服务部署任务中受支持。
  2. 自定义容器映像：我们增强了 App 服务 部署任务，以支持将自定义容器映像部署到 Linux 上的 Azure Functions。 当函数需要特定语言版本或需要内置映像中未提供的特定依赖项或配置时，可以使用 Azure Pipelines 生成自定义映像并部署到 Linux 上的 Azure Functions。

Azure Test Plans

用于为桌面应用程序运行手动测试的 Azure 测试运行器客户端

现在可以使用 Azure Test Runner (ATR) 客户端为桌面应用程序运行手动测试。 这会帮助你从 Microsoft 测试管理器迁移到 Azure Test Plans。 请在此处参阅我们的指南。 使用 ATR 客户端可以运行手动测试并记录每个测试步骤的测试结果。 还可获得数据收集功能，如屏幕截图、图像操作日志和音频视频录制。 如果在测试时发现问题，请使用测试运行程序创建 bug，bug 中会自动包含测试步骤、屏幕截图和注释。

ATR 需要对运行程序进行一次性下载和安装。 选择为桌面应用程序运行，如下所示。

Azure 测试运行程序

Azure 测试运行程序安装

Azure Artifacts

管道项目的公共预览版

我们将发布管道项目的公共预览版，这是一种新的高度可缩放的项目类型，旨在与 Azure Pipelines 一起使用。 管道项目基于最近发布的 通用包 功能使用的相同技术，可以显著减少存储大型企业级生成的生成输出所需的时间。

Wiki

使用参与权限将代码发布为 wiki

以前，只有对 git 存储库拥有创建存储库权限的用户才能将代码发布为 wiki。 这使得存储库管理员或创建者成为将 git 存储库中托管的 Markdown 文件发布为 wiki 的任何请求的瓶颈。 现在，如果只是对代码存储库具有“参与讨论”权限，则可以将代码发布为 Wiki。

管理

PAC 强制实施 CAP

2017 年 2 月，我们宣布 支持 Azure Active Directory 条件访问策略 (CAP) ，但存在一个限制，即备用身份验证机制（如个人访问令牌）不会强制实施 CAP。 我们很高兴地宣布，我们已经填补了这一空白，Azure DevOps 现在在使用 PAT、SSH 密钥、备用身份验证凭据和 OAuth 时将遵循 CAP IP 隔离策略。 管理员无需执行任何操作即可利用此功能。 它将自动应用于所有现有策略。

后续步骤

注意

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

阅读下面的新功能，并转到 Azure DevOps 亲自试用。

转到 Azure DevOps

如何提供反馈

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

提出建议

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

此致

亚伦·布约克