如何...

选择TeamCity Server的操作系统/平台

服务器/操作系统满足要求后 ，TeamCity即可在任何系统上运行。还请查看计划使用的集成的要求 ，例如，在Windows下安装TeamCity服务器时，以下功能需要或更好地起作用：

• VCS与TFS集成

• VCS与VSS集成

• Windows域登录（在Linux下也可以使用，但可能不稳定），尤其是NTLM HTTP身份验证

• 服务器上的NuGet提要（也可以在Linux下工作，但可能不太稳定）

• 代理推送到Windows计算机

如果没有优先选择，由于文件系统操作更有效以及所需的常规OS维护级别，Linux平台可能更可取。

最终操作系统的选择可能应更多地取决于组织中的可用资源和已建立的实践。

如果选择安装64位操作系统，TeamCity可以在64位JDK（服务器和代理）下运行。但是，除非需要为TeamCity提供超过1Gb的内存，否则建议的方法是即使在64位OS下也要使用32位JVM。我们的经验表明，使用64位JVM不会显着提高性能。同时，它确实将内存需求增加到几乎2的大小。请参阅有关内存配置的注释 。

估算TeamCity的硬件要求

服务器和代理的硬件要求不同。

代理程序硬件要求基本上由运行的版本确定。运行TeamCity代理软件会要求增加CPU时间（但与构建过程的CPU要求相比通常可以忽略）和额外的内存：大约500Mb。所需的磁盘空间对应于在代理程序上运行的构建所使用的磁盘使用情况（源签出，下载的工件，在构建期间消耗的磁盘空间；所有这些都结合了定期进行的构建）。尽管您可以在与TeamCity服务器相同的计算机上运行构建代理，但是建议的方法是为每个构建代理使用单独的计算机（可能是虚拟的）。如果选择在同一台计算机上安装多个代理，请考虑可能发生的CPU，磁盘，内存或网络瓶颈。性能监视器构建功能可以帮助您分析实时数据。

服务器硬件要求取决于服务器负载，而服务器负载又取决于构建类型和服务器使用情况。请考虑以下一般准则。

数据库说明：
广泛使用服务器时，数据库性能开始发挥更大的作用。
出于可靠性和性能的原因，您应该使用外部数据库。
查看笔记上选择外部数据库。
数据库大小要求自然会根据存储的数据量（构建数，测试数等）而变化。可以估计每年活动服务器数据库的使用量为几GB数据。

TeamCity硬件资源使用概述：

• CPU：TeamCity利用CPU的多个核心，因此增加核心数量是有意义的。对于平凡的TeamCity使用率，建议至少使用4个CPU内核。

• 内存：由TeamCity服务器主进程和子进程使用（用于Maven集成，版本控制集成，Kotlin DSL执行）。请参阅有关主进程内存使用情况的注释 。通常，如果您不打算运行超过100个并发构建（代理），不支持200个以上的在线用户或使用大型存储库，则可能不需要为TeamCity服务器分配4G以上的内存。

• HDD /磁盘使用情况：这主要来自临时目录的使用情况（ < TeamCity Home >/temp和操作系统默认的临时目录）和< TeamCity Data Directory >/system用法。TeamCity服务器的性能在很大程度上取决于磁盘系统的性能。由于TeamCity在以下位置存储大量数据< TeamCity Data Directory >/system （最值得注意的是，VCS缓存和构建结果）重要的是，对磁盘的访问要快速（特别是在多个线程中读写文件，列出具有属性的文件）。如果计划将数据目录存储在网络驱动器上，则确保磁盘具有良好的性能尤为重要。建议将本地存储用于TeamCity Data Directory/system/caches目录。另请参见TeamCity数据目录 。

• 网络：这主要是从VCS服务器到客户端（Web浏览器，IDE等）和构建代理（发送源，接收构建结果，日志和工件）之间的流量的总和。

服务器上的负载取决于：

• 构建配置数量；

• 历史上的建筑数量；

• 每天运行的内部版本数；

• 构建消耗和生成的数据量（使用的源和工件的大小，构建日志的大小，单元测试的数量和输出大小，检查和重复命中的次数，生成的工件的大小和数量，等等） ;

• 配置的清理规则

• 代理商数量及其利用率

• 打开TeamCity网页的用户数量；

• 从IDE插件登录的用户数；

• VCS根的数量和类型，以及为VCS根配置的更改间隔检查。VCS检出模式也很重要：服务器检出模式会产生更大的服务器负载。特定类型的VCS也会影响服务器负载，但是可以根据本机VCS客户端性能粗略估算它们。

• TeamCity每天在所有VCS根目录中检测到的更改数量；

• TeamCity与之合作的存储库的大小；

• TeamCity每天检出的资源的总大小。

能够处理多达100个并发运行的构建并且仅运行TeamCity服务器的硬件配置的一般示例可以是：
适用于服务器的现代多核CPU，8Gb内存，快速的网络连接，快速可靠的HDD，快速的外部数据库访问。

根据我们的经验，适度的硬件（例如Intel 3.2 GHz双核CPU，Windows下的3.2Gb内存，1Gb网络适配器，单个HDD）可以为以下设置提供可接受的性能：

• 60个项目和300个构建配置（其中一个处于活动状态并定期运行）；

• 每天有300多个建筑物；

• 每个版本大约2Mb日志；

• 50名建筑代理商；

• 50个Web用户和30个IDE用户；

• 100个VCS根目录（主要是使用服务器检出的Perforce和Subversion），平均检查更改间隔为120秒；

• 每天超过150次更改；

• 未使用Kotlin DSL；

• 数据库（MySQL）在同一台计算机上运行；

• TeamCity服务器进程具有-Xmx1100m JVM设置。

以下配置可以为负载更重的TeamCity服务器提供可接受的性能：
Intel Xeon E5520 2.2 GHz CPU（4个核心，8个线程），Windows Server 2008 R2 x64下的12Gb内存，1Gb网络适配器，3个HDD RAID1磁盘（通用，一个用于工件，日志和缓存存储，一个用于数据库存储）

服务器负载特征：

• 150个项目和1500个构建配置（其中三分之一处于活动状态并定期运行）；

• 每天建造1500多个；

• 每个版本约4Mb日志；

• 100名建筑代理商；

• 150个Web用户和40个IDE用户；

• 250个VCS根目录（主要是使用代理端检出的Git，Hg，Perforce和Subversion），平均检查更改间隔为180秒；

• 每天超过1000次更改；

• 数据库（MySQL）在同一台计算机上运行；

• TeamCity服务器进程具有-Xmx3700m x64 JVM设置。

但是，为了确保可以很好地处理峰值负载，建议使用功能更强大的硬件。

HDD的可用空间需求主要由存储在服务器上的构建数量以及每个构建中的构件大小/构建日志大小确定。服务器磁盘存储还用于存储与VCS相关的缓存，您可以估算出该值是服务器上配置的所有VCS根的签出大小的两倍。

如果构建生成大量数据（工件/构建日志/测试数据），请使用快速硬盘进行存储.BuildServer/system建议使用目录和代理与服务器之间的快速网络。

部署大规模TeamCity安装的一般建议是从考虑硬件升级的合理硬件开始。然后逐渐增加服务器上的负载（例如添加更多项目），监视性能特征并确定必要的硬件或软件改进。还有一个基准插件 ，可用于估计当前服务器安装可以处理的同时构建数量。无论如何，建议最佳管理实践，例如保持足够的磁盘碎片整理级别，等等。

从适当加载的系统开始，如果随后将并发运行的内部版本（代理）的数量增加某个倍数，则准备将CPU，数据库和HDD的访问速度，内存量增加相同的倍数，以实现相同的性能。
如果增加每天的内部版本数，请准备增加磁盘大小。

如果您考虑为TeamCity代理部署云（例如，在Amazon EC2上），还请查看为Amazon EC2设置TeamCity

关于JetBrains内部TeamCity安装中的代理设置的说明：
我们既使用分别运行一个代理的单独计算机，又使用运行多个虚拟机的专用“服务器”，每个虚拟机都安装了一个代理。当每台core7i物理机运行3个虚拟代理（每个代理使用单独的硬盘）时，我们在配置硬件和软件时进行了试验。这是因为我们的（主要是Java）构建首先取决于HDD性能。但是YMMV。

众所周知，TeamCity可与500多个构建代理（500个同时运行的构建主动记录构建运行时数据）配合使用。在综合测试中，该服务器可以运行多达1000个并发构建（包括8个核，在Linux下运行的总内存为32Gb的服务器以及在单独的可比较机器上运行的MySQL服务器）的运行正常。每个构建所产生的服务器负载取决于构建所产生的数据量（构建日志，测试编号和故障详细信息，检查/重复问题编号等）。保持合理的数据量限制（将较大的输出作为构建工件发布，而不是将其打印到标准输出中；调整检查配置文件以报告有限的最重要的检查命中集等）将有助于扩展服务器以处理更多的并发构建。
如果您需要更多的代理/并行构建，建议使用几个节点设置 。如果需要大量代理，建议考虑使用几个单独的TeamCity实例并在它们之间分配项目。我们一直致力于TeamCity的性能改进，并愿意与运行大型TeamCity安装的组织紧密合作，以研究任何性能问题并改进TeamCity以处理更大的负载。另请参阅有关TeamCity可以处理的最大座席数的相关文章

另请参阅相关文章： 大量TeamCity设置的描述 。

配置TeamCity Server以获得性能

以下是一些调整TeamCity服务器设置以提高性能的建议。生产服务器使用列表是先决条件：

• 定期查看报告的服务器运行状况报告（包括隐藏的报告）

• 使用单独的反向代理服务器（例如NGINX）来处理HTTPS

• 对外部数据库使用单独的服务器并监视数据库性能

• 监视服务器的CPU和IO性能，必要时增加硬件资源（另请参阅硬件说明 ）

• 确保使用适当的保留策略为所有项目配置了清理，并确保清理完全定期完成（请查看“管理/清理”页面）

• 考虑确保以下各项的良好IO性能： < TeamCity Data Directory >/system/caches目录，例如通过将其移动到单独的本地驱动器（或存储在本地驱动器上，您选择将TeamCity数据目录存储在网络存储上）

• 定期存档过时的项目

• 定期检查已安装但未捆绑的插件，并删除那些对于服务器正常运行不重要的插件

• 考虑尽可能使用代理方结帐

• 确保构建日志不大（最多数十兆，最好小于10 Mb）

• 如果在服务器上配置了很多VCS根目录，请考虑配置存储库提交挂钩，而不是使用轮询进行更改，或者至少将VCS轮询间隔增加到300秒或更多

• 如果服务器经常被大量用户使用（例如，超过1000个），请考虑通过增加UI刷新间隔来减少后台UI请求的频率

• 当定期超过500个同时运行的内部版本记录大量数据时，请考虑使用“ 多个节点设置”

检索管理员密码

在首次使用空数据库开始时，TeamCity将显示“管理员设置”页面，该页面允许创建具有完全管理权限的用户（分配系统管理员角色）。

如果要重新获得对系统的访问权限，并且不能以具有系统管理员角色的用户身份登录，则可以以超级用户身份登录并更改现有的管理员帐户密码，或者以系统管理员角色创建新帐户。

也可以使用REST API将系统管理员角色添加到任何现有用户。

如果您使用内置身份验证并指定了正确的电子邮件，则可以从登录页面重置密码 。

估计外部数据库容量

设置或迁移到外部数据库时，很难提供准确的数字，因为所需的容量会因TeamCity的使用方式而异。

数据库大小和数据库性能是要考虑的关键方面。

数据库大小

数据库的大小取决于：

• 每天开始多少次构建

• 生成报告了多少测试

• 清理规则（保留政策）

• 清理时间表

我们建议数据空间的初始大小为4 GB。从内部数据库迁移时，建议至少将当前内部数据库的大小增加一倍。例如，JetBrains中内部TeamCity服务器的外部数据库（不包括重做日志文件）的大小约为50 GB。将数据库设置为自动增长有助于在必要时将文件大小增加到预定限制，从而最大程度地减少了监视磁盘空间的工作。

在大多数情况下，为重做日志（请参阅下表）和撤消文件分配1 GB就足够了。

数据库性能

要考虑以下因素：

• 数据库类型（RDBMS）

• 代理数量（实际上意味着并行运行的构建数量）

• 所有用户打开的网页数

• 清理规则（保留政策）

建议放置TeamCity Data Directory和物理上不同的硬盘上的数据库数据文件（即使TeamCity服务器和RDBMS共享同一主机）。

还建议将重做日志放在单独的物理磁盘上，特别是在代理数量过多（50个及更多）的情况下。

特定于数据库的注意事项

为不同的RDBMS命名的重做日志（或类似实体）：

PostgreSQL：我们建议使用9.2+版本，该版本具有很多查询优化功能。另请参阅PostgreSQL文档中有关预写日志（WAL）的信息。

Oracle：建议保留统计信息：应启用所有自动收集的统计信息（从Oracle 10.0开始，这是默认设置）。另请参阅Oracle文档中有关重做日志文件的信息。

MS SQL Server：不建议使用jTDS驱动程序：不适用于nchar/nvarchar ，并且要保留unicode流，这可能会导致查询花费很长时间并消耗大量IO。另请参阅Microsoft知识库中有关重做日志的信息。如果您使用jTDS，请迁移 。

MySQL：查询优化器可能效率低下：某些查询可能执行错误的计划，导致它们花费很长时间并消耗大量IO。

估计所需的构建代理数量

没有精确的数据，所需的构建代理程序的数量在很大程度上取决于服务器使用模式，构建类型，团队规模，团队对CI流程的承诺等。
最好的方法是从默认的3个代理开始，并查看它们如何与已配置的项目一起使用，然后基于此进行进一步估计。

看到以下信息时，您可能希望增加座席数量：

• 在构建队列中等待空闲代理的构建；

• 每个构建中包含的更改多于您觉得舒适的程度（例如，构建失败分析）；

• 不同环境的必要性。我们已经看到了每20个构建配置（构建类型）中都有一个代理的模式。或每1-2个开发人员使用一个构建代理。

另请参阅有关支持的最大代理数的注释 。

在复制/群集环境中设置TeamCity

TeamCity仅支持主服务器的单个实例，但是可以添加辅助节点以在当前数据上提供仅查看的UI，并从代理收集运行中的构建数据。所有节点都需要连接到同一节点TeamCity Data Directory和数据库。

为了解决快速灾难恢复的情况，TeamCity支持活动-故障转移（冷备用）方法：可以复制TeamCity服务器使用的数据，并且可以采用一种解决方案，以在当前活动的服务器发生故障时使用相同的数据来启动新服务器。

对于数据，TeamCity服务器同时使用数据库和文件存储（数据目录）。您可以浏览TeamCity数据备份和TeamCity数据目录页面，以获取有关TeamCity数据存储的更多信息。基本上，磁盘上的TeamCity数据目录和TeamCity使用的数据库都必须保持一致状态，因此必须一起复制。
任何时候，只有一个TeamCity服务器实例应使用数据库和数据目录。

确保TeamCity故障转移/备份服务器的分发版本与主服务器的版本完全相同。确保相同的服务器环境/启动选项（如内存设置等）也很重要。

TeamCity代理服务器场可以在主服务器和故障转移服务器之间重用。如果您使故障转移服务器通过旧服务器DNS名称进行解析，则代理将自动连接到新服务器，并且代理将使用DNS名称连接到服务器。另请参阅有关从一台服务器切换到另一台服务器的信息。
如果合适，可以像服务器一样复制代理。但是，除了conf \ buildAgent.properties文件外，无需在代理上复制任何TeamCity特定的数据，因为通常可以从服务器续订所有其余数据。如果是复制代理场，则只需将复制代理连接到故障转移服务器。

如果出于冗余目的而安装了两个服务器，则它们可以使用同一组许可，因为在给定的时刻仅其中一个正在运行。

TeamCity安全说明

以下注释仅供参考，并不意味着它们是完整的或准确的。

开发TeamCity时会考虑安全问题，并已做出合理的努力以使系统不受各种类型的攻击。我们与第三方合作，使用安全扫描器和渗透测试评估TeamCity的安全性。
我们的目标是在最新的TeamCity主要版本的最近的错误修复版本中迅速解决新发现的安全问题。
但是，一般的假设和建议的设置是将TeamCity部署在受信任的环境中，恶意用户不可能对其进行访问。

连同这些准则一起，请查看有关配置TeamCity服务器以供生产使用的注释 。有关已公开的与安全相关的问题的列表，请参见我们的公共问题跟踪器和发行说明中的“安全”部分。建议您尽快升级到新发布的TeamCity版本，因为它们可能包含与安全相关的修补程序。

请注意， 自TeamCity 2017.2起 ，TeamCity Windows安装程序将TeamCity安装目录的权限修改为不使用可继承的权限，并明确授予对目录的访问权限给Administrators用户组和配置该服务在其下运行的accrount。
强烈建议将权限限制为TeamCity Data Directory以同样的方式。

TeamCity使用什么加密

TeamCity尝试不通过Web UI（从浏览器到服务器）以明文形式传递密码值：相反，它使用具有1024位密钥的RSA对其进行加密。但是，建议仅通过HTTPS使用TeamCity Web UI，因此此预防措施应该无关紧要。TeamCity以加密形式将密码存储在设置中（在该密码中，原始密码值是在其他系统中执行身份验证所必需的）。使用带有固定密钥的3DES进行加扰。

配置新安装的MySQL服务器

如果除了基本设置之外，还要将MySQL服务器与TeamCity一起使用，则应查看并可能更改某些MySQL服务器设置。如果Windows上安装了MySQL，则设置位于my.ini该文件通常可以在MySQL安装目录下找到。对于类Unix系统，该文件称为my.cnf可以放在下面的某个地方/etc目录。在MySQL文档中阅读有关配置文件位置的更多信息。注意：在中更改设置后，您需要重新启动MySQL服务器my.ini|my.cnf 。

应检查和/或更改以下设置：

配置新安装的PostgreSQL服务器

为了获得更好的TeamCity服务器性能，建议更改新安装的PostgreSQL服务器的某些参数。您可以在PostgreSQL Wiki中阅读有关PostgreSQL性能优化的更多信息 。

可以在以下参数中更改以下参数postgresql.conf文件位于PostgreSQL的数据目录中。

在代理服务器后面设置TeamCity

本节介绍在TeamCity服务器Web UI前面安装的反向代理服务器的建议设置。建议在代理级别配置HTTPS，但这不在这些说明的范围内-有关此信息，请参阅代理服务器的文档。

考虑示例：
TeamCity服务器安装在URL（本地URL）： http：//teamcity.local：8111 / tc上 。
它以URL（公共URL）在外部可见： http：//teamcity.public：400 / tc 。

您需要设置反向代理（请参阅下面的代理服务器设置 ），还需要配置TeamCity捆绑的Tomcat服务器（请参见下面的TeamCity Tomcat配置 ），以确保TeamCity“知道”客户端用于访问资源的实际绝对URL。然后，这些URL用于在客户端重定向和其他响应中生成绝对URL。

注意：内部TeamCity服务器应该在相同的上下文 （即主机名后面的URL的一部分）下工作，因为外部地址可以从外部看到它。另请参见TeamCity服务器上下文更改说明 。如果仍然需要在不同的上下文中运行服务器，请注意，上下文更改代理应该对TeamCity隐藏这一事实：例如，它应该映射服务器重定向URL以及将cookie设置为原始（外部）上下文的路径。

为TeamCity Web UI配置HTTPS

TeamCity不为HTTPS访问提供现成的支持（请参阅TW-12976 ）。强烈建议在TeamCity之前设置一个反向代理，例如Nginx或Apache，该代理将处理HTTPS并将HTTP TeamCity服务器端口用作上游。代理的HTTPS相关配置并非特定于TeamCity，并且对于任何Web应用程序都是通用的。确保按照下面的建议配置反向代理。通用的Web应用程序最佳做法适用（例如完全禁止对TeamCity的http访问）。

对于小型服务器，您可以通过内部Tomcat手段设置HTTPS，但是不建议这样做，因为这可能会大大增加CPU负载。

要配置客户端使用自签名证书时通过HTTPS访问TeamCity服务器，请查看相关说明 。

配置TeamCity以使用代理服务器进行传出连接

本节介绍将TeamCity配置为将代理服务器用于某些传出HTTP连接。要将代理后面的TeamCity连接到Amazon EC2云代理，请参阅本节 。

TeamCity可以将代理服务器用于TeamCity服务器与其他服务（例如问题跟踪器等）建立的某些传出HTTP连接。

要将TeamCity指向您的代理服务器： 自TeamCity 2017.1.5起 ，可以使用以下服务器内部属性 （有关以前的版本，请参见下面的替代方法）：

适用于任何TeamCity版本的另一种方法是在启动时将额外的以空格分隔的附加JVM选项传递给TeamCity服务器：

配置TeamCity代理以使用代理连接到TeamCity服务器

本节介绍用于TeamCity代理到服务器连接的代理服务器的配置（ 自TeamCity 2017.1开始 ）。

在TeamCity代理端，使用以下属性指定代理以连接到TeamCity服务器： buildAgent.properties文件：

请注意，必须将代理配置为不缓存任何TeamCity服务器响应。例如，如果您使用Squid，则将“ cache deny all”行添加到squid.conf文件。

在同一台计算机上安装多个代理

请参阅代理程序安装文档下的相应部分 。

更改服务器端口

请参阅服务器安装说明中的相应部分 。

升级前试用新版TeamCity版本

建议在升级生产服务器之前尝试使用新的TeamCity版本。通常的过程是创建生产TeamCity安装的副本 ，然后对其进行升级 ，进行尝试，然后在检查完所有内容后放下测试服务器并升级主服务器。启动测试服务器时，请记住更改服务器URL，禁用电子邮件和Jabber通知程序以及新服务器上的其他功能 。

创建包含所有数据的TeamCity Server副本

如果您想保留原始服务器及其副本，请确保检查许可注意事项 。

将TeamCity项目从一台服务器移动到另一台服务器

如果需要将数据移动到没有现有数据的新服务器上，建议先移动服务器或复制它，然后删除新服务器上不需要的数据。

如果您需要将数据与新服务器上的现有数据结合在一起，则可以使用一项专用功能将包含大多数关联数据的项目从一台服务器移动到另一台服务器： Projects Import 。

以下是有关手动移动设置的一些注意事项，以防您想要执行设置

从TeamCity 8.0开始，可以通过简单的文件复制将项目或构建配置的设置移动到另一台服务器。对于早期的TeamCity版本，请参阅注释 。

两个TeamCity服务器（源服务器和目标服务器）应具有完全相同的版本（相同的内部版本）。

两个服务器的所有项目，构建配置和VCS根目录中的所有标识符均应唯一。如果不是，则可以通过Web UI进行更改。如果在不同的服务器上存在具有相同ID的实体，则假定这些实体相同。例如，这对于在所有服务器上具有一组全局的VCS根很有用。

要将项目及其所有构建配置的设置从一台服务器移动到另一台服务器：

来自TeamCity Data Directory ，复制相应项目的目录（ .BuildServer\config\projects\ ）及其所有父项目.BuildServer\config\projects目标服务器。这将移动项目设置，构建配置设置，在项目中定义的VCS根目录，并保留它们之间的链接。如果目标服务器上有与复制的文件同名的文件，则可能发生以下情况：a）id匹配：目标服务器上已经存在相同的实体，在这种情况下，可以将冲突文件排除在复制之外，或者b）id冲突：不同的实体碰巧具有相同的ID。在这种情况下，应通过更改源或目标服务器上的实体ID来满足唯一性要求来解决该问题。

父项目集将根据Web UI或磁盘上的目录名称进行手动标识（默认情况下将具有相同的前缀）。

注意：保持根项目的设置在所有服务器之间同步可能是有意义的（通过同步.BuildServer\config\projects_Root目录）。例如，这将确保所有服务器上的默认清除策略设置相同。

项目复制后的其他步骤可能是：

• 删除目标服务器上已复制的父项目（如果有）中的未使用数据

• 使用“服务器运行状况”报告来识别由于复制而出现的重复VCS根（如果有）

• 在源服务器上存档项目并调整清理规则（以便在必要时能够查看构建的历史记录）

上面的方法没有复制什么：

• 暂停注释和暂停构建配置的用户

• 归档项目的用户

• 全局服务器设置（例如Maven settings.xml配置文件，工具（例如handle.exe），外部更改查看器，构建队列优先级，问题跟踪器）。这些存储在下面的各种文件下.BuildServer\config目录，并且应该在文件级别或通过在服务器管理UI中配置相同的设置进行同步。

• 与代理商池的项目关联

• 不是复制项目的父项目的其他项目的模板。实际上，TeamCity 8.0中已弃用此配置，并且仅支持旧配置。在多个项目中使用的模板应移至公共父项目或根项目。

• 没有为代理配置任何数据（允许在代理上运行的构建配置）。

• 没有与用户相关或与用户组相关的设置（例如角色和通知规则）

• 没有与状态相关的数据，例如静音和调查等。

将TeamCity安装移至新计算机

如果您需要将现有的TeamCity安装移动到新硬件或干净的OS上，则可以在新计算机上安装相同的TeamCity版本，停止旧服务器，然后将新服务器连接到同一台计算机上。 TeamCity Data Directory并确保服务器使用相同的环境 。或者，您可以按照有关将服务器从一台计算机复制到另一台计算机上的说明进行操作 。

移动后，使客户端使用新的服务器地址 （如果更改）。

将服务器从一台计算机移动到另一台计算机时，可以使用现有的许可证密钥 （只要没有同时运行两个服务器）。由于许可证密钥存储在< TeamCity Data Directory > ，您将许可证密钥与所有其他TeamCity设置数据一起传输。

通常建议不要将TeamCity更新与任何其他操作（例如环境或硬件更改）结合使用，并且一次执行一次更改，以便在出现问题时可以轻松地找到原因。

将TeamCity Agent移至新计算机

除二进制文件外，TeamCity代理程序安装还存储其配置和运行时生成的数据。通常，以前版本的数据可以为将来的版本做准备，但是可以在必要时将其删除。配置存储在conf和launcher\conf目录。先前版本收集的数据存储在work和system目录。

将代理程序安装移至新计算机或新位置的最简单方法是：

• 停止现有代理

• 在新机器上安装新代理

• 复制conf/buildAgent.properties从旧的安装到新的安装

• 启动新代理。通过这些步骤，TeamCity服务器将识别代理为相同代理，并将对所有构建执行干净签出。

也请查看此部分以获取可删除的目录列表，而不会影响版本一致性。

在链式构建中共享构建的内部版本号

可以通过引用以下依赖项属性来共享由快照依赖项或工件依赖项连接的内部版本号： %dep.<btID>.system.build.number% 。

例如，您具有要同步构建的构建配置A和B：使用相同的来源并采用相同的构建号。
请执行下列操作：

1. 创建构建配置C，然后创建快照依赖项： C 上的 A以及C上的 B。

2. 在A和B中将内部版本号格式设置为：

哪里是构建配置 C的ID。当通过将Snapshot Dependencies快照依赖项选项设置为off来关闭生成重用时，该方法最有效。

阅读有关依赖属性的更多信息。

请观看/评论有关共享内部版本号TW-7745的问题 。

使生成之间删除临时生成文件

更新您的构建脚本以使用存储在其中的路径${teamcity.build.tempDir} （蚂蚁的样式名称）属性作为临时目录。TeamCity代理在构建之前创建目录，并在构建之后立即将其删除。

如果由于配置错误而导致构建数量过多，请清除构建队列

尝试暂停将构建排队的构建配置。在构建配置暂停时，将从队列中删除其所有构建。
还可以在单个对话框中从构建队列中删除许多构建。

自动创建或更改TeamCity构建配置设置

如果您需要一定程度的自动化并且Web管理UI不能满足您的需求，则有几种可能性：

• 使用REST API

• 直接在磁盘上更改配置文件（有关更多信息，请参见< TeamCity Data Directory > ）

• 编写一个TeamCity Java插件，它将使用开放的API执行任务。

将Cucumber Reporter附加到Ant Build

如果将Cucumber用于Java应用程序测试，则应使用--expand又特别--format选项。此外，您还应该指定RUBYLIB环境变量，该变量指向必要的TeamCity Rake Runner红宝石脚本：

请检查RUBYLIB路径分隔符（为安全起见，对于Windows为';'，对于Linux为'：'或在蚂蚁中为'$ {path.separator}'）。
如果使用Rake构建语言启动Cucumber测试，TeamCity将自动添加所有必需的命令行参数和环境变量。此技巧在TeamCity版本> = 5.0中有效。

获取上一个成功的内部版本号

使用如下网址：

内部版本号将作为纯文本响应返回。
对于 ，请参阅标识符 。
REST API提供了此功能

在TeamCity中为我的应用程序设置部署

TeamCity具有足够的功能，可以使用在构建脚本/构建运行器中配置的实际部署逻辑来处理部分编排流程。TeamCity支持各种通用的构建工具，因此可以在TeamCity中运行任何特定的工具。为了简化特定工具的使用，可以将其包装到meta-runner中或为此编写一个自定义插件。

通常，用于配置部署的设置步骤为：

1. 编写一个构建脚本，该脚本将对磁盘上可用的二进制文件执行部署任务。 （例如，为此使用Ant或MSBuild。对于典型的部署传输，请使用Deployer运行程序 。另请参阅与构建和报告工具集成 。您可以使用Meta-Runner通过方便的UI重用脚本。

2. 在TeamCity中创建一个构建配置，该配置将执行构建脚本并执行实际部署。如果只有有限的一组用户可以看到或开始部署，则将构建配置放在单独的TeamCity项目中，并确保用户在项目中具有适当的权限。

3. 在此构建配置中，配置工件依赖于生成需要部署的二进制文件的构建配置。

4. 如果您需要自动触发部署（例如，部署上一个固定的构建中的最后一个成功），或者在生成要部署的二进制文件的构建中使用“升级”操作，请在部署的构建配置中配置可用的触发器之一。

5. 除了考虑工件依赖之外 ，还考虑使用快照依赖关系 ，并检查“ 构建链”选项卡以获取构建概述。在这种情况下，工件依赖项应使用“从同一链构建”选项。

6. 如果需要对部署进行参数化（例如，在不同的运行中指定不同的目标计算机），请使用自定义构建运行对话框将参数传递给构建脚本。考虑使用类型化参数使自定义运行对话框更易于使用或处理密码。

7. 如果手动触发部署构建，请考虑在构建脚本中添加命令以固定和标记正在部署的构建（通过发送REST API请求）。您还可以使用生成工件的内部版本号 。

进一步建议：

• 为每个目标环境设置单独的构建配置

• 使用内部版本的“依赖关系”选项卡在内部版本生成二进制文件和部署内部版本/任务之间进行导航

• 如有必要，请在“提示”显示模式下使用参数，以在运行构建时要求“ 确认 ”

• 更改构建配置的标题 “运行”按钮

官方网站上的相关部分： 使用TeamCity进行持续部署

使用我的构建所依赖的外部工具

如果需要使用特定的外部工具来安装在构建代理上以运行构建，则可以使用以下选项：

• 在TeamCity中安装并注册该工具：

  1. 在将运行该构建的所有代理上安装该工具。这可以手动完成，也可以通过自动脚本完成。对于简单的文件分发，另请参阅安装代理工具

  2. 将属性添加到buildAgent.properties文件（或将环境变量添加到系统），并以工具起始位置作为值。

  3. 在构建配置中为属性添加代理要求。

  4. 使用构建脚本中的属性。

• 将工具签入版本控制并使用相对路径。

• 将环境准备阶段添加到构建脚本中，以在其他位置获取工具表格。

• 使用单个“伪”构建创建一个单独的构建配置，该构建将包含所需文件作为工件，然后使用工件依赖关系将文件发送到目标构建。

与构建和报告工具集成

如果您拥有一个构建工具或一个生成一些报告/提供代码度量标准的工具，而TeamCity或任何插件尚不支持这些度量标准，那么即使没有专门的集成，您很可能也可以在TeamCity中使用它。

涉及的集成任务是在构建范围内收集数据，然后将数据报告给TeamCity，以便可以以构建结果或其他方式显示它们。

数据采集

最简单的开始方法是修改构建脚本，以使用选定的工具并收集所有必需的数据。
如果可以从命令行控制台运行该工具，则可以使用命令行运行器在TeamCity中运行它。这将使您能够检测到打印到标准错误输出中的消息。如果退出代码不为零，或者通过构建失败条件输出到标准错误，则可以将该构建标记为失败。
如果该工具具有用于任何受支持的构建脚本引擎（如Ant，Maven或MSBuild）的启动器，则可以在TeamCity中使用相应的运行器来启动该工具。另请参阅使用我的构建所依赖的外部工具，以获取有关如何运行外部工具的建议。

您也可以考虑创建一个Meta Runner，以使该工具在TeamCity中具有专用的UI。

对于高级集成，可以使用Java开发自定义的TeamCity插件 ，以简化工具的配置和运行。

在TeamCity中呈现数据

可以通过服务消息将构建进度报告给TeamCity，还可以更新构建状态文本。

对于测试工具，如果尚不支持它们，则可以通过与测试相关的服务消息将测试进度从构建报告给TeamCity，或者在构建中生成一个受支持的XML报告 ，然后通过配置的XML报告的服务消息将其导入。处理构建功能。

为了显示通用报告的结果，该方法可能是在构建脚本中生成HTML报告，将其打包到存档中并作为构建工件发布。然后配置报告选项卡，以将HTML报告显示为构建结果的选项卡。

度量值可以通过服务消息作为TeamCity统计信息发布 ，然后显示在自定义图表中 。您还可以根据指标配置构建失败条件 。

如果该工具报告检查或重复等代码属性信息，则可以使用TeamCity捆绑的报告来显示结果。必须使用自定义插件才能将工具特定的报告处理为TeamCity特定的数据模型。可以在XML Test Reporting插件和FXCop插件中找到此示例（请参阅开源捆绑插件上的链接）。

另请参见TeamCity中的导入覆盖率结果 。

对于高级集成，将需要一个自定义插件来根据需要存储和显示数据。有关插件开发的更多信息，请参见开发TeamCity插件 。

恢复刚刚删除的项目

TeamCity将已删除的项目设置目录（以项目ID命名）移至< TeamCity Data Directory >/config/_trash目录添加""后缀到目录。

要还原项目，请在_trash目录中找到项目目录，然后将其移动到常规项目设置目录中： < TeamCity Data Directory >/config/projects同时删除".projectN"目录名称的后缀。
您可以在服务器运行时执行此操作，它应自动选择还原的项目。

请注意，TeamCity会在删除时间之后的5天内将生成的历史记录和其他存储在数据库中的数据保留在已删除的项目/生成配置中。在可配置 （默认为5天）超时过去之后，在下次清理期间将删除所有关联的数据（内部版本和测试历史记录，更改等）。

的config/_trash如果您确定不需要删除的项目，则不会自动清除该目录，并且可以手动清空该目录。无需重新启动服务器。

将3个默认代理传输到另一台服务器

这是不可能的。

每个TeamCity服务器（专业版和企业版）允许使用绑定到该服务器的3个或更多代理，而无需任何代理许可证。对于Professional服务器，默认情况下，该服务器实例绑定了3个代理：用户不为这些代理付费，则没有针对它们的许可证密钥。
对于企业服务器，代理的数量取决于您的软件包，并且代理绑定到服务器许可证密钥。

因此，绑定到服务器的代理无法转移到另一台服务器。

如果您需要TeamCity服务器随附的更多构建代理，则可以购买附加的构建代理许可证，并连接服务器附带的代理之外的更多代理。

有关许可的更多信息。

在TeamCity中导入覆盖结果

TeamCity与IntelliJ IDEA / Emma和Java的JaCoCo覆盖引擎以及.NET的dotCover / NCover / PartCover捆绑在一起。

但是，还有很多其他覆盖工具，例如Cobertura和TeamCity不直接支持的其他工具。

为了使用这些工具获得类似的体验，您可以：

• 将Coverage HTML报告发布为TeamCity工件：大多数工具以HTML格式生成Coverage报告，您可以将其发布为工件并配置报告选项卡以在TeamCity中显示它。如果工件在根工件目录中发布，并且其名称为coverage.zip并且有index.html文件中，“报告”标签将自动显示。至于运行外部工具，请选中与构建和报告工具集成 。

• 从覆盖率报告中提取覆盖率统计数据，并借助服务消息将统计值发布到TeamCity：如果这样做，您将在构建配置“统计信息”选项卡上看到覆盖率图表，并且还可以通过以下方式使构建失败度量标准更改时构建失败的条件（例如，如果覆盖率下降，则构建失败）。

从“数据目录（NNN）的数据格式和数据库（MMM）的数据格式不匹配”中恢复

如果得到“数据目录（NNN）的数据格式与数据库（MMM）的数据不匹配”。启动TeamCity时出现错误，这意味着数据库或TeamCity数据目录最近被更改为不一致状态，因此无法一起使用。仔细检查数据库和数据目录的位置，如果它们不是服务器用来存储数据的位置，请更改它们。

如果它们是正确的，则很可能意味着服务器已使用另一个数据库或数据目录进行了升级 ，并且主数据目录和数据库未达到一致的升级要求。

要从状态中恢复，您将需要备份升级前所做的一致状态。您将需要还原该备份，确保将正确的位置用于数据目录和数据库，然后执行TeamCity升级。

在特定代理上调试构建

如果某个代理上的构建失败，则可以在该代理上对其进行调试以调查特定于代理的问题。请执行下列操作：

1. 进入TeamCity Web UI中的“ 代理”页面，然后选择代理 。

2. 禁用该代理以将其暂时从构建网格中删除。添加评论（可选）。要在一定时间段后自动启用代理，请选中相应的框并指定时间。

3. 选择要调试的版本。

4. 打开``自定义运行''对话框并指定以下选项：a。在代理下拉列表中，选择禁用的代理 。b。建议选择“ 以个人版本运行”选项，以避免与常规版本相交。

5. 调试完成后，如果尚未配置自动重新启用，请手动启用代理。

您还可以通过TeamCity的IntelliJ IDEA插件在代理上执行测试的远程调试 。

调试构建的一部分（构建步骤）

如果包含多个步骤的构建在某个步骤失败，则可以调试中断的步骤。请执行下列操作：

1. 转到构建配置并禁用要调试的构建步骤。

2. 选择要调试的版本。

3. 打开“ 自定义运行”对话框，然后选择将构建放入队列顶部，以赋予您构建优先权。

4. 调试完成后，重新启用构建步骤。

漏洞

本节介绍与已宣布的安全漏洞有关的影响和必要的保护步骤。

观看带有Windows托盘通知程序的多个TeamCity服务器

TeamCity托盘通知程序通常用于监视构建并从单个TeamCity服务器接收通知。但是，如果您有多个TeamCity服务器，并且希望同时使用Windows Tray Notifier对其进行监视，则需要使用以下命令从命令行为每个服务器启动一个单独的Tray Notifier实例： /allowMultiple选项：

• 从TeamCity托盘通知程序安装文件夹（默认情况下， C:\Program Files\JetBrains\TeamCity ），运行以下命令：

（可选）对于每个纸盘通知程序实例，您可以使用来显式指定要连接的服务器的URL。 /server选项。否则，对于每个其他的托盘通知程序实例，您将需要注销并通过UI更改服务器的URL。

另请参阅问题跟踪器中的详细信息 。

个人用户数据处理

关于TeamCity产品，JetBrains不会收集本地TeamCity安装用户的任何个人数据。有关与JetBrains的客户关系的相关文档可在官方网站上找到： 隐私政策 ， 购买条款 ， TeamCity许可协议 。

当评估您对TeamCity的使用方式如何符合通用数据保护条例（GDPR）（EU）2016/679条例时，以下注释会很有用。这些说明旨在解决最基本的问题，并且可以作为评估特定TeamCity安装的输入。

这些说明基于TeamCity 2017.2.4，在GDPR实施之日即为实际。请至少将TeamCity实例更新为该版本，因为以前的版本可能包含与以下注释不符的问题。

TeamCity发布周期

以下信息仅可用于参考目的。

以下的“主要”发行版本是指第一个或第二个版本号有所更改的版本（例如XXZ中的X）“错误修正”发行版本是指第三个版本号有所更改的版本（例如XXZ中的Z版本）

我们通常拥有的发布阶段是：

• 在EAP（早期访问计划）下可用-通常仅适用于主要版本，在上一个主要版本之后的几个月开始，通常在下一个主要版本之前的几个月开始。通常，新的EAP版本每月或每两个月发布一次。

• 常规发布 -通常，每8个月发布一个主要版本。在主要版本之后，有多个错误修正版本。在该版本的“销售终止”之前，将提供Bugfix版本和针对关键问题的支持修补程序（如果适用）。

• 终止销售 -在发布新的主要版本时发生。在此时间之后，通常不会提供错误修正更新或补丁（异常是没有解决方法的关键问题，同时又允许相对简单的修复，并且由于重要原因客户也无法升级）。这些版本仅提供有限的支持。

• 支持终止 -随着两个较新的主要版本的发布而发生。此时，我们将停止为该发行版提供常规技术支持。

先前版本的日期和TeamCity版本的顺序在“ 先前版本的下载”页面上列出。