如何操作...
安装非捆绑版本的 Java
TeamCity 服务器 需要一个 Java SE JRE 安装才能运行。 兼容的 JRE 版本已捆绑在 TeamCity .exe 安装程序中，但在使用其他发行版时需要单独安装。
TeamCity 会按照以下方式选择运行服务器进程的 Java 版本：
默认情况下，如果您的 TeamCity 安装有捆绑的 JRE（
<TeamCity 安装目录>\jre目录存在），它将用于运行 TeamCity 服务器进程。 要使用不同的 JRE，通过TEAMCITY_JRE环境变量指定其路径。如果没有
<TeamCity 安装目录>\jre目录，TeamCity 会寻找指向 JRE 或 JVM （Java SDK）安装目录的JRE_HOME或JAVA_HOME环境变量。 如果两个变量都已声明，将使用 JRE。
更新 Java 安装所需的步骤取决于所使用的发行版。
如果您的 TeamCity 安装有捆绑的 JRE （存在 <TeamCity 安装目录>\jre 目录），请根据安装说明安装新版本的 JRE 并复制生成的目录的内容，以替换现有 <TeamCity 安装目录>\jre 目录的内容。
如果您还从 <TeamCity 安装目录>\buildAgent 目录运行 TeamCity 代理，请安装 JDK （Java SDK）而不是 JRE 并将 JDK 安装目录的内容复制到 <TeamCity 安装目录>\jre 中。
将 32 位升级为 64 位 Java
TeamCity 服务器与 64 位 JVM 一起捆绑，但可以在 32 位和 64 位版本下运行。
如果您需要将32位Java更新为64位JVM，请注意，从32位切换到64位时，内存使用量几乎翻倍。 确保为 32 位 JVM 指定至少两倍的内存。 阅读如何更改内存设置。
要更新到 64 位的 Java，您可以使用捆绑的 Java 版本，或者：
更新服务器要使用的 Java 。
设置 JVM 内存选项。 建议为 64 位 JVM 设置
-Xmx4g选项。
安装非捆绑版本的 Tomcat
TeamCity 服务器 发行版包含一个已测试过能够与当前版本良好配合的 Tomcat 版本。 您可以使用其他Tomcat 版本，但请注意，其他组合不能保证能够正确工作。
要使用Tomcat网络服务器的另一个版本，而非内置版本，您需要执行Tomcat升级 / 补丁。
当您要升级 TeamCity 使用的 Tomcat 版本时，我们建议您：
备份当前的 TeamCity 安装目录。
删除/移动那些同时存在于 TeamCity 安装目录 目录和 Tomcat 发行版本中的文件。
将 Tomcat 发行版解压到 TeamCity 安装目录 目录。
将特定于 TeamCity 的文件从之前备份/移动的目录复制到 TeamCity 安装目录：
位于
bin下的文件并未包含在 Tomcat 发行版中审查默认的 Tomcat
conf目录和 TeamCity 的目录之间的差异，将 Tomcat 文件更新为 TeamCity 特有的设置 (teamCity-*文件和部分server.xml)。删除默认的 Tomcat
webapps/ROOT目录，并用 TeamCity 提供的目录替换它。
在 macOS 上自动启动 TeamCity 服务器
在 macOS 上启动 TeamCity 服务器与在 macOS 上启动 Tomcat 非常相似。
安装 TeamCity 并确保如果从命令行启动
bin/teamcity-server.sh start，它可以正常运行。 这个指令假设 TeamCity 已安装到/Library/TeamCity。创建含有以下内容的
/Library/LaunchDaemons/jetbrains.teamcity.server.plist文件：<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>WorkingDirectory</key> <string>/Library/TeamCity</string> <key>Debug</key> <false/> <key>Label</key> <string>jetbrains.teamcity.server</string> <key>OnDemand</key> <false/> <key>KeepAlive</key> <true/> <key>ProgramArguments</key> <array> <string>/bin/bash</string> <string>--login</string> <string>-c</string> <string>bin/teamcity-server.sh run</string> </array> <key>RunAtLoad</key> <true/> <key>StandardErrorPath</key> <string>logs/launchd.err.log</string> <key>StandardOutPath</key> <string>logs/launchd.out.log</string> </dict> </plist>通过运行测试您的文件：
launchctl load /Library/LaunchDaemons/jetbrains.teamcity.server.plist这个命令应该能启动 TeamCity 服务器（您可以从
logs/teamcity-server.log和您的浏览器中看到这一点）。如果您不希望 TeamCity 以根权限启动，请在
.plist文件中指定UserName键，例如：<key>UserName</key> <string>teamcity_user</string>
TeamCity 服务器现在会在计算机启动时自动启动。 要配置 TeamCity 构建代理的自动启动，请参阅 专门部分。
自动化 TeamCity 服务器安装
对于自动化的 TeamCity 服务器安装，请使用 .tar.gz 分发版。
通常，您需要解压它并执行脚本来执行此部分中提到的步骤。
如果您希望立即获得预先配置的服务器，请将以前配置的服务器中的文件放入 Data Directory。 对于每台新服务器，您需要：
确保它指向一个新的数据库（在
<数据目录>\config\database.properties中配置）；更改
<数据目录>\config\main-config.xml文件，使其在根 XML 元素中不具有uuid属性（以便可以生成新的）；为rootURL属性设置适当的值。
检索管理员密码
在首次启动时使用空数据库，TeamCity 会显示管理员设置页面，允许创建具有完全管理权限的用户（分配 系统管理员 角色）。
如果您想重新获得对系统的访问权限，而您无法以系统管理员角色的用户身份登录，您可以作为超级用户登录，并更改现有管理员帐户的密码或创建一个具有系统管理员角色的新帐户。
也可以使用 REST API 将系统管理员角色赋予任何现有用户。
如果您使用内置身份验证并已正确指定电子邮件，您可以从登录页面 重设密码。
在复制/集群环境中设置 TeamCity
可以添加一个 secondary TeamCity node，以确保高可用性并减轻主服务器的某些操作负担。 所有节点都需要连接到同一个 TeamCity Data Directory（TeamCity 数据目录） 和数据库。
为应对快速的灾难恢复场景，TeamCity 支持主动 - 故障转移（冷备份）方法：TeamCity 服务器所使用的数据可以被复制，并提供一种解决方案，如果当前正在使用的服务器出现故障，可以使用相同的数据启动新的服务器。
关于数据，TeamCity 服务器使用数据库和文件存储（数据目录）两种方式。 您可以浏览 TeamCity 数据备份 和 TeamCity 数据目录 页面，以获取更多有关 TeamCity 数据存储的信息。 基本上，磁盘上的 TeamCity 数据目录和 TeamCity 使用的数据库必须保持一致的状态，因此必须一起复制。只有一个 TeamCity 服务器实例应在任何时候使用数据库和数据目录。
确保 TeamCity 故障转移 / 备份服务器的分发与主服务器的版本完全相同。 确保相同的服务器环境 / 启动选项，如内存设置等，也是非常重要的。
TeamCity 代理服务器农场可以在主服务器和备用服务器之间重复使用。 如果您使故障转移服务器通过旧服务器 DNS 名称解析，并且代理使用 DNS 名称连接到服务器，那么代理将自动连接到新服务器。 也请查看有关切换从一个服务器到另一个服务器的信息。
如果适当，代理可以像服务器一样复制。 然而，除了 conf\buildAgent.properties 文件以外，无需在代理上复制任何 TeamCity 特定的数据，因为所有其他数据通常可以从服务器更新。 在复制代理农场的情况下，复制代理只需要连接到故障转移服务器即可。
为了冗余目的，如果安装了两个服务器，它们可以使用相同的许可证组，因为在任何给定的时刻只有其中一个在运行。
估算所需构建代理的数量
所需的构建代理数取决于服务器使用模式、构建类型、团队规模、团队对 CI 过程的承诺等。 一般来说，最好的方式是从三个代理开始，看看它们如何处理您服务器上的项目，然后对未来做出预估。
当您看到以下情况时，您可能需要增加代理数：
正在构建队列中等待空闲代理的构建；
每个构建中包含的更多改动可能超出了您的舒适范围（例如，针对构建失败的分析）；
对不同环境的必需性。
我们已经看到，每20个构建配置（构建类型）就有一个代理的模式。 或为每1-2位开发者配置一个构建代理。
配置新安装的 MySQL 服务器
如果除了 基本设置 以外，MySQL 服务器还要与 TeamCity 一起使用，您应该审查并可能需要更改一些 MySQL 服务器的设置。 如果 MySQL 已安装在 Windows 上，设置位于 my.ini 文件中，通常可以在 MySQL 安装目录下找到。 对于 Unix 类型的系统，文件被称为 my.cnf 并可以放置在 /etc 目录的某个位置下。 在 MySQL documentation 中阅读更多关于配置文件位置的信息。 注意：在更改 my.ini|my.cnf 中的设置后，您需要重新启动 MySQL 服务器。
以下设置应被审查和/或更改：
表主键
TeamCity 管理没有主键的表。 因此，MySQL 服务器的 sql_require_primary_key 系统变量必须设置为 关闭。
InnoDB 数据库引擎
确保您在 TeamCity 数据库中的表格上使用的是 InnoDB 数据库引擎。 您可以使用此命令来检查使用的是什么引擎：
或者一次性处理所有表格：
max_connections
您应确保 max_connections 参数的值大于在 TeamCity <TeamCity 安装目录>/config/database.properties 文件中指定的值。
innodb_buffer_pool_size 和 innodb_redo_log_capacity
在 innodb_buffer_pool_size 中指定过小的值可能会显著影响性能：
我们建议您从 2Gb 开始，如果您感觉运行速度慢并且内存足够的话，可以适当增加。 在增大缓冲池大小后，您也应该更改innodb_redo_log_capacity 设置的大小。
对于 MySQL 版本 8.0.30 之前，请使用 innodb_log_file_size 和 innodb_log_files_in_group 参数，而非 innodb_redo_log_capacity 参数。
innodb_file_per_table
为了更好的性能，您可以启用所谓的 per-table tablespaces。 请注意，一旦您添加了 innodb_file_per_table 选项，新的表格将会创建并置于单独的文件中，但是启用此选项之前创建的表格仍将位于共享的表空间中。 您需要重新导入数据库以便将它们放置在单独的文件中。
innodb_flush_log_at_trx_commit
如果 TeamCity 是唯一使用 MySQL 数据库的应用程序，那么您可以通过将 innodb_flush_log_at_trx_commit 变量设置为 2 或 0 来提升性能：
注意：对于 TeamCity 而言，数据库提供完全的 ACID 行为并不重要，因此您可以安全地更改此变量。
log 文件位于不同的磁盘上
将 MySQL 日志文件放置在不同的磁盘上有时可以帮助提升性能。 您可以在 MySQL 文档 中阅读相关内容。
设置二进制日志格式
如果默认的 MySQL 二进制日志格式不是 MIXED （这取决于您使用的 MySQL 的版本），那么应明确将其设置为 MIXED：
启用额外的诊断功能
为了在出现某些数据库特定错误的情况下获取额外的诊断数据，通过 SQL 命令为 TeamCity 数据库用户授予更多权限：
配置新安装的 PostgreSQL 服务器
为了提高 TeamCity 服务器的性能，建议更改新安装的 PostgreSQL 服务器的一些参数。 您可以在 PostgreSQL Wiki 中阅读更多有关 PostgreSQL 性能优化的信息。
以下参数可以在 PostgreSQL 的数据目录中的 postgresql.conf 文件中更改。
shared_buffers
https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-SHARED-BUFFERS 参数的默认值过小，应该增大。
synchronous_commit
如果 TeamCity 是唯一使用 PostgreSQL 数据库的应用，我们建议禁用 https://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT 参数：
与检查点相关的参数
对于如 TeamCity 这样的写入密集型应用程序，建议更改一些与 检查点相关参数：
对于 PostgreSQL 9.5 及以后版本：
对于 PostgreSQL 9.5 之前的版本：
在代理服务器后面设置 TeamCity
此部分的内容已被移至 专用文章。
强制隐藏堆栈跟踪
如果具有访问您的 TeamCity 服务器权限的用户提交了无效的跨站脚本 (XSS) 载荷，服务器将显示包含相关堆栈跟踪的“意外错误”页面。 为了防止通过此堆栈跟踪暴露您环境中的任何敏感信息，您可能需要禁用其显示。 为此，将 teamcity.web.runtimeError.showStacktrace 内部属性 设置为 false。
为 TeamCity 网页用户界面配置 HTTPS
现在，TeamCity 允许 轻松配置 HTTPS 访问。 然而，对于大型的面向公众的 TeamCity 安装，我们仍然建议您在 TeamCity 前面设置一个像 NGINX 或 Apache 这样的反向代理，来处理 HTTPS，并使用 HTTP TeamCity 服务器端口作为上游。
代理的 HTTPS 相关配置不是专为 TeamCity 设计的，与任何web应用程序一样通用。 确保根据 我们的建议 配置反向代理。 通用的网络应用最佳实践都适用（比如全部禁用对 TeamCity 的 http 访问）。
对于小型服务器，您可以通过内部的 Tomcat means 设置 HTTPS，但不推荐这么做，因为这样可能会大大增加 CPU 负载。
为了使客户端能够通过使用自签名证书的 HTTPS 访问 TeamCity 服务器，请检查 相关说明。
配置 TeamCity 使用代理服务器进行外部连接
此部分的内容已被移至 专用文章。
配置 TeamCity 代理 使用代理连接到 TeamCity 服务器
此部分介绍了为 TeamCity 代理服务器到服务器连接配置代理服务器的内容。
在 TeamCity 代理端，使用 buildAgent.properties 文件中的以下属性来指定连接到 TeamCity 服务器的代理：
请注意，代理必须配置为不缓存任何 TeamCity 服务器的响应；例如，如果您使用的是 Squid，就需要在 squid.conf 文件中添加 "cache deny all" 行。
在同一台机器上安装多个代理
请查看代理安装文档下的 对应部分。
更改服务器端口
请查看服务器安装指南中的 相应章节。
在升级前试用更新版的 TeamCity
建议您在升级生产服务器之前，尝试一下新的 TeamCity 版本。 通常的做法是复制您的生产 TeamCity 安装，然后对其进行升级，尝试各种操作，然后，当所有事项都经过检查后，删除测试服务器并升级主服务器。 当您启动测试服务器时，请记得更改服务器URL，禁用电子邮件通知程序，并在新服务器上禁用 其他功能。
创建一份包含所有数据的 TeamCity 服务器副本
如果您想要保留原始服务器以及副本，请务必检查 许可证考虑因素。
创建服务器副本
您可以使用 TeamCity 备份功能或手动创建服务器的副本。 推荐手动方法来进行完整的服务器迁移。
使用 TeamCity 备份
创建一个包含所有内容的 备份。 （如果您要移动构建日志，可以跳过备份构建日志的选项，详见下文）。
安装一个与您现有运行的版本相同的新 TeamCity 服务器。 确保：
合适的环境已配置（请参见下面的注释）
服务器使用自己的
<TeamCity 数据目录>和自己的 数据库（请检查<TeamCity 数据目录>config / database.properties文件）
恢复备份。
将工件（这些未包含在备份中）通过移动
<TeamCity 数据目录>/system/artifacts目录的内容从旧位置移至新位置。 由于构建工件的尺寸可能会很大，这可能需要大量的时间，因此请相应地规划。执行必要的 环境转移。
手动复制
如果您不想使用捆绑的备份功能，或者需要对过程进行手动控制，以下是关于如何手动创建服务器副本的一般指导：
创建一个 备份，以便在出现任何问题时可以恢复。
确保服务器未在运行。
要么执行干净的 安装，要么将 TeamCity 二进制文件（
TeamCity Home Directory（TeamCity 主目录））复制到新的位置（在复制过程中可以省略temp和work子目录）。 使用与 TeamCity 版本完全相同的版本。 如果您计划在复制后进行升级，请在已有版本启动并运行后再进行升级。复制
<TeamCity 数据目录>。 如果您不需要完整副本，请参考下面的选项。为了保留项目和构建配置设置
.BuildServer/config.BuildServer/lib和.BuildServer/plugins如果您有的话如果您使用内部数据库且不想移动此数据库，可以从
.BuildServer/system的根目录中获取文件。.BuildServer/system/artifacts（可选）如果您希望在新服务器上保留构建工件和构建日志（包括测试失败的详细信息）.BuildServer/system/changes（可选）如果您希望在新服务器上保留个人更改.BuildServer/system/pluginData（可选）如果您希望保留各种插件、构建触发器和设置审核差异的状态.BuildServer/system/caches和.BuildServer/system/caches（可选）无需复制到新服务器，它们将在启动时重新创建，但可能需要一些时间来重建（预期会有一些减慢）。
构件目录通常很大。 如果您需要在移动服务器时尽量减少停机时间，您可以使用通用的数据复制方法：在原始服务器运行时，使用 rsync、robocopy 或类似工具复制数据。 多次重复同步运行，直到同步数据的数量减少。 在原始服务器关闭后运行最终同步。 服务器迁移的另一种解决方案是使旧的数据构件目录对新服务器可访问，并将其配置为第二个 构件的位置。 然后在服务器运行时，从第二个位置复制文件到主位置。 在复制完成后重启服务器。
在新的模式或新的数据库服务器中，创建一个您的 TeamCity 安装正在使用的 数据库 的副本。 这可以通过使用特定数据库的工具或者捆绑的 maintainDB 工具来完成，方法是先通过 备份 数据库数据，然后进行 恢复。
将新的 TeamCity 安装配置为使用正确的
<TeamCity 数据目录>和 数据库（.BuildServer/config/database.properties指向数据库的副本）。执行必要的 环境转移。
环境转移
如果特别为现有的 TeamCity 安装修改了相关环境，请考虑进行转移。 这可能包括：
使用适当的 OS 用户帐户来运行配置设置，全局和文件系统权限已正确配置的 TeamCity 服务器进程
使用相同的 TeamCity 进程启动选项，特别是检查 / 复制以
TEAMCITY_开头的环境变量。确保在 TeamCity 网页用户界面中配置的任何具有绝对路径的文件/设置都是可访问的。
如果依赖于操作系统级别的用户/机器设置，如默认的SSH密钥、缓存的VCS访问凭据，请将它们也一并转移。
考虑在网络配置中复制与机器相关的任何特殊设置或例外等
如果 TeamCity 安装以任何方式进行了修补（如 GroovyPlug 插件，用于 MS SQL Server 集成安全认证的本地驱动程序），则将相同的修改应用到安装副本上
如果您在操作系统启动时运行 TeamCity（例如，Windows 服务），请确保在新机器上执行相同的配置
在
<TeamCity 安装目录>\conf\teamcity-startup.properties文件中审查并转移设置请考虑在
<TeamCity 安装目录>\conf\server.xml中的任何自定义设置。
许可证问题
单个 TeamCity 许可证 不能同时在两台正在运行的服务器上使用。
已复制服务器检查清单
如果您需要创建服务器的副本（而非将服务器移至新位置），请按照以下清单操作：
确保原始服务器和复制服务器使用不同的 Data Directories 、数据库和工件目录。
在第一次启动前，通过从
<TeamCity 数据目录>/config/main-config.xml文件的 XML 中删除 "uuid" 属性，来更改唯一的服务器 ID。确保相同的许可证密钥没有在几个服务器上使用（更多关于许可证）。
在 Administration | Global Settings 页面上更新 Server URL 为服务器的实际 URL。
请检查您是否能够成功地在新服务器上进行身份验证，如有必要，使用 super user 权限。
检查 VCS 服务器、问题跟踪服务器、电子邮件服务器和其他服务器访问系统是否可访问。
请检查已配置为向 TeamCity 服务器推送事件的任何系统（如 VCS 钩子，自动化构建触发器，监视器等）是否已更新了新服务器的信息。
审查已安装插件的列表，以确定它们的设置是否需要更改。
安装新的代理（或从现有的代理中选择一些）并配置它们以连接到新的服务器（使用新的服务器URL）。
检查从服务器读取的客户端（下载工件，使用服务器的 REST API，NuGet 源等）是否需要重新配置。
如果您复制生产服务器来创建一个 测试服务器，您需要确保用户和生产系统不受影响。
以下是在首次启动测试服务器之前应更改的设置列表：
禁用清理进程，以避免清理外部存储中的文件，例如 S3 桶或 Docker Registry。 要做到这一点，找到
<TeamCity 数据目录>/config/main-config.xml文件，然后将<db-compact enabled="true">行更改为<db-compact enabled="false">。禁用云集成：测试服务器不应能够启动新的云代理。 在
<TeamCity 数据目录>/config/internal.properties文件中设置teamcity.cloud.integration.enabled=false内部属性（如果此文件尚不存在，请创建此文件）。禁用可能修改外部系统状态的插件，例如 commit status publisher。 创建含有以下内容的文件
<TeamCity Data Directory>/config/disabled-plugins.xml：<?xml version="1.0" encoding="UTF-8"?> <disabled-plugins> <disabled-plugin name="commit-status-publisher" /> <disabled-plugin name="slackNotifier" /> <disabled-plugin name="email" /> <disabled-plugin name="webhooks" /> <disabled-plugin name="searchBuildByNumber" /> </disabled-plugins>请考虑将任何根据 TeamCity 事件向其他非复制系统推送数据的第三方插件添加到此列表中。
将
teamcity.versionedSettings.enabled=false内部属性设为关闭，防止项目在 VCS 中存储其设置。
在测试服务器启动之后：
导航至 Administration | Authentication 并禁用电子邮件验证。
确保您的测试服务器不运行任何更改（例如，部署到）生产环境的构建。 这通常也包括将 Maven 构建部署到非本地仓库。 您可以通过暂停 构建队列 来阻止任何构建的开始。
您可能还希望显著增加 VCS 检查更改间隔（服务器范围内的默认值和 VCS 根中的覆盖值都已更改），或者更改 VCS 根的设置，以防止它们联系生产服务器。 另请参见 TW-47324。
另请参阅下面的部分，关于从一台机器 移动服务器 到另一台机器。
将 TeamCity 项目从一个服务器移动到另一个服务器
如果您需要将数据移到一个没有现有数据的新服务器，建议移动服务器或复制服务器，然后删除新服务器上不必要的数据。
如果您需要将数据与新服务器上已有的数据进行合并，我们已为此提供了一个专用功能，可以将大部分相关数据从一个服务器移动到另一个服务器：项目导入。
这里有一些关于手动移动设置的注意事项，以防您将来想要执行此操作
可以通过简单的文件复制，将项目或构建配置的 settings 移至另一台服务器。
两个 TeamCity 服务器（源服务器和目标服务器）应该是完全相同的版本（相同的构建）。
所有项目、构建配置和两个服务器的 VCS 根中的所有 标识符 都应该是唯一的。 如果它们不是，您可以通过网页用户界面进行更改。 如果具有相同 id 的实体存在于不同的服务器上，那么这些实体被认为是相同的。 例如，这对于在所有服务器上都有一套全局的 VCS roots 很有用。
要将项目的设置以及所有构建配置从一个服务器移动到另一个服务器：
从 TeamCity Data Directory（TeamCity 数据目录） ，将相应项目（ .BuildServer\config\projects\<id> ）的目录及其所有父项目复制到目标服务器的 .BuildServer\config\projects。 此操作将项目设置、构建配置设置、在项目中定义的 VCS 根保留在他们之间的链接。 如果目标服务器上存在与被复制的文件同名的文件，可能会出现以下情况： a) id 匹配：目标服务器上已经存在相同的实体，在这种情况下，可能会排除冲突文件的复制，或 b) id 冲突：不同的实体恰好拥有相同的 id。 在这种情况下，应通过更改源服务器或目标服务器上的实体 ID 来消除问题，从而满足唯一性要求。
父级项目的集合需要根据网页用户界面或磁盘上的目录名称（默认情况下会有相同的前缀）来手动识别。
注意：将所有服务器的 root project 设置保持同步（通过同步 .BuildServer\config\projects_Root 目录的内容）可能是有意义的。 例如，这将确保所有服务器上的默认清理策略具有相同的设置。
复制项目后的进一步步骤可能是：
在目标服务器上删除复制的父项目中的未使用数据（如果有）
使用“服务器健康”报告来识别由拷贝产生的重复的 VCS 根，如果有的话
在源服务器上存档项目，并调整清理规则（如有必要，可以查看构建的历史记录）
以下方法未能复制的是什么：not：
暂停评论和使用了暂停构建配置的用户
存档项目的归档用户
全球服务器设置（例如，Maven
settings.xml 配置文件，像handle.exe这样的工具，外部更改查看器，构建队列优先级，问题跟踪器）。 这些存储在.BuildServer\config目录下的各种文件中，应通过文件级别同步，或者在服务器管理界面中配置相同的设置。项目与代理池的关联
来自非复制项目的父项目的模板。 此配置实际上在 TeamCity 8.0 中已被弃用，只作为遗留功能进行支持。 在多个项目中使用的模板应该被移动到公共父项目或根项目。
代理服务器（被允许在代理上运行的构建配置）没有配置数据。
没有与用户或用户组相关的设置（如角色和通知规则）
没有像静音和调查这样的状态相关数据。
将 TeamCity 安装迁移到新的机器
如果您需要将现有的 TeamCity 安装移至新的硬件或干净的操作系统，您可以在新机器上安装相同的 TeamCity 版本，停止旧的服务器，将新服务器连接到相同的 TeamCity Data Directory（TeamCity 数据目录） ，并确保服务器使用相同的环境。 或者，您可以遵照复制服务器从一台机器到另一台机器的指导。
移动后，如果服务器地址有所更改，让客户端 使用新的服务器地址。
您可以在将服务器从一台机器移动到另一台机器时（只要没有两台服务器同时运行）使用现有的 许可证密钥。 由于许可证密钥存储在 <TeamCity 数据目录> 下，您可以与所有其他 TeamCity 设置数据一起转移许可证密钥。
通常建议不要将 TeamCity 更新与其他任何操作，如环境或硬件更改，一并进行，而应该一次执行一个更改，这样，如果出现问题，可以轻松追踪到原因。
从一台服务器切换到另一台服务器
请注意，任何给定时刻， <TeamCity 数据目录> 和数据库都应由单个 TeamCity 实例使用。 如果您配置了一个新的 TeamCity 实例来使用相同的数据，请确保在启动新的实例之前关闭并禁用旧的 TeamCity 实例。
通常，建议使用域名来访问服务器（在代理配置和用户访问 TeamCity 网络 UI 时）。 通过这种方式，您可以更新 DNS 条目，使地址解析为新服务器的 IP 地址，所有缓存的 DNS 结果过期后，所有客户端将自动使用新服务器。 您可能需要在变更前提前减少 DNS 服务器的缓存 / 租期时间，以便让客户端快速“理解”这个变更。
然而，如果您需要使用另一个服务器域名地址，您将需要：
将代理切换到新的 URL （需要在每个代理的
buildAgent.properties中更新serverUrl属性）。 如果您希望重新安装代理，但保留代理的名称和认证状态，您可以安装一个新代理，并从旧代理复制conf\buildAgent.properties文件（确保其中的任何路径都已相应更新）。在新服务器启动时，记得在Administration | Global Settings页面更新服务器URL。
通知所有 TeamCity 用户新的地址
如果外部服务的设置取决于请求的发起地址，请考虑更新这些设置。
将 TeamCity 代理 移至新的机器
除了二进制文件外，TeamCity 代理安装还会存储其配置和从其运行的构建中留下的数据。 通常，来自先前构建的数据会使得为未来构建做准备的过程略微加快，但如有必要，其也可以被删除。 配置存储在 conf 和 launcher\conf 目录下。 由先前构建收集的数据存储在 work 和 system 目录下。
将代理安装移至新机器或新位置的最简单方法是：
停止已有的 agent
install 在新机器上安装一个新的代理
将
conf / buildAgent.properties从旧安装版复制到新的安装版启动新的代理程序。 按照这些步骤，代理将会被 TeamCity 服务器识别为相同的，并将对所有构建执行 清理检出。
请也查看 部分，列出了可以删除而不影响构建一致性的目录列表。
分享链式构建中的构建编号
构建编号可以通过引用以下依赖性属性来共享用于通过 快照依赖关系 或 工件依赖关系 连接的构建： %dep.<btID>.system.build.number%。
例如，您有构建配置 A 和 B，您希望它们同步构建：使用相同的源代码并采用相同的构建号。
请按照以下步骤操作：
创建构建配置 C，然后快照依赖性：A 依赖于 C 和 B 依赖于 C。
将 A 和 B 中的 Build number format 设置为：
在这里， <btID> 是构建配置 C 的 ID。 该方法在通过 Snapshot Dependencies 快照依赖选项设置为关闭时，构建重用效果最佳。
阅读更多关于依赖属性的内容。
请关注/评论与分享构建号 TW-7745 相关的问题。
在构建之间删除临时构建文件
将您的构建脚本更新为使用存储在 ${teamcity.build.tempDir} （Ant 的样式名称）属性作为临时目录。 TeamCity 代理在构建前创建 directory，并在构建后立即删除。
如果由于配置错误而构建队列中的构建过多，请清除构建队列
尝试暂停有构建队列的构建配置。 在构建配置暂停时，所有构建都会从队列中删除。
还有一种能力可以在单个对话框中删除构建队列中的许多构建。
自动创建或更改 TeamCity 构建配置设置
如果您需要一定程度的自动化，并且网络管理界面无法满足您的需求，那么有几种可能性：
使用 REST API
直接在磁盘上更改配置文件（在
<TeamCity 数据目录>查看更多）编写一个 TeamCity Java 插件，使用 open API 来执行任务。
将 Cucumber 报告器附加到 Ant 构建
如果您用 Cucumber 进行 Java 应用测试，您应该用 --展开 和特别的 --格式化 选项运行 Cucumber。 更进一步，您应该指定指向必要的 TeamCity Rake Runner ruby 脚本的 RUBYLIB 环境变量：
请检查 RUBYLIB 路径分隔符（Windows 为 ';'，Linux 为 ':'，或者在 ant 中为了安全起见使用 '${path.separator}'）。
如果您正在使用 Rake 构建语言启动 Cucumber 测试，TeamCity 将自动添加所有必要的命令行参数和环境变量。 这个提示适用于 TeamCity 版本 >= 5.0。
获取最后一次成功构建的编号
使用如下的 URL：
构建号将以纯文本形式返回。
有关 <ID of build configuration> ，请参见标识符。
这个功能由REST API提供。
在 TeamCity 中为我的应用程序设置部署
TeamCity 具有多种功能，可以处理部署的编排部分，实际的部署逻辑在构建脚本 / 构建运行程序中配置。 TeamCity 支持各种通用构建工具，因此任何特定工具都可以在 TeamCity 中运行。 为了方便特定工具的使用，您可以将其包装到 meta-runner 中，或者为此编写自定义插件。
一般来说，配置部署的设置步骤是：
编写一个构建脚本，用于执行磁盘上可用的二进制文件的部署任务。 例如，使用 Ant 或 MSBuild 来实现这个功能。 对于典型的部署传输，使用 Deployer 运行器）。 另请参见 与构建和报告工具集成。 您可以使用 Meta-Runner 以方便的用户界面复用脚本。
在 TeamCity 中创建一个构建配置，该配置将执行构建脚本并进行实际部署。 如果部署只能被有限的用户集可见或启动，请将构建配置放在一个单独的 TeamCity 项目中，确保用户在项目中具有适当的权限。
在此构建配置中，配置对生成需要部署的二进制文件的构建配置的 工件依赖。
如果您需要自动触发部署（例如，部署最后一次成功或最后一次固定的构建），则请在部署构建配置中配置一个可用的触发器，或在生成要部署的二进制文件的构建中使用 “部署” 操作。
请考虑在工件依赖项之外，还使用快照依赖项，并查看构建链选项卡以获得构建的概览。 在这种情况下，构件依赖应使用“来自同一链的构建”选项。
如果您需要参数化部署（例如，在不同的运行中指定不同的目标机器），请使用 自定义构建运行对话框 将参数传递给构建脚本。 请考虑使用 Typed Parameters 来使自定义运行对话框更易于使用或处理密码。
如果部署构建是手动触发的，也考虑在构建脚本中添加命令以固定和标记正在部署的构建（通过发送一个 REST API 请求或一条 Service Message）。 您也可以从生成工件的构建中 使用构建编号。
更多建议：
使用我构建依赖的外部工具
如果您需要使用特定的外部工具并需要在构建代理上安装以运行您的构建，您有以下选项：
在 TeamCity 中安装并注册此工具：
在所有将运行构建的代理上安装该工具。 这可以手动完成，也可以通过自动化脚本完成。 对于简单的文件分发，也请参见 安装 Agent 工具
在
buildAgent.properties文件中添加一个属性（或将环境变量添加到系统中），并使用工具主目录位置作为值。在构建配置中为属性添加代理要求。
在构建脚本中使用该属性。
将工具检入版本控制，并使用相对路径。
在构建脚本中添加环境准备阶段，以从其他地方获取工具。
创建一个单独的构建配置，其中包含一个包含所需文件作为工件的“虚假”构建，然后使用工件依赖关系将文件发送到目标构建。
与构建和报告工具集成
如果您有一个构建工具或者一个生成报告 / 提供代码度量的工具，但尚未得到 TeamCity 或者任何 插件 的支持，那么您可能仍然可以在 TeamCity 中使用它，甚至不需要专用的集成。
涉及的集成任务包括在构建范围内收集数据，然后将数据报告给 TeamCity，以便它们可以在构建结果中展示，或以其他方式展示。
数据收集
最简单的启动方式是修改您的构建脚本，以便使用所选工具并收集所有必要的数据。
如果您能从命令行控制台运行该工具，那么您可以在 TeamCity 中使用命令行运行器来运行它。 这将使您能够检测打印到标准错误输出的消息。 如果退出代码不为零或者通过 构建失败条件向标准错误输出，那么可以将构建标记为失败。
如果该工具对任何受支持的构建脚本引擎（如 Ant、Maven 或 MSBuild）有启动器，那么您可以在 TeamCity 中使用相应的运行程序来启动该工具。 参见 我的构建依赖的使用外部工具 ，了解如何运行外部工具的推荐方法。
您也可以考虑创建一个 Meta Runner，让该工具在 TeamCity 中拥有专用的用户界面。
为了实现高级集成，可以使用 Java 开发自定义的 TeamCity 插件，以简化工具配置和运行。
在 TeamCity 中呈现数据
构建进度可以通过 服务消息 报告给 TeamCity，构建状态文本也可以被 更新。
对于测试工具，如果它们还未被 支持，您可以通过 与测试相关的服务消息 或在构建中生成一种受支持的 XML 报告，并让其通过配置的 XML 报告处理构建功能的服务消息导入，来报告 TeamCity 的测试进度。
为了展示通用报告的结果，方法可能是在构建脚本中生成 HTML 报告，将其打包到存档，并作为构建成果物发布。 然后配置一个 report tab ，使 HTML 报告在构建结果中作为一个标签页显示。
一个指标值可以通过 服务消息 作为 TeamCity 统计信息发布，然后在 自定义图表 中显示。 您还可以根据指标配置 构建失败条件。
如果该工具报告了代码属性信息，如检查或重复项，可以使用 TeamCity 自带的报告来显示结果。 需要一个自定义插件来处理工具特定的报告，转化为 TeamCity 特定的数据模型。 此示例可以在 XML 测试报告 插件和 FXCop 插件中找到（请参见 捆绑的开源插件 页面上的链接）。
对于高级集成，需要一个自定义插件来存储和按需展示数据。 请参阅 开发 TeamCity 插件以获取有关插件开发的更多信息。
恢复刚刚删除的项目
TeamCity 将已删除的项目设置目录（以项目 id 命名）移至 <TeamCity 数据目录>/config/_trash 目录，并在目录名后添加 "<internal ID>" 后缀。
要恢复一个项目，请在 _trash 目录中找到项目目录，并将其移动到常规项目设置目录： <TeamCity 数据目录>/config/projects ，同时从目录名称中删除 ".projectN" 后缀。
您可以在服务器运行时执行此操作，系统应自动接收恢复的项目。
请注意，TeamCity 会在删除项目/构建配置后的5天内保留数据库中保存的构建历史和其他数据。 所有相关的数据（构建和测试历史、更改等）将在下一次清理时被删除，这发生在可配置的超时（默认为5天）结束后。
config/_trash 目录不会自动清理，如果您确定不再需要已删除的项目，可以手动清空该目录。 不需要重新启动服务器。
将 3 个默认代理转移到另一台服务器
这是不可能的。
每个 TeamCity 服务器（专业版和企业版）都允许绑定到服务器的 3 个或更多代理，无需任何代理许可证。 对于专业服务器，默认情况下有3个代理绑定到服务器实例：用户无需为这些代理付费，也没有为它们提供的许可证密钥。
对于企业服务器，代理的数量取决于您的套餐，代理将绑定到服务器许可证密钥。
所以，绑定到服务器的代理不能被转移到另一个服务器。
如果您需要更多的构建代理，超过了您的 TeamCity 服务器所包含的，您可以购买额外的构建代理许可证，并连接更多的代理，除了那些与服务器捆绑的代理。
查看 更多 关于许可证的信息。
从"Data Directory (NNN) 和数据库 (MMM) 的数据格式不匹配"错误中恢复
如果在启动 TeamCity 时，您遇到了 "Data format of the Data Directory (NNN) and the database (MMM) do not match." 的错误提示，这意味着数据库或 TeamCity 数据目录最近发生了改变，导致其状况不一致，因此无法一起使用。 请仔细检查数据库和数据目录的位置，并在他们并非服务器用来存储数据的位置时进行更改。
如果他们是对的，那么最有可能的是，服务器已经通过另一个数据库或数据目录进行了升级，而您主要的数据目录和数据库没有满足 一致升级 的要求。
为了从当前状态恢复，您需要备份在升级前所做的一致状态。 您需要恢复该备份，确保正确的位置被用于数据目录和数据库，并执行 TeamCity 升级。
在特定代理上调试构建
如果构建在某个代理上失败，可以在这个代理上调试它，以调查代理特定的问题。 请按照以下步骤操作：
前往 TeamCity 网页版用户界面中的 Agents 页面，并 选择代理。
禁用代理以临时从构建网格中移除它。 添加评论（可选）。 要使代理在一段时间后自动启用，请检查相应的框并指定时间。
打开 自定义运行 对话框，并指定以下选项： a。 在 Agent 下拉菜单中，选择被禁用的 agent。 b. 建议选择 作为 个人构建 运行的选项，以避免与常规构建发生交叉。
当调试完成后，如果未配置自动重新启用，则需手动启用 agent。
您还可以通过用于 TeamCity 的 IntelliJ IDEA 插件 在代理上执行 远程调试 测试。
调试构建的一部分（一个构建步骤）
如果一个包含多个步骤的构建在某个步骤失败，那么可以对导致失败的步骤进行调试。 请按照以下步骤操作：
使用 Windows 托盘通知程序监视多个 TeamCity 服务器
TeamCity 托盘通知程序通常用于监视构建并从单个 TeamCity 服务器接收通知。 然而，如果您有多个 TeamCity 服务器并想同时用 Windows Tray Notifier 监控它们，您需要从命令行启动 Tray Notifier 的一个独立实例来为每个服务器进行监控，启动时需要带上 /allowMultiple 选项：
从 TeamCity 托盘通知程序的安装目录（默认是
C:\Program Files\JetBrains\TeamCity）运行以下命令：
如有需要，您可以为每一个托盘通知程序实例明确指定使用 /服务器 选项连接服务器的URL。 否则，对于每一个额外的托盘通知程序实例，您需要登出并通过用户界面更改服务器的 URL。
也请参阅问题跟踪器中的 详情。
个人用户数据处理
关于 TeamCity 产品，JetBrains 不会收集任何现场安装的 TeamCity 用户的个人数据。 与客户的关系所相关的文档在 JetBrains 官方网站上可供查阅：隐私政策、购买条款、TeamCity 许可协议。
以下注释在评估您使用 TeamCity 时如何符合《一般数据保护条例》（GDPR）（欧盟）2016/679规定时可能有所帮助。 这些笔记旨在解答最基础的问题，可作为评估您特定的 TeamCity 安装的输入。
这些注释是基于目前实际执行 GDPR 的 TeamCity 2017.2.4 版本。 请至少将您的 TeamCity 实例更新至此版本，因为之前的版本可能包含与下方注释不符的问题。
TeamCity 和用户个人数据
TeamCity 存储的最重要的用户相关数据包括：
全名和用户名 - 存储在数据库中，并在用户的个人资料和每次提及用户时显示。 当用户触发构建时，这些也会存储在构建的参数中，并传递到构建中。
用户的电子邮件 - 存储在数据库中，并在用户的个人资料中显示，用于发送通知
客户端访问服务器的 IP 地址 - 可以出现在 内部日志中
TeamCity 内部日志也可以记录一些非结构化的用户相关信息（例如，用户提交的信息或通过 HTTP 请求由浏览器发送的信息，根据配置的设置从用户源（如 LDAP）中检索）。
删除用户数据
当您想删除特定用户的个人数据时，最好的方法是在 TeamCity 中删除该用户。 这样，所有对用户的引用都将继续存储数字用户 id ，而所有其他用户信息将不再存储。 请注意，Audit记录将在删除用户后提及内部的数字用户ID。
如果用户触发了任何构建（即在仍存在于服务器上的任何项目中都具有“运行构建”权限），则用户的用户名和全名将被记录在构建的 teamcity.build.triggeredBy 参数中作为文本值，因为这些都是构建的“环境”的一部分。 如果您需要移除这些，您可以删除相关的构建（以及所有依赖于它们的构建工件或快照），或者删除受影响的构建的参数（这些参数存储在 <TeamCity Data Directory>\system\artifacts***.teamcity\properties 目录下的存档文件中）。
在用户删除和其他数据清理后，请确保重置搜索索引，以从搜索索引中剪除可能缓存的已删除用户的数据。
还有一些其他地方可以存储用户相关的数据
如果用户具有 "编辑项目" 权限，全名 / 用户名可以出现在：
一些审计条目（使用2017.2.1之前的 TeamCity 版本保存） — TW-52215
在 '等待待处理的持久化任务完成' 的构建日志行中的一些构建日志（用 TeamCity 2017.2.1 之前的版本保存） — TW-52872
在存储版本设置的仓库中，提交注释会在用户界面上存储做出更改的用户的名称
在 VCS 相关数据中的 VCS 用户名：
在 UI 中或存储在数据库中可见的 VCS 更改
在服务器和代理上的本地
.git仓库的克隆
用户名也可以出现在配置在不同集成中的访问凭证中，如 VCS roots 、问题跟踪器、数据库访问等。 （这些都存储在 TeamCity 数据目录和 VCS 根目录的设置文件和审计差异文件中，当前和以前版本的 VCS 根目录的用户名也存储在数据库中）
为确保用户的详细信息不被 TeamCity 存储，您可能需要检查 TeamCity 支持的存储以确保没有存储任何数据：数据库、数据目录和 TeamCity 安装目录（日志和定期放在“bin”目录下的内存转储）。
用户协议
如果您希望用户在使用您的 TeamCity 实例之前接受特殊协议，您可以安装由 JetBrains 开发的专用于此目的的 专用插件。 请参阅插件的文档以获取更多详情。
加密
如果您想加密 TeamCity 使用的数据，建议使用通用的、非 TeamCity 特定的工具，因为 TeamCity 并未提供专用的功能。 TeamCity 将数据存储在 SQL 数据库和文件系统中。 您可以配置数据库以加密形式存储数据，并使用安全的 JDBC 支持的连接到数据库（在 database.properties 中配置）。
此外，您还可以在操作系统级别上配置磁盘存储的加密。
日志和调试数据
如果您想确保不将内部 TeamCity 日志存储超过限定的天数，您可以配置 内部日志记录以每日轮换日志文件，并限制保留文件的数量。 TeamCity 代理通常不会以结构化的方式操作任何用户相关的数据，但是如果您需要确保代理上的日志定期轮换，那么您需要以相同的方式配置 agent logging。
每日轮换可以通过在所有必需的 <appender name="..." class="jetbrains.buildServer.util.TCRollingFileAppender"> 附加器中添加 <param name="rotateOnDayChange" value="true"/> 行来配置。 此更改应应用于默认的 conf\teamcity-server-log4j.xml ，并且还应用于存储在 <TeamCity 数据目录>\config\_logging 下的日志预设。
TeamCity也可以储存诊断数据，如线程转储，这可以以非结构化的方式记录用户相关的数据。 建议您定期查看 <TeamCity 安装目录>\日志 目录的内容，并确保没有无用旧文件保存在其中。 另外，像收集调试日志等的日志定制会话之后，应删除额外的日志。 存在一个已知问题，即 logs\catalina.out 文件如果完全不自动旋转。 建议建立自动程序，定期轮换文件。
customizations
这些注释仅涵盖了与最常见文档设置相关的 TeamCity 的捆绑功能。 您应评估您的特定 TeamCity 安装，考虑像配置的构建脚本、已安装的插件、通过 API 与 TeamCity 通信的外部系统等自定义内容。