TeamCity 2019.1帮助

如何...

在此页:

选择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命名的重做日志(或类似实体):

关系数据库管理系统

日志名称

甲骨文

重做日志

MS SQL服务器

交易记录

PostgreSQL的

WAL(预写日志)

MySQL + InnoDB和Percona

重做日志

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.installation.completed=true线成< TeamCity Home Directory >\conf\teamcity-startup.properties文件-这将阻止以空数据库启动的服务器向第一个即将到来的用户授予对计算机的访问权限。

TeamCity没有针对DoS(拒绝服务)攻击的内置保护:高请求率可能会使服务器超载,并使其无响应。如果将TeamCity实例部署在允许此类服务滥用的环境中,请在反向代理级别上实施保护。

简短清单 (请参阅下面的完整说明)

  • 您正在运行最新发布的TeamCity版本,并准备在几周内升级到新发布的版本

  • 使用HTTPS(例如,借助代理服务器(如NGINX))可确保对TeamCity Web界面的访问安全。TeamCity Web界面采用了保护Web应用程序安全的最佳实践。例如:无法使用HTTP协议访问服务器。反向代理不会删除Referer请求标头

  • TeamCity服务器计算机不运行代理(至少在允许读取代理< TeamCity server's home directory< TeamCity Data Directory >

  • TeamCity服务器和代理进程在具有最小限度所需权限的受限用户下运行。安装目录只能由一组有限的OS用户读取和写入。的conf\buildAgent.properties代表服务管理员的OS用户只能读取文件和服务器日志以及数据目录,因为读取这些位置可以分别接管代理或服务器。

  • 来宾用户和用户注册已禁用,或者已审核来宾和“ 所有用户”组的角色

  • 具有管理权限的TeamCity用户具有不平凡的密码

  • 如果您配置了外部身份验证(例如LDAP),则禁用内置身份验证模块

  • 密码不会打印到构建日志中,也不会存储在构建工件中,也不会存储在非密码参数中

与安全相关的风险评估

以下是有关不同安全性方面的一些说明:

  • 中间人关注
    • 在TeamCity服务器和用户的Web浏览器之间:建议对TeamCity服务器使用HTTPS 。登录期间,TeamCity以中等加密级别的加密形式传输用户登录密码。

    • 在TeamCity代理和TeamCity服务器之间:请参阅本节

    • 在TeamCity服务器和其他外部服务器(版本控制,问题跟踪器等)之间:一般规则适用于连接到外部服务器的客户端(在这种情况下为TeamCity服务器),请参阅所涉及服务器的准则。

  • 有权访问TeamCity Web UI的用户:通过TeamCity 用户角色定义了用户可访问的特定信息。

  • 可以更改TeamCity运行的构建中使用的代码的用户(包括任何分支/拉取请求中的提交者(如果它们基于TeamCity构建):
    • 可以执行运行TeamCity代理的系统用户可以执行的所有操作;有权访问可在其构建物上运行的代理计算机上安装的OS资源和其他应用程序。

    • 可以访问和更改在同一代理上构建的其他项目的源代码,修改TeamCity代理代码,将任何文件发布为在代理上运行的构建的工件(这意味着文件可以随后显示在TeamCity Web UI中并公开Web漏洞或可以在其他版本中使用)等。

    • 可以模拟TeamCity代理(运行与TeamCity服务器外观相同的新代理)。

    • 可以对服务器上的所有项目执行具有“查看内部配置设置”权限的用户所能执行的所有操作(请参见下文)。

    • 可以检索运行构建的构建配置的设置,包括密码字段的值。

    • 可以从服务器上的任何内部版本下载工件。
      因此,建议在OS帐户下仅使用必要的权限集运行TeamCity代理并使用代理池功能来确保需要不同访问集的项目不会建立在同一代理上。

  • 具有“查看构建配置设置”权限的用户(默认情况下为“项目开发人员” TeamCity角色)可以查看服务器上的所有项目,但是由于TeamCity 9.0有一种限制方式,请参见相应问题TW- 24904

  • 在一个项目中具有“编辑项目”权限(默认情况下为“项目管理员” TeamCity角色)的用户,通过更改设置可以检索工件并从他们仅具有查看权限的任何构建配置中触发构建( TW-39209 )。用户可能还可以使TeamCity服务器运行服务器上的任何可执行文件。

  • 具有“更改服务器设置”权限的用户(默认情况下为“系统管理员” TeamCity角色):假定用户还可以使用用于运行服务器进程的用户帐户访问运行TeamCity服务器的计算机。因此,用户可以使用该OS用户帐户获得对计算机的完全访问权限:浏览文件系统,更改文件,运行任意命令等。

  • TeamCity服务器计算机管理员:具有对TeamCity存储的数据的完全访问权限,并且可以影响TeamCity执行的进程。在外部系统(如VCS,问题跟踪器等)中进行身份验证所需的密码以加扰的形式存储在TeamCity Data Directory中 ,也可以存储在数据库中。但是,这些值仅是加扰的,这意味着任何有权访问服务器文件系统或数据库的用户都可以检索它们。

  • 对TeamCity服务器日志(TeamCity服务器主目录)具有读取访问权限的用户可以将其访问权限升级为TeamCity服务器管理员。

  • 具有读取权限的用户< TeamCity Data Directory >可以访问服务器上的所有设置,包括配置的密码。

  • 对以下版本的构建工件具有读取权限的用户: < TeamCity Data Directory >/system/artifacts获得具有“查看构建运行时参数和数据”权限的用户的相同权限(特别是可以访问构建中使用的所有密码参数的值)。

  • TeamCity代理计算机管理员:与“可以更改TeamCity运行的版本中使用的代码的用户”相同。

  • 建议在代理之间分配项目,以使一个TeamCity代理不会运行多个项目的构建,这些项目的开发人员和管理员不应访问彼此的项目。推荐的分配项目的方法是使用代理程序池功能,并确保“默认”代理程序池没有代理程序,因为在进行某些重新配置后(例如,当项目中没有其他池时)可以将项目分配给默认池被分配给)。

  • 当启用了在VCS中存储设置时
    • 可以访问设置存储库的任何用户(包括使用同一VCS根目录对构建配置具有“查看文件内容”权限的用户)都可以查看设置并根据其存储的加扰形式检索实际密码

    • 任何可以在VCS中针对服务器上构建的单个构建配置修改设置的用户,都可以通过更改设置来检索工件并从他们仅具有查看权限的任何构建配置中触发构建( TW-39192 )。

    • 可以通过更改构建中的设置来基于每个构建自定义构建配置设置的用户(例如,当版本设置设置为“使用VCS中的设置”时可以运行个人构建的用户)可以检索工件并触发任何构建配置中的构建他们仅具有( TW-46065 )的查看权限。

  • 其他:
    • TeamCity Web应用程序漏洞:一旦发现任何重大漏洞(如跨站点脚本编写的可能性),TeamCity开发团队就会做出合理的努力。请注意,任何可能影响构建文件的用户(“可以更改由TeamCity运行的构建中使用的代码的用户”或“ TeamCity代理计算机管理员”的用户)都可以将恶意文件用作构建工件,然后再利用网站脚本漏洞。( TW-27206

    • TeamCity代理完全由TeamCity服务器控制:由于TeamCity代理支持从服务器下载自动更新,因此代理应仅连接到受信任的服务器。服务器计算机的管理员可以在连接的代理上强制执行任意代码。

    • 任何可以访问服务器URL的人都可以使用服务器上安装的代理插件的二进制文件。

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

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

InnoDB数据库引擎

确保对TeamCity数据库中的表使用InnoDB数据库引擎。您可以在以下命令的帮助下检查使用哪种引擎:

显示表格状态,例如“
';

或一次所有表格:

显示表格状态,如“%”;

max_connections

你应该确保max_connections参数的值大于TeamCity中指定的值< TeamCity Home Directory >/config/database.properties文件。

innodb_buffer_pool_size和innodb_log_file_size

在中指定的值太小innodb_buffer_pool_size可能会严重影响性能:

#InnoDB与MyISAM不同,它使用缓冲池缓存索引和#行数据。设置得越大,#表中的数据访问所需的磁盘I / O越少。在专用数据库服务器上,您可以将此参数最多设置为计算机物理内存大小的80%。但是,请勿将其设置为太大,因为物理内存的竞争可能会导致操作系统中的页面调度。请注意,在32位系统上,您#可能每个进程只能使用2-3.5G的用户级内存,因此请#不要将其设置得太高。innodb_buffer_pool_size = 2000M

我们建议从2Gb开始,如果速度变慢并且有足够的内存,请增加它。增加缓冲池大小后,还应该更改innodb_log_file_size设置的大小(其值可以计算为innodb_log_file_size/N ,其中N是该组中的日志文件数(默认为2)):

innodb_log_file_size = 1024M

innodb_file_per_table

为了获得更好的性能,可以启用所谓的每表表空间 。请注意,一旦添加innodb_file_per_table选项将创建新表并将其放置在单独的文件中,但是在启用此选项之前创建的表仍将位于共享表空间中。您需要重新导入数据库,以便将它们放置在单独的文件中。

innodb_flush_log_at_trx_commit

如果TeamCity是唯一使用MySQL数据库的应用程序,则可以通过设置innodb_flush_log_at_trx_commit可变为2要么0

#如果设置为1,则InnoDB将在每次提交时将事务日志刷新(fsync)到#磁盘上,从而提供完整的ACID行为。如果您#愿意损害这种安全性,并且正在运行#小事务,则可以将其设置为0或2以将磁盘I / O减少到#日志中。值0表示仅将日志写入日志文件,并且#日志文件大约每秒刷新一次到磁盘。值2#表示在每次提交时将日志写入日志文件,但是log#文件仅大约每秒刷新一次到磁盘。innodb_flush_log_at_trx_commit = 2

注意:数据库对数据库提供完整的ACID行为对于TeamCity并不重要,因此您可以安全地更改此变量。

记录不同磁盘上的文件

将MySQL日志文件放在不同的磁盘上有时可以帮助提高性能。您可以在MySQL文档中阅读有关内容

设置二进制日志格式

如果默认的MySQL二进制日志记录格式不是MIXED(取决于您使用的MySQL版本 ),则应将其显式设置为MIXED

binlog-format =混合

启用其他诊断

要在某些特定于数据库的错误的情况下获取其他诊断数据,请通过SQL命令为TeamCity数据库用户授予更多权限:

授予过程*。*至;

配置新安装的PostgreSQL服务器

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

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

shared_buffers

http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-SHARED-BUFFERS参数的默认值太小,应增加:

shared_buffers = 512MB

检查点相关参数

对于TeamCity这样的写密集型应用程序,建议更改一些与检查点相关的参数

对于PostgreSQL 9.5及更高版本

max_wal_size = 1500MB checkpoint_completion_target = 0.9

对于PostgreSQL 9.5之前的版本:

checkpoint_segments = 32 checkpoint_completion_target = 0.9

同步提交

如果TeamCity是唯一使用PostgreSQL数据库的应用程序,我们建议禁用http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT参数:

sync_commit =关闭

在代理服务器后面设置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设置为原始(外部)上下文的路径。

代理服务器设置

应该在配置代理时考虑通用的Web安全性。例如,诸如Referer和Origin之类的标头通常应以未经修改的形式传递给TeamCity Web应用程序。另外,未知的HTTP请求标头应未经修改地传递到TeamCity Web应用程序。例如,TeamCity依赖于客户端添加的“ X-TC-CSRF-Token”标头。

阿帕奇

建议使用2.4.5+版本。早期版本不支持WebSocket协议,因此请使用先前文档版本中注明的设置。

使用Apache时,请确保使用专用的“连接器”节点方法来配置TeamCity服务器。

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so LoadModule headers_module /usr/lib/apache2/modules/mod_headers.so LoadModule proxy_wstunnel_module / usr / lib / apache2 /modules/mod_proxy_wstunnel.so ProxyRequests Off ProxyPreserveHost on ProxyPass / tc / app / subscriptions ws://teamcity.local:8111 / tc / app / subscriptions connectiontimeout = 240 timeout = 1200 ProxyPassReverse / tc / app / subscriptions ws:// teamcity .local:8111 / tc / app / subscriptions ProxyPass / tc http://teamcity.local:8111 / tc connectiontimeout = 240 timeout = 1200 ProxyPassReverse / tc http://teamcity.local:8111 / tc

请注意ProxyPass规则的顺序:冲突的ProxyPass规则必须首先从最长的URL开始进行排序。

请注意,默认情况下,Apache仅允许有限数量的并行连接,这些并行连接在使用WebSocket协议时可能不足。例如,当许多客户端打开Web UI时,它可能导致TeamCity服务器不响应。要修复该问题,您可能需要微调Apache配置。

例如,在Unix上,您应该切换到mpm_worker并配置最大同时连接数:

ServerLimit 100个启动服务器3个MinSpareThreads 25个MaxSpareThreads 75个ThreadLimit 64个ThreadsPerChild 25个MaxClients 2500个MaxRequestsPerChild 0

在Windows上,您可能需要按照Apache文档中的说明增加ThreadsPerChild值。

NGINX

对于以下NGINX配置,请使用“ RemoteIpValve”方法来配置TeamCity服务器。

推荐使用1.3+版本。早期版本不支持WebSocket协议,因此请使用先前文档版本中注明的设置。

http {#...默认设置为此处proxy_read_timeout 1200; proxy_connect_timeout 240; client_max_body_size 0; #HTTP请求的最大大小。 0允许将大型工件上传到TeamCity地图$ http_upgrade $ connection_upgrade {#WebSocket支持默认升级; ''; }服务器{收听400; #公共服务器端口server_name teamcity.public; #公共服务器主机名位置/ {#公共上下文(应与内部上下文相同)proxy_pass http://teamcity.local:8111; #完整的内部地址proxy_http_version 1.1; proxy_set_header主机$ server_name:$ server_port; proxy_set_header X转发的主机$ http_host; #正确的绝对重定向和TeamCity CSRF检查proxy_set_header X-Forwarded-Proto $ scheme所必需; proxy_set_header X-Forwarded-For $ remote_addr; proxy_set_header升级$ http_upgrade; #WebSocket支持proxy_set_header连接$ connection_upgrade; #WebSocket支持}}}

常见配置错误

检查您的反向代理(或类似工具)是否符合以下要求:

  • 支持URL以点(“。”符号)开头的路径(隐藏工件的路径开始包含“ .teamcity”目录)

  • 支持带有冒号(“:”符号)的URL(许多TeamCity资源都使用冒号)。相关的IIS设置 。症状:构建没有工件,并且“此构建中没有用户定义的工件”。文字,即使有人工痕迹。

  • 最大响应长度/时间没有太大限制(由于TeamCity可以提供大文件来减慢客户端速度,因此响应的大小和时间可以为Gb)

  • 完全支持gzip Content-Encoding。例如,某些IIS配置可能导致UI中出现“正在加载数据...”和500个HTTP响应(请参阅相关问题

其他服务器

确保使用对请求(上传)和响应(下载)的大小和超时(根据代码库和工件的大小至少为数十分钟和千兆字节)的适当(高)限制的高性能代理。

建议使用能够与WebSocket协议配合使用的代理,因为这有助于UI尽快刷新。

通常,您需要配置TeamCity服务器,以便它“了解”客户端使用的原始URL,并且可以生成可供客户端访问的正确的绝对URL。实现此目标的首选方法是将原始“ Host”标头传递给TeamCity。另一种方法是将“ X-Forwarded-Host”标头设置为原始“ Host”标头值。

请注意,每当代理更改“主机”标头的值时(建议保留原始主机标头值),并且不提供具有原始主机值的“ X-Forwarded-Host”标头时,如果原始和引荐来源标头包含原始的主机标头值,则应进行对应映射(如果不包含原始标头和引荐标头,则不应设置它们,以便不避开TeamCity CSRF保护 )。

从下面的部分中选择适当的方法,并相应地配置代理。

TeamCity Tomcat配置

对于适当的TeamCity Tomcat配置,有两种选择:

  • 在服务器配置中使用带有硬编码公共URL详细信息的专用“连接器”节点 ,并确保仅对配置的公共URL的请求使用连接器中配置的端口。

  • 配置代理以传递适当的请求标头:“主机”或“ X-Forwarded-Host”(原始请求主机),“ X-Forwarded-Proto”(原始请求协议),“ X-Forwarded-Port”(原始请求端口)并为TeamCity Tomcat配置配置“ RemoteIpValve”

专用“连接器”节点方法

如果配置的端口仅接收对配置的公共URL的请求,则此方法可以与任何代理配置一起使用。

设置代理服务器以将所有请求重定向到teamcity.public:400到TeamCity服务器上的专用端口( 8111在下面的示例中)并在以下位置更改“ Connector”节点< TeamCity Home >/conf/server.xml文件如下。请注意,只能通过配置的代理地址访问以这种方式配置的“连接器”端口。如果您还想直接访问TeamCity端口,请使用单独的“连接器”节点和专用port价值。

当公共服务器地址为HTTPS时 ,请使用secure="true"scheme="https"属性。

“ RemoteIpValve”方法

当代理服务器将“ X-Forwarded-Proto”,“ X-Forwarded-Port”请求标头设置为原始URL的值时,可以使用此方法。同样,尽管对于大多数设置而言并不重要,但可以使用这种方法来确保将原始客户端IP正确传递到TeamCity服务器。这对于遗留代理的双向通信很重要。

添加以下到 Tomcat的主节点conf\server.xml文件(另请参见Tomcat doc ):

也建议指定internalProxies属性的正则表达式仅与代理服务器的IP地址匹配。例如internalProxies="192\.168\.0\.1"

为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起 ,可以使用以下服务器内部属性 (有关以前的版本,请参见下面的替代方法):

#对于HTTP协议##代理主机的域名或IP地址以及端口:teamcity.http.proxyHost = proxy.domain.com teamcity.http.proxyPort = 8080 ##无需通过访问即可访问的主机代理,通常是内部主机。提供主机列表,以“ |”分隔字符。可以使用通配符'*':teamcity.http.nonProxyHosts = localhost | * .mydomain.com)##对于经过身份验证的代理,请添加以下属性:###身份验证类型。支持“基本”和“ ntlm”值。默认值为基本。teamcity.http.proxyAuthenticationType =基本###代理的登录名和密码:teamcity.http.proxyLogin =用户名teamcity.http.proxyPassword =密码#对于HTTPS协议##代理主机的域名或IP地址以及端口:teamcity.https.proxyHost = proxy.domain.com teamcity.https.proxyPort = 8080 ##无需通过代理即可访问的主机,通常是内部主机。提供主机列表,以“ |”分隔字符。可以使用通配符'*':teamcity.https.nonProxyHosts = localhost | * .mydomain.com ##对于经过身份验证的代理,请添加以下属性:###身份验证类型。支持“基本”和“ ntlm”值。默认值为基本。teamcity.https.proxyAuthenticationType =基本###代理的登录名和密码:teamcity.https.proxyLogin =登录teamcity.https.proxyPassword =密码

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

-Dproxyset = true -Dhttp.proxyHost = proxy.domain.com -Dhttp.proxyPort = 8080 -Dhttp.nonProxyHosts = domain.com -Dhttps.proxyHost = proxy.domain.com -Dhttps.proxyPort = 8080 -Dhttps.nonProxyHosts = domain .com

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

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

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

##代理主机的域名或IP地址以及端口teamcity.http.proxyHost = 123.45.678.9 teamcity.http.proxyPort = 8080 ##如果代理服务器需要身份验证,请指定登录名和密码teamcity.http.proxyLogin =登录teamcity.http.proxyPassword =密码

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

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

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

更改服务器端口

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

升级前试用新版TeamCity版本

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

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

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

创建服务器副本

您可以使用TeamCity备份功能或手动创建服务器的副本。建议使用手动方法完成整个服务器的移动。

使用TeamCity备份

  1. 创建包括所有内容的备份 。(当您移动工件时,可以跳过备份构建日志的选项,请参见下文)。

  2. 安装与您已经在运行的相同版本的新TeamCity服务器。确保这件事:
  3. 恢复备份

  4. 通过移动以下内容移动工件(这些不包括在备份中) < TeamCity Data Directory >/system/artifacts目录从旧位置到新位置。由于工件的尺寸可能很大,因此可能要花费很多时间,因此请进行相应的计划。

  5. 执行必要的环境转移

手动复制

如果您不想使用捆绑的备份功能或需要对该过程进行手动控制,则以下是手动创建服务器副本所需执行的一般步骤:

  1. 创建备份,以便在出现任何问题时可以将其还原,

  2. 确保服务器未运行,

  3. 执行全新安装或复制TeamCity二进制文件( TeamCity Home Directory )移至新地方( tempwork子目录可以在复制过程中省略)。使用完全相同的TeamCity版本。如果您打算在复制后升级,请仅在现有版本启动并运行后执行升级。

  4. 复制< TeamCity Data Directory > 。如果不需要完整副本,请参阅以下各项以获取选项。
    • .BuildServer/config保留项目并建立配置设置

    • .BuildServer/lib.BuildServer/plugins如果你有他们

    • 来自根目录的文件.BuildServer/system如果您使用内部数据库,并且不想执行数据库移动。

    • .BuildServer/system/artifacts (可选)是否要在新服务器上保留构建工件和构建日志(包括测试失败详细信息)

    • .BuildServer/system/changes (可选)如果要在新服务器上保留个人更改

    • .BuildServer/system/pluginData (可选)如果您想保留各种插件的状态,请构建触发器和设置审计差异

    • .BuildServer/system/caches.BuildServer/system/caches (可选)无需复制到新服务器,它们将在启动时重新创建,但是可能需要一些时间才能重建(预计会变慢)。

  5. Artifacts目录通常很大,如果在服务器移动的情况下需要最大程度地减少服务器的停机时间,则可以使用通用方法来复制数据:使用rsync,robocopy或类似工具复制原始服务器时的数据运行。重复执行几次同步,直到同步的数据量减少。在原始服务器关闭后运行最终同步。服务器移动的替代解决方案是使新服务器可以访问旧数据工件目录,并将其配置为工件的第二个位置 。然后在服务器运行时将文件从第二个位置复制到主位置,复制完成后重新启动服务器。

  6. 创建在新架构或新数据库服务器中TeamCity安装正在使用的数据库的副本。可以使用特定于数据库的工具或捆绑的keepDB工具来完成此任务,方法是备份数据库数据,然后还原它。

  7. 配置新的TeamCity安装以使用正确的< TeamCity Data Directory >数据库.BuildServer/config/database.properties指向数据库的副本)

  8. 执行必要的环境转移

环境转移

如果已针对现有TeamCity安装进行了专门修改,请考虑转移相关环境。这可能包括:

  • 使用适当的OS用户帐户通过正确配置的设置,全局和文件系统权限运行TeamCity服务器进程

  • 使用相同的TeamCity进程启动选项 ,特别是从以下位置开始检查/复制环境变量TEAMCITY\_

  • 确保可以访问在TeamCity Web UI中使用绝对路径配置的任何文件/设置

  • 如果依靠操作系统级别的用户/机器设置(例如默认的ssh密钥,缓存的VCS访问凭据),也要进行传输

  • 考虑在网络配置等中复制与机器相关的任何特殊设置或例外。

  • 如果对TeamCity安装进行了任何修补(GrrovyPlug插件,用于MS SQL Server集成安全认证的本机驱动程序),请对安装副本进行相同的修改

  • 如果在操作系统启动时运行TeamCity(例如Windows服务),请确保在新计算机上执行相同的配置

  • 查看并转移设置中的< TeamCity Home >\conf\teamcity-startup.properties文件

  • 考虑以下任何自定义设置<TeamCity Home>\conf\server.xml

许可问题

单个TeamCity许可证不能同时在两个运行的服务器上使用。

  • 为冗余/备份目的而创建的服务器副本可以使用相同的许可证,因为一次只能运行其中一台服务器。

  • 为测试目的而创建的服务器的副本需要附加许可证。您可以从TeamCity官方下载页面中获得一次限时的TeamCity 评估许可证 。如果您需要扩展许可证或已经评估了相同的TeamCity版本,请联系我们的销售部门

  • 打算与主要服务器同时(出于生产目的)同时运行的服务器副本需要单独的许可证。

复制的服务器清单

如果要创建副本(而不是这种方式移动服务器),那么请仔细阅读以下清单:

  • 确保新服务器配置为使用与原始服务器不同的其他数据目录和数据库;还要检查服务器的全局设置上的“工件目录”设置;

  • 通过从XML的XML中删除“ uuid”属性来更改服务器唯一ID < TeamCity Data Directory >\config\main-config.xml第一次启动之前归档;

  • 确保在多个服务器上不使用相同的许可证密钥( 更多关于许可 );

  • 管理上更新服务器URL | 全局设置页面到服务器的实际URL;

  • 检查您是否可以在新服务器上成功进行身份验证,必要时使用超级用户访问权限;

  • 检查VCS服务器,问题跟踪服务器,电子邮件和Jabber服务器以及其他服务器访问的系统是否可访问;

  • 检查是否配置了任何将事件推送到TeamCity服务器的系统(例如VCS挂钩,自动生成触发,监视器等),以了解新服务器;

  • 查看已安装插件的列表,以确定是否需要更改其设置;

  • 安装新代理(或从现有代理中选择一些)并配置它们以连接到新服务器(使用新服务器URL);

  • 检查是否已重新配置从服务器读取的客户端(下载工件,使用服务器的REST API,NuGet feed等)。

如果要创建测试服务器 ,则需要确保用户和生产系统不受影响。通常,这意味着您需要:

  • 禁用电子邮件,Jabber(在“管理>通知程序”部分中),还可能禁用自定义通知程序,或更改其设置以防止新服务器发出通知;

  • 禁用电子邮件验证(在“管理>身份验证”部分中);

  • 确保不要运行任何会更改(例如部署到)生产环境的构建。这通常还包括部署到非本地存储库的Maven构建。您可以通过暂停构建队列来阻止任何构建;

  • 禁用云集成(以使其不干扰主服务器);

  • 禁用外部工件存储(否则运行/删除构建和服务器清理将影响生产服务器可能使用的存储);

  • 禁用Git注册表清理(或仅禁用服务器上的清理);

  • 禁用提交状态发布; *禁用基于TeamCity事件将数据推送到其他非复制系统的任何插件; *禁用将项目设置存储在VCS中的功能 :set teamcity.versionedSettings.enabled=false内部财产;

  • 考虑大幅增加VCS检查更改间隔 (服务器范围的默认值,并在VCS根目录中覆盖)或更改VCS根目录的设置,以防止它们联系生产服务器。从TeamCity 10.0.3开始,另请参见TW-47324

另请参阅以下有关将服务器从一台机器移动到另一台机器的部分。

将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 Data Directory >数据库应在任何给定时刻由单个TeamCity实例使用。如果您将新的TeamCity实例配置为使用相同的数据,请确保在启动新的TeamCity实例之前先关闭并禁用它。

通常,建议使用域名访问服务器(在代理配置中以及用户访问TeamCity Web UI时)。这样,您可以更新DNS条目以使地址解析为新服务器的IP地址,并且所有缓存的DNS结果过期后,所有客户端将自动使用新服务器。您可能需要提前减少更改之前的DNS服务器缓存/租赁时间,以使客户端快速“理解”更改。

但是,如果需要使用其他服务器域地址,则需要:

  • 将代理切换到新的网址(需要更新serverUrl财产buildAgent.properties在每个代理上)。如果要重新安装代理,但保留代理的名称和身份验证状态,则可以安装新的代理并复制conf\buildAgent.properties来自旧代理的文件(检查其中的所有路径是否已相应更新)。

  • 新服务器启动后,请记住在“ 管理” |“更新”上更新服务器URL全局设置页面。

  • 在新地址上通知所有TeamCity用户

  • 如果外部服务的设置取决于请求的原始地址,请考虑更新它们

将TeamCity Agent移至新计算机

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

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

  • 停止现有代理

  • 在新机器上安装新代理

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

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

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

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

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

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

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

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

%dep。 .system.build.number%

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

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

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

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

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

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

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

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

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

将Cucumber Reporter附加到Ant Build

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

< ....                                                                                                   

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

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

使用如下网址:

http:// / app / rest / buildTypes / id: / builds / status:SUCCESS / number

内部版本号将作为纯文本响应返回。
对于 ,请参阅标识符
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. 调试完成后,重新启用构建步骤。

漏洞

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

伤心欲绝,ShellShock

JetBrains提供的TeamCity发行版不包含软件/库,也不使用受Heart出血和Shell冲击漏洞影响的技术。仍需要评估的是特定的TeamCity安装实现,该实现可能使用JetBrains提供/推荐的组件后面的组件,并且可能容易受到上述漏洞的攻击。

泡菜

如果您配置了对TeamCity服务器的HTTPS访问,请检查用于HTTPS的解决方案,因为它可能会受到影响(例如Tomcat似乎受到影响 )。目前,TeamCity发行版中没有默认包含HTTPS访问权限,并且调查/消除与HTTPS相关的漏洞不在TeamCity的范围内。

根据使用的设置,TeamCity服务器(和代理)可以建立与其他服务器(例如Subversion)的HTTPS连接。根据服务器设置,这些连接可能会回退到使用SSL 3.0协议。推荐的解决方案不是特定于TeamCity的,而是要在目标SSL服务器端禁用SSLv3。

在glibc库中发现了CVE-2015-0235漏洞,TeamCity代码未直接使用该漏洞。在* nix平台下,TeamCity使用的Java / JRE使用它。由于Java没有与TeamCity发行版捆绑在一起,因此您应采用所用Java的供应商推荐的安全措施。目前,还没有发布相关的Java特定安全公告,因此更新OS应该足以消除漏洞利用的风险。

怪物

在OpenSSL实施中发现了CVE-2015-0204漏洞。TeamCity不捆绑OpenSSL产品的任何部分,因此不容易受到攻击。您可能仍需要查看设置TeamCity服务器和代理的环境,以及除TeamCity之外安装的工具,以采取可能的漏洞缓解步骤。

Apache Struts

CVE-2017-5638影响Apache Struts中的Jakarta Multipart解析器。CVE-2016-1181还影响某些旧版Apache Struts中的多部分请求处理。

TeamCity捆绑了IntelliJ IDEA,其中包含来自以下两个版本的jar:Apache Struts 1.x和Apache Struts2.x。仅当IntelliJ IDEA收集TeamCity代理上的项目检查时,IntelliJ IDEA Struts插件才使用这些jar。

在任何情况下,这些版本的Apache Struts都不用于处理任何HTTP请求。因此,TeamCity服务器和TeamCity代理均不受这些漏洞的影响。

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

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

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

JetBrains。TrayNotifier.exe / allowMultiple

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

JetBrains。TrayNotifier.exe / allowMultiple / server:http:// myTeamCityServer

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

个人用户数据处理

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

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

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

TeamCity和用户的个人数据

TeamCity存储的最重要的与用户相关的数据是:

  • 全名和用户名-存储在数据库中,并在用户的个人资料中以及在引用用户时显示。当用户触发构建时,这些也会存储在构建的参数中并传递到构建中

  • 用户的电子邮件-存储在数据库中并显示在用户的个人资料中,用于发送通知

  • 访问服务器的客户端的IP地址-可以显示在内部日志中

TeamCity内部日志还可以记录一些非结构化的用户相关信息(例如,由用户提交或由浏览器发送的HTTP请求,这些请求是根据已配置的设置从LDAP等用户源中检索的)

删除用户数据

当您要删除特定用户的个人数据时,最好的方法是在TeamCity中删除该用户。这样,所有对用户的引用将继续存储数字用户ID,而不再存储所有其他用户信息。请注意,删除用户后, 审核记录将提及内部数字用户ID。

如果用户触发了任何构建(即在服务器上仍然存在的任何项目中都具有“运行构建”权限),则用户的用户名和全名将记录为构建的“ teamcity.build.triggeredBy”参数中,如下所示:作为构建“环境”一部分的文本值。如果需要删除它们,则可以删除相关的内部版本(以及所有依赖于工件或快照的内部版本),也可以删除那些受影响的内部版本的参数(这些参数存储在\ system \ artifacts下的存档文件中) ***。teamcity \ properties目录)。

删除用户并清除其他数据后,请确保将搜索索引重置为从搜索索引中删除已删除用户的可能缓存数据。

还有其他几个地方可以保存与用户相关的数据

如果用户具有“编辑项目”权限,则全名/用户名可以显示在:

  • 一些审核条目(在2017.2.1之前与TeamCity版本一起保存)-TW -52215

  • “等待等待的持久性任务完成”构建日志行中的一些构建日志(与2017.2.1之前的TeamCity版本一起保存)-TW -52872

  • 在存储版本化设置的存储库中提交注释,该版本存储了在UI中进行更改的用户的名称

与VCS相关的数据中的VCS用户名:

  • VCS中的更改在UI中可见或存储在数据库中

  • 服务器和代理上的本地.git存储库中的克隆

用户名也可以出现在以不同集成方式配置的访问凭据中,例如VCS根目录,问题跟踪器,数据库访问等。(这些存储在TeamCity数据目录中的设置文件和审核差异文件中,而VCS根用户名也存储在数据库中用于VCS根目录的当前版本和先前版本)

为确保TeamCity不存储用户的详细信息,您可能需要检查TeamCity支持的存储,以确保未存储任何数据:数据库,数据目录和TeamCity主目录(日志和内存转储,通常放置在“ bin”目录)。

用户协议

如果您希望用户在使用TeamCity实例之前接受特殊协议,则可以安装JetBrains为此目的开发的专用插件 。有关更多详细信息,请参阅插件的文档。

加密

如果您想对TeamCity使用的数据进行加密,则建议为此使用非TeamCity的通用工具,因为TeamCity不提供专用功能。TeamCity将数据存储在SQL数据库和文件系统中。您可以将数据库配置为以加密形式存储数据,并使用安全的JDBC支持的数据库连接(在database.properties )。
另外,您可以在操作系统级别的磁盘存储上配置加密。

日志和调试数据

如果要确保内部TeamCity日志的存储时间不超过有限的几天,可以将内部日志配置为每天轮换日志文件并限制要保留的文件数量。TeamCity代理通常不会以结构化方式处理任何与用户相关的数据,但是如果需要确保日志在代理上定期轮换,则需要以相同的方式配置代理日志

每天轮播可以通过添加配置所有必填项中的行追加器。将此更改更改为默认值conf\teamcity-server-log4j.xml并记录存储在下面的预设\config\_logging

TeamCity还可以存储诊断数据,例如线程转储,可以以非结构化方式记录与用户相关的数据。建议检查一下内容< TeamCity Home >\logs定期目录,并确保其中不保留任何旧文件。另外,在记录定制会话(例如收集调试日志等)之后,应删除多余的日志。存在一个已知问题 logs\catalina.out文件,如果根本没有自动旋转。建议建立自动程序以定期旋转文件。

客制化

这些说明仅介绍捆绑的TeamCity功能以及最常见的记录设置。您应该考虑特定的定制来评估特定的TeamCity安装,例如配置的构建脚本,已安装的插件,通过API与TeamCity通信的外部系统等。

TeamCity发布周期

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

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

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

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

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

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

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

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