TeamCity 2020.1ヘルプ

使い方...

TeamCityサーバーのOS /プラットフォームの選択

Once the server/OS fulfills the requirements, TeamCity can run on any system. Please also review the requirements for the integrations you plan to use, for example the following functionality requires or works better when TeamCity server is installed under Windows:

  • TFSとVCSの統合

  • VSSとVCSの統合

  • Windowsドメインログイン（Linuxでも動作しますが、不安定になる可能性があります）、特にNTLM HTTP認証

  • サーバー上のNuGetフィード (Linuxでも動作しますが、安定していない可能性があります。)

  • Windowsマシンへのエージェントプッシュ

嗜好がない場合は、Linuxプラットフォームがより効果的なファイルシステム操作と必要な一般的なOSメンテナンスのレベルのためにさらに望ましいかもしれません。

最終的なオペレーティングシステムの選択は、おそらく、組織内で利用可能なリソースと確立されたプラクティスにより左右されるはずです。

TeamCityのハードウェア要件の推定

ハードウェア要件はサーバーとエージェントで異なります。

The agent hardware requirements are basically determined by the builds that are run. Running TeamCity agent software introduces a requirement for additional CPU time (but it can usually be neglected comparing to the build process CPU requirements) and additional memory: about 500Mb. The disk space required corresponds to the disk usage by the builds running on the agent (sources checkouts, downloaded artifacts, the disk space consumed during the build; all that combined for the regularly occurring builds). Although you can run a build agent on the same machine as the TeamCity server, the recommended approach is to use a separate machine (it may be virtual) for each build agent. If you chose to install several agents on the same machine, consider the possible CPU, disk, memory or network bottlenecks that might occur. The パフォーマンスモニター build feature can help you in analyzing live data.

サーバーのハードウェア要件はサーバーの負荷に依存します。サーバーの負荷は、ビルドのタイプとサーバーの使用状況に大きく依存します。以下の一般的なガイドラインを考慮してください。

データベースノート :
サーバーを広範囲に使用すると、データベースのパフォーマンスがより大きなロールを果たすようになります。
信頼性とパフォーマンスの理由から、外部データベースを使用する必要があります。
外部データベースの選択に関する注記を参照してください。
データベースサイズの要件は、保存されるデータの量（ビルド数、テスト数など）に応じて当然異なります。アクティブなサーバーデータベースの使用量は、年間数ギガバイトのデータと推定できます。

TeamCityハードウェアリソース使用量の概要：

  • CPU：TeamCityはCPUの複数のコアを使用するため、コアの数を増やすことは理にかなっています。自明ではないTeamCityを使用するには、少なくとも4つのCPUコアをお勧めします。

  • メモリ：TeamCityサーバーのメインプロセスと子プロセスで使用（Maven統合、バージョン管理統合、Kotlin DSL実行に使用）。メインプロセスのメモリ使用量に関する注意を参照してください。一般に、100を超える同時ビルド（エージェント）の実行、200人を超えるオンラインユーザーのサポート、または大規模なリポジトリの使用を計画していない場合は、おそらく4Gを超えるメモリをTeamCityサーバー専用にする必要はないでしょう。

  • HDD /ディスク使用量：これは、主に一時ディレクトリの使用量（<[TeamCity Home](teamcity-home-directory.md)>/temp およびOSのデフォルトの一時ディレクトリ）と <[TeamCity Data Directory](teamcity-data-directory.md)>/system の使用量を合計したものです。TeamCityサーバーのパフォーマンスは、ディスクシステムのパフォーマンスに大きく依存します。TeamCityは <[TeamCity Data Directory](teamcity-data-directory.md)>/system に大量のデータを保存するため（特に、VCSキャッシュとビルド結果）、ディスクへのアクセスが高速であることを確認することが重要です（特に、複数のスレッドでのファイルの読み取り/書き込み、属性付きのファイルのリスト）。データドライブをネットワークドライブに保存する場合は、ディスクのパフォーマンスを保証することが特に重要です。 TeamCity Data Directory/system/caches ディレクトリにはローカルストレージを使用することをお勧めします。TeamCityデータディレクトリも参照してください。

  • ネットワーク：これは主に、VCSサーバーからのトラフィック、クライアント（Webブラウザ、IDEなど）、およびビルドエージェントへの/からのトラフィック（ソースの送信、ビルド結果の受信、ログ、およびアーティファクト）の合計です。

サーバーの負荷は次の要素によって異なります。

  • ビルド構成の数

  • 履歴内のビルド数。

  • 毎日実行されているビルドの数。

  • ビルドによって消費および生成されたデータの量（使用されたソースとアーティファクトのサイズ、ビルドログのサイズ、ユニットテストの数と出力サイズ、インスペクションと重複のヒット数、生成されたアーティファクトのサイズと数など） ;

  • 構成されたクリーンアップルール

  • エージェントの数とその使用率

  • TeamCity Webページを開いているユーザーの数。

  • IDEプラグインからログインしたユーザー数。

  • VCSルートの数とタイプ、およびVCSルートの変更間隔の設定済みチェック。VCSチェックアウトモードも関連性があります。サーバーチェックアウトモードはより大きなサーバー負荷を生成します。特定の種類のVCSもサーバーの負荷に影響しますが、ネイティブのVCSクライアントのパフォーマンスに基づいて概算できます。

  • すべてのVCSルートで1日にTeamCityによって検出された変更の数。

  • TeamCityが使えるリポジトリのサイズ。

  • 毎日TeamCityによってチェックアウトされたソースの合計サイズ。

最大100の同時実行ビルドを処理でき、TeamCityサーバーのみを実行できるハードウェア構成の一般的な例は、次のとおりです。
サーバーに適した最新のマルチコアCPU、8 GBのメモリ、高速ネットワーク接続、高速で信頼性の高いHDD、高速外部データベースアクセス。

経験に基づいて、Intel 3.2 GHzデュアルコアCPU、Windows下の3.2 GBメモリ、1 GBネットワークアダプタ、シングルHDDのような控えめなハードウェアは、以下のセットアップで許容できるパフォーマンスを提供できます。

  • 60のプロジェクトと300のビルド構成（1つはアクティブで定期的に実行中）。

  • 1日に300を超えるビルドが行われます。

  • 1ビルドあたり約2Mbのログ。

  • 50人のビルドエージェント。

  • 50人のWebユーザーと30人のIDEユーザー。

  • 100個のVCSルート（主にサーバーチェックアウトを使用したPerforceおよびSubversion）、変更間隔の平均チェックは120秒です。

  • 1日150回以上の変更

  • Kotlin DSLは使用されていません。

  • データベース（MySQL）が同じマシン上で稼働しています。

  • TeamCityサーバープロセスには -Xmx1100m JVM設定があります。

次の構成は、より負荷の高いTeamCityサーバーに許容できるパフォーマンスを提供できます。
Intel Xeon E5520 2.2 GHz CPU（4コア、8スレッド）、Windows Server2008R2 x64で12Gbメモリ、1Gbネットワークアダプター、3 HDD RAID1ディスク (一般に、成果物、ログおよびキャッシュ記憶域用、データベース記憶域用)

サーバー負荷特性

  • 150のプロジェクトと1500のビルド構成（3分の1がアクティブで、定期的に実行されています）。

  • 1日に1500以上のビルドがあります。

  • ビルドごとに約4Mbのログ。

  • 100のビルドエージェント

  • 150人のWebユーザーと40人のIDEユーザー。

  • 250のVCSルート（主にエージェント側のチェックアウトを使用するGit、Hg、Perforce、およびSubversion）、変更間隔の平均チェックは180秒です。

  • 1日あたり1000回以上の変更。

  • データベース（MySQL）が同じマシン上で稼働しています。

  • TeamCityサーバープロセスには -Xmx3700m x64 JVM設定があります。

ただし、ピーク負荷を適切に処理できるように、より強力なハードウェアをお勧めします。

HDDの空き容量の要件は、主にサーバーに保存されているビルド数とそれぞれのアーティファクトサイズ/ビルドログサイズによって決まります。サーバーのディスク記憶域はVCS関連のキャッシュの保存にも使用され、サーバー上に設定されているすべてのVCSルートのチェックアウトサイズを2倍にすることができます。

ビルドによって大量のデータ（成果物/ビルドログ/テストデータ）が生成される場合は、.BuildServer/system ディレクトリの格納に高速ハードディスクを使用し、エージェントとサーバー間の高速ネットワークを使用することをお勧めします。

The general recommendation for deploying large-scale TeamCity installation is to start with a reasonable hardware while considering hardware upgrade. Then increase the load on the server (e.g. add more projects) gradually, monitoring the performance characteristics and deciding on necessary hardware or software improvements. There is also a benchmark plugin(英語) which can be used to estimate the number of simultaneous build the current server installation can handle. Anyway, best administration practices are recommended like keeping adequate disk defragmentation level, and so on.

適切にロードされたシステムから始めて、同時に実行中のビルド（エージェント）の数を何らかの要因で増やす場合は、CPU、データベース、およびHDDのアクセス速度、メモリの量を同じ要因で増やして、同じパフォーマンスを実現する準備をしてください。
1日あたりのビルド数を増やす場合は、ディスクサイズを増やす準備をしてください。

TeamCityエージェントのクラウドデプロイ（たとえば、Amazon EC2上）を検討する場合は、Amazon EC2用のTeamCityのセットアップも検討してください。

JetBrains内部TeamCityインストールでのエージェントのセットアップに関するメモ：
それぞれが単一のエージェントを実行する個別のマシンと、それぞれに単一のエージェントがインストールされている複数の仮想マシンを実行する専用の「サーバー」の両方を使用します。各core7i物理マシンが3つの仮想エージェントを実行し、それぞれが個別のハードディスクを使用する場合、ハードウェアとソフトウェアを試して構成を決定しました。これは、私たち（主にJava）のビルドがそもそもHDDのパフォーマンスに依存しているという事実から生じています。しかし、YMMV。

TeamCityは、500+ビルドエージェント（500の同時実行ビルドがアクティブにビルドランタイムデータをログに記録する）でうまく機能することが知られています。総合テストでは、サーバーは1000もの同時ビルドで正常に機能していました（8コアのサーバー、32Gbの合計メモリをLinuxで実行し、MySQLサーバーを別の同等のマシンで実行）。各ビルドによって生成されるサーバーの負荷は、ビルドが生成するデータの量（ビルドログ、テスト数と失敗の詳細、インスペクション /重複課題数など）によって異なります。データの量を適度に制限する（大量の出力をビルドアーティファクトとして発行し、標準出力に出力しないでください。インスペクションプロファイルを調整して、最も重要なインスペクションヒットの限られたセットを報告するなど）は、サーバーをスケーリングして、より多くの同時ビルドを処理できるようにします。
さらに多くのエージェント/並列ビルドが必要な場合は、いくつかのノードのセットアップを使用することをお勧めします。かなり大量のエージェントが必要な場合は、いくつかの個別のTeamCityインスタンスを使用して、それらの間でプロジェクトを分散することを検討することをお勧めします。常にTeamCityのパフォーマンス改善に取り組んでおり、大規模なTeamCityインストールを実行している組織と緊密に連携してパフォーマンスの課題を調査し、より大きな負荷を処理するようにTeamCityを改善します。TeamCityが処理できるエージェント(英語)の最大数(英語)に関する関連記事も参照してください。

関連する投稿も参照してください： 実質的なTeamCityセットアップの説明(英語)。

サーバーとエージェント間のネットワークトラフィック

一部のエージェントとサーバー間のバイナリ転送を含むため、トラフィックはほとんど設定に依存します。
エージェントとサーバー間のトラフィックの最も重要なフローは次のとおりです。

  • エージェントはサーバーからコマンドを取得します。これらは通常、ビルド構成設定のダンプとビルドパラメーターのフルセットを含むビルド開始タスクです。ラージビルドチェーンの場合、後者は大きくなることがある（たとえばメガバイト）。パラメータはビルドのパラメータタブで確認できます。

  • エージェントは、現在のステータスデータを定期的にサーバーに送信します（これには、エージェントのエージェントパラメータタブで確認できるすべてのエージェントパラメータが含まれます）。

  • ビルド中に、エージェントはビルドログメッセージとパラメータデータをサーバーに返送します。これらはビルドのビルドログとパラメータータブで確認できます。

  • （サーバー側のチェックアウトモードが使用されている場合）エージェントはビルドの前に（フルまたは増分パッチとして）サーバーからソースをダウンロードします。

  • （ 成果物依存関係が構成されている場合）エージェントは、ビルドを開始する前に、サーバーから他のビルドのビルド成果物をダウンロードします。

  • （成果物がビルド用に構成されている場合）エージェントはビルド成果物をサーバーにアップロードします。

  • 一部のランナー（報道やコード分析など）には、結果レポートのサーバーへの自動アップロードが含まれています。

パフォーマンスのためのTeamCityサーバーの設定

Here are some recommendations to tweak TeamCity server setup for better performance. The list for production server use is a prerequisite:

  • 報告されたServer Healthレポートを定期的に確認する (隠されたものを含む)

  • HTTPSを処理するために別のリバースプロキシサーバー（たとえばNGINX）を使用する

  • 外部データベースに別のサーバーを使用してデータベースのパフォーマンスを監視する

  • サーバーのCPUとIOのパフォーマンスを監視し、必要に応じてハードウェアリソースを増やす (see also hardware notes)

  • クリーンアップがすべてのプロジェクトに対して適切な保存方針で構成されていることを確認し、クリーンアップが完全に定期的に終了することを確認する (管理/クリーンアップページを確認してください)

  • <[TeamCity Data Directory](teamcity-data-directory.md)>/system/caches ディレクトリの良好なIOパフォーマンスを確保することを検討してください。別のローカルドライブに移動する (またはTeamCity Data Directoryをネットワークストレージに保存することを選択したローカルドライブに保存する)

  • 古くなったプロジェクトを定期的にアーカイブする

  • インストールされていないバンドルされていないプラグインを定期的に確認し、サーバーの機能に不可欠ではないプラグインを削除します。

  • できるだけエージェントサイドのチェックアウトを使用することを検討してください

  • ビルドログが大きくないことを確認してください (せいぜい数十メガバイト、10メガバイト以下)

  • 多数のVCSルートがサーバー上で構成されている場合は、変更のポーリングを使用する代わりにリポジトリコミットフックを構成するか、少なくともVCSポーリング間隔を300秒以上に増やすことを検討してください。

  • サーバーが多数のユーザー（たとえば1000人以上）によって使用されることが多い場合は、UIリフレッシュ間隔を増やしてバックグラウンドUI要求の頻度を減らすことを検討してください。

  • 大量のデータを記録する500を超える同時実行ビルドを定期的に超える場合は、いくつかのノード設定の使用を検討してください。

管理者パスワードを取得する

On the first start with the empty database, TeamCity displays the Administrator Setup page which allows creating a user with full administrative permissions (assigning the System Administrator role).

If you want to regain access to the system and you cannot log in as a user with the System Administrator role, you can log in as a super user and change the existing administrator account password or create a new account with the System Administrator role.

It is also possible to use REST API to add the System Administrator role to any existing user.

If you use built-in authentication and have correct email specified, you can reset the password from the login page.

Estimate External Database Capacity

It is quite hard to provide the exact numbers when setting up or migrating to an external database, as the required capacity varies greatly depending on how TeamCity is used.

The database size and database performance are crucial aspects to consider.

Database Size

The size of the database will depend on:

  • how many builds are started every day

  • how many test are reported from builds

  • clean-up rules (retention policy)

  • clean-up schedule

We recommend the initial size of data spaces to be 4 GB. When migrating from the internal database, we suggest at least doubling the size of the current internal database. For example, the size of the external database (without the Redo Log files) of the internal TeamCity server in JetBrains is about 50 GB. Setting your database to grow automatically helps to increase file sizes to a pre-determined limit when necessary, which minimizes the effort to monitor disk space.

Allocating 1 GB for the redo log (see the table below) and undo files is sufficient in most cases.

Database Performance

The following factors are to be taken into account:

  • type of database (RDBMS)

  • number of agents (which actually means the number of builds running in parallel)

  • number of web pages opened by all users

  • clean-up rules (retention policy)

It is advised to place the TeamCity Data Directory 物理的に異なるハードディスク上のデータベースデータファイル（TeamCityサーバーとRDBMSの両方が同じホストを共有する場合でも）。

特に多数のエージェント（50人以上）がいる場合は、REDOログを別の物理ディスクに配置することをお勧めします。

データベース固有の考慮事項

異なるRDBMSのREDOログ（または類似のエンティティ）の命名：

RDBMS

ログ名

Oracle

やり直しログ

MS SQL Server

トランザクション・ログ

PostgreSQL

WAL (先読みログ)

MySQL + InnoDBとPercona

やり直しログ

PostgreSQL：多くのクエリ最適化機能を備えた9.2+バージョンを使用することをお勧めします。PostgreSQLのドキュメント(英語)の先行書き込みログ（WAL）に関する情報も参照してください

Oracle：統計をオンにしておくことをお勧めします。自動的に収集された統計はすべて有効にする必要があります（Oracle 10.0以降、これがデフォルトの設定です）。Oracleのドキュメント(英語)のREDOログファイルに関する情報も参照してください。

MS SQL Server:jTDSドライバを使用することはお勧めできません。nchar/nvarcharでは機能しません。また、Unicodeストリームを維持するために、クエリに時間がかかり、大量のIOを消費する可能性があります。マイクロソフトサポート技術情報(英語)のREDOログに関する情報も参照してください。jTDSを使用している場合は、移行してください。

MySQL：クエリオプティマイザは非効率的かもしれません。クエリによっては間違った実行計画を取得して長い時間がかかり、大量のIOを消費することがあります。

必要なビルドエージェントの数を引用もる

正確なデータはなく、必要なビルドエージェントの数は、サーバーの使用パターン、ビルドのタイプ、チームのサイズ、CIプロセスへのチームのコミットメントなどに大きく依存します。
最善の方法は、デフォルトの3つのエージェントから始めて、構成されたプロジェクトでどのように機能するかを確認し、それに基づいてさらに引用もることです。

次のような場合は、エージェントの数を増やすことをお勧めします。

  • ビルドキュー内のアイドル状態のエージェントを待ってビルドします。

  • 各ビルドに含まれている変更の数が、快適ではないと思われます（ビルド失敗の分析など）。

  • 異なる環境での必要性。20のビルド構成（ビルドのタイプ）ごとにエージェントが存在するパターンを見てきました。または、1-2人の開発者ごとのビルドエージェント。

サポートされるエージェントの最大数に関する注意も参照してください。

レプリケーション/クラスタリング環境でのTeamCityの設定

TeamCityはメインサーバーの単一インスタンスのみをサポートしますが、現在のデータに対して表示専用のUIを提供し、エージェントから実行中のビルドデータを収集するためにセカンダリノードを追加することは可能です。すべてのノードが同じ TeamCity Data Directory とデータベースに接続されている必要があります。

高速災害復旧シナリオに対応するために、TeamCityはアクティブ - フェイルオーバー（コールドスタンバイ）アプローチをサポートしています。TeamCityサーバーが使用するデータを複製し、現在アクティブなサーバーが故障した場合は同じデータを使用して新しいサーバーを起動するソリューションを導入できます。

データに関しては、TeamCityサーバーはデータベースとファイルストレージ（データディレクトリ）の両方を使用します。TeamCityデータのバックアップおよびTeamCityデータディレクトリページを参照して、TeamCityデータの保存に関する詳細情報を取得できます。基本的に、ディスク上のTeamCityデータディレクトリとTeamCityが使用するデータベースの両方が一貫した状態を維持している必要があるため、一緒に複製する必要があります。
常に1つのTeamCityサーバーインスタンスのみがデータベースとデータディレクトリを使用する必要があります。

TeamCityフェイルオーバー/バックアップサーバーのディストリビューションが、メインサーバーとまったく同じバージョンであることを確認してください。メモリ設定など、同じサーバー環境/起動オプションを確保することも重要です。

TeamCity agents farm can be reused between the main and the failover servers. Agents will automatically connect to the new server if you make the failover server to be resolved via the old server DNS name and agents connect to the server using the DNS name. See also information on switching from one server to another.
If appropriate, the agents can be replicated just as the server. However, there is no need to replicate any TeamCity-specific data on the agents except for the conf\buildAgent.properties file as all the rest of the data can typically be renewed from the server. In case of replicated agents farm, the replica agents just need to be connected to the failover server.

冗長性の目的で2台のサーバーをインストールする場合、どちらか一方のみが実行されているため、同じライセンスセットを使用できます。

TeamCityセキュリティノート

以下の注意はあなたの参考のためにのみ提供されており、完全なものでも正確なものでもありません。

TeamCityは、セキュリティ上の懸念を念頭に置いて開発されており、さまざまな種類の攻撃に対してシステムを無防備にするための合理的な努力が払われています。セキュリティスキャナーと侵入テストを使用して、TeamCityのセキュリティを評価するためにサードパーティと協力しています。
最新のTeamCityメジャーバージョンの最も近いバグ修正リリースで新たに発見されたセキュリティ課題に迅速に対処することを目指しています。
ただし、TeamCityを悪意のあるユーザーがアクセスできないように信頼できる環境にデプロイすることが一般的な前提であり、推奨される設定です。

これらのガイドラインと共に、TeamCityサーバーを本番環境で使用するための構成に関する注意事項を確認してください。公開されているセキュリティ関連の課題のリストについては、公開課題トラッカー(英語)とリリースノートの「セキュリティ」セクションを参照してください。セキュリティ関連の修正が含まれている可能性があるため、利用可能になり次第、新しくリリースされたTeamCityバージョンにアップグレードすることをお勧めします。

TeamCity 2017.2以降、TeamCity WindowsインストーラーはTeamCityインストールディレクトリの権限を変更して、継承可能なアクセス許可を使用しないようにし、ディレクトリへのアクセスをAdministratorsユーザーグループと、サービスを実行するように構成されているアカウントに明示的に許可することに注意してください。
同じ方法で、 TeamCity Data Directory へのアクセス許可を制限することを強くお勧めします。

追加のセキュリティ関連設定

teamcity.installation.completed=true 行を <[TeamCity Home Directory](teamcity-home-directory.md)>\conf\teamcity-startup.properties ファイルに追加することを検討してください。これにより、空のデータベースで起動されたサーバーが、最初に来るユーザーにマシンへのアクセスを許可しなくなります。

TeamCityにはDoS（サービス拒絶）攻撃に対する保護機能が組み込まれていません。リクエストが頻繁に発生するとサーバーがオーバーロードになり、応答しなくなる可能性があります。TeamCityインスタンスがそのようなサービスの悪用を許可する環境にデプロイされている場合は、リバースプロキシレベルで保護を実装してください。

短いチェックリスト (全文は下記を参照)

  • 最新のTeamCityバージョンを実行しており、数週間以内に新しくリリースされたバージョンにアップグレードする準備が整いました

  • TeamCity WebインターフェースへのアクセスはHTTPSを使用して保護されています（たとえばNGINXのようなプロキシサーバーの助けを借りて）。Webアプリケーションを保護するためのベストプラクティスは、TeamCity Webインターフェースに採用されています。例：HTTPプロトコルを使用してサーバーにアクセスすることは不可能です。リバースプロキシがRefererリクエストヘッダを削除しない

  • TeamCityサーバーマシンはエージェントを実行しません (少なくとも <[TeamCity server's home directory](teamcity-home-directory.md)> および <[TeamCity Data Directory](teamcity-data-directory.md)>の読み取りを許可されたユーザーの下 )

  • TeamCityサーバーとエージェントのプロセスは、最小限の必要な権限で制限されたユーザーで実行されます。インストールディレクトリは、限られたOSユーザーのセットのみが読み取りおよび書き込みできます。 conf\buildAgent.properties ファイルとサーバーログ、およびデータディレクトリは、サービスの管理者を表すOSユーザーのみが読み取ることができます。これらの場所を読み取ると、エージェントまたはサーバーをそれぞれ引き継ぐことができるためです。

  • ゲストユーザーおよびユーザー登録が無効になっているか、ゲストおよびすべてのユーザーグループのロールが見直されている

  • 管理者権限を持つTeamCityユーザーは重要なパスワードを持っています

  • LDAPなどの外部認証が設定されている場合、組み込み認証モジュールは無効になります。

  • Passwords are not printed into the build log, not stored in build artifacts, nor are they stored in non-password parameters

セキュリティ関連のリスク評価

セキュリティ関連のさまざまな側面についてのいくつかのメモがあります。

  • 中間者の懸念

    • between the TeamCity server and the user's web browser: It is advised to use HTTPS for the TeamCity server. During login, TeamCity transmits the user login password in an encrypted form with a moderate encryption level.

    • TeamCityエージェントとTeamCityサーバーの間： このセクションを参照してください。

    • TeamCityサーバーと他の外部サーバー（バージョン管理、課題トラッカーなど）の間：外部サーバーに接続するクライアント（この場合TeamCityサーバー）に関して一般的な規則が適用されます。課題のサーバーのためのガイドラインを参照してください。

  • users that have access to the TeamCity web UI: the specific information accessible to the user is defined via TeamCity user roles.

  • TeamCityによって実行されるビルドで使用されるコードを変更できるユーザー（TeamCityでビルドされている場合はブランチ / pull要求のコミッターも含む）：

    • TeamCityエージェントが実行されているシステムユーザーが実行できるすべてのことを実行できます。ビルドを実行できるエージェントマシンにインストールされているOSリソースおよびその他のアプリケーションにアクセスできます。

    • 同じエージェント上でビルドされた他のプロジェクトのソースコードにアクセスして変更したり、TeamCityエージェントコードを変更したり、ビルド用の成果物として任意のファイルをエージェント上で実行したりできます（つまり、TeamCity Web UIに表示してWebを公開できます）脆弱性または他のビルドで使用することができます）、など

    • TeamCityエージェントになりすますことができます（TeamCityサーバーと同じように見える新しいエージェントを実行します）。

    • サーバー上のすべてのプロジェクトに対して「ビルド構成設定の表示」権限を持つユーザーができることはすべて実行できます（下記参照）。

    • パスワードフィールドの値を含む、ビルドが実行されるビルド構成の設定を取得できます。

    • can download artifacts from any build on the server.
      Hence, it is advised to run TeamCity agents under an OS account with only necessary set of permissions and use the agent pools feature to ensure that projects requiring a different set of access are not built on the same agents.

  • 「ビルド構成設定の表示」権限（デフォルトでは「プロジェクト開発者」TeamCityロール）を持つユーザーは、サーバー上のすべてのプロジェクトを表示できますが、TeamCity 9.0ではこれを制限する方法があるため、対応する課題TW-24904(英語)の詳細を参照してください。

  • 1つのプロジェクトで「プロジェクトの編集」権限（デフォルトでは「プロジェクト管理者」TeamCityロール）を持つユーザーは、設定を変更することで、成果物を取得し、表示権限のみを持つビルド構成からビルドをトリガーできます（TW-39209(英語)）。また、ユーザーはTeamCityサーバーにサーバー上の任意の実行可能ファイルを実行させることができます。

  • "サーバー設定の変更"権限を持つユーザー（デフォルトでは "システム管理者" TeamCityロール）：ユーザーは、サーバープロセスの実行に使用されるユーザーアカウントでTeamCityサーバーが実行されているコンピューターにもアクセスできると見なされます。ユーザーはそのOSユーザーアカウントでマシンへのフルアクセスを得ることができます。ファイルシステムの閲覧、ファイルの変更、任意のコマンドの実行など。

  • TeamCityサーバーコンピューター管理者：TeamCity保存データへのフルアクセスを持ち、TeamCity実行プロセスに影響を及ぼす可能性があります。外部システム（VCS、課題追跡システムなど）で認証するために必要なパスワードは、TeamCityデータディレクトリにスクランブル形式で保存され、データベースに保存することもできます。ただし、値はスクランブルされているだけなので、サーバーファイルシステムまたはデータベースにアクセスできるすべてのユーザーが値を取得できます。

  • TeamCityサーバーログ（TeamCityサーバーホームディレクトリ）への読み取りアクセス権を持つユーザーは、TeamCityサーバー管理者へのアクセス権を段階的にプルアップすることができます。

  • <[TeamCity Data Directory](teamcity-data-directory.md)> への読み取りアクセス権を持つユーザーは、構成されたパスワードを含むサーバーのすべての設定にアクセスできます。

  • <[TeamCity Data Directory](teamcity-data-directory.md)>/system/artifacts のビルドアーティファクトへの読み取りアクセス権を持つユーザーは、「ビルドランタイムパラメーターとデータの表示」を持つユーザーと同じ権限を取得します。権限（特に、ビルドで使用されるすべてのパスワードパラメータの値へのアクセス権）。

  • TeamCityエージェントのコンピューター管理者：「TeamCityによって実行されるビルドで使用されるコードを変更できるユーザー」と同じです。

  • 1つのTeamCityエージェントが、開発者と管理者が互いのプロジェクトにアクセスできないようにする複数のプロジェクトのビルドを実行しないように、プロジェクトをエージェント間で分散することをお勧めします。プロジェクトを配布するための推奨される方法は、エージェントプール機能を使用し、特定の再設定後にプロジェクトをデフォルトプールに割り当てることができるように「デフォルト」エージェントプールにエージェントがないようにすることです。に割り当てられています。

  • 設定をVCSに保存することが有効になっている場合：

    • 設定リポジトリにアクセスできるすべてのユーザー（同じVCSルートを使用してビルド設定の「ファイル内容の表示」権限を持つユーザーを含む）は、設定を確認し、保存されているスクランブル形式に基づいて実際のパスワードを取得できます。

    • 設定の変更を介して、サーバー上に構築された単一のビルド構成用にVCSの設定を変更できるユーザーは、表示権限のみを持つすべてのビルド構成から成果物を取得してビルドをトリガーできます（TW-39192(英語)）。

    • ビルドの設定を変更することで、ビルドごとにビルド構成設定をカスタマイズできるユーザー（バージョン対応の設定が「VCSの設定を使用する」に設定されているときに個人用ビルドを実行できるユーザーなど）それらは（TW-46065(英語)）の表示権限のみを持っています。

  • その他:

    • TeamCity Webアプリケーションの脆弱性：TeamCity開発チームは、発見された重大な脆弱性（クロスサイトスクリプティングの可能性など）を修正するために妥当な努力をします。ビルドファイルに影響を与える可能性のあるユーザー（「TeamCityによって実行されるビルドで使用されるコードを変更できるユーザー」または「TeamCityエージェントのコンピューター管理者」）は、悪意のあるファイルをビルドアーティファクトとして利用できるようにすることに注意してください。クロスサイトスクリプティングの脆弱性を不正利用します。( TW-27206(英語) )

    • TeamCityエージェントはTeamCityサーバーによって完全に制御されます。TeamCityエージェントはサーバーからの自動更新ダウンロードをサポートしているため、エージェントは信頼できるサーバーにのみ接続する必要があります。サーバーコンピューターの管理者は、接続されたエージェント上で任意のコードの実行を強制することができます。

    • サーバーにインストールされているエージェントプラグインのバイナリは、サーバーのURLにアクセスできる人なら誰でも利用できます。

TeamCityが使用する暗号化

TeamCityは、Web UIを介して（ブラウザからサーバーに）パスワード値をクリアテキストで渡さないようにします。代わりに、RSAを使用して1024ビットのキーを暗号化します。ただし、TeamCity Web UIはHTTPS経由でのみ使用することをお勧めします。この予防策は関係ありません。TeamCityは、パスワードを設定（他のシステムで認証を実行するために元のパスワード値が必要な場合）にスクランブル形式で格納します。スクランブリングは、固定キー付きの3DESを使用するか、カスタムキーを使用して行われます。

新しくインストールしたMySQLサーバーを設定する

MySQLサーバーを基本設定に加えてTeamCityと共に使用する場合は、MySQLサーバー設定のいくつかを確認して変更する必要があります。MySQLがWindowsにインストールされている場合、設定は通常 my.ini ファイルにあります。これは通常MySQLインストールディレクトリにあります。Unix系システムでは、ファイルは my.cnf と呼ばれ、/etc ディレクトリのどこかに置くことができます。MySQLのドキュメント(英語)で設定ファイルの場所についてさらに読む。注： my.ini|my.cnfの設定を変更した後はMySQLサーバーを再起動する必要があります。

以下の設定を確認または変更する必要があります。

InnoDBデータベースエンジン

TeamCityデータベースのテーブルにInnoDBデータベースエンジンを使用していることを確認してください。どのエンジンがこのコマンドの助けによって使用されるか確認できます：

show table status like '<table name>';

または一度にすべてのテーブルに対して：

show table status like '%';

max_connections

max_connections パラメータの値がTeamCity <[TeamCity Home Directory](teamcity-home-directory.md)>/config/database.properties ファイルで指定された値より大きいことを確認する必要があります。

innodb_buffer_pool_sizeおよびinnodb_log_file_size

innodb_buffer_pool_size に小さすぎる値を指定すると、パフォーマンスに大きな影響を与える可能性があります。

# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and # row data. The bigger you set this the less disk I/O is needed to # access data in tables. On a dedicated database server you may set this # parameter up to 80% of the machine physical memory size. Do not set it # too large, though, because competition of the physical memory may # cause paging in the operating system. Note that on 32bit systems you # might be limited to 2-3.5G of user level memory per process, so do not # set it too high. 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に設定することでパフォーマンスを向上させることができます。

# If set to 1, InnoDB will flush (fsync) the transaction logs to the # disk at each commit, which offers full ACID behavior. If you are # willing to compromise this safety, and you are running small # transactions, you may set this to 0 or 2 to reduce disk I/O to the # logs. Value 0 means that the log is only written to the log file and # the log file flushed to disk approximately once per second. Value 2 # means the log is written to the log file at each commit, but the log # file is only flushed to disk approximately once per second. innodb_flush_log_at_trx_commit=2

注：データベースが完全なACID動作を提供することはTeamCityにとって重要ではないため、この変数を安全に変更できます。

異なるディスク上のログファイル

MySQLログファイルを別のディスクに配置すると、パフォーマンスが向上することがあります。それについてMySQLのドキュメント(英語)で読むことができます。

バイナリログ形式の設定

デフォルトのMySQLバイナリロギング形式がMIXEDでない場合（使用しているMySQL(英語)のバージョン(英語)によって異なります）、明示的にMIXEDに設定する必要があります。

binlog-format=mixed

追加の診断を有効にする

データベース固有のエラーが発生した場合に追加の診断データを取得するには、SQLコマンドを使用してTeamCityデータベースユーザーにさらに権限を付与します。

GRANT PROCESS ON *.* TO <teamcity-user-name>;

新しくインストールしたPostgreSQLサーバーの設定

TeamCityサーバーのパフォーマンスを向上させるために、新しくインストールしたPostgreSQLサーバーの一部のパラメーターを変更することをお勧めします。PostgreSQL Wiki(英語)でPostgreSQLのパフォーマンス最適化についてさらに読むことができます。

以下のパラメータはPostgreSQLのデータディレクトリにある postgresql.conf ファイルで変更できます。

shared_buffers

http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-SHARED-BUFFERS(英語)パラメータのデフォルト値は小さすぎるため、増やす必要があります。

shared_buffers=512MB

checkpoint-related parameters

For write-intensive applications such as TeamCity, it is recommended to change some of the checkpoint-related parameters(英語):

For PostgreSQL 9.5 and later:

max_wal_size = 1500MB checkpoint_completion_target=0.9

For versions prior to PostgreSQL 9.5:

checkpoint_segments=32 checkpoint_completion_target=0.9

synchronous_commit

If TeamCity is the only application using the PostgreSQL database, we recommend disabling the http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT(英語) parameter:

synchronous_commit=off

Set Up TeamCity behind a Proxy Server

This section covers the recommended setup of reverse-proxy servers installed in front of the TeamCity server web UI. Configuring HTTPS on the proxy level is recommended, but is out of the scope of these instructions - refer to the documentation of the proxy server for that.

Consider the example:
TeamCity server is installed at URL (local URL): http://teamcity.local:8111/tc(英語)。
これは、URL（パブリックURL）： http://teamcity.public:400/tc (英語)として外部に表示されます。

リバースプロキシ (下記のプロキシサーバーの設定を参照) を設定し、TeamCityにバンドルされているTomcatサーバー (下記のTeamCity Tomcatの設定を参照) を設定して、TeamCityが知るリソースにアクセスするためにクライアントが使用する実際の絶対URLであることを確認する必要があります。これらのURLは、クライアントのリダイレクトやその他の応答で絶対URLを生成するために使用されます。

Note: An internal TeamCity server should work under the same context (i.e. part of the URL after the host name) as it is visible from outside by an external address. See also TeamCity server context changing instructions. If you still need to run the server under a different context, note that context changing proxy should conceal this fact from the TeamCity: e.g. it should map server redirect URLs as well as cookies setting paths to the original (external) context.

プロキシサーバーの設定

プロキシは、一般的なWebセキュリティを考慮して設定する必要があります。たとえばRefererやOriginのようなヘッダは通常TeamCity Webアプリケーションに変更されていない形式で渡されるべきです。また、未知のHTTPリクエストヘッダをTeamCity Webアプリケーションに変更せずに渡す必要があります。たとえば、TeamCityはクライアントによって追加された "X-TC-CSRF-Token"ヘッダに依存しています。

Apache

Versions 2.4.5+ are recommended. Earlier versions do not support the WebSocket protocol, so use the settings noted in the previous documentation version(英語).

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(英語)に切り替えて、同時接続の最大数を構成する必要(英語)があります。

<IfModule mpm_worker_module> ServerLimit 100 StartServers 3 MinSpareThreads 25 MaxSpareThreads 75 ThreadLimit 64 ThreadsPerChild 25 MaxClients 2500 MaxRequestsPerChild 0 </IfModule>

Windowsでは、Apacheのドキュメント(英語)で説明されているように、 ThreadsPerChild(英語)値を増やす必要がある場合があります。

NGINX

以下のNGINX構成では、TeamCityサーバーを構成するために" RemoteIpValve"アプローチを使用してください。

1.3+バージョンをお勧めします。以前のバージョンはWebSocketプロトコルをサポートしていないため、以前のドキュメントバージョン(英語)に記載されている設定を使用してください。

http {     # ... default settings here     proxy_read_timeout     1200;     proxy_connect_timeout  240;     client_max_body_size   0;    # maximum size of an HTTP request. 0 allows uploading large artifacts to TeamCity       map $http_upgrade $connection_upgrade { # WebSocket support         default upgrade;         '' '';     }           server {         listen       400; # public server port         server_name  teamcity.public; # public server host name               location / { # public context (should be the same as internal context)             proxy_pass http://teamcity.local:8111; # full internal address             proxy_http_version  1.1;             proxy_set_header    Host $server_name:$server_port;             proxy_set_header    X-Forwarded-Host $http_host;    # necessary for proper absolute redirects and TeamCity CSRF check             proxy_set_header    X-Forwarded-Proto $scheme;             proxy_set_header    X-Forwarded-For $remote_addr;             proxy_set_header    Upgrade $http_upgrade; # WebSocket support             proxy_set_header    Connection $connection_upgrade; # WebSocket support         }     } }

よくある設定ミス

リバースプロキシ（または同様のツール）が以下の要件に準拠していることを確認してください。

  • ドット（ "。"記号）で始まるパスを持つURLがサポートされています (隠されたアーティファクトへのパスは ".teamcity" ディレクトリを含みます)

  • コロン（ ":"記号）を含むURLがサポートされています（多くのTeamCityリソースはコロンを使用します）。関連IISの設定(英語)症状：「このビルドにはユーザー定義の成果物はありません」というビルドに成果物がありません。アーティファクトがあってもテキスト。

  • 最大応答時間/時間はそれほど制限的ではありません (TeamCityは遅いクライアントに大きなファイルを提供できるため、応答はサイズがGb、時間が数時間になる可能性があります。)

  • gzip Content-Encodingは完全にサポートされています。たとえば特定のIIS構成では、UIに500個のHTTPレスポンスがあり、"データの読み込み中..."が表示されることがあります。(see the related issue(英語))

Other servers

Make sure to use a performant proxy with due (high) limits on request (upload) and response (download) size and timeouts (at least tens of minutes and gigabyte, according to the sizes of the codebase and artifacts).

It is recommended to use a proxy capable of working with the WebSocket protocol as that helps UI to refresh sooner.

Generally, you need to configure the TeamCity server so that it "knows" about the original URL used by the client and it can generate correct absolute URLs accessible for the client. Preferred way to achieve that is to pass original "Host" header to TeamCity. Alternative is to set "X-Forwarded-Host" header to the original "Host" header value.

Note that whenever the value of the "Host" header is changed by the proxy (while it is recommended to preserve original Host header value) and no "X-Forwarded-Host" header with the original Host value is provided, the values of the Origin and Referer headers should be mapped correspondingly if they contain the original Host header value (if they do not, they should not be set in order not to circumvent TeamCity CSRF protection).

Select a proper approach from the section below and configure the proxy accordingly.

TeamCity Tomcat Configuration

For a due TeamCity Tomcat configuration, there are two options:

  • use a dedicated "Connector" node in the server configuration with hard-coded public URL details and make sure that the port configured in the connector is used only by the requests to the public URL configured.

  • configure proxy to pass due request headers: "Host" or "X-Forwarded-Host" (original request host), "X-Forwarded-Proto" (original request protocol), "X-Forwarded-Port" (original request port) and configure "RemoteIpValve" for the TeamCity Tomcat configuration.

Dedicated "Connector" Node Approach

This approach can be used with any proxy configuration, provided the configured port is receiving requests only to the configured public URL.

Set up the proxying server to redirect all requests to teamcity.public:400 to a dedicated port on the TeamCity server (8111 in the example below) and change "Connector" node in <[TeamCity Home](teamcity-home-directory.md)>/conf/server.xml file as below. Note that the "Connector" port configured this way should only be accessible via the configured proxy's address. If you also want to make TeamCity port accessible directly, use a separate "Connector" node with a dedicated port value for that.

When the public server address is HTTPS, use the secure="true" and scheme="https" attributes.

"RemoteIpValve" Approach

This approach can be used when the proxy server sets X-Forwarded-Proto, X-Forwarded-Port request headers to the values of the original URL. Also, while not critical for the most setups, this approach can be used to make sure the original client IP is passed to the TeamCity server correctly. This is important for legacy agents' bidirectional communication.

Add the following into the Tomcat main <Host> node of the conf\server.xml file (see also Tomcat doc(英語)):

<Valve    className="org.apache.catalina.valves.RemoteIpValve"    remoteIpHeader="x-forwarded-for"    protocolHeader="x-forwarded-proto"    portHeader="x-forwarded-port"    />

It is also recommended to specify the internalProxies attribute with the regular expression matching only the IP address of the proxy server. For example, internalProxies="192\.168\.0\.1".

Enforce hiding stacktrace

If a user with access to your TeamCity server submits an invalid cross-site scripting (XSS) payload, the server will display the "Unexpected error" page containing a related stacktrace. To prevent exposing any sensible information about your environment via this stacktrace, you might want to disable its display. For this, set the teamcity.web.runtimeError.showStacktrace internal property to false.

Configure HTTPS for TeamCity Web UI

TeamCity does not provide out-of-the-box support for HTTPS access (see TW-12976(英語)). It is highly recommended to set up a reverse proxy like Nginx or Apache in front of TeamCity that would handle HTTPS and use HTTP TeamCity server port as the upstream. HTTPS-related configuration of the proxy is not specific for TeamCity and is generic as for any Web application. Make sure to configure the reverse proxy per our recommendations below. Generic web application best practices apply (like disabling http access to TeamCity at all).

For small servers, you can set up HTTPS via the internal Tomcat means(英語), but this is not recommended as it may significantly increase the CPU load.

For configuring clients to access TeamCity server via HTTPS while using self-signed certificate, check the related instructions.

Configure TeamCity to Use Proxy Server for Outgoing Connections

This section describes configuring TeamCity to use proxy server for certain outgoing HTTP connections. To connect TeamCity behind a proxy to Amazon EC2 cloud agents, see this section.

TeamCity can use proxy server for certain outgoing HTTP connections made by the TeamCity server to other services like issues trackers, and so on.

To point TeamCity to your proxy server: Since TeamCity 2017.1.5 the following server internal properties are available (see the alternative approach below for the previous version):

# For HTTP protocol ## The domain name or the IP address of the proxy host and the port: teamcity.http.proxyHost=proxy.domain.com teamcity.http.proxyPort=8080   ## The hosts that should be accessed without going through the proxy, usually internal hosts. Provide a list of hosts, separated by the '|' character. The wildcard '*' can be used: teamcity.http.nonProxyHosts=localhost|*.mydomain.com)   ## For an authenticated proxy add the following properties: ### Authentication type. "basic" and "ntlm" values are supported. The default is basic. teamcity.http.proxyAuthenticationType=basic ### Login and Password for the proxy: teamcity.http.proxyLogin=username teamcity.http.proxyPassword=password   # For HTTPS protocol ## The domain name or the IP address of the proxy host and the port: teamcity.https.proxyHost=proxy.domain.com teamcity.https.proxyPort=8080   ## The hosts that should be accessed without going through the proxy, usually internal hosts. Provide a list of hosts, separated by the '|' character. The wildcard '*' can be used: teamcity.https.nonProxyHosts=localhost|*.mydomain.com   ## For an authenticated proxy add the following properties: ### Authentication type. "basic" and "ntlm" values are supported. The default is basic. teamcity.https.proxyAuthenticationType=basic ### Login and Password for the proxy: teamcity.https.proxyLogin=login teamcity.https.proxyPassword=password

The alternative approach, which will work for any TeamCity version, is to pass additional space-delimited additional JVM options to the TeamCity server on the start up:

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

Configure TeamCity Agent to Use Proxy To Connect to TeamCity Server

This section covers the configuration of a proxy server for TeamCity agent-to-server connections (since TeamCity 2017.1).

On the TeamCity agent side, specify the proxy to connect to TeamCity server using the following properties in the buildAgent.properties ファイル:

## The domain name or the IP address of the proxy host and the port teamcity.http.proxyHost=123.45.678.9 teamcity.http.proxyPort=8080   ## If the proxy requires authentication, specify the login and password teamcity.http.proxyLogin=login teamcity.http.proxyPassword=password

プロキシはTeamCityサーバーの応答をキャッシュしないように設定する必要があります。たとえば、Squidを使用している場合は、squid.conf ファイルに「cache deny all」という行を追加します。

同じマシンに複数のエージェントをインストールする

エージェントインストールマニュアルの対応するセクションを参照してください。

サーバーポートの変更

See corresponding section in server installation instructions.

アップグレード前に新しいTeamCityバージョンをテストドライブ

It's advised to try a new TeamCity version before upgrading your production server. The usual procedure is to create a copy of your production TeamCity installation, then upgrade it, try the things out, and, when everything is checked, drop the test server and upgrade the main one. When you start the test server, remember to change the Server URL, disable Email and Jabber notifiers as well as other features on the new server.

全データを含むTeamCityサーバーのコピーを作成する

In case you want to preserve the original server as well as the copy, make sure to check the licensing considerations.

サーバーコピーを作成する

TeamCityバックアップ機能を使用して、または手動でサーバーのコピーを作成できます。サーバーを完全に移動するには、手動による方法をお勧めします。

TeamCityバックアップを使用

  1. すべてを含むバックアップを作成してください。（ビルドログをバックアップするオプションはスキップできます。アーティファクトを移動している場合は、下記を参照してください）。

  2. すでに実行しているのと同じバージョンの新しいTeamCityサーバーをインストールします。確認しておいて：

    • 適切な環境が構成されている (下記のメモを参照)

    • the server uses its own <[TeamCity Data Directory](teamcity-data-directory.md)> and its own database ( <[TeamCity Data Directory](teamcity-data-directory.md)>config/database.properties ファイルを確認する)

  3. バックアップを復元します。

  4. <[TeamCity Data Directory](teamcity-data-directory.md)>/system/artifacts ディレクトリのコンテンツを古い場所から新しい場所に移動して、アーティファクト（これらはバックアップに含まれません）を移動します。アーティファクトのサイズが大きくなる可能性があるため、これには長い時間がかかる可能性があるため、それに応じて計画を立ててください。

  5. 必要な環境転送を実行してください。

手動コピー

バンドルされたバックアップ機能を使用しない場合、またはプロセスを手動で制御する必要がある場合は、サーバーのコピーを手動で作成する方法に関する一般的な手順を次に示します。

  1. 問題が発生した場合に復元できるように、バックアップを作成します。

  2. サーバーが稼働していないことを確認します。

  3. クリーンインストールを実行するか、TeamCityバイナリ（ TeamCity Home Directory ）を新しい場所にコピーします（ temp および work サブディレクトリはコピー中に省略できます）。まったく同じTeamCityバージョンを使用してください。コピー後にアップグレードする場合は、既存のバージョンを起動して実行してからアップグレードを実行してください。

  4. <[TeamCity Data Directory](teamcity-data-directory.md)>をコピーします。完全なコピーが必要でない場合は、オプションについて以下の項目を参照してください。

    • プロジェクトを保存し、構成設定を構築するための.BuildServer/config

    • .BuildServer/lib と .BuildServer/plugins があれば

    • 内部データベースを使用していて、このデータベースを移動したくない場合は、.BuildServer/system のルートからのファイル

    • .BuildServer/system/artifacts （オプション）ビルドアーティファクトとビルドログ（テストの失敗の詳細を含む）を新しいサーバーに保持する場合

    • .BuildServer/system/changes （オプション）個人の変更を新しいサーバーに保存する場合

    • .BuildServer/system/pluginData （オプション）さまざまなプラグイン、ビルドトリガー、設定監査差分の状態を保持したい場合

    • .BuildServer/system/caches および .BuildServer/system/caches （オプション）は、新しいサーバーにコピーする必要はありません。起動時に再作成されますが、再構築に時間がかかる場合があります。(多少の減速が予想されます)

  5. アーティファクトディレクトリは通常大きいです。サーバーを移動するときにサーバーのダウンタイムを最小限に抑える必要がある場合は、データをコピーするための一般的なアプローチを使用できます。元のサーバーの実行中に、rsync、robocopyなどのツールを使用してデータをコピーします。同期データの量が減少するまで、同期実行を数回繰り返します。元のサーバーのシャットダウン後に最後の同期を実行します。サーバー移動の代替ソリューションは、古いデータアーティファクトディレクトリを新しいサーバーにアクセス可能にし、それをアーティファクトの 2番目の場所として構成することです。次に、サーバーの実行中に、この2番目の場所からメインの場所にファイルをコピーします。コピー完了後、サーバーを再起動します。

  6. Create a copy of the database, which your TeamCity installation is using, in a new schema or new database server. This can be done with database-specific tools or with the bundled maintainDB tool by backing up database data and then restoring it.

  7. Configure the new TeamCity installation to use proper <[TeamCity Data Directory](teamcity-data-directory.md)> and database ( .BuildServer/config/database.properties はデータベースのコピーを指する)

  8. Perform the necessary environment transfer.

Environment transferring

Consider transferring the relevant environment if it was specially modified for an existing TeamCity installation. This might include:

  • use the appropriate OS user account for running the TeamCity server process with properly configured settings, global and file system permissions

  • use the same TeamCity process launching options, specifically check/copy environment variables starting with TEAMCITY_

  • ensure any files/settings that were configured in the TeamCity web UI with absolute paths are accessible

  • if relying on the OS-level user/machine settings like default SSH keys, cached VCS access credentials, transfer them as well

  • consider replicating any special settings or exceptions related to the machine in the network configuration, and so on

  • if the TeamCity installation was patched in any way (GroovyPlug plugin, native driver for MS SQL Server integrated security authentication), apply the same modifications to the installation copy

  • if you run TeamCity with the OS startup (for example, Windows service), make sure the same configuration is performed on the new machine

  • review and transfer settings in the <[TeamCity Home](teamcity-home-directory.md)>\conf\teamcity-startup.properties file

  • consider any custom settings in <TeamCity Home>\conf\server.xml

Licensing issues

A single TeamCity license cannot be used on two running servers at the same time.

Copied Server Checklist

If you are creating a copy (as opposed to moving the server this way), it is important to go through the checklist below:

  • ensure the new server is configured to use another Data Directory and another database than the original server; check also "Artifact directories" setting on server's Global Settings;

  • change server unique id by removing "uuid" attribute from XML of <[TeamCity Data Directory](teamcity-data-directory.md)>\config\main-config.xml file before the first start;

  • ensure the same license keys are not used on several servers (more on licensing);

  • update Server URL on the Administration | Global Settings page to the actual URL of the server;

  • check that you can successfully authenticate on the new server, use super user access if necessary;

  • check that VCS servers, issue tracker servers, email and Jabber server and other server-accessed systems are accessible;

  • check that any systems configured to push events to TeamCity server (like VCS hooks, automated build triggering, monitors, etc.) are updated to know about the new server;

  • review the list of installed plugins to determine if their settings need changes;

  • install new agents (or select some from the existing ones) and configure them to connect to the new server (using the new server URL);

  • check that clients reading from the server (downloading artifact, using server's REST API, NuGet feed, etc.) are reconfigured, if necessary.

If you are creating a test server, you need to ensure that the users and production systems are not affected. Typically, this means you need to:

  • disable Email, Jabber (in the "Administration > Notifier" sections) and possibly also custom notifiers or change their settings to prevent the new server from sending out notifications;

  • disable email verification (in the "Administration > Authentication" section);

  • be sure not to run any builds which change (for example, deploy to) production environments. This also typically includes Maven builds deploying to non-local repositories. You can prevent any builds from starting by pausing the build queue;

  • disable cloud integration (so that it does not interfere with the main server);

  • disable external artifact storage (as otherwise running/deleting builds and server clean-up will affect the storage which might be used by the production server);

  • disable Docker registry clean-up (or just disable clean-up on the server);

  • disable Commit Status Publishing;

  • disable any plugins which push data into other non-copied systems based on the TeamCity events;

  • disable functionality to store project settings in VCS: set teamcity.versionedSettings.enabled=false internal property;

  • consider significantly increasing VCS checking for changes interval (server-wide default and overridden in the VCS roots) or changing settings of the VCS roots to prevent them from contacting production servers. Since TeamCity 10.0.3, see also TW-47324(英語)。

See also the section below on moving the server from one machine to another.

Move TeamCity Projects from One Server to Another

If you need to move data to a fresh server without existing data, it is recommended to move the server or copy it and then delete the data which is not necessary on the new server.

If you need to join the data with already existing data on the new server, there is a dedicated feature to move projects with most of the associated data from one server to another: Projects Import.

Here are some notes on manual move of the settings in case you ever want to perform it

Since TeamCity 8.0 it is possible to move settings of a project or a build configuration to another server with simple file copying. For earlier TeamCity versions see the comment(英語).

The two TeamCity servers (source and target) should be of exactly the same version (same build).

All the identifiers throughout all the projects, build configurations and VCS roots of both servers should be unique. If they are not, you can change them via web UI. If entities with the same id are present on different servers, the entities are assumed to be the same. For example this is useful for having global set of VCS roots on all the servers.

To move settings of the project and all its build configuration from one server to another:

From the TeamCity Data Directory、対応するプロジェクト（.BuildServer\config\projects\<id>）とそのすべての親プロジェクトのディレクトリをターゲットサーバーの .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 に接続して、サーバーが同じを使用するようにします。環境。あるいは、サーバーをあるマシンから別のマシンにコピーすることに関する指示に従うこともできます。

移動後、変更した場合は、クライアントに新しいサーバーアドレスを使用させます。

サーバーをあるマシンから別のマシンに移動するときに、既存のライセンスキーを使用できます（同時に2つのサーバーが実行されていない場合）。ライセンスキーは <[TeamCity Data Directory](teamcity-data-directory.md)>に保存されるため、他のすべてのTeamCity設定データとともにライセンスキーを転送します。

通常、TeamCityの更新を環境やハードウェアの変更などの他の操作と組み合わせずに、一度に1つずつ変更を実行して、問題が発生した場合にその原因を簡単に追跡できるようにすることをお勧めします。

あるサーバーから別のサーバーに切り替える

<[TeamCity Data Directory](teamcity-data-directory.md)> とデータベースは、常に単一のTeamCityインスタンスで使用する必要があることに注意してください。同じデータを使用するように新しいTeamCityインスタンスを構成した場合は、新しいインスタンスを開始する前に、古いTeamCityインスタンスをシャットダウンして無効にしてください。

一般に、サーバーへのアクセスにはドメイン名を使用することをお勧めします（エージェント構成内、およびユーザーがTeamCity Web UIにアクセスするとき）。この方法で、DNSエントリを更新してアドレスを新しいサーバーのIPアドレスに解決し、キャッシュされたすべてのDNS結果が期限切れになると、すべてのクライアントが自動的に新しいサーバーを使用します。クライアントが変更を早く理解できるようにするには、変更前にDNSサーバーのキャッシュ/リース時間を事前に短縮する必要があります。

ただし、別のサーバードメインアドレスを使用する必要がある場合は、次のことが必要になります。

  • エージェントを新しいURLに切り替えます（各エージェントの buildAgent.properties の serverUrl プロパティを更新する必要があります）。エージェントを新しくインストールしたいが、エージェントの名前と認証状況を保存したい場合は、新しいエージェントをインストールして古いエージェントから conf\buildAgent.properties ファイルをコピーすることができます（その中のパスがそれに応じて更新されることを確認します）。

  • 新しいサーバーの起動時に、管理 | グローバル設定ページでサーバー URLを必ず更新してください。

  • 新しい住所ですべてのTeamCityユーザーに通知する

  • 要求元アドレスに依存する場合は、外部サービスの設定を更新することを検討してください。

TeamCityエージェントを新しいマシンに移動する

バイナリとは別に、TeamCityエージェントのインストールには、実行されたビルドから残った構成とデータが保存されます。通常、以前のビルドのデータにより、将来のビルドの準備が少し速くなりますが、必要に応じて削除できます。構成は、conf および launcher\conf ディレクトリに保管されます。前のビルドで収集されたデータは、work および system ディレクトリに保存されます。

エージェントのインストールを新しいマシンまたは新しい場所に移動する最も簡単な方法は、次のとおりです。

  • 既存のエージェントを停止

  • 新しいマシンに新しいエージェントをインストールする

  • 古いインストールから新しいものに conf/buildAgent.properties をコピーする

  • 新しいエージェントを起動します。これらのステップで、エージェントはTeamCityサーバーによって同じものとして認識され、すべてのビルドに対してクリーンチェックアウトを実行します。

ビルドの一貫性に影響を与えずに削除できるディレクトリのリストについても、このセクションを確認してください。

チェーンビルドでビルドのビルド番号を共有する

ビルド番号は、以下の依存関係プロパティへの参照を使用して、スナップショット依存関係または成果物依存 関係によって接続されたビルドに対して共有することができます。%dep.<btID>.system.build.number%。

例：同期してビルドするビルド構成AとBがあります。同じソースを使用し、同じビルド番号を取得します。
以下を実施：

  1. ビルド構成Cを作成し、次にスナップショットの依存関係（AにCとBのC）を作成します。

  2. AとBのビルド番号の形式を次のように設定します。

%dep.<btID>.system.build.number%

<btID> がビルド構成のID Cの場合。このアプローチは、スナップショットの依存関係スナップショット依存関係オプションをオフに設定してビルドの再利用を無効にした場合に最も効果的に機能します。

依存関係プロパティについてのさらに読み込む。

ビルド番号TW-7745(英語)の共有に関連する課題を見てコメントします。

ビルド間で一時ビルドファイルを消去する

${teamcity.build.tempDir} （Antのスタイル名）プロパティに保存されているパスを一時ディレクトリとして使用するようにビルドスクリプトを更新します。TeamCityエージェントは、ビルドの前にディレクトリを作成し、ビルドの直後にそれを削除します。

構成エラーが原因でビルドが多すぎる場合はビルドキューをクリアする

ビルドがキューに入れられているビルド構成を一時停止してみてください。ビルド構成を一時停止すると、そのすべてのビルドがキューから削除されます。
また、1つのダイアログでビルドキューから多くのビルドを削除する機能もあります。

TeamCityビルド構成設定を自動的に作成または変更する

あるレベルの自動化が必要でWeb管理UIがあなたのニーズに合っていない場合、いくつかの可能性があります。

  • REST APIを使用

  • ディスク上の設定ファイルを直接変更する ( <[TeamCity Data Directory](teamcity-data-directory.md)>で詳細を見る )

  • オープンAPI(英語)を使用してタスクを実行するTeamCity Javaプラグインを記述します。

CucumberレポーターをAntビルドに接続

JavaアプリケーションのテストにCucumberを使用する場合は、cucumberを --expand および特別な --format オプションと共に実行する必要があります。さらに、必要なTeamCity Rakeランナーrubyスクリプトを指すRUBYLIB環境変数を指定する必要があります。

<<target name="features">     <java classname="org.jruby.Main" fork="true" failonerror="true">       <classpath>         <pathelement path="${jruby.home}/lib/jruby.jar"/>         <pathelement path="${jruby.home}/lib/ruby/gems/1.8/gems/jvyaml-0.0.1/lib/jvyamlb.jar"/>         ....       </classpath>       <jvmarg value="-Xmx512m"/>       <jvmarg value="-XX:+HeapDumpOnOutOfMemoryError"/>       <jvmarg value="-ea"/>       <jvmarg value="-Djruby.home=${jruby.home}"/>       <arg value="-S"/>       <arg value="cucumber"/>       <arg value="--format"/>       <arg value="Teamcity::Cucumber::Formatter"/>       <arg value="--expand"/>       <arg value="."/>       <env key="RUBYLIB"            value="${agent.home.dir}/plugins/rake-runner/rb/patch/common${path.separator}${agent.home.dir}/plugins/rake-runner/rb/patch/bdd"/>       <env key="TEAMCITY_RAKE_RUNNER_MODE" value="buildserver"/>     </java>   </target>

RUBYLIBパス区切り文字（Windowsの場合は「;」、Linuxの場合は「：」、antの「${path.separator}」を確認してください）。
Rakeビルド言語を使用してCucumberテストを起動する場合、TeamCityは必要なすべてのコマンドラインパラメータと環境変数を自動的に追加します。このヒントは、TeamCityバージョン5.0以上で機能します。

最後に成功したビルド番号を取得

次のようにURLを使用してください。

http://<your TeamCity server>/app/rest/buildTypes/id:<ID of build configuration>/builds/status:SUCCESS/number

ビルド番号はプレーンテキストの応答として返されます。
<ID of build configuration>については、識別子を参照してください。
この機能はREST APIによって提供されます

TeamCityで私のアプリケーション用にデプロイを設定する

TeamCityは、ビルドスクリプト/ビルドランナーで設定された実際のデプロイロジックでデプロイのオーケストレーション部分を処理するのに十分な機能を持っています。TeamCityはさまざまな汎用ビルドツールをサポートしているため、TeamCity内から特定のツールを実行できます。特定のツールの使用方法を簡単にするために、それをメタランナーにラップするか、そのためのカスタムプラグインを書くことが可能です。

一般に、デプロイを設定するための設定手順は次のとおりです。

  1. ディスク上の利用可能なバイナリファイルに対してデプロイタスクを実行するビルドスクリプトを書きます。（たとえば、AntまたはMSBuildを使用してください。通常のデプロイトランスポートでは、デプロイヤーランナーを使用してください）。ビルドおよびレポート作成ツールと統合するも参照してください。便利なUIでスクリプトを再利用するためにメタランナーを使うことができます。

  2. TeamCityでビルドスクリプトを実行して実際のデプロイを実行するビルド構成を作成します。デプロイを限定されたユーザーセットのみが表示または起動できるようにする場合は、ビルド構成を別のTeamCityプロジェクトに配置し、ユーザーがプロジェクトで適切な権限を持っていることを確認してください。

  3. このビルド構成では、デプロイする必要があるバイナリを生成するビルド構成に成果物の依存関係を構成します。

  4. デプロイを自動的にトリガーする必要がある場合（最後の固定ビルドのうち最後に成功したものをデプロイする場合など）、デプロイするビルド構成で使用可能なトリガーの1つを構成するか、デプロイするバイナリを生成したビルドで「プロモート」アクションを使用します。

  5. アーティファクトに加えてスナップショットの依存関係の使用を検討し、ビルド・チェーンタブを確認してビルドの概要を取得します。この場合、アーティファクトの依存関係は「同じチェーンからビルド」オプションを使用する必要があります。

  6. デプロイをパラメータ化する必要がある場合（たとえば、実行ごとに異なるターゲットマシンを指定する場合）、カスタムビルド実行ダイアログを使用してパラメータをビルドスクリプトに渡します。カスタム実行ダイアログを使いやすくしたり、パスワードを扱いやすくするために型付きパラメータを使用することを検討してください。

  7. デプロイするビルドが手動で起動された場合は、ビルドスクリプトにコマンドを追加してデプロイされるビルドを固定してタグ付けすることも検討してください（REST API要求を送信することによって）。成果物を生成したビルドからのビルド番号を使用することもできます。

さらなる推奨事項

  • ターゲット環境ごとに別々のビルド構成をセットアップする

  • ビルドのバイナリ生成とビルド/タスクのデプロイ間のナビゲーションには、ビルドの依存関係タブを使用します。

  • 必要に応じて、「プロンプト」表示モードでパラメーターを使用して、ビルドの実行時に「 確認(英語) 」を求めます

  • ビルド構成の「タイトルを変更(英語)」「実行」ボタン

公式サイトの関連セクション: TeamCityとの連続デプロイ

ビルドが依存している外部ツールを使用する

ビルドを実行するためにビルドエージェントにインストールするために特定の外部ツールを使用する必要がある場合は、次の選択肢があります。

  • TeamCityにツールをインストールして登録します。

    1. ビルドを実行するすべてのエージェントにツールをインストールしてください。これは手動でも自動スクリプトでも実行できます。単純なファイルディストリビューションについてはエージェントツールのインストールも見てください

    2. ツールのホームロケーションを値として使用して、プロパティを buildAgent.properties ファイルに追加します（またはシステムに環境変数を追加します）。

    3. ビルド構成でプロパティのエージェント要件を追加します。

    4. ビルドスクリプトでプロパティを使用します。

  • ツールをバージョン管理にチェックインし、相対パスを使用します。

  • ツールスクリプトを他の場所に配置するには、ビルドスクリプトに環境の準備段階を追加します。

  • 成果物として必要なファイルを含む単一の「偽の」ビルドで別のビルド構成を作成してから、成果物依存関係を使用してファイルをターゲットビルドに送信します。

ビルドおよびレポート作成ツールと統合する

ビルドツールや、TeamCityやプラグイン(英語)でまだサポートされていないレポートを生成したりコードメトリックを提供したりするツールがある場合は、専用の統合がなくても、TeamCityで使用できます。

関連する統合タスクは、ビルドの範囲内でデータを収集してからTeamCityに報告して、それらがビルド結果または他の方法で提示できるようにすることです。

データ収集

開始する最も簡単な方法は、選択したツールを利用して必要なすべてのデータを収集するようにビルドスクリプトを変更することです。
コマンドラインコンソールからツールを実行できる場合は、コマンドラインランナーを使用してTeamCityでツールを実行できます。これにより、標準エラー出力に出力されるメッセージを検出できます。ビルドに失敗のマークを付けることができるのは、終了コードがゼロでないか、ビルドの失敗条件によって標準エラーに出力される場合です。
ツールに、Ant、Maven、MSBuildなどのサポートされているビルドスクリプトエンジンのランチャーがある場合は、TeamCityの対応するランナーを使用してツールを起動できます。外部ツールの実行方法に関する推奨事項については、ビルドが依存している外部ツールを使用するも参照してください。

ツールにTeamCityの専用UIを持たせるためにメタランナーを作成することも検討できます。

高度な統合のために、カスタムTeamCityプラグイン(英語)をJavaで開発してツールの設定と実行を容易にすることができます。

TeamCityでデータを提示する

ビルドの進行状況はサービスメッセージを介してTeamCityに報告でき、ビルドステータステキストも更新できます。

テストツールについては、それらがまだサポートされていない場合は、テスト関連のサービスメッセージを介してビルドからTeamCityにテストの進行状況を報告するか、ビルドでサポートされているXML レポートのいずれかを生成して設定済みのXML Report Processingビルド機能のサービスメッセージを介してインポートできます。

一般的なレポートの結果を表示するには、ビルドスクリプトでHTMLレポートを生成し、それをアーカイブにパックしてビルド成果物として公開するというアプローチが考えられます。次に、レポートのタブを設定して、HTMLレポートをビルド結果のタブとして表示します。

メトリクス値は、サービスメッセージを介してTeamCity統計として公開し、カスタムチャートに表示することができます。メトリックに基づいてビルド失敗条件を構成することもできます。

ツールがインスペクションやDuplicatesなどのコード属性情報をレポートする場合は、TeamCityバンドルレポートを使用して結果を表示できます。ツール固有のレポートをTeamCity固有のデータモデルに処理するには、カスタムプラグインが必要になります。この例はXMLテスト報告プラグインとFXCopプラグインにあります（オープンソースのバンドルプラグイン(英語)のリンクを見てください）。

カバレッジ内容のインポートはTeamCityになりますも参照してください。

高度な統合のためには、必要に応じてデータを保存し提示するためのカスタムプラグインが必要になります。プラグイン開発の詳細についてはTeamCityプラグインの開発(英語)を参照してください。

削除したばかりのプロジェクトを復元する

TeamCityは、削除されたプロジェクト設定ディレクトリ（プロジェクトIDにちなんで名付けられた）を <[TeamCity Data Directory](teamcity-data-directory.md)>/config/_trash ディレクトリに移動し、ディレクトリに "<internal ID>" サフィックスを追加します。

プロジェクトを復元するには、_trash ディレクトリでプロジェクトディレクトリを見つけて、それを通常のプロジェクト設定ディレクトリ <[TeamCity Data Directory](teamcity-data-directory.md)>/config/projects に移動し、ディレクトリ名から ".projectN" サフィックスを削除します。
これはサーバーの実行中に行うことができます。サーバーは復元されたプロジェクトを自動的に取得します。

TeamCityは、削除されたプロジェクト/ビルド構成について、データベースに保存されているビルド履歴およびその他のデータを削除後5日間保存します。設定可能な （デフォルトでは5日間）タイムアウトが経過した後のすべての関連データ（ビルドおよびテスト履歴、変更など）は、次回のクリーンアップ中に削除されます。

config/_trash ディレクトリは自動的にクリーンアップされず、削除されたプロジェクトが不要であると確信できる場合は手動で空にすることができます。サーバーの再起動は不要です。

3つのデフォルトエージェントを別のサーバーに転送する

これは不可能です。

各TeamCityサーバー（ProfessionalおよびEnterprise）では、エージェントライセンスなしでサーバーにバインドされた3つ以上のエージェントを使用できます。Professionalサーバーの場合、デフォルトでは3つのエージェントがサーバーインスタンスにバインドされます。ユーザーはこれらのエージェントに料金を支払わず、ライセンスキーはありません。
Enterpriseサーバーの場合、エージェントの数はパッケージによって異なり、エージェントはサーバーライセンスキーにバインドされます。

そのため、サーバーにバインドされているエージェントを別のサーバーに転送することはできません。

TeamCityサーバーに含まれているより多くのビルドエージェントが必要な場合は、サーバーにバインドされているライセンスに加えて、追加のビルドエージェントライセンスを購入してより多くのエージェントを接続することができます。

参照してくださいより多くのライセンスにします。

カバレッジ内容のインポートはTeamCityになります

TeamCityは、IntelliJ IDEA / Emma、およびJava用のJaCoCoカバレッジエンジン、およびdotCover / NCover / PartCover for .NETにバンドルされています。

ただし、コベルチュラ(英語)やTeamCityによって直接サポートされていない他のツールなど、他にもたくさんのカバレッジツールがあります。

これらのツールで同様の経験を積むためには、次のことができます。

  • カバレッジHTMLレポートをTeamCityアーティファクトとして公開：ほとんどのツールはカバレッジレポートをHTML形式で生成します。アーティファクトとしてパブリッシュし、レポートタブをTeamCityで表示するように設定できます。成果物がルート成果物ディレクトリに公開され、その名前が coverage.zip で index.html ファイルがある場合は、レポートタブが自動的に表示されます。外部ツールの実行に関しては、ビルドおよびレポート作成ツールと統合するを確認してください。

  • カバレッジレポートからカバレッジ統計を抽出し、サービスメッセージを使用してTeamCityに統計値を公開します。その場合は、ビルド構成のStatisticsタブにカバレッジチャートが表示されます。メトリクスの変更時に失敗条件を構築します（たとえば、カバレッジが低下した場合は失敗します）。

「データディレクトリ（NNN）とデータベース（MMM）のデータ形式が一致しない」エラーから回復する

「データディレクトリ（NNN）とデータベース（MMM）のデータ形式が一致しません」というメッセージが表示された場合。TeamCityの起動エラー。データベースまたはTeamCityデータディレクトリのいずれかが最近矛盾した状態に変更されたため、一緒に使用できないことを意味します。データベースとデータディレクトリの場所を再確認し、サーバーがデータの保存に使用した場所でない場合は変更します。

それらが正しい場合、おそらく、サーバーが別のデータベースまたはデータディレクトリでアップグレードされ、メインのデータディレクトリとデータベースの一貫したアップグレード要件が満たされなかったことを意味します。

状態から回復するには、アップグレード前に作成された一貫性のある状態のバックアップが必要です。そのバックアップを復元し、データディレクトリとデータベースに正しい場所が使用されていることを確認し、TeamCityアップグレードを実行する必要があります。

特定のエージェントでビルドをデバッグする

一部のエージェントでビルドが失敗した場合、このエージェントでそれをデバッグしてエージェント固有の課題を調査することが可能です。以下を実施：

  1. TeamCity Web UIのエージェントページに移動し、エージェントを選択します。

  2. ビルドグリッドから一時的に削除するエージェントを無効にします。コメントを追加します（オプション）。特定の期間後にエージェントを自動的に有効にするには、対応するボックスをオンにして時間を指定します。

  3. デバッグするビルドを選択。

  4. カスタムランダイアログを開き、以下のオプションを指定します。エージェントドロップダウンで、無効化されたエージェントを選択します。b。通常のビルドとの交差を避けるために、パーソナルビルドとして実行オプションを選択することをお勧めします。

  5. デバッグが完了したら、自動再有効化が設定されていない場合はエージェントを手動で有効化します。

TeamCity用のIntelliJ IDEAプラグインを使用して、エージェント上でテストのリモートデバッグを実行することもできます。

ビルドの一部をデバッグする (ビルドステップ)

複数のステップを含むビルドが特定のステップで失敗した場合、中断したステップをデバッグすることが可能です。以下を実施：

  1. ビルド設定にジャンプし、デバッグしたいものまでのビルドステップを無効にします。

  2. デバッグするビルドを選択。

  3. カスタムランダイアログを開き、ビルドをキューの先頭に置くを選択して優先順位を付けます。

  4. デバッグが完了したら、ビルド手順を再度有効にします。

脆弱性

このセクションでは、発表されているセキュリティ上の脆弱性に関する効果と必要な保護手順について説明します。

Heartbleed、ShellShock

JetBrainsが提供するTeamCityディストリビューションにはソフトウェア/ライブラリが含まれておらず、ハートブリードとシェルショックの脆弱性の影響を受けるテクノロジーを使用していません。まだ評価が必要なのは、JetBrainsによって提供/推奨されるコンポーネントの背後にあるコンポーネントを使用する可能性のある特定のTeamCityインストール実装であり、前述のエクスプロイトに対して脆弱です。

POODLE

TeamCityサーバーへのHTTPSアクセスを構成した場合、影響を受ける可能性があるため、HTTPSに使用されるソリューションを調べます（例：Tomcatが影響を受ける(英語)ようです）。現在のところ、TeamCityディストリビューションにはデフォルトでHTTPSアクセスが含まれておらず、HTTPS関連の脆弱性の調査/排除はTeamCityの範囲外です。

使用される設定に応じて、TeamCityサーバー（およびエージェント）は、他のサーバー（例：Subversion）へのHTTPS接続を確立できます。サーバーの設定によっては、これらの接続はSSL 3.0プロトコルの使用にフォールバックする場合があります。推奨される解決策はTeamCity固有ではなく、ターゲットSSLサーバー側でSSLv3を無効にすることです。

GHOST

CVE-2015-0235の脆弱性は、TeamCityコードによって直接使用されていないglibcライブラリに見つかります。これは* nixプラットフォームでTeamCityによって使用されるJava / JREによって使用されます。JavaはTeamCityディストリビューションにバンドルされていないため、使用するJavaのベンダーによって推奨されているセキュリティ対策を適用する必要があります。現時点では、関連するJava固有のセキュリティ勧告は発表されていません。そのため、OSのアップデートで脆弱性が悪用される危険性を排除するのに十分なはずです。

FREAK

OpenSSLの実装にCVE-2015-0204の脆弱性が見つかりました。TeamCityはOpenSSL製品のいかなる部分もバンドルしていないため、この脆弱性の影響を受けません。TeamCityサーバーとエージェントがセットアップされている環境、および考えられる脆弱性の軽減手順についてTeamCityに加えてインストールされているツールを確認する必要があります。

Apache Struts

CVE-2017-5638はApache StrutsのJakarta Multipartパーサに影響します。CVE-2016-1181は、Apache Strutsの一部の古いバージョンでのマルチパートリクエストの処理にも影響します。

TeamCityは、Apache Struts 1.xとApache Struts 2.xの両方からのjarを含むIntelliJ IDEAをバンドルしています。IntelliJ IDEAがTeamCityエージェント上のプロジェクトのインスペクションを収集するとき、これらのjarファイルはIntelliJ IDEA Strutsプラグインによってのみ使用されます。

どのような状況でも、これらのバージョンのApache StrutsがHTTPリクエストの処理に使用されることはありません。TeamCityサーバーもTeamCityエージェントもこれらの脆弱性の影響を受けません。

Windows Tray Notifierで複数のTeamCityサーバーを見る

TeamCity Tray Notifierは通常、ビルドを監視し、単一のTeamCityサーバーから通知を受け取るために使用されます。ただし、複数のTeamCityサーバーがあり、Windows Tray Notifierで同時に監視する場合は、/allowMultiple オプションを使用して、コマンドラインから各サーバーに対して個別にTray Notifierインスタンスを起動する必要があります。

  • TeamCity Tray Notifierのインストールフォルダー（デフォルトでは C:\Program Files\JetBrains\TeamCity）から、次のコマンドを実行します。

JetBrains.TrayNotifier.exe /allowMultiple

オプションで、各Tray Notifierインスタンスに対して、/server オプションを使用して接続するサーバーのURLを明示的に指定できます。それ以外の場合は、トレイ通知インスタンスごとに、ログアウトしてUIを介してサーバーのURLを変更する必要があります。

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

課題トラッカーの詳細も参照してください(英語)。

個人ユーザーデータ処理

TeamCity製品に関連して、JetBrainsはオンプレミスのTeamCityインストールユーザーの個人データを収集しません。顧客とJetBrainsの関係を規定する関連ドキュメントは、公式Webサイト（ プライバシーポリシー、購入条件、TeamCityライセンス契約）で入手できます。

以下の注意事項は、TeamCityの使用方法が一般データ保護規則（GDPR）（EU）の2016/679規則にどのように準拠しているかを評価するときに役立ちます。これらのノートは最も基本的な質問に対処することを意図しており、あなたの特定のTeamCityインストールの評価へのインプットとして役立つことができます。

ノートはGDPR実施日の時点で実際のものであるTeamCity 2017.2.4に基づいています。以前のバージョンには以下の注意事項に沿っていない課題が含まれている可能性があるため、少なくともTeamCityインスタンスをそのバージョンに更新してください。

TeamCityとユーザーの個人データ

TeamCityが保存する最も重要なユーザ関連のデータは以下の通りです。

  • フルネームとユーザー名 - データベースに格納され、ユーザーのプロファイルに表示され、ユーザーが参照されるたびに表示されます。ユーザーがビルドを起動すると、これらもビルドのパラメータに格納され、ビルドに渡されます。

  • ユーザーのメール - データベースに保存され、ユーザーのプロファイルに表示されます。通知の送信に使用されます。

  • サーバーにアクセスしているクライアントのIPアドレス - 内部ログに表示されることがあります

TeamCityの内部ログには、構造化されていないユーザー関連の情報も記録できます。(たとえばLDAPなどのユーザーソースから構成された設定に従って取得された、HTTPリクエストと共にユーザーによって送信されたか、ブラウザによって送信された)

ユーザデータの削除

特定のユーザーの個人データを削除したい場合は、TeamCityでそのユーザーを削除するのが最善の方法です。このようにして、他のすべてのユーザー情報はもう格納されなくなりますが、ユーザーへのすべての参照は数値のユーザーIDを格納し続けます。監査レコードは、ユーザー削除後に内部数値ユーザーIDにメンションすることに注意してください。

ユーザーがビルドをトリガーした場合（つまり、サーバー上にまだ存在するプロジェクトのいずれかで「ビルドの実行」権限があった場合）、ユーザーのユーザー名とフルネームがビルドの「teamcity.build.triggeredBy」パラメーターに記録されます。ビルドの「環境」の一部であったテキスト値。削除する必要がある場合、関連するビルド（およびそれらに依存するアーティファクトまたはスナップショットに依存するすべてのビルド）を削除するか、影響を受けるビルドのパラメーターを削除することができます（パラメーターは<TeamCity Data Directoryのアーカイブファイルに保存されます。> \ 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ルートの現在および以前のバージョンのユーザー名もデータベースに保存されます。)

ユーザーの詳細がTeamCityによって確実に保存されないようにするために、TeamCityのバッキングストレージでデータの発生が保存されていないことを確認します。データベース、データディレクトリ、TeamCityホームディレクトリ（ログ、およびメモリダンプ） "bin" ディレクトリ）

利用規約

TeamCityインスタンスを使用する前にユーザーに特別な同意を求めたい場合は、この目的のためにJetBrainsによって開発された専用プラグイン(英語)をインストールできます。詳細については、プラグインのドキュメントを参照してください。

暗号化

TeamCityが使用するデータを暗号化する場合は、TeamCityが専用機能を提供していないため、TeamCity固有ではない汎用ツールを使用することをお勧めします。TeamCityは、SQLデータベースとファイルシステムにデータを格納します。暗号化された形式でデータを格納するようにデータベースを構成し、データベースへの安全なJDBCを利用した接続を使用できます（ database.properties で構成）。
また、OSレベルでディスクストレージの暗号化を設定できます。

ログとデバッグデータ

限られた日数を超えて内部TeamCityログを保存しないようにするには、毎日ログファイルをローテーションして保存するファイルの数を制限するように内部ログを設定します。TeamCityエージェントは通常、ユーザー関連のデータを構造的に処理することはありませんが、ログがエージェント上で定期的にローテーションされるようにする必要がある場合は、エージェントロギングを同じ方法で構成する必要があります。

1日あたりの回転は、必要なすべての <appender name="..." class="jetbrains.buildServer.util.TCRollingFileAppender"> アペンダ内に <param name="rotateOnDayChange" value="true"/> 行を追加することによって構成できます。この変更はデフォルトの conf\teamcity-server-log4j.xml に対して行われ、<TeamCity Data Directory>\config\_loggingに保存されているプリセットのロギングも行われます。

TeamCityは、構造化されていない方法でユーザー関連データを記録できるスレッドダンプなどの診断データも保存できます。 <[TeamCity Home](teamcity-home-directory.md)>\logs ディレクトリのコンテンツを定期的に確認し、そこに古いファイルが保存されていないことを確認することをお勧めします。また、デバッグログの収集などのカスタマイズセッションをログに記録した後、余分なログを削除する必要があります。logs\catalina.out ファイルが自動的にローテーションされない場合、既知の課題(英語)があります。ファイルを定期的にローテーションする自動手順を確立することをお勧めします。

カスタム

これらのノートは、最も一般的な文書化された設定でバンドルされたTeamCity機能性だけを扱います。構成されたビルドスクリプト、インストールされたプラグイン、APIを介してTeamCityと通信する外部システムなどのカスタマイズを考慮して、特定のTeamCityインストールを評価する必要があります。

TeamCityリリースサイクル

以下の情報は、参照目的にのみ使用できます。

以下の「メジャー」リリースは、最初または2番目のバージョン番号が変更されたリリースを意味します（例：X.X.ZのX）「バグ修正」リリースは、3番目のバージョン番号が変更されたリリースを意味する (たとえばX.X.ZのZ)

一般的に持っているリリース段階は次のとおりです。

  • EAPで利用可能 (早期アクセス・プログラム) - usually available only for major releases, starts several months after previous major release and usually months before the next major release. Typically new EAP releases are published(英語) on monthly or bi-monthly basis.

  • 一般提供予定 - 原則として、8か月ごとにメジャーリリースがあります。メジャーリリースに続いて複数のバグ修正リリースがあります。（該当する場合）重大な課題に対するバグ修正リリースおよびサポートパッチは、リリースの「販売終了」まで提供されています。

  • 販売終了 - 新しいメジャーバージョンのリリースとともに発生します。これ以降、バグ修正の更新やパッチは通常提供されません（例外は回避策のない重大な課題であり、同時に比較的簡単な修正と重要な理由でアップグレードできないことを可能にします）。これらのバージョンでは、限定的なサポートのみが提供されています。

  • サポート終了 - 2つの新しいメジャーバージョンのリリースで発生します。現時点では、リリースに対する定期的なテクニカルサポートの提供を中止しています。

以前のリリースの日付とTeamCityバージョンの順序は、以前のリリースダウンロード(英語)ページにリストされています。

最終更新日: 2020年8月31日
カスタムチャートの制限を編集するトラブルシューティング

関連ページ：

サポートされているプラットフォームと環境

このページはTeamCityが動作するソフトウェア関連の環境をカバーします。ハードウェア関連の注意事項については、このセクションを参照してください。プラットフォーム (オペレーティング・システム)：TeamCityサーバーTeamCityサーバーのコア機能はプラットフォームに依存しません。サーバープ...

パフォーマンスモニター

パフォーマンスモニタービルド機能を使用すると、ビルドエージェントでのビルド実行中にCPU、ディスク、およびメモリの使用量に関する統計を取得できます。パフォーマンスモニターは、Windows、Linux、macOS、Solaris、およびFreeBSDオペレーティングシステムをサポートしています。Pe...

Amazon EC2用のTeamCityのセットアップ

TeamCity Amazon EC2統合により、AmazonアカウントでTeamCityを構成し、キューに入れられたビルドに基づいてTeamCityエージェントでオンデマンドでイメージを開始および停止できます。他のクラウドソリューションとの統合が可能です。概要：マシンイメージは、起動時にTeamC...

マルチノード設定

TeamCityでは、メインインスタンスに加えて、1つ以上のセカンダリサーバーインスタンス（ノード）を構成および起動できます。メインノードとセカンダリノードは同じライセンスで動作し、TeamCityデータディレクトリとデータベースを共有します。マルチノードセットアップを使用すると、次のことができます...

REST APIリファレンス

プロジェクトとビルド構成/テンプレートリスト：プロジェクト一覧 GET http://teamcity:8111/app/rest/projects プロジェクトの詳細 GET http://teamcity:8111/app/rest/projects/<projectLocator&g...

クリーンアップ

TeamCityのクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。Clean-up r...