TeamCity 2022.04 中的新功能
在多个代理上进行并行测试
TeamCity 现在可以将构建的测试分批进行，并在单独的构建代理上运行每一批。 这样，测试将并行运行，构建将更快完成。 速度提升比例取决于构建中的测试类数量和使用的代理数量。
请参考 此文章 了解详细信息。
使用 Qodana 进行高级代码质量检查
Qodana 插件 已与 TeamCity 一起捆绑。 现在，您可以启用 Qodana 构建运行器，并将静态分析添加到您的构建链中，运行高级代码检查，查找代码重复项，跟踪代码质量的进展。 有关构建运行程序的详细信息，请参阅 Qodana。
如果您之前安装过非捆绑的 Qodana 插件并使用了 DSL，请查看我们的 升级说明。
增强了与 Amazon Web Services 的整合
TeamCity 2022.04 为其云集成添加了新功能。
将构建工件从本地存储迁移到 Amazon S3
2022.04 版本不仅允许您将新的构建工件存储在 Amazon S3 中，还可以 将现有工件从 TeamCity 的本地存储移动到 Amazon S3。 这对于刚刚开始从自我托管的设置迁移到云平台的团队来说，尤其有用。
通过 Amazon CloudFront 传输构建工件
在 Amazon S3 中存储的构建工件的传输速度取决于您与 S3 桶所在地区之间的地理距离。 为了帮助您提高工件的上传/下载速度并降低成本，TeamCity 2022.04 添加了对 Amazon CloudFront 的原生支持，这是一种提供低延迟和高传输速度的内容分发网络。
启用对 S3 存储的支持将允许 TeamCity 通过最近的 CloudFront 服务器传输构建工件。
需要构建审批
生产环境中的一些程序可能需要多于一人的批准。 TeamCity 现在允许要求指定的人或团队手动批准以运行构建。 为了防止用户意外触发构建，并更好地控制部署、资源消耗型构建或资源移除操作，请配置 构建审批功能。
限制每个分支运行的构建数量
TeamCity 2022.04 帮助您通过 限制每个分支同时运行的构建数量 来改善构建代理的分配。 例如，您的主分支可能有无限数量的构建，这些构建将占用它们需要的尽可能多的构建代理，而您限制您的功能分支一次只运行一个构建。
更智能的 VCS 集成
TeamCity 改进了 VCS 集成，并提供了以下新功能。
空间合并请求
TeamCity 现已与 JetBrains Space 集成，包含 Pull Requests 构建功能。 如果您在构建配置中启用此功能，TeamCity 将自动检测提交到您的 Space 仓库的合并请求中的更改。 对于在这些更改上运行的构建，它将在构建的概述中显示合并请求的详细信息，并将构建状态反馈到 JetBrains Space。
要在 TeamCity 中启用此功能：
在 项目设置中，配置 JetBrains Space 连接 ，并使用您的 Space 存储库 URL 和空的分支规范创建一个 Git VCS 根目录。
在 构建配置设置中，添加 拉取请求构建功能，并选择 JetBrains Space VCS 托管类型：
您可以指定 分支过滤器 ，以仅监控符合指定条件的目标分支上的合并请求。 例如，如果您设置了+:refs/heads/feature-*过滤器，TeamCity 将仅监视发送到名称以功能-开始的分支的合并请求。为了允许将构建状态发布到 JetBrains Space 中的提交详细信息中，您还需要向此构建配置添加 Commit Status Publisher 功能。
配置集成后，TeamCity 将检测提交给 JetBrains Space 目标分支的合并请求。 对于运行在请求更改上的构建，它将在 概述 选项卡中显示合并请求的详细信息：
TeamCity 也将针对每个构建更改发送状态至 JetBrains Space 中的合并请求时间线（如果在构建配置中启用了 Commit Status Publisher 功能，也会发送到提交详情）：
为了保护目标分支并确保只有经过验证的请求被合并进来，您可以为您的 Space 仓库设置 Quality Gates ，并使用 TeamCity 构建作为外部检查。 如果合并请求的构建失败，Space 将通知您，更改未通过所需的质量检查。
与 GitLab 问题的集成
从这个版本开始，TeamCity 开始支持开箱即用的 GitLab issues。
排队构建报告
现在，Commit Status Publisher 会在将相应的构建添加到队列后立即更新版本控制系统中的提交状态，为您提供最新的信息。 GitHub 、 GitLab 、 Space 、 Bitbucket 和 Azure DevOps 都是受支持的。
运行具有特定修订版本的自定义构建
当运行自定义构建时，您现在可以指定一个可能不一定属于构建配置已知更改列表的确切修订版本。 这为您在重现历史构建、部署旧版本、调试新构建配置等方面提供了更多的灵活性。
安全性
Log4J 与 Log4Shell
尽管 TeamCity 并未受到 Log4Shell 漏洞（CVE-2021-44228）的影响，但一些安全扫描器错误地报告了它的漏洞。 为避免扫描器误报，我们已将 Log4J 升级到最新版本。
Spring 和 Spring4Shell
与 Log4Shell 类似，Spring4Shell 漏洞（CVE-2022-22965）不影响 TeamCity。 然而，为了避免安全扫描器的误报，我们已将在 TeamCity 中使用的 Spring Framework 升级到了最新版本。
在服务器上进行 VCS 相关操作的原生 Git
TeamCity 现在可以将原生 Git 作为服务器上 Git 操作的默认选项。 切换到原生 Git 可提高服务器上检查更改操作的性能，与之前使用的 JGit 实现相比。 它还解决了与大型 Git 仓库相关的一些问题。
在切换之前，请确保在您的服务器机器上安装了版本为 2.29 或更高的 原生 Git 客户端 ，并在 PATH 环境变量中指定了其可执行文件的路径。 或者，您可以通过 teamcity.server.git.executable.path 内部属性设置可执行文件的完整路径（无需重启服务器）。 在 Windows 上，记得在路径中使用双反斜杠。
要将您的 TeamCity 服务器切换到原生 Git，请转到 管理 | 诊断 并打开 Git 选项卡。 在此，您可以通过原生 Git 在服务器上的任何 VCS 根目录测试连接。 如果您选择测试所有的 VCS 根，TeamCity 将检查它们是否能通过 JGit 成功连接，然后通过原生 Git 测试它们的连接。 这项措施有助于确保在切换到本地 Git 后，您的所有管道都不会中断。 如果连接测试成功，您可以在您的服务器上启用本地 Git 支持。
我们内部的 TeamCity 服务器统计数据显示，使用原生 git 显著提高了服务器上与 VCS 相关操作的性能：与 JGit 相比，新更改和分支的出现速度快了数倍。
新的用户界面
编辑代理池
现在，您可以在新的 Sakura UI 中直接编辑 代理池s ，并快速将 agents 和项目分配给它们，无需切换到经典的 UI 模式。 要编辑代理池，请在其设置中点击 分配代理。 在此对话框中，您可以选择您想要指派到资源池的代理：
更改页面
新的 Changes 页面 添加了过滤器，提供了灵活的搜索选项，允许您按注释（提交信息）、修改文件的路径和修订版本号来排序更改。
将构建产生的 Docker 镜像存储在公共 ECR 注册表中
TeamCity 现在可以将构建产生的 Docker 镜像存储到私有和 —— 自此更新以来 —— 公共的 ECR 注册表中。
要使用此功能，您需要在 项目设置中添加一个 Amazon ECR 连接 ，并选择 ECR Public注册表类型：
请记住，也要在您的构建中启用 Docker 注册表连接。
自动从外部系统导入用户头像
当用户首次通过第三方帐户 如 GitHub 或 Bitbucket 登录 TeamCity 时，TeamCity 将自动从外部系统获取他们的头像，并将其附加到他们的 TeamCity 用户资料上。 请注意，TeamCity 只能访问使用过经过验证的电子邮件的用户的头像（如果您正在使用 GitLab，请检查您的帐户中是否设置了 公开电子邮件）。
在 TeamCity 用户个人资料设置中，您可以稍后上传不同的头像。
对多个构建应用操作
现在可以选择多个构建，并一次性对它们所有的进行操作：
固定/取消固定
标签
与另一个构建进行比较
添加评论
添加到收藏夹
删除
在 概述 选项卡的 构建配置主页 中，您可以通过悬停在构建上时出现的复选框选择所需的构建。 要对它们应用操作，使用弹出上下文菜单的相应命令。 如果您需要选择一系列构建，请按 Shift 并点击范围边缘的构建复选框以进行选择。
Perforce 集成：Helix Swarm 测试运行和构建状态同步的自动创建
Commit Status Publisher 具有一个新选项，可将构建状态报告发送到 Perforce Helix Swarm — 创建 Swarm 测试。 如果您启用它，TeamCity 将在 Helix Swarm 服务器上 创建一个测试运行 ，并根据 TeamCity 中的构建状态更新其状态。
在包名中不含版本的 Kotlin DSL API
之前版本的 TeamCity 生成的 Kotlin DSL 代码中的导入语句存在在包名中带有 v2019_2 的情况，例如：
自 TeamCity 2019.2 以来，由于 DSL API 没有重大的不兼容变更，因此没有新的 DSL API 包。 但多个版本的包的存在会在 IntelliJ IDEA 中导致代码补全的持续问题，因为它会从不同版本的包中建议几个相似的类。
为了解决代码补全的问题，TeamCity 2022.04 中引入了 DSL API Maven 工件的新版本。 这些 DSL API 工件在其包名中没有版本号。 新生成的 Kotlin DSL 代码已自动切换到这些 无版本 的工件。 现有的 Kotlin DSL 项目可以 手动切换。
通过用户界面获取项目的 SSH 密钥的公共部分
您现在可以从项目设置中复制上传的非加密 SSH 密钥的公共部分。 为此，请转到 项目设置 | SSH 密钥 并点击 复制公钥 下的密钥名称。
这样，项目管理员在需要公共 SSH 密钥时（例如，要将他们的 TeamCity 项目与 VCS 托管服务集成），就无需再向系统管理员请求 —— 他们可以直接通过 TeamCity UI 获取。
其他更新
排队构建优化改进 在 TeamCity 2022.04 之前，队列中的构建只能优化为已启动或已完成的构建。 例如，如果队列中有两个构建链：
A -> B和A -> C，则只有在有另一个正在运行或已完成的构建A具有相同的设置和修订版本时，才能由构建队列优化器替换两个构建链中排队的构建A。从 TeamCity 2022.04 开始，此算法得到改进，允许重用仍在队列中的构建。 所以对于上述示例，两个构建链将在它们仍在队列中时合并在一起，因此两个构建链将使用相同的排队构建
A。构建失败条件：为每个匹配的错误创建一个构建问题
在配置 根据构建日志中特定文本失败构建 失败条件时，您现在可以指定是仅为构建日志中找到的第一个文本出现创建构建问题（默认）还是为每个匹配指定模式的错误创建问题。Eclipse 插件 已从 TeamCity 中分离。 联系我们的支持如果您需要插件。
已解决的问题
升级说明
在升级之前，我们强烈建议您阅读有关 2022.04 版本相对于 2021.2.x 的重要变化的内容。
以前的版本
路线图
参阅 TeamCity 路线图 ，了解未来的更新。