Azure DevOps Server 2019 Update 1 发行说明

| 开发者社区System 要求 | 许可条款 | DevOps博客 | SHA-1 哈希

在本文中,你将找到有关Azure DevOps Server最新版本的信息。

若要详细了解如何安装或升级Azure DevOps Server部署,请参阅Azure DevOps Server要求。 若要下载Azure DevOps产品,请访问Azure DevOps Server下载页面

Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本支持直接升级到 Azure DevOps Server 2020。 如果 TFS 部署为 TFS 2010 或更低版本,必须先执行一些过渡步骤,然后才能升级到 Azure DevOps Server 2019。 若要了解详细信息,请参阅安装和配置本地Azure DevOps


从 2019 Azure DevOps Server 安全升级到 2020 Azure DevOps Server

Azure DevOps Server 2020 引入了新的管道运行 (生成) 保留模型,该模型基于项目级设置工作。

Azure DevOps Server 2020 根据管道级保留策略以不同的方式处理生成保留。 某些策略配置会导致升级后删除管道运行。 升级后不会删除手动保留或由发布保留的管道运行。

阅读我们的博客帖子,详细了解如何从 2019 Azure DevOps Server 安全地升级到 2020 Azure DevOps Server。

Azure DevOps Server 2019 Update 1.2 发布日期:2022 年 5 月 17 日

Azure DevOps Server 2019 Update 1.2 是 bug 修复的汇总。 可以直接安装 Azure DevOps Server 2019 Update 1.2 或从 Azure DevOps Server 2019 或 Team Foundation Server 2013 或更高版本升级。

注意

此版本发布后,数据迁移工具将用于 Azure DevOps Server 2019 Update 1.2。2 大约三周后。 可在此处查看导入的当前支持的版本列表。

此版本包括以下修补程序:

  • 禁用用户的 Active Directory 帐户后,撤销所有个人访问令牌。

Azure DevOps Server 2019 Update 1.1 修补程序 13 发布日期:2022 年 1 月 26 日

我们发布了 Azure DevOps Server 2019 Update 1.1 的修补程序,其中包括以下修补程序。

  • 使用 @mention 工作项中的控件时,不会发送电子邮件通知。
  • 用户个人资料中的首选电子邮件地址未更新。 这导致了电子邮件发送到之前的电子邮件地址。
  • 通过从 log4j 二进制文件中删除 jndilookup 类来解决 Elasticsearch 漏洞。

安装步骤

  1. 使用 Patch 13 升级服务器。
  2. 检查 HKLM:\Software\Elasticsearch\Version 的注册表值。 如果注册表值不存在,请添加一个字符串值,并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
  3. 按照自述文件中的说明运行 update 命令 PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update。 它可能会返回类似于下面的警告:无法连接到远程服务器。 请勿关闭窗口,因为更新正在执行重试,直到完成。

注意

如果Azure DevOps Server和 Elasticsearch 安装在不同的计算机上,请按照下面概述的步骤进行操作。

  1. 使用 Patch 13 升级服务器。
  2. 检查 HKLM:\Software\Elasticsearch\Version 的注册表值。 如果注册表值不存在,请添加一个字符串值,并将版本设置为 5.4.1 (Name = Version, Value = 5.4.1)。
  3. 将名为 zip C:\Program Files\{TFS Version Folder}\Search\zip 的文件夹的内容复制到 Elasticsearch 远程文件文件夹中。
  4. 在 Elasticsearch 服务器计算机上运行 Configure-TFSSearch.ps1 -Operation update

SHA-256 哈希: DB762E391F9DF8E71E58D6FAA169CA44DFBE996AE6567B55F772CBA9E3DA2AB3

Azure DevOps Server 2019 Update 1.1 修补程序 12 发布日期:2021 年 9 月 15 日

Azure DevOps Server 2019 Update 1.1 的修补程序 12 包括以下修补程序。

  • 修复包含“包含单词”的查询的工作项宏。 以前,查询为包含换行符的值返回不正确的结果。
  • 自定义工作项布局状态的本地化问题。
  • 电子邮件通知模板中的本地化问题。
  • 为字段定义了多个 NOTSAMEAS 规则时,NOTSAMEAS 规则评估的问题。

Azure DevOps Server 2019 Update 1.1 修补程序 11 发布日期:2021 年 9 月 14 日

Azure DevOps Server 2019 Update 1.1 的修补程序 11 包括以下修补程序。

Azure DevOps Server 2019 Update 1.1 修补程序 10 发布日期:2021 年 8 月 10 日

Azure DevOps Server 2019 Update 1.1 的修补程序 10 包括以下修补程序。

  • 修复了某些工作项类型的电子邮件传递作业的问题。

Azure DevOps Server 2019 Update 1.1 修补程序 9 发布日期:2021 年 6 月 15 日

Azure DevOps Server 2019 Update 1.1 的修补程序 9 包括以下修补程序。

  • 修复了数据导入问题。 对于具有大量过时测试用例的客户来说,数据导入需要很长时间。 这是因为引用增加了表的大小 tbl_testCaseReferences 。 在此修补程序中,我们删除了对过时测试用例的引用,以帮助加快数据导入过程的速度。

Azure DevOps Server 2019 Update 1.1 修补程序 8 发布日期:2021 年 4 月 13 日

我们发布了 Azure DevOps Server 2019 Update 1.1 的修补程序,修复了以下内容。

若要实现此修补程序的修补程序,必须按照下面列出的步骤 安装常规修补程序AzureResourceGroupDeploymentV2 任务安装。

常规修补程序安装

如果已Azure DevOps Server 2019 Update 1.1,则应安装 Azure DevOps Server 2019 Update 1.1 修补程序 8

验证安装

  • 选项 1:运行 devops2019.1.1patch8.exe CheckInstall,devops2019.1.1patch8.exe是从上述链接下载的文件。 命令的输出将指示已安装修补程序或未安装修补程序。

  • 选项 2:检查以下文件的版本: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll。 默认情况下,Azure DevOps Server 2019 安装到c:\Program Files\Azure DevOps Server 2019。 安装 Azure DevOps Server 2019.1.1 修补程序 8 后,版本将为 17.153.31129.2。

AzureResourceGroupDeploymentV2 任务安装

注意

下面提及的所有步骤都需要在 Windows 计算机上执行

安装

  1. AzureResourceGroupDeploymentV2.zip 包提取到计算机上的新文件夹。 例如: D:\tasks\AzureResourceGroupDeploymentV2

  2. 下载并安装 Node.js 14.15.1,npm (随计算机下载Node.js一起下载) 。

  3. 在管理员模式下打开命令提示符,并运行以下命令以安装 tfx-cli。

npm install -g tfx-cli
  1. 创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。

  2. 从命令提示符下运行以下命令。 出现提示时,输入服务 URL 和个人访问令牌。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 运行以下命令,将任务上传到服务器。 使用从步骤 1 中提取的 .zip 文件的路径。
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019 Update 1.1 修补程序 7 发布日期:2021 年 1 月 12 日

我们发布了 Azure DevOps Server 2019 Update 1.1 的修补程序,修复了以下内容。 有关详细信息,请参阅博客文章

  • 测试运行详细信息不显示使用 OpsHub 迁移迁移的测试数据的测试步骤详细信息
  • “Microsoft.TeamFoundation.TestManagement.Server.TCMLogger”初始值设定项的异常
  • 迁移到 Azure DevOps Server 2020 后,立即删除未执行的内部版本
  • 修复数据提供程序异常

Azure DevOps Server 2019 Update 1.1 修补程序 6 发布日期:2020 年 12 月 8 日

我们发布了修复以下内容的 Azure DevOps Server 2019 Update 1.1 修补程序。 有关详细信息,请参阅博客文章

  • CVE-2020-1325:Azure DevOps Server欺骗漏洞
  • CVE-2020-17135:Azure DevOps Server欺骗漏洞
  • CVE-2020-17145 :Azure DevOps Server 和 Team Foundation Services 欺骗漏洞
  • 修复了 TFVC 未处理所有结果的问题

重要

请在安装此修补程序之前阅读下面提供的完整说明。

常规修补程序安装

如果已Azure DevOps Server 2019 Update 1.1,则应安装 Azure DevOps Server 2019 Update 1.1 修补程序 6

验证安装

  • 选项 1:运行 devops2019.1.1patch6.exe CheckInstall,devops2019.1.1patch6.exe是从上述链接下载的文件。 命令的输出将指示已安装修补程序或未安装修补程序。

  • 选项 2:检查以下文件的版本: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll。 默认情况下,Azure DevOps Server 2019 安装。c:\Program Files\Azure DevOps Server 2019 安装 Azure DevOps Server 2019.1.1 修补程序 6 后,版本将为 17.153.30723.5。

AzurePowerShellV4 任务安装

注意

下面提及的所有步骤都需要在 Windows 计算机上执行

先决条件

  1. 在专用代理计算机上安装 Azure PowerShell Az 模块 Azure Powershell

  2. 使用 AzurePowerShellV4 任务创建管道。 任务中只会看到一个 “标准错误失败 ”。

安装

  1. AzurePowerShellV4.zip 包提取到名为 AzurePowerShellV4 的文件夹。

  2. 根据计算机的要求下载并安装 Node.js 14.15.1 和 npm(包含在 Node.js 下载项中)。

  3. 在管理员模式下打开命令提示符,并运行以下命令以安装 tfx-cli。

npm install -g tfx-cli
  1. 创建具有完全访问特权的个人访问令牌并复制它。 运行 tfx login 命令时将使用此个人访问令牌。

  2. 从命令提示符下运行以下命令。 出现提示时,输入服务 URL 和个人访问令牌。

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

  1. 运行以下命令,将任务上传到服务器。 提取的包的路径为 D:\tasks\AzurePowerShellv4
  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019 Update 1.1 修补程序 5 发布日期:2020 年 9 月 8 日

我们发布了修复以下内容的 Azure DevOps Server 2019 Update 1.1 修补程序。 有关详细信息,请参阅博客文章

  • DTS 1713492 - 将 AD 组添加到安全权限时出现意外行为。

Azure DevOps Server 2019 Update 1.1 修补程序 4 发布日期:2020 年 7 月 14 日

我们发布了修复以下内容的 Azure DevOps Server 2019 Update 1.1 修补程序。 有关详细信息,请参阅博客文章

  • CVE-2020-1326:跨站点脚本漏洞
  • 选择其他 Git 源时,生成管道显示未经授权的用户的连接不正确。
  • 修复了在 XAML 生成定义中将继承更改为“打开”或“关闭”时出错。

Azure DevOps Server 2019 Update 1.1 修补程序 3 发布日期:2020 年 6 月 9 日

我们发布了修复以下内容的 Azure DevOps Server 2019 Update 1.1 修补程序。 有关详细信息,请参阅博客文章

  • CVE-2020-1327:确保Azure DevOps服务器清理用户输入。

Azure DevOps Server 2019 Update 1.1 修补程序 2 发布日期:2020 年 4 月 14 日

我们发布了修复以下内容的 Azure DevOps Server 2019 Update 1.1 修补程序。 有关详细信息,请参阅博客文章

  • SVN 提交不会触发管道

  • 在 AZURE DEVOPS 上添加对 SSH 中的 SHA2 的支持

Azure DevOps Server 2019 Update 1.1 修补程序 1 发布日期:2020 年 3 月 10 日

我们发布了 Azure DevOps Server 2019 Update 1.1 的安全修补程序,修复了以下 bug。 有关详细信息,请参阅博客文章


Azure DevOps Server 2019 Update 1.1 RTW 发布日期:2019 年 12 月 10 日

Azure DevOps Server 2019 Update 1.1 是 bug 修复和安全更新的汇总。 它包括以前发布的 Azure DevOps Server 2019 Update 1 修补程序中的所有修补程序。 可以直接安装 Azure DevOps Server 2019 Update 1.1 或从 Azure DevOps Server 2019 或 Team Foundation Server 2012 或更高版本升级。

注意

数据迁移工具将在发布后大约三周Azure DevOps Server 2019 Update 1.1 提供。 可在此处查看导入的当前支持的版本列表。

此版本包括针对以下 bug 的修补程序:

Azure Boards

  • 从产品积压工作项创建新工作项时,不会使用进程模板中的默认值初始化“标题”字段。
  • 使用Azure Boards时速度缓慢和超时。
  • 工作项链接上的“修订依据”值不正确。

Azure Pipelines

Azure Test Plans

  • 编辑Test Plans中的字段速度较慢。
  • 在测试用例中,从Boards (打开而不是Test Plans) 时,共享步骤详细信息不会打开。

常规

管理

  • 内存使用率高
  • 具有负载均衡器配置的服务器必须将其公共源显式添加到 AllowedOrigins 注册表项。
  • 在SQL Azure上安装的客户看不到“完整试用版”对话框。
  • 安装扩展会显示错误“错误消息缺少贡献 (ms.vss-dashboards-web.widget-sdk-version-2) ”。
  • 设置弹性搜索时,出现错误:“用户未经授权”。
  • 从 TFS 2018 Update 2 或更高版本升级时,弹性搜索中的索引和查询失败。
  • 配置Azure DevOps Server时,“创建仓库”步骤失败。

此版本包括以下更新:

  • 支持 SQL Server 2019。

Azure DevOps Server 2019 Update 1 修补程序 1 发布日期:2019 年 9 月 10 日

我们发布了 Azure DevOps Server 2019 Update 1 的安全修补程序,修复了以下 bug。 有关详细信息,请参阅博客文章


Azure DevOps Server 2019 Update 1 发布日期:2019 年 8 月 20 日

注意

数据迁移工具将在发布后大约三周Azure DevOps Server 2019 Update 1 使用。 可在此处查看导入的当前支持的版本列表。


RC2 发布日期:2019 年 7 月 23 日

RC2 包括自 RC1 以来的多个 bug 修复,也是最终计划的预发行版。


RC1 发布日期:2019 年 7 月 2 日

Azure DevOps Server 2019 Update 1 中的新增功能摘要

Azure DevOps Server 2019 Update 1 引入了许多新功能。 其中一些要点包括:

还可以跳转到各个部分以查看新功能:


常规

深色主题

深色主题是Azure DevOps Services的热门功能,现在可在Azure DevOps Server中使用。 可以通过从每个页面右上角的头像下方的菜单中选择 “主题 ”来打开深色主题。

Dark theme

Boards

新的基本流程

从历史上看,敏捷是新项目的默认过程,提供一组可靠的灵活工作项类型和状态,以满足各种项目交付方法。 对于一些更熟悉其他工具或想要采用更强大的工具集的团队,想要开始使用他们更熟悉的术语。

新的基本流程提供了三种工作项类型, (史诗、问题和任务) 来规划和跟踪工作。 建议使用问题跟踪用户情景、bug 和功能等内容,同时使用 Epics 将问题组合到更大的工作单元中。 在工作上取得进展时,将项沿简单状态工作流移动微软待办、“执行”和“完成”。

basic process

请参阅 跟踪问题和任务 文档,帮助你开始使用新项目。

工作项窗体上的状态值顺序

以前,工作项窗体上的状态值按字母顺序排序。 通过此更新,我们更改了状态值的顺序以匹配进程设置中的工作流顺序。 还可以更改状态自定义设置中每个类别中状态的顺序。

state order

功能启用不再可用

客户需要手动更新每个项目的 XML,以便在升级集合后启用新功能。

feature enablement

请参阅 文档 ,了解如何启用特定功能。

使用更丰富的工作项附件组织参考资料

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

Work item attachments

使用锁屏提醒共享团队的董事会

存储库的自述文件通常是项目团队转为了解如何参与和使用解决方案的主页。 现在,就像可以在 Azure Pipelines 中使用生成或部署状态一样,可以在 Azure Boards 中添加团队董事会的徽章。 可以将锁屏提醒配置为仅显示“正在进行”列或所有列,甚至可以在项目开放源代码时公开显示锁屏提醒。

Short video that shows how to share your team's boards using badge.

如果自述文件基于 Markdown,只需从状态锁屏提醒设置页复制示例 Markdown 并将其粘贴到文件中。

Screenshot showing Badge in a README on GitHub.

查询相对于日期、星期、月或年份开始的工作

虽然团队通常专注于下一个或基于冲刺迭代的上下文中的工作,但通过日历的镜头回顾工作,以报告上个月或当年第一季度发生的所有工作,这通常很有趣。 现在,可以使用以下新的 一组@StartOf 宏以及任何基于日期的字段根据一天、周、月或年开始查询:

  • @StartOfYear
  • @StartOfMonth
  • @StartOfWeek
  • @StartOfDay

其中每个宏还接受新的修饰符字符串,使你可以按不同的日期单位移动数据。 例如,可以通过查询状态更改日期 = @StartOfYear 和状态更改日期 ><= @StartOfYear(“+3M”) ,编写查询以查找今年第一季度完成的所有工作项。 有关详细信息,请参阅 查询宏 文档。

Screenshot showing query for work relative to the start of the day, week, month, or year.

编辑和删除讨论批注

我们很高兴地宣布,在Azure Boards的工作项讨论中,提供高度投票的开发者社区功能、编辑和删除批注。 若要编辑批注,只需将鼠标悬停在你拥有的任何批注上,你将看到两个新按钮。 如果单击铅笔图标,将进入编辑模式,只需进行编辑,然后按“更新”按钮保存编辑。

Screenshot showing discussion comments.

单击溢出菜单时,将看到删除批注的选项。 单击此项后,系统会再次提示确认要删除此批注,并将删除批注。

Screenshot showing how to delete discussion comments.

你将在工作项窗体的“历史记录”选项卡中完整跟踪编辑和删除的所有批注。 你还将看到,我们更新了讨论体验的 UI,使其感觉更现代和交互。 我们添加了批注周围的气泡,以明确个人评论的开始和结束位置。

将查询结果导出到 CSV 文件

现在可以直接从 Web 将查询结果导出到 CSV 格式化文件。

Short video showing how to export query results.

现在,使用语法在注释中提及问题、拉取请求或提交GitHubAB#{work item ID}的工作项时,这些提及将变为超链接,你可以单击这些超链接直接导航到所提及的工作项。

这不会创建一个正式链接,使每个相关对话的工作项Azure Boards混乱,而是为团队提供了一种在讨论代码或客户报告问题时提供有关工作项的详细信息的方法。 有关详细信息,请参阅Azure Boards GitHub集成文档。

Screenshot showing a pull request on GitHub.

在Azure Boards中规划时,在GitHub中接受和执行问题

现在可以将Azure Boards中的工作项与GitHub中的相关问题链接。 有了这种新型链接,现在可以使用其他几种方案。 例如,如果团队希望继续接受来自用户的 bug 报告,例如,作为GitHub内的问题,但现在可以在Azure Boards中关联和组织团队的整体工作。

Screenshot showing that you can link work items in Azure Boards with related issues in GitHub.

团队用于提交和拉取请求的相同提及语法仍然适用,当然,你可以手动在Azure Boards中链接到问题 URL。 有关详细信息, & 请参阅GitHub Azure Boards文档。

Screenshot showing how to link manually in Azure Boards with the GitHub issue URL.

从看板快速查看链接GitHub活动

当你自己或团队查看看板时,你经常有问题,例如“此项目是否尚未开始开发?”或“此项目是否尚未审查?”使用 Kanban 开发板上的新GitHub批注,现在可以快速了解项的位置,并直接导航到GitHub提交、拉取请求或问题以获取更多详细信息。 有关此和任务和测试的其他批注的详细信息,请参阅 “自定义卡片 ”文档。

Screenshot showing how to view linked GitHub activity from the Kanban board.

Repos

草稿拉取请求

为了阻止拉取请求在已准备就绪之前完成以及轻松地创建可能不涉及任何人的正在进行的工作,我们现在支持草稿拉取请求。

在创建拉取请求时,可以通过从创建按钮下拉列表中选择创建为草稿来创建草稿拉取请求。

Create PR draft

创建了草稿拉取请求之后,便会在标题旁看到一个指示其状态的徽章。

Screenshot of a pull request showing that it is a DRAFT.

草稿拉取请求不包括审阅者或默认运行生成,但允许手动添加审阅者和运行生成。 若要将拉取请求提升为普通拉取请求,只需单击拉取请求详细信息页中的 “发布 ”按钮。

重新运行自动完成拉取请求的过期生成

Azure Repos现在会自动对请求策略触发的过期生成进行排队。 这适用于已传递所有其他策略并设置为自动完成的拉取请求。

以前,当拉取请求具有所需的审阅者等策略时,审批过程可能需要太长的时间,关联的生成可能会在审阅者批准拉取请求之前过期。 如果拉取请求设置为自动完成,则在用户手动排队过期生成之前,该请求将保持阻止状态。 通过此更改,生成将自动排队,以便拉取请求可以在成功生成后自动完成。

注意

此自动化只会为每个拉取请求排队最多五个过期的内部版本,并且只会尝试对每个生成重新排队一次。

在拉取请求中仅查看左侧或右侧文件

目前,在拉取请求中查看文件更改时,可以使用 并行差异内联差异 模式。 我们已收到反馈,表明你们中的许多人只想查看原始文件或已更改的文件,而无需对其进行比较,因此我们添加了一个新选项,允许你单独查看左侧文件或右文件。

Screenshot of the Side-by-side diff options with the cursor hovering over the Show modified content.

用于完成拉取请求的新合并类型

将请求请求中的更改合并到目标分支时,现在有更多的选项。 我们在开发者社区添加了对两项最请求的功能的支持:快速向前合并半线性合并 (也称为“重新基和合并”) 。

现在,你将在 “完成拉取请求 ”对话框中看到这些新选项:

Screenshot showing new merge types for completing pull requests.

更新的策略管理页允许管理员控制分支或分支文件夹上允许哪些合并策略。

Screenshot of the Limit merge types section.

注意

仍强制实施现有策略。 例如,如果分支当前只有“仅壁球合并”策略,则必须编辑该策略才能使用新的合并策略。

在拉取请求完成期间重新分组的情况有以下几种情况:

  • 如果目标分支上的策略禁止使用存储库策略,则需要“替代分支策略”权限。
  • 如果拉取请求的源分支具有策略,则无法对其进行重新定基。 Rebasing 将修改源分支,而无需执行策略审批过程。
  • 如果使用 合并冲突扩展 来解决合并冲突。 对三向合并应用的冲突解决很少成功, (甚至有效的) 每次重新提交拉取请求中的所有提交。

在所有这些情况下,你仍可以选择在本地重新设置分支并推送到服务器,或者在完成拉取请求时将更改合并到库。

(PR) 拉取请求中按目标分支进行筛选

拉取请求可让团队查看代码,并在将更改合并到主分支之前提供更改反馈。 他们已成为许多团队工作流的重要组成部分,因为你可以逐步完成建议的更改、留下批注和投票以批准或拒绝代码更改。

为了更轻松地查找拉取请求,我们添加了一个筛选选项,用于使用目标分支搜索 PR。

Screenshot of Azure Pipelines pull request filtering options.

还可以使用目标分支筛选自定义 “我的” 选项卡中的拉取请求视图。

Screenshot of the Customize pull request in Mine tab.

允许扩展添加语法突出显示和自动完成

目前,我们针对 摩纳哥编辑器支持的语言子集发布语法突出显示。 但是,许多你希望为不支持的语言创建自己的语法突出显示。

通过此更新,我们添加了一个扩展点,允许扩展将语法突出显示和自动完成添加到文件资源管理器并拉取请求视图。

在此处找到演示此功能的扩展示例。

此外,我们添加了对Kusto语言语法突出显示的支持。

存储库创建扩展点

我们添加了一个扩展点,用于向存储库选取器添加新项。 通过此扩展点,可以将自定义操作添加到存储库选取器菜单中 (重定向、弹出窗口等) ,从而启用备用存储库创建方案等流。

Screenshot showing repository creation extension.

改进了编码支持

以前,在 Web 上编辑和保存文件只会另存为 UTF-8 编码,在文件编码发生更改时,我们没有提示你。 现在,当你尝试保存未通过 (Web 编码的 UTF 文件时,我们将发出警告,该文件仅支持 UTF 编码) 。 此外,我们还添加了对通过 Web 推送终结点进行 UTF-16 和 UTF-32 编码的支持。 这意味着我们将保留编码类型,因此无需将其重写为 UTF-8。

以下屏幕截图显示了在 Web 推送引入编码更改时将看到的对话框示例。

Screenshot showing a warning mesaage that says: Non-ASCII charachters have been added. Commiting will encode this file as Unicode.

go 获取Azure Repos中的命令支持

Go 是一种开放源代码编程语言,也称为 Golang。 在 Go 中,可以使用 get 命令 下载和安装包和依赖项。 通过此更新,我们在Azure DevOps存储库中添加了对go get的支持。 使用 go get时,你将能够下载包及其依赖项,这些依赖项由导入路径命名。 可以使用 import 关键字指定导入路径。

管道

包含 YAML 管道IntelliSense的 Web 编辑器

如果使用 YAML 定义管道,现在可以利用此版本引入的新编辑器功能。 无论是创建新的 YAML 管道还是编辑现有的 YAML 管道,都可以在管道 Web 编辑器中编辑 YAML 文件。 编辑 YAML 文件时,请使用 Ctrl+Space 进行IntelliSense支持。 你将看到突出显示的语法错误,并获取有关更正这些错误的帮助。

Screenshot showing the syntax errors highlighted.

用于编辑 YAML 文件的任务助手

我们将继续收到大量反馈,要求更轻松地编辑管道的 YAML 文件,因此我们正在向 YAML 编辑器添加任务助理。 在这种情况下,你将具有与经典编辑器中相同的熟悉体验,以便将新任务添加到 YAML 文件。 此新助手支持大多数常见的任务输入类型,例如选取列表和服务连接。 若要使用新的任务助手,请选择基于 YAML 的管道上的 “编辑 ”,然后选择 “任务助手”。

Short video showing how to use the Task assistant to edit YAML files.

使用标记触发 YAML 管道

将标记添加到提交时,可以触发 YAML 管道。 对于工作流包含标记的团队来说,这非常有用。 例如,当提交标记为“最后一个已知良好”时,可以启动进程。

可以指定要包含和排除的标记。 例如:

trigger:
  tags:
    include:
    - releases/*
    exclude:
    - releases/old*

内联声明容器资源

以前,我们需要在 YAML 管道中声明容器资源,然后按名称引用它们。 现在,我们提供了一个内联语法,用于不多次引用容器的情况。

jobs:
- job: my-container-job
  container:
    image: microsoft/dotnet:latest

设置为在更新拉取请求时自动取消现有管道

默认情况下,如果新提交推送到同一 PR,则拉取请求触发的管道将取消 (PR) 。 在大多数情况下,这是可取的,因为通常不想继续在过期代码上运行管道。 如果不希望此行为,可以将 autoCancel: false 添加到 PR 触发器。

pr:
  branches:
    include:
    - main
    - releases/*
  autoCancel: false

在 YAML 管道中选择签出代码的目录

以前,我们已签出 s 到 $ (Agent.BuildDirectory) 下的目录。 现在,可以选择 Git 存储库将签出以用于 YAML 管道的目录。

使用关键字 path on checkout ,你将控制文件夹结构。 下面是可用于指定目录的 YAML 代码示例。

steps:
- checkout: self
  path: my-great-repo

在此示例中,代码将签出到 my-great-repo 代理工作区中的目录。 如果未指定路径,则存储库将继续签出到名为 s 的目录。

针对 YAML 优化的新Azure 应用服务任务

我们现在支持四个新任务,这些任务提供了一种简单而强大的方法来部署具有现代开发人员Azure 应用服务。 这些任务具有优化的 YAML 语法,使在 Windows 和 Linux 平台上创作到 Azure AppServices(包括 WebApps、FunctionApps、用于容器的 WebApps 和用于容器的 FunctionApp for Containers)的部署变得简单直观。

我们还支持用于文件转换的新实用工具任务,以及 XML 和 JSON 格式的变量替换。

对新项目的默认权限的更改

到目前为止,除非项目参与者显式授予“创建生成定义”权限,否则无法创建管道。 对于新项目,团队成员可以轻松创建和更新管道。 此更改将减少新客户加入Azure Pipelines的摩擦。 始终可以更新参与者组的默认权限并限制其访问权限。

使用管道管理GitHub版本

GitHub版本是打包和向用户提供软件的好方法。 我们很高兴地宣布,你现在可以在Azure Pipelines中使用GitHub发布任务自动执行它。 使用任务可以创建新版本、修改现有草稿/已发布版本或放弃旧版本。 它支持上传多个资产、将发布标记为预发行、将发布保存为草稿等功能。 此任务还有助于创建发行说明。 它还可以自动计算 (提交和关联问题) 在此版本中所做的更改,并将其添加到用户友好格式的发行说明中。

下面是任务的简单 YAML:

task: GithubRelease@0 
displayName: 'Create GitHub Release'      
inputs:
  githubConnection: zenithworks
  repositoryName: zenithworks/pipelines-java
  assets: $(build.artifactstagingdirectory)/*.jar

Screenshot of the GitHub Release (Preview) dialog box.

使用此任务创建的示例GitHub版本:

Screenshot of a sample GitHub release created using this task.

现在可以共享指向生成日志中特定行的链接。 当与其他团队成员协作诊断生成失败时,这将有助于你。 只需从结果视图中选择日志行即可获取链接图标。

Screenshot of the Build solution dirs.proj file with a line of the log highlighted and the Copy Link to this selection option called out.

资源授权改进

我们需要为受保护的资源提供安全性 (,例如服务连接、变量组、代理池、安全文件) 在 YAML 文件中引用时。 同时,我们希望更轻松地设置和使用管道,这些类型的资源用于非生产方案。 以前,我们添加了一个设置,用于将资源标记为“已授权在所有管道中使用”。

通过此更新,即使尚未标记资源,我们也能更轻松地解决资源授权问题。 在新体验中,当生成因资源授权错误而失败时,你将看到一个选项来显式授权使用这些资源在管道中,然后继续操作。 有权授权资源的团队成员将能够直接从失败的生成中完成此操作。

Screenshot showing a pipeline summary with authorization error.

Pipelines“测试”选项卡中的新扩展贡献点

我们继续通过在Pipelines的“测试结果”选项卡中添加两个新的贡献点,使扩展框架更加强大。 这将使 市场扩展 能够提供更多定制的报告体验,并添加进一步的交互性。

这两个贡献点是:

  1. 工具栏中的“自定义操作”按钮

    有时,你可能想要执行一个操作,例如更新 API 的数据或使用测试结果中的元数据运行自定义工具。 使用此贡献点,可以创建使用所选测试结果的即时上下文将自定义 操作添加到*自定义操作-按钮的扩展。

    Screenshot of the Custom Action option.

  2. 详细信息窗格中的“自定义详细信息”选项卡

    你可能具有各种测试报告消耗工作流,并且可能需要针对失败的测试查看不同的数据点,以便进行调试和分析。 通过使用此贡献点,你的团队可以向详细信息窗格添加新选项卡,在数据网格中选择任何测试结果行时会出现该选项卡。 此新选项卡可以显示一个视图,其中包含使用内部或外部 API 提取的静态内容或动态数据。

运行一次代理

如果使用基础结构(如Azure 容器实例)运行弹性专用代理,则通常希望每个代理在离开之前只接受一个作业。 到目前为止,这并不容易,因为你必须终止代理 (可能导致) 报告失败或接受代理可能会在关闭它之前收到另一个作业的风险。 通过此更新,我们向代理配置添加了 --once 标志。 以这种方式配置代理时,它只接受一个作业,然后关闭自身。

代理池用户界面更新

项目设置中的代理池管理页已使用新的用户界面进行更新。 现在,可以轻松查看池中运行的所有作业。 此外,还可以了解作业未运行的原因。

Screenshot showing an agent pool user experience (UX) update

部署到部署组中失败的目标

默认情况下,在重新部署以前失败的运行时,Azure Pipelines用于重新运行所有作业。 现在,可以通过在部署时配置 部署选项 来替代此行为。 通过选择“ 所有作业”和“限制为部署组”选项中失败的目标 ,重新运行将运行所有作业,并将部署跳过到已更新的目标。

Screenshot showing the Deploy option selected, a test failure, and the Deployment Option section called out.

在失败时自动重新部署

当部署到阶段失败时,Azure Pipelines现在可以自动重新部署最后一次成功的部署。 可以通过在部署后条件中配置自动重新部署触发器来配置阶段以自动部署最后一个成功版本。 我们计划在未来冲刺中向自动重新部署配置添加其他触发的事件和操作。 有关详细信息,请参阅 部署组 文档。

Screenshot showing the Post-deployment conditions dialog box with the Auto-redeploy trigger section called out.

Grafana 批注服务挂钩

我们现在支持新的服务挂钩,使 你可以将 Grafana 批注添加到 Grafana 仪表板。 这样,就可以将部署与在 Grafana 仪表板中可视化的应用程序或基础结构指标中的更改相关联。

Screenshot of the Grafana dashboard showing changes in metrics.

查询 Azure Monitor 警报任务

以前版本的 查询 Azure Monitors 任务 仅支持针对经典监视体验查询警报。 使用此新版本的任务,可以查询 Azure Monitor 最近引入的统一监视体验的警报。

Screenshot showing the Query Azure Monitor Alerts preview.

部署到 Kubernetes 任务的规范文件的内联输入

以前,Kubernetes 部署任务要求你提供配置的文件路径。 现在还可以内联添加配置。

Screenshot showing the Inline configuration feature.

Docker CLI 安装程序任务

此任务允许在用户指定的代理上安装任何版本的 Docker CLI。

Screenshot showing the DockerCLI installed.

还原已删除的发布管道

删除未使用的发布管道有助于使发布管道列表保持干净,但有时会错误地删除某些内容。 通过此更新,现在可以还原在过去 30 天内删除的发布管道。 我们在“发布”页的左侧面板中添加了一个新选项卡,该选项卡将显示已删除的发布管道列表。 在此视图中,可以通过从列表中选择管道并单击 “还原 ”按钮来还原已删除的发布管道。

Screenshot showing the Restore option for pipelines.

有关发布创建请求失败的通知

可以设置通知,以在生成、代码库和其他操作发生更改时接收电子邮件。 例如,可以设置一个警报,以便在分配给工作项时收到通知。

通过此更新,我们向 “发布 ”类别添加了一个新的通知订阅。 当发布创建请求失败时,此通知将向你发送电子邮件。 一个示例方案,其中这可能是当请求创建发布失败时,因为项目版本不可用。 若要了解如何管理通知, 请参阅此处的文档。

Screenshot showing the New subscription wizard with the Release category highlighted and the A request for release creation failed option called out.

在源或管道更改时计划发布

以前,如果有计划的发布触发器,即使上游项目或发布定义中未检测到任何更改,发布也会触发发布。 仅当项目版本或发布定义发生更改时,才会将选项添加到 “计划发布触发器 ”面板,以计划发布。

Screenshot of the Scheduled release trigger section with the Only schedule releases if the source or pipeline has changed option called out.

创建发布对话框中变量的贡献点

以前,在发布创建期间所需的变量值必须由用户输入,而无需任何帮助或建议。 我们已将贡献点添加到 “创建新发布 ”对话框,以支持有助于在发布创建期间填充变量的值的扩展。

Screenshot of the Create a new release dialog box.

发布到Azure 服务总线会话队列

我们扩展了 无代理作业 生成任务,包括将消息发布到会话队列的功能。 此选项已添加到“发布到”Azure 服务总线任务。

Screenshot of the Publish To Azure Service Bus task.

Kubernetes 服务连接中的新 Azure 订阅选项

生成和版本的服务连接允许连接到外部和远程服务以执行生成或部署的任务。 可以从项目的管理员设置定义和管理服务连接

通过此更新,我们向 Kubernetes 服务连接表单添加了身份验证选项。 现在,可以选择 Azure 订阅 对连接进行身份验证。 这样就可以使用 Azure 订阅和群集名称设置 Kubernetes 连接,轻松部署到特定命名空间。

对于启用了角色的访问控制 (已启用 RBAC) 群集,在所选命名空间中创建 ServiceAccountRoleBinding 对象。 RoleBinding 对象仅将创建的服务帐户的操作限制为所选命名空间。 对于禁用 RBAC 的群集,创建的服务帐户具有跨命名空间的群集范围权限。

Screenshot of the Add a Kubernetes service connection dialog box with the Azure Subscription option called out.

Docker 注册表服务连接中的 Azure 容器注册表

现在,可以从项目的设置页创建 Docker 注册表服务连接。 若要创建连接,请在与 Azure Active Directory (AAD) 标识关联的订阅中选择一个 Azure 容器注册表。 需要与容器注册表(如 Docker@2KubernetesManifest@0 )建立服务连接的所有任务都支持指定连接的单一方法。

Screenshot showing how to add a Docker service connection.

按发布定义中的文件夹名称搜索

可以通过将它们存储在文件夹中来组织发布定义。 以前,你没有选择按文件夹执行搜索。 如果创建了大量文件夹,则很难找到特定的发布定义。 现在,可以在发布定义中按文件夹名称进行搜索,以便更轻松地查找要查找的定义。

Screenshot showing release definitions stored in folders.

生成和发布管道中的 Duffle 工具安装程序任务

Duffle 是一种命令行工具,可用于安装和管理云本机应用程序捆绑包 (CNAB) 。 使用 CNAB,可以捆绑、安装和管理容器原生应用及其服务。

在此更新中,我们添加了用于生成和发布管道的新任务,可用于安装特定版本的 Duffle 二进制文件。

Screenshot of the Duffle tool installer.

Kubernetes 清单任务

我们向发布管道添加了一个新任务,以简化使用清单文件部署到 Kubernetes 群集的过程。 与脚本中 kubectl 二进制文件的用法相比,此任务将提供以下优势:

  • 项目替换 - 部署操作将用作容器映像列表的输入,该列表可以连同其标记或摘要一起指定。 在将清单文件应用到群集之前,此版本将替换为清单文件的非模板版本,以确保群集节点拉取映像的正确版本。

  • 清单稳定性 - 对部署的 Kubernetes 对象进行检查,以便在将任务状态计算为成功/失败时合并稳定性检查的 Kubernetes 对象。

  • 可跟踪注释 - 将批注添加到已部署的 Kubernetes 对象,以叠加有关发起的组织、项目、管道和运行的可跟踪性信息。

  • 烘焙清单 - 任务的烘焙操作允许将 Helm 图表烘焙到 Kubernetes 清单文件中,以便将其应用于群集。

  • 部署策略 - 选择具有部署操作的 Canary 策略会导致创建使用 -baseline-canary 后缀的所需工作负荷百分比,以便在使用任务的提升/拒绝操作完成要保留的版本之前在任务期间 ManualIntervention 进行比较。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

升级到 Docker 任务

我们升级了 Docker 任务,以简化管道创作体验。 buildAndPush 命令现在可用于为特定容器存储库生成多个标记,并在一个步骤中将其推送到多个容器注册表。 该任务可以使用 Docker 注册表服务连接登录到容器注册表。 有关源存储库、提交和生成证明的可追溯性元数据作为标签添加到使用此任务生成的映像。

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectl 工具安装程序

我们添加了一个新任务,用于在代理上安装特定版本的 Kubectl 二进制文件。 将“v1.14.0”等 最新 版本字符串和 semver 版本字符串接受为 Kubectl 版本规范输入的有效值。

Screenshot showing the Kubectl tool installer.

ServiceNow 集成改进

跨团队协作的关键功能是让每个团队都能够使用他们选择的服务,并具有有效的端到端交付。 通过此更新,我们增强了 ServiceNow 集成,以支持所有类型的更改 (正常、标准和紧急) 。 此外,还可以根据组织中遵循的 ITSM 过程指定用于使用现有模板创建新更改请求的入口。 最后,还可以根据现有更改请求对发布进行门控。 这使你能够采用 CD,而无需更改 IT 团队建议的过程。

Screenshot showing the ServiceNow change management feature.

对 Red Hat Enterprise Linux 6 的支持

通过此更新,我们添加了对 Red Hat Enterprise Linux 6 的代理支持。 现在可以配置面向 Red Hat Enterprise Linux 6 平台的代理来执行生成和发布作业。

Azure PowerShell Az 模块支持

Azure PowerShell提供了一组 cmdlet,可用于从命令行管理 Azure 资源。 去年 12 月,Azure PowerShell Az 模块可用,现在是用于管理 Azure 资源的目标模块。

以前,我们不支持托管代理中的 Azure PowerShell Az 模块。 在生成和发布管道中使用新的Azure PowerShell任务版本 4.*,我们为所有平台添加了对新 Az 模块的支持。 Azure PowerShell任务版本 3.* 将继续支持 AzureRM 模块。 但是,为了跟上最新的 Azure 服务和功能,我们建议尽快切换到Azure PowerShell任务版本 4.* 。

Az 模块具有兼容性模式,可帮助你在更新现有脚本以使用新语法时使用现有脚本。 若要为 Az 模块启用兼容性,请使用 Enable-AzureRmAlias 命令。 别名允许将旧 cmdlet 名称与 Az 模块配合使用。 可以在此处获取有关从 Azure RM 模块迁移到 Azure PowerShell Az 模块的更多详细信息。

注意

如果使用专用代理,则需要在代理计算机上安装 Az 模块。

有关 Azure PowerShell Az 模块的详细信息,请参阅此处的文档。

Azure Active Directory (AD) 身份验证支持Azure SQL任务

除了对SQL服务器身份验证的现有支持外,还增强了Azure SQL任务,以支持使用 Azure AD (集成&密码) 和连接字符串连接到数据库。

Screenshot of the Azure SQL Database Deployment dialog box with the Authentication Type dropdown option highlighted.

使用长文件路径发布生成项目

到目前为止,存在一个限制,阻止上传路径超过 233 个字符的生成项目。 这可以防止上传 Linux 中的代码覆盖率结果,并且macOS版本的文件路径超过限制。 限制已更新,以支持长路径。

跳过提交 (CI) 的持续集成

现在可以告诉Azure Pipelines忽略提交,并跳过运行提交通常触发的管道。 只需包含在 [skip ci] HEAD 提交的提交消息中,Azure Pipelines将跳过 CI。 还可以使用下面列出的任何变体。 支持提交到 Azure Repos Git 和 GitHub Enterprise Server。

  • [skip ci][ci skip]
  • skip-checks: trueskip-checks:true
  • [skip azurepipelines][azurepipelines skip]
  • [skip azpipelines][azpipelines skip]
  • [skip azp][azp skip]
  • ***NO_CI***

Test Plans

测试结果趋势 (高级) 小组件

“测试结果趋势” (高级) 小组件提供对多个生成和版本的测试数据的准实时可见性。 “测试结果趋势” (高级) 小组件显示管道或跨管道的测试结果趋势。 可以使用它跟踪每日测试计数、通过率和测试持续时间。 随着时间推移跟踪测试质量并提高测试抵押品是维护正常DevOps管道的关键。

Screenshot of the Test Result Trend (Advanced) widget.

“测试结果趋势” (高级) 小组件可帮助你在测试结果中找到离群值,并回答如下问题:测试运行时间是否比平常长? 哪些测试文件或管道会影响我的总体合格率? 我的长时间运行的测试是什么?

为了帮助你回答这些问题,小组件提供这些功能:

  • 显示通过率的趋势,以及测试结果或测试持续时间的计数
  • 基于多个生成管道或发布管道显示测试结果
  • 使用组合图表选项在同一趋势中显示两个指标
  • 按测试结果筛选一段时间内的测试计数
  • 按分支或测试筛选所有测试结果
  • 按测试属性(如优先级环境)堆叠指标
  • 对测试文件、所有者或管道的数据进行分组

该小组件高度可配置,可用于各种方案。

通过 URL 共享测试运行结果

可以将自动化测试配置为作为生成或发布的一部分运行。 可以在生成或发布摘要的 “测试 ”选项卡中查看已发布的测试结果。 通过此更新,我们添加了 “复制结果 URL ”功能,以便你可以与团队中的其他人共享单个测试运行结果。

共享级别包括:

  • 运行级别
  • 结果级别
  • 在测试运行中选择的单个选项卡
  • 共享也与配置的任何扩展选项卡兼容

共享 URL 时,查看者将在全屏视图中看到测试结果。

Artifacts

使用 SemVer 2.0.0 版本号NuGet包

以前,Azure Artifacts不支持使用 SemVer 2.0.0 版本号 (的包NuGet包,这些版本号通常包含版本的内部元数据部分,由) 表示+。 现在,可以从包含生成元数据的 nuget.org 保存包,并使用生成元数据推送自己的包。 根据 SemVer 规范NuGet.org 策略,生成元数据不能用于订购包。 因此,不能同时1.0.0+build1发布和1.0.0+build2Azure Artifacts (或 nuget.org) ,因为这些版本将被视为等效版本,因此受不可变约束的约束。

有关包的证明信息

通过此更新,我们更轻松了解包的证明:发布包的人员或发布的内容以及它们来自的源代码提交内容。 此信息会自动填充使用 NuGetnpmMavenTwine 对 Azure Pipelines 中 Python) 任务发布的所有包进行身份验证 (。

包使用情况统计信息

到目前为止,Azure Artifacts没有提供一种方法来衡量包的使用或受欢迎程度。 通过此更新,我们向包列表和包详细信息页添加了 “下载 ”和 “用户 ”计数。 可以在任一页面右侧看到统计信息。

Screenshot of the package usage stats.

对 Python 包的支持

Azure Artifacts现在可以托管 Python 包:生成自己的包和从公共 PyPI 保存的上游包。 有关详细信息,请参阅公告博客帖子和文档

现在,可以在同一源中托管所有NuGet、npm、Maven 和 Python 包。

Screenshot showing all packages hosted in the same feed.

Maven 的上游源

上游源现在可用于 Maven 源。 这包括主要 Maven Central 存储库和Azure Artifacts源。 若要将 Maven 上游添加到现有源,请访问 源设置,选择 上游源透视,然后选择“ 添加上游源”。

Screenshot showing the Add upstream source option.

到目前为止,许多与Artifacts相关的生成任务没有为Azure Pipelines的代理基础结构提供完全支持,这导致使用来自本地代理的任务的挑战。 通过此更新,我们向以下任务添加了对代理的支持:

  • 设计器) 中的Npm@1 (“npm”
  • 设计器中的NuGetCommand@2 (“NuGet”) :仅还原和推送命令
  • 设计器中的 DotNetCoreCLI@2 (“.NET Core”) :仅还原和 nuget 推送命令
  • 设计器中的NpmAuthenticate@0、PipAuthenticate@0和TwineAuthenticate@0 (“[type] 身份验证”) :这些任务在获取身份验证令牌期间支持代理,但仍有必要配置任何后续任务/脚本/工具以使用代理。 换句话说,这些任务不会为基础工具 (npm、pip、孪生体) 配置代理。
  • 设计器中的 NuGetToolInstaller@0、NodeTool@0、DotNetCoreInstaller@0 (“[type] Installer”)

版本支持的所有Artifacts包类型

到目前为止,Pipelines版本中Azure Artifacts项目类型仅支持NuGet包。 通过此更新,支持所有Azure Artifacts包类型 (Maven、npm 和 Python)。

版本支持的Artifacts视图

以前,Azure Artifacts项目类型只能在新包版本发布到源时触发。 现在,我们还添加了对视图的支持,因此,当源中已有的包提升为视图时,可以触发发布。

保留策略可以跳过最近下载的包

到目前为止,Azure Artifacts源提供了基本保留策略,这些保留策略将在达到“每个包的最大版本数”时开始删除旧包版本。 通过此更新,我们添加了在执行此清理时跳过最近下载的包的功能。 若要启用,请编辑源并选中 最近下载的跳过包 复选框。

委托谁可以管理源

在Azure Artifacts中,Project收集管理员 (PCA) 始终能够管理Azure DevOps服务器中的所有源。 通过此更新,PCA 还可以向其他用户和组提供此功能,从而委派管理任何源的能力。

Wiki

公式和视频的 Markdown 模板

编辑 Wiki 时,不再需要记住用于添加 公式视频YAML 标记 的 markdown 语法。 现在可以单击工具栏中的上下文菜单,然后选择所选选项。

Screenshot showing the expanded context menu with the following options: Table of Contents, Videos, YAML Tag, and Formulas.

在 Wiki 中嵌入Azure Boards查询结果

现在可以以表格的形式将Azure Boards查询结果嵌入 Wiki 页面中。 下图显示了 Wiki 页面的示例,其中包含已发布的所有功能列表以及 Wiki 中嵌入的当前冲刺中的所有活动 bug。 页面中显示的内容使用现有的工作项查询。 借助此功能,可以创建动态内容,无需担心手动更新 Wiki 页面。

Screenshot of embedded Azure Boards query results displayed in the Wiki.

可以在两个步骤中添加查询结果:

  1. 单击编辑工具栏中的“查询结果”按钮。

Screenshot showing the expanded context menu with the Query Results option called out.

  1. 选择所需的查询,然后单击“插入”按钮。

现在可以在保存页面后以表的形式查看查询结果。

Screenshot of the Query Results dialog box.

Wiki Markdown 编辑器的单空格字体

随着 Wiki Markdown 编辑器的单空格字体的引入,可读性不再是挑战。 Markdown 源看起来干净且易于阅读。 此功能已根据 此建议票证确定优先级。

Screenshot of the Wiki with monospaced font.

直到现在,如果链接页面已重命名或移动,共享 Wiki 页面链接将中断。 我们现在通过向 URL 添加页面 ID 来引入永久链接。 这可确保在 Wiki 随时间变化时共享的链接保持不变。

此功能是根据 建议票证确定优先级的。

在 Wiki 页面中显示工作项状态

在此更新中,我们通过将工作项的状态添加到页面以及其 ID 和标题来增强 Wiki 页面中的工作项提及。

Screenshot showing enhanced work item mentions.

拉取请求注释中的工作项引用和Boards讨论也将显示状态。

@mention 用户和组

现在可以 @mention 在 Wiki 页面中使用用户和组。 这使得文档如团队的联系人页面、指导文档和知识文档更丰富。 下图显示了一个示例,其中显示了对任务和负责人进行冲刺回顾。

Screenshot showing what it looks like when you <span class=@mention用户和组。 />

此外,还可以通过在 Wiki 编辑页中键入“@”,从自动建议中选择用户或组。 提到的人员还将通过电子邮件收到通知。

Screenshot showing the autosuggestions that appear when you start typing an <span class=@mention." />

最后,还可以单击 @mentioned 用户以查看个人资料信息卡。 此功能已根据 此功能 建议确定优先级。

Wiki 页面上的通知

直到现在,你还没有办法知道 Wiki 页面上的内容何时发生更改。 现在,你可以关注 Wiki 页面,在编辑、删除或重命名页面时通过电子邮件收到通知。 若要跟踪对 Wiki 所做的更改,请从 Wiki 页面选择“ 关注 ”按钮。

Screenshot of an Azure DevOps Wiki page with the Follow option called out.

此功能已根据 建议票证确定优先级。 若要了解详细信息,请参阅 此处的文档。

支持 HTML 标记

现在,可以使用 HTML 标记在 Wiki 中创建更丰富的内容。 请查看下面的 HTML 标记可以执行的操作。

  1. 现在,可以使用 详细信息摘要 标记在 Wiki 页面中创建可折叠部分。 可以添加 打开 的属性,以使详细信息默认保持展开状态。

    Screenshot showing the collapsible sections that are created with the details and summary tags.

    有关 详细信息 标记的详细信息,请查看 此处的文档。

    这是基于 此建议票证的优先级。

    注意

    Edge 和 Internet Explorer 浏览器不支持此标记。

改进了表创建和编辑

到目前为止,在 Wiki 中创建和编辑表很困难。 我们进行了更改,以便更轻松地在 Wiki 中添加和管理表。

  1. 从网格创建表

    不再需要记住 markdown 表语法。 现在,可以通过从 15 X 15 网格中进行选择轻松创建 markdown 表。 只需选择所需的列数和行数,即可单击一下即可插入表格。

    Screenshot showing a blank wiki page with the Format table option selected.

    此功能已根据以下建议票证确定优先级:

  2. 更好的表可读性

    现在可以为编辑器切换 换行, 以便更好地阅读表格。 禁用换行会添加一个滚动条,使你能够更轻松地看到大型表的内容。

    Screenshot of a Wiki page with the Word Wrap option and the horizontal scrollbar called out.

  3. 自动设置 Markdown 表格式

    不再需要添加空格来对齐 markdown 列。 使用 “格式表 ”按钮,markdown 表格会自动设置格式,方法是向单元格添加空格以对齐列。 如果有大型表,请将其与 禁用换行 结合使用,使表格更易于阅读。

    Screenshot of a Wiki page with the Format tables option called out.

    还可以使用 Ctrl + Shift + F 快捷方式设置表格的格式。

报表

使用 Analytics 不再需要分析扩展

分析正日益成为Azure DevOps体验不可或缺的一部分。 客户帮助客户做出数据驱动决策是一项重要功能。

对于 Update 1,我们很高兴地宣布客户不再需要 Analytics 扩展才能使用 Analytics。 客户现在可以在 Project 集合设置下启用 Analytics。 这是一个简单的过程,适合在产品中。

下面是客户如何启用 Analytics:

  1. 导航到Project集合设置:

Screenshot showing where to find the Analytics setting.

  1. 单击“启用分析

Screenshot showing the Enable Analytics option.

大功告成! 将为集合启用分析提供支持的体验。

在 Update 1 和 Azure DevOps Server 2019 集合中创建的新集合,其中安装了已升级的 Analytics 扩展将默认启用 Analytics。

若要详细了解 Analytics 及其启用的体验,


反馈

我们期待你的宝贵意见和建议! 可以报告问题或提供想法,并通过开发者社区跟踪它,并获取有关 Stack Overflow 的建议。


返回页首