TeamCity 路线图
该页面包含我们正在为 TeamCity 积极开发或设计的新功能列表。 这会让您对未来一年中可能看到的公告有所了解。
此页面上的信息会在每次发布后更新。 以下是路线图功能的当前状态：
云功能
我们希望 TeamCity 拥有您所需的一切，让您的 CI/CD 管道变得快捷、经济高效。 因此，我们正在开发一系列功能，让您可以更轻松地在云端设置和运行构建。
构建运行程序和集成
全世界的开发者都喜欢 TeamCity 与构建工具和外部服务的紧密集成，我们会竭尽全力提供最好的支持。 在本部分中，您可以了解我们计划添加的新集成。
多节点设置
运行多个 TeamCity 服务器并让它们协同工作可以将 CI/CD 的性能和可靠性提升到新水平。 通过扩展辅助服务器的能力，我们正在改进 TeamCity 在集群环境中的性能。
安全
持续集成是开发流程的核心，工作流必须保证能够将数据暴露给第三方或成为网络攻击受害者的风险降至最低。 我们正在开发多项新功能来提高 CI/CD 管道的安全性。
配置即代码
我们很高兴越来越多的用户开始以代码的形式存储 CI/CD 配置。 在不久的将来，我们会提升 Kotlin DSL 的表现力，并增加更多入门方式。
核心 CI 改进
为了让您更好地控制 CI，我们正在开发各种新功能，让您更轻松地自动执行 DevOps 管道并帮助您以更有效的方式组织开发流程。
用户界面
我们将继续寻求创建一个快捷、易于使用的用户界面，为所有类型的工作流和开发做法提供最大的灵活性。
TeamCity Cloud
TeamCity Cloud 是由 JetBrains 完全托管和管理的托管版 TeamCity。 它自己的路线图拥有许多附加功能。
TeamCity Pipelines
TeamCity Pipelines 是我们一直在开发的一款新产品的代号。 它将为构建 CI/CD 管道提供简单直观的体验，由 JetBrains 的标志性智能提供支持。
云功能
我们希望 TeamCity 拥有您所需的一切，让您的 CI/CD 管道变得快捷、经济高效。 因此，我们正在开发一系列功能，让您可以更轻松地在云端设置和运行构建。
云代理的持久缓存
在云端使用 TeamCity 的团队应该可以像使用本地安装一样快速完成构建。 持久云缓存将允许云构建代理相互传输构建依赖项（例如 Maven 工件和 NPM 软件包），从而节省时间和网络成本。
另外，更少的下载对地球有利。 它可以节省电力并减少碳足迹。 因此，这一功能将帮助您和您的构建都更加绿色环保。
重新组织 AWS 凭据管理
我们最近发布了新的凭据管理系统 – AWS Connection – 它通过仅具有执行特定作业所需权限的临时 AWS 安全凭据提供 TeamCity 的构建功能和云集成。 我们的下一步是在 TeamCity 中可用的所有插件中实现对 AWS Connection 的支持。 这将减轻团队手动配置 EC2、ECR、S3 等资源访问权限的负担。
开箱即用的 Microsoft Azure 支持
我们有越来越多的客户愿意在云端运行构建代理，因为这可以在需要时快速增加交付管道的容量。 为了支持用户迁移到 Microsoft Azure，我们计划改进并捆绑 TeamCity Azure 插件。
构建代理映像生成器
使用 TeamCity 的映像生成器，您将能够为各种环境构建 TeamCity 构建代理的自定义 VM 映像。 这将使用预烘焙的 VCS 仓库、构建依赖项、Docker 镜像等加快构建速度。
执行器模式
我们希望支持 Kubernetes、HashiCorp Nomad、AWS ECS 或类似的通用计划程序，以便运行简单的构建任务而无需指定和维护构建代理。
这将使您无需考虑将有哪些工作线程会运行您的构建，即可开始设置项目构建配置。
这种方式对于不需要 VCS 根、依赖项等本地缓存的小型简单任务而言十分方便。 它还将使用计划程序提高资源利用率。 计划程序可以直接在同一集群节点上并行运行多个任务。
JetBrains 托管代理
我们正在考虑为 TeamCity Cloud 的 JetBrains 托管代理添加更多选项。 这将包括重新创建按分钟计算的 macOS 代理，以及提供基于 ARM 的 Linux 代理。
多租户 TeamCity
目前，TeamCity Cloud 为每位客户提供单独的服务器。 我们正在考虑在同一服务器上托管多个项目的可能性。 这将帮助我们降低成本，甚至让我们有机会提供免费版本的 TeamCity Cloud。
构建运行程序和集成
全世界的开发者都喜欢 TeamCity 与构建工具和外部服务的紧密集成，我们会竭尽全力提供最好的支持。 以下是我们计划添加的新集成功能列表。
控制触发的拉取请求构建功能
目前，拉取请求构建功能扩展了 VCS 根的分支规范，包含与特定筛选条件匹配的未解决拉取请求的分支。
我们希望扩展这一功能，让您可以自动触发一部分拉取请求的构建，同时也能够手动触发其他分支的构建。
集成相关项目和构建功能的整合
这一功能将允许您在项目级别配置连接（例如，到 GitHub）。 您将能够直接在连接设置中指示是否需要 TeamCity 收集拉取请求和问题跟踪器信息，并指示哪些构建配置必须发布状态。
这一功能将为您节省大量时间，因为您将能够一劳永逸地在项目级别配置设置。
令牌管理 UI
通过 Connections（连接）颁发的 OAuth 令牌存储在内部 TeamCity 令牌存储空间中。 目前，通过管理 UI 配置某些设置（例如，VCS 根或构建功能）时，它们会从存储空间中提取。
我们想引入一个用于令牌管理的 UI。 这允许您检查令牌使用和范围，以及：
- 查看令牌 ID 和连接、用于分发令牌的帐户等。
- 发行新的令牌，使其可以通过 ID 引用（例如，从 DSL 代码）。
- 从存储空间中删除令牌。
- 查看和编辑令牌的项目范围。
- 从各种设置中查看令牌的实际使用情况。
从 VCS 自动设置新项目
大型公司喜欢 TeamCity，因为它能够扩展到数千个构建代理和数万个项目。 但有些时候，添加新项目不再有趣，它会成为您在每项新工作中都必须重复完成的必要负担。
通过此功能，我们正在考虑实现在新建 .teamcity 仓库时自动在 TeamCity 中创建项目的功能。
UI 中的拉取请求支持
TeamCity 对 GitHub 拉取请求提供了专门支持。 从 TeamCity 的角度而言，拉取请求是一个特殊分支。 我们将在 UI 中标记这些分支，使其便于识别。
实现 GitHub Checks 支持
借助 GitHub Checks 支持，我们将根据源自 GitHub 的数据，为用户提供有关构建过程中发生的情况的更详尽报告。
此功能的主要好处包括：
- 扩展的超文本报告而非普通状态。
- 支持注释源代码中的特定位置（例如用于检查）。
游戏开发
TeamCity 结合了其他 CI 工具所没有的功能和通用性。 无疑是游戏开发中使用的最受欢迎的 CI 解决方案之一。 我们已开始探索它可以在三个主要领域为行业做出的贡献：
- Unity 支持。
- Unreal Engine 支持。
- 游戏开发中的常规 CI/CD 工作流。
有兴趣使用 TeamCity 构建您的游戏？ 我们欢迎您在此处注册参与我们的研究。
Perforce 集成改进
TeamCity 提供与 Perforce Helix Core 的原生集成，这是游戏开发中最常用的版本控制系统之一。 以下是我们对 Perforce 支持的计划。
自动删除由 TeamCity 创建的 Perforce 工作区
使用 Perforce 代理端签出创建 Perforce 工作区。 当 TeamCity 代理不再使用时，工作区将保留在 Perforce 服务器上。
为了避免耗尽服务器资源，我们将为不再活动的 TeamCity 代理引入自动删除 TeamCity 创建的 Perforce 工作区的功能。
对 Commit Status Publisher 的 Helix Swarm 审查评论的更多控制
目前，Commit Status Publisher 提供有关构建每个阶段的信息（已加入队列、已开始、成功/失败等），这些信息可能会让人不知所措。
我们将让您更好地控制发送哪些评论以及哪些状态会触发它们。
代理端签出的自定义 Perforce 工作区名称
目前，TeamCity 在代理端签出期间会自动生成 Perforce 工作区名称。 我们计划添加为工作区名称指定自定义模式的选项。 此模式将允许使用：
- 项目 ID 和配置 ID。
- VCS 根外部 ID。
- 签出目录的名称。
Unreal Engine 支持
Unreal Engine 是游戏开发领域最受欢迎的游戏引擎之一。 我们正在开发一款新的 Unreal Engine 插件，它将为 TeamCity 用户提供以下功能：
- 构建代理端 Unreal Engine 安装检测。
- 专用 Unreal Engine 运行程序。
- 自动发现 Unreal Engine 构建步骤。
- 高亮显示问题的结构化构建日志。
- 测试报告。
多节点设置
运行多个 TeamCity 节点并让它们协同工作可以将 CI/CD 的性能和可靠性提升到新水平。 我们正在通过为多节点设置实现新功能来改进 TeamCity 在集群环境中的性能。
提高可用性
服务器维护不应成为开发者运行他们的构建时的障碍。 我们计划在提高 TeamCity 可用性的功能上进行更多投资，包括从辅助节点到主节点的自动转换，我们还将继续移除对多节点设置中共享数据目录的依赖。
改进配置文件中更改的传播
我们计划开始将所有配置文件存储在本地 Git 仓库中。 这个仓库可用于在多节点设置的 TeamCity 节点之间共享配置文件。
这将允许我们设置这些文件中更改的事务通知，确保这些修改的原子性以及相关辅助节点通知的原子性。
独立构建日志服务
在多节点设置中，所有节点在运行时都会使用存储在共享数据目录中的构建日志文件。 多数情况下，一个节点“拥有”对应于某个构建的日志文件。 此节点会写入文件，而其他节点只能读取该文件。
如果 TeamCity 节点确定“拥有”日志文件的节点发生崩溃（尽管实际上它运行正常），另一个节点可能会开始写入同一日志文件并使其受损。
我们希望实现一种可通过 HTTPS 从每个节点访问的独立构建日志服务。 新方式将帮助我们消除因两个节点写入同一文件而导致日志文件损坏的可能性。
提交 Git 仓库中的所有配置更改
此功能背后的想法是将每项更改（项目相关和全局）提交并推送到指定的 Git 仓库。 此仓库随后可用于在多节点设置的 TeamCity 节点之间共享配置文件。
此仓库还可用于审核 TeamCity 设置中的所有更改（通过 UI、Rest API 或版本化设置所做的更改）。
安全
持续集成是开发过程的核心，工作流必须保证能够将数据暴露给第三方或成为网络攻击受害者的风险降至最低。 除了产品安全方面的持续改进之外，我们还将引入以下功能：
与远程密钥存储空间集成
这一功能允许 TeamCity 在运行构建之前获取位于外部参数存储空间中的参数值。 您可以转到 TeamCity 的参数 UI 并添加引用外部参数的参数。 对于将参数存储在 AWS Parameter Store、HashiCorp Vault、Azure App Configuration、Azure Key Vault 等外部存储空间中的团队来说，这个功能相当实用。
此仓库还可用于审核 TeamCity 设置中的所有更改（通过 UI、Rest API 或版本化设置所做的更改）。
处理不安全的构建
我们正在开发一项功能，将检测所有受支持的 VCS 托管的复刻中的拉取与合并请求。 为了提高安全性，我们还将对以这种方式触发的构建实现强制手动审批。
配置即代码
得益于 Kotlin DSL 的表现力，我们的用户真正开始以代码的形式存储 CI/CD 配置。 我们想改进此功能，以下是我们计划在不久的将来进行的主要更改。
简化用户体验
使用 Kotlin DSL 可以让更有经验的 TeamCity 用户更自然地重用构建配置设置，节省团队的时间和精力。 由于 Kotlin DSL 是静态类型，在 IDE 中使用它还可以更简单地发现可用 API。
同时，我们明白 Kotlin 知识或使用特定 IDE 的需求不应成为在 TeamCity 中配置管道的障碍。 因此，我们正在研究简化用户体验并使 TeamCity 更易使用的方法。
在 IDE 中免于导入
为了简化非 IDE 代码编辑器中的 Kotlin 文件编辑，我们将移除在 .kt 文件中显式指定 DSL 相关软件包导入的必要性。 导入将在 TeamCity 服务器端自动处理。
这将允许您在任何代码编辑器中编译代码。 TeamCity 将确保它确实有效。
为小型项目简化基本 DSL
虽然 Kotlin DSL 提供了按照您需要的方式准确配置管道的功能，但较小的项目可能不需要 Kotlin DSL 的复杂性。 因此，我们将为较小的项目简化基本 DSL，让您可以从文档轻松复制粘贴 DSL 代码示例。 这将显著加快配置过程。
试验 YAML
虽然 Kotlin DSL 为您提供了配置 CI/CD 项目的强大途径，但有些人可能更习惯使用 YAML 进行管道配置。
我们正在寻找机会，添加 YAML 作为以代码形式配置项目的选项。
允许在外部系统（GitHub、Space）中打开版本化设置仓库
如果您使用 Kotlin DSL 配置版本设置并需要进行一些更改，TeamCity 能够将您转至外部系统（GitHub、JetBrains Space 等）的仓库中存储相关代码的相应文件。 这意味着不再需要在仓库中四处浏览以寻找该文件！
核心 CI 改进
JBA 登录和新的许可证格式
我们希望您能够通过 JetBrains Account 透明灵活地管理服务器和代理许可证。 我们还希望 TeamCity 能够实时获取这些许可证，无需生成和下载离线许可证密钥。
我们计划：
- 简化 TeamCity On-Premises 客户的许可证管理，允许通过 JetBrains Account 管理服务器和构建代理许可证，无需处理大量离线许可证密钥。
- 为 TeamCity 安装（包括 TeamCity Professional）引入 JetBrains Account 登录。
矩阵构建
我们计划添加一项新功能，允许 TeamCity 获取一组参数并为每个组合运行构建 – 矩阵构建。 当您需要在不同的环境（例如，不同的操作系统、Java/.NET 版本、不同的浏览器等）中运行相同的构建或测试时，这一功能尤其有用。
矩阵构建将显著减少时间和精力，允许您一次建立一组指定参数（例如，操作系统和环境），然后在其他构建配置上并行运行同一组。
部署仪表板
我们将使您可以保存已部署构建的历史。
借助这项新功能，您将能够检查所有部署的当前状态，例如哪个版本部署在生产环境中，哪个版本部署在暂存环境中。
您还可以访问所有实例的部署历史报告。 在部署仪表板上，您会找到一个实例列表、它们的当前状态（进行中、成功、失败）和相关的构建详细信息（时间、代理、构建触发者等）
安排构建在指定时间运行
您是否曾经希望能够安排构建，使其在指定时间运行而非立即运行？
我们正在开发一项功能，使您能够安排构建在指定时间（包括时区）运行，或者以倒计时方式（例如，从现在开始倒计时两小时）运行。
构建将立即添加到队列中，并等待至指定的计划时间。
在复合构建中使用共享资源
我们正在研究将复合构建中锁定的值传递到其依赖项构建的可能性。 将来，我们还希望为 TeamCity 用户提供一项功能，使其能够为与快照依赖项链接的一组构建锁定资源。
TeamCity UI
因为开发者每天都会使用 CI/CD 解决方案，我们希望 TeamCity 提供熟悉的感觉。
Sakura UI 标签页迁移
从 2022.10 版本开始，Sakura UI 在 TeamCity 中默认启用。 我们正在使经典 UI 与 Sakura UI 之间实现完全功能对等。 为此，我们将重新实现经典 UI 中的页面并打磨插件子系统，将插件标签页集成到 Sakura UI 中。
TeamCity 入门改进
TeamCity 是一个功能强大的 CI/CD 系统，具有大量高级功能。 为了帮助用户熟悉 TeamCity 并按照他们希望的方式准确配置软件，我们将在解决方案中提供入门指南。 交互式指南和提示将指导新手如何有效使用 TeamCity，并帮助现有客户从经典 UI 迁移到 Sakura UI。
交互式指南和模板项目
为了改善用户入门，我们将在 TeamCity 中引入模板演示项目。 借助这些模板项目，您无需将自己的代码库连接到 CI/CD 工具即可尝试 TeamCity，并更快地获得首个绿色构建。
借助交互式指南，您在 UI 内即可概括了解 TeamCity 的核心功能。 这些指南将介绍不同的场景和用例，让您更快地熟悉 TeamCity。
Sakura UI 性能
我们正在为更大的 TeamCity 安装提高性能。 我们的主要关注点是代理和项目页面。 我们的目标是缩短第一字节时间、减小累积布局偏移，以及优化可交互时间指标和其他网页指标。 TeamCity 用户可以在所有浏览器中更快渲染和加载应用程序页面。
Sakura UI：Problems（问题）标签页
TeamCity 提供了项目和构建级别的当前问题和调查的概览。 用户可以检查构建配置错误、失败的测试、正在调查的问题，以及检查其被指派者和状态。
我们正在重新设计 UI，以便让用户更好地概括了解所选项目中的所有问题及其状态。 现在可以在 Problems（问题）通用标签页下找到这些信息。
在这里，用户将能够按类型（失败的测试、构建问题和构建配置问题）、状态（忽略/取消忽略）和调查者（被指派者）筛选问题。
通过此更新，我们致力于为用户提供一种更加方便简洁的方式来检查现有构建问题及其状态。
TeamCity Pipelines
TeamCity Pipelines 将为构建 CI/CD 管道提供简单直观的体验，由 JetBrains 产品的标志性智能提供支持。
借助 TeamCity Pipelines，我们的计划是将重点从自动执行构建和测试的各个步骤转移到设置交付管道的整体体验。 TeamCity Pipelines 将为构建 CI/CD 管道提供简单直观的体验，由 JetBrains 产品的标志性智能提供支持。
TeamCity Pipelines 中全新的可视化管道编辑器能够简化任何复杂程度 CI/CD 管道的使用，它由 TeamCity 的 CI/CD 引擎提供支持，可以处理企业级工作负载。 TeamCity Pipelines 的内置智能配置辅助将指导您完成管道配置的所有步骤，并在过程中自动提出优化建议。
以下是我们正在为 TeamCity Pipelines 开发的一些新功能：
配置即代码的 YAML
Kotlin DSL 是以代码形式配置管道的强大方法。 不过，一些用户可能会发现使用 YAML（CI/CD 行业广泛使用的语言）来着手配置 CI/CD 项目更加方便。
TeamCity Pipelines 将使用户可以使用 YAML 存储构建设置并定义作业及其依赖项。
测试并行化
TeamCity 可以使用智能算法自动并行化测试套件，用户无需进行任何额外输入。 用户只需选择他们的测试应并行运行多少个构建代理。 这将有助于显著缩短下次运行的构建时间。
代理演练场
有时，用户可能很难了解 TeamCity 构建代理上安装了哪些软件、代理具体使用哪种操作系统，以及用户如何修改 JetBrains 托管的构建代理。
我们希望开发一个代理演练场，让人们能够在代理上运行脚本而无需运行管道。 这样，用户将能够在构建完成后连接到演练场代理进行调查和调试。
我们还将为用户提供直接从 TeamCity Pipelines UI 打开代理终端的功能，以便快速检查代理环境并调试特定代理的问题。
增强的 Docker 集成
如果代理上没有管道配置所需的软件，您可以选择在 Docker 容器中运行构建。
The enhanced Docker integration in TeamCity Pipelines will allow you to use the autocomplete feature to find the correct Docker image from https://hub.docker.com/. 它还将显示以前使用过的 Docker 镜像的列表，并为每个 Docker 镜像查找结果提供一个链接。 这将使您更加方便快捷地查找必要的 Docker 镜像。
我们正在研究当 Docker Hub 中不存在特定镜像时提供人性化解决方案的可能性。 用户也许能够引用来自当前 VCS 仓库的 Docker 文件。
显示已应用的优化和建议的优化
得益于智能测试并行化、构建重用、缓存和其他功能，TeamCity 可以帮助组织显著缩短构建时间。 目前，TeamCity 会显示每次构建运行的总优化（节省）时间。
为扩展此功能，我们将提供更全面的视图，以展示构建运行应用了哪些优化。 我们还将努力提供包含可用于进一步缩短构建时间的潜在优化的列表。
您可以在此处注册以抢先体验 TeamCity Pipelines。
TeamCity Cloud
我们希望我们的用户能够在无需安装和维护构建基础架构的情况下进行开发。 为此，我们提供了 TeamCity Cloud，这是一种由 JetBrains 完全托管和管理的全托管式 CI/CD 解决方案。 除了云安装中不需要的几项管理功能以外，其功能与本地部署版本相同。
虽然产品的本地部署和云版本中均已包含我们开发的所有功能，但 TeamCity Cloud 自己的路线图中具有多项附加功能：
- 适用于 Apple 芯片（M1 芯片）的 macOS 代理 正在开发
- 与其他 JetBrains 产品集成 正在设计
- 开源友好许可 正在设计
- 新的定价层级。 正在开发