TeamCity 一段时间以来一直受益于 HashiCorp Vault 插件集成。 去年，我们改进了这种集成的运作方式，使其更易配置。

在 2024.03 版本中，我们开始将插件与 TeamCity 捆绑，使其成为 TeamCity 安装的关键组件。

在我们的文档中详细了解 TeamCity 的 HashiCorp Vault 集成。

工件依赖项使您的构建配置能够获取其他配置或同一配置中的构建生成的文件。 要建立这些依赖项，应定义工件规则，指定要下载的文件及其存储位置。

此前，如果 TeamCity 无法根据这些规则找到文件，构建将会失败，并出现“Unable to resolve artifact dependency”错误。

从 2024.03 版本开始，我们引入了一种适应性更强的方式来定义工件依赖项。 现在，您可以配置依赖项，使其在以下情况被忽略：

• 源构建根本不存在（除非有其他非可选规则）。
• 源构建缺少所需文件。
• 工件规则基于归档，并且该归档不包含所需文件。

如果您想提供有关此功能的反馈，请随时使用此 YouTrack 工单。

有关新功能的完整列表，请访问文档中的“最新变化”页面。

拉取请求功能使您能够在将代码合并到主代码库之前进行审查。 用户可以选择运行来自任何贡献者的构建，或仅来自其组织内的贡献者的构建。 前一个选项存在安全风险，可能会将 TeamCity 服务器暴露给有害代码，而后一个选项则会限制与更广泛的贡献者的协作。

在 2024.03 版本中，我们引入了不可信构建组，让 TeamCity 可以区分可信用户编写的更改和来自外部源的更改。

不可信构建组当前支持 GitHub 和 GitLab。 在我们的文档中了解详情。

JetBrains dotCover 作为 TeamCity 中 .NET 相关项目的代码覆盖率工具受到支持已经有一段时间。 在 2024.03 版本中，我们向 .NET Support 插件添加了一个新的构建运行程序，将其与 dotCover 工具集成。

新的 dotCover 运行程序允许用户：

• 在 dotCover 分析下运行任意进程以生成覆盖率快照。
• 合并其他 .NET 或 dotCover 运行程序生成的构建步骤快照。
• 跨构建链为并行测试生成合并报告，并将其转换为 TeamCity 自定义报告。

在我们的文档中了解详情。

在 2024.03 版本中，我们向 .NET 构建运行程序添加了新功能。 新选项将允许用户为失败的测试设置构建级重试策略。

此功能将有助于解决测试不稳定问题并缓解集成测试的瞬态失败。

在我们的文档中了解详情。

Gradle 中的配置缓存选项通过缓存配置阶段的结果并在后续构建中重用来显著增强构建性能。 在 2024.03 版本之前，TeamCity 的 Gradle 构建运行程序缺乏对此功能的支持。

在这个版本中，我们将此功能引入 TeamCity，希望提高 Gradle 构建的效率和性能。 查看我们的文档了解如何在 TeamCity 设置中启用配置缓存选项。

借助 TeamCity 中的矩阵构建，您可以定义参数和相应值的组合来创建构建矩阵。 每个参数值组合都会生成一个独特构建。 然后，多个并行运行的构建组成矩阵构建。

在不同操作系统或浏览器版本等配置之间测试软件时，矩阵构建特别实用。

Read more about matrix builds in our documentation.

在 CI/CD 中，使用一次性构建代理是公认最好、最安全的做法。 但是，最佳做法也并非十全十美。

每次在一次性构建代理上运行构建时，都需要从互联网下载大量库才能执行构建。 这就导致构建速度缓慢和构建启动延迟。

现在不需要了！

构建缓存会下载项目依赖的文件并在项目中重用，帮助优化 CI/CD 构建时间。

Learn more about Build Caches in our documentation.

在 2023.11 版本中，我们彻底重做了设置云配置文件和镜像的方式。 新 UI 将引导您完成整个过程，并提供相关的设置选项建议。

现在，您可以使用 EC2 Mac 实例，运行具有 Spot 置放评分的 AWS EC2 Spot 实例构建代理，等等。

S3 插件还具有直观简洁的新 UI，设计时考虑了 Amazon S3 存储桶和 S3 兼容存储。

在我们的文档中了解详情。

TeamCity 可与许多 Git 托管平台无缝集成，包括 GitHub、GitLab、Bitbucket（Cloud 和 Data Center），以及 Azure DevOps。

在 2023.05 中，我们引入了一种新的 GitHub 连接类型。 您可以使用 GitHub Apps，而不是传统的基于 OAuth 的仓库访问方法。

从 2023.11 版本开始，您可以更高效地建立这些连接，无需在 GitHub 中手动配置和注册新应用。

在身份验证方面，您现在还可以在 提交Commit Status Publisher、Pull Requests（拉取请求）构建功能和 GitHub 问题跟踪器设置页面上为 GitHub App 连接发放非个人可刷新访问令牌。

从 2023.11 版本开始，您可以将 TeamCity 配置为忽略 GitLab 的 Pull Requests（拉取请求）构建功能中的草稿合并请求。

针对 GitLab 仓库的 Commit Status Publisher 和 Pull Requests（拉取请求）现在可以使用可刷新 OAuth 令牌来通过身份验证。

针对 GitLab 仓库的 Commit Status Publisher 和 Pull Requests（拉取请求）现在可以使用可刷新应用程序令牌来通过身份验证。

TeamCity 现在为 Azure DevOps 的 Commit Status Publisher 和 Pull Requests（拉取请求）构建功能支持可刷新 OAuth 令牌。

在我们的文档中了解详情。

在这个版本中，我们从多个方面增强了 Bitbucket 身份验证。

In addition to app passwords and VCS Root credential authentication types, TeamCity also supports refreshable and permanent access tokens as an authentication method for the Pull Request Build Feature for Bitbucket Cloud.

Pull Requests（拉取请求）功能现在可以使用可刷新 OAuth 令牌访问 Bitbucket Server/Data Center 上的仓库。

在我们的文档中了解详情。

We’ve also improved the existing Swarm and TeamCity integration. 集成允许您在 Swarm 中使用 TeamCity 构建状态，并从 TeamCity UI 导航到 Swarm 界面。

从 2023.11 版本开始，Commit Status Publisher 构建功能的 TeamCity Perforce Helix Swarm 发布器可与 Swarm 设置中已存在的自定义工作流集成。 此外，Commit Status Publisher 不再需要具有管理员访问权限的用户的凭据。

现在，无需在 TeamCity 中使用 Swarm 管理级凭据即可设置集成。 更新后的集成还允许将基于 TeamCity 检查的门纳入自定义工作流。

在我们的文档中了解详情。

您现在可以收藏代理池并从统一位置访问。 这有助于您访问负责的代理池。

Agent terminal is a unique TeamCity feature that provides a convenient and quick way to get direct access to an agent machine by opening a remote terminal directly from the TeamCity UI. Linux、Windows（使用 PowerShell）和 macOS 均已支持代理终端。

从 2023.11 版本开始，代理终端在 TeamCity UI 的同一页面上打开，无需切换标签页。

开发者应该能够舒适地使用日常工具。 因此，我们开发了 TeamCity 历史上最受欢迎的功能之一：深色主题。

深色主题有助于减轻眼疲劳和消除视觉干扰。 此外，有些用户也认为它更加美观。

TeamCity 的深色主题适用于 Classic 和 Sakura UI。 除了 Light（浅色）和 Dark（深色）选项外，您还可以选择 System theme（系统主题），它会自动匹配您的操作系统设置。

在 TeamCity 2023.05 中，您现在可以直接从 TeamCity UI 打开代理机器的远程终端，轻松查看代理日志，检查已安装的软件，以及调试特定的代理问题。

这个新功能在排查代理问题时特别有用，因为远程终端无需维护 SSH 密钥即可连接到代理。 它在 Mac、Linux 和 Windows（使用 PowerShell）均受支持。

在这个版本中，我们还实现了一个改进的请求分配逻辑，可以在主节点和辅助节点之间有效分配负载。

为了增强 TeamCity 的可扩缩性，节点现在可以完全互换。 TeamCity 网络中的所有节点都有助于平衡用户请求，使 Web UI 用户生成的工作负载能够在所有节点之间更均匀地分布。

在 2023.05 版本中，TeamCity 用户不再受限于单个节点执行 VCS 仓库轮询职责。 最新版本允许将此功能委托给多个节点，实现更均匀的工作负载分配以及更快的新提交识别和构建启动。

利用这一功能改进，用户可以简化其构建、测试和部署流程，提高整体效率、减少延迟并提高生产力。

对于 TeamCity，确保强大的安全性是我们的首要任务。 为了加强产品抵御数据泄露和潜在业务中断的能力，我们整合了以下功能。

TeamCity 现在与 Let's Encrypt 集成，Let's Encrypt 是一个证书颁发机构，提供免费和自动化数字证书以在网站上推广使用 HTTPS。 通过联系 Let's Encrypt，TeamCity 可以自动获取和安装有效证书，后续无需用户干预即可更新。

在以前的版本中，启用强制双重身份验证模式会影响整个服务器。 但是，在最新版本中，即使全局模式设置为 Optional（可选），现在也可以形成需要使用 2FA 的自定义用户群组。

TeamCity 用户已经可以为特定事件配置电子邮件和 Slack 通知。 2023.05 使此功能更加完善，允许您使用服务消息发送 Slack 消息和电子邮件通知。

有关新功能的完整列表，请访问文档中的最新变化页面。

与往常一样，我们期待您的反馈！ 欢迎通过支持表单提交请求，或者在这篇博文下留言。

Sakura /sa.ku.ʁa/（樱花）象征着万象更新和积极乐观，我们相信，这完美描述了我们在 TeamCity 2022.10 中将 Sakura UI 设为默认选项时的感受。

Sakura UI 现代、美观且迅速。 它采用了无障碍设计，在经典 UI 功能之外，还提供了大量独特的新功能。 我们已经在 Sakura UI 上工作了超过四年，确保将最小的细节做到完美。 我们有独一无二的机会对包括 IntelliJ IDEA 和 Kotlin 等巨头在内的数千个内部和外部项目进行测试。 我们相信您也会爱上它！

我们理解，部分用户可能不愿离开旧的用户界面。在一定时间内，我们将继续为这些用户提供服务。 但是，在未来的某个版本中，我们会弃用旧 UI 以支持 Sakura UI。如果您认为我们遗漏了某些内容，请在 YouTrack 中创建问题。

新实现的 AWS 凭据管理系统可以发布临时的短期 AWS 密钥，并以安全方式为您的构建公开。

如果您曾经需要调试云实例上执行的 CI/CD 管道中的问题，您一定知道这可能相当棘手。 您不仅需要花时间来找出和启动正确的构建代理，还需要确保它不会在进程中启动新构建。

这就是维护模式的用武之地。 在这种模式下，TeamCity 不会在构建完成后自动终止云代理，也不会分配它们来运行新的构建，从而让您可以进行故障排除。

从 TeamCity 2022.10 开始，TeamCity 的二级节点可以启动和停止云实例，从而在维护主服务器期间提供基于云的 CI 的不间断运行。

TeamCity 2022.10 带来了两项与 Perforce 工具集成相关的改进：

• Perforce Shelve Trigger 现在可以理解搁置的更改列表与非默认流相关，并允许构建在它上面运行。
• TeamCity 现在可以检测在 Perforce Helix Swarm 中有审查的更改列表，并分别在 Build Overview（构建概览）和 Changes（更改）页面中添加指向相应审查和更改页面的链接。

TeamCity 2022.10 在与 GitLab、Bitbucket Cloud 和 Azure DevOps 搭配时会使用短期 OAuth 令牌，允许您创建 VCS 根而无需为这些服务手动生成访问令牌。

为了支持更多工作流并让 TeamCity 的体验更加流畅，我们现在支持使用 Google 帐号进行身份验证。 使用 Google 帐号登录时，TeamCity 会立即将 Google 电子邮件与现有 TeamCity 用户匹配，并且无需密码即可登录。 这还可以在新成员加入团队时自动创建新的个人资料，前提是他们的电子邮件地址属于您指定的域名之一。

Free Disk Space（释放磁盘空间）构建功能现在会跟踪工件大小并自动计算解析工件依赖项所需的磁盘空间。 这使构建功能更加直观，您不再需要了解构建期间下载的工件的大小，只需要指定构建进程本身所需的磁盘空间量。

从 TeamCity 2022.10 开始，您可以提升个人构建。 提升后触发的构建也会成为个人构建。

TeamCity 始终与 Amazon EC2 和 Amazon S3 有着强大集成，让您可以自由扩缩构建基础架构，无论项目的规模和复杂程度如何。 版本 2022.04 不仅允许您在 Amazon S3 中存储新的构建工件，您还可以将现有工件从 TeamCity 的本地存储空间移动到 Amazon S3。 这特别适合刚开始从自托管设置迁移到云平台的团队。

将 CI/CD 配置与项目的代码库一起存储是确保其始终可被构建、测试和部署的最佳方式。 为了在云端构建软件时提供更多灵活性，TeamCity 2022.04 扩展了 Kotlin DSL，让每个项目都有机会拥有自己的云配置文件配置。

我们将继续改进与 JetBrains Space 的集成，增加对合并请求的支持。 构建合并请求时，TeamCity 现在会将状态发布到 Space 中的相应合并请求时间线。

我们通过添加 GitLab 丰富了支持的问题跟踪器列表。 工作原理：当提交消息提及问题 ID 时，TeamCity 会自动添加指向 GitLab 中相应问题的链接并显示相关信息。

此前，在 TeamCity 实际开始构建之前，Commit Status Publisher 构建功能不会将信息发送到版本控制系统，这倾向于在提交后很长时间后发生。 从新版本开始，在将相应构建添加到队列后，TeamCity 会立即更新提交状态，提供最新信息。 此功能适用于所有受支持的 VCS 服务，包括 GitHub、GitLab、Space、Bitbucket 和 Azure DevOps。

尽管 TeamCity 并未受到 Log4Shell 漏洞 (CVE-2021-44228) 的影响，但一些安全扫描程序会在未检查产品所用 Log4J 框架的确切版本号的情况下错误地将其报告为易受攻击。 为了避免误报扫描仪报告，我们已将 Log4J 升级到最新版本。

与 Log4Shell 类似，Spring4Shell 漏洞 (CVE-2022-22965) 不会影响 TeamCity。 但是，为了避免来自安全扫描程序的误报，我们已将 TeamCity 中使用的 Spring 框架升级到最新版本。

新的 Sakura UI 越来越接近经典 TeamCity UI 的功能。 在 2022.04 版本中，我们重新实现了 Agent Pools（代理池）和 Changes（更改）页面，大幅提高了新 UI 的整体性能。 现在，我们距离将其设为默认选项仅几步之遥，我们计划在 TeamCity 2022.10 中实现这一目标。 敬请关注！