使い方 ...

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

サーバー / OS が要件を満たせば、TeamCity はどのシステムでも実行できます。使用する予定の統合の要件も確認してください。たとえば、TeamCity サーバーが Windows にインストールされている場合、次の機能が必要になるか、より適切に機能します。

TFS と VCS の統合
VSS と VCS の統合
Windows ドメインログイン（Linux でも動作しますが、不安定になる可能性があります）、特に NTLM HTTP 認証
サーバー上の NuGet フィード (Linux でも動作しますが、安定していない可能性があります。)
Windows マシンへのエージェントプッシュ

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

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

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

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

エージェントのハードウェア要件は、基本的に実行されるビルドによって決定されます。TeamCity エージェントソフトウェアを実行すると、追加の CPU 時間（ただし、ビルドプロセスの CPU 要件と比較すると、通常は無視できます）と追加のメモリ（約 500Mb）が必要になります。必要なディスク容量は、エージェントで実行されているビルドによるディスク使用量に対応します（ソースチェックアウト、ダウンロードされたアーティファクト、ビルド中に消費されたディスク容量、これらすべてが定期的に発生するビルドで組み合わされます）。TeamCity サーバーと同じマシンでビルドエージェントを実行できますが、推奨されるアプローチは、ビルドエージェントごとに個別のマシン（仮想の場合もあります）を使用することです。同じマシンに複数のエージェントをインストールすることを選択した場合は、発生する可能性のある CPU、ディスク、メモリ、またはネットワークのボトルネックを考慮してください。パフォーマンスモニタービルド機能は、ライブデータの分析に役立ちます。

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

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

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

CPU：TeamCity は CPU の複数のコアを使用するため、コアの数を増やすことは理にかなっています。自明ではない TeamCity を使用するには、少なくとも 4 つの CPU コアをお勧めします。
メモリ：TeamCity サーバーのメインプロセスと子プロセスによって使用されます（Maven 統合、バージョン管理統合、Kotlin DSL 実行に使用されます）。メインプロセスのメモリ使用量に関する注意事項を参照してください。一般に、100 を超える同時ビルド（エージェント）を実行したり、200 を超えるオンラインユーザーをサポートしたり、大規模なリポジトリで作業したりする予定がない場合は、おそらく 4G を超えるメモリを TeamCity サーバー専用にする必要はありません。
HDD / ディスク使用量：これは、主に一時ディレクトリの使用量（<TeamCity Home>/temp および OS のデフォルトの一時ディレクトリ）と <TeamCity Data Directory>/system の使用量を合計したものです。TeamCity サーバーのパフォーマンスは、ディスクシステムのパフォーマンスに大きく依存します。TeamCity は <TeamCity Data Directory>/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 ディレクトリの格納に高速ハードディスクを使用し、エージェントとサーバー間の高速ネットワークを使用することをお勧めします。

大規模な TeamCity インストールをデプロイするための一般的な推奨事項は、ハードウェアのアップグレードを検討しながら、妥当なハードウェアから始めることです。次に、サーバーの負荷を徐々に増やし（プロジェクトを追加するなど）、パフォーマンス特性を監視し、必要なハードウェアまたはソフトウェアの改善を決定します。現在のサーバーのインストールで処理できる同時ビルドの数を推定するために使用できるベンチマークプラグイン(英語)もあります。適切なディスク最適化レベルを維持するなど、管理のベストプラクティスをお勧めします。

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

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 サーバーの設定

パフォーマンスを向上させるために TeamCity サーバーの設定を調整するための推奨事項は次のとおりです。実動サーバー用のリストは前提条件です。

報告された Server Health レポートを定期的に確認する (隠されたものを含む)
HTTPS を処理するために別のリバースプロキシサーバー（たとえば NGINX）を使用する
外部データベースに別のサーバーを使用してデータベースのパフォーマンスを監視する
サーバーの CPU と IO のパフォーマンスを監視し、必要に応じてハードウェアリソースを増やす ( ハードウェアノートも参照)
クリーンアップがすべてのプロジェクトに対して適切な保存方針で構成されていることを確認し、クリーンアップが完全に定期的に終了することを確認する (管理 / クリーンアップページを確認してください)
<TeamCity Data Directory>/system/caches ディレクトリの良好な IO パフォーマンスを確保することを検討してください。別のローカルドライブに移動する (または TeamCity Data Directory をネットワークストレージに保存することを選択したローカルドライブに保存する)
古くなったプロジェクトを定期的にアーカイブする
インストールされていないバンドルされていないプラグインを定期的に確認し、サーバーの機能に不可欠ではないプラグインを削除します。
できるだけエージェントサイドのチェックアウトを使用することを検討してください
ビルドログが大きくないことを確認してください (せいぜい数十メガバイト、10 メガバイト以下)
多数の VCS ルートがサーバー上で構成されている場合は、変更のポーリングを使用する代わりにリポジトリコミットフックを構成するか、少なくとも VCS ポーリング間隔を 300 秒以上に増やすことを検討してください。
サーバーが多数のユーザー（たとえば 1000 人以上）によって使用されることが多い場合は、UI リフレッシュ間隔を増やしてバックグラウンド UI 要求の頻度を減らすことを検討してください。
大量のデータを記録する 500 を超える同時実行ビルドを定期的に超える場合は、いくつかのノード設定の使用を検討してください。

Retrieve Administrator Password

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 ノードを追加して、高可用性を確保し、メインサーバーから一部の操作をオフロードすることができます。すべてのノードを同じ TeamCity Data Directory とデータベースに接続する必要があります。

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

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

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

TeamCity エージェントファームは、メインサーバーとフェイルオーバーサーバーの間で再利用できます。フェイルオーバーサーバーを古いサーバーの DNS 名で解決し、エージェントが DNS 名を使用してサーバーに接続すると、エージェントは自動的に新しいサーバーに接続します。あるサーバーから別のサーバーへの切り替えに関する情報も参照してください。
必要に応じて、エージェントをサーバーと同じように複製できます。ただし、conf \ buildAgent.properties ファイルを除いて、エージェントで TeamCity 固有のデータを複製する必要はありません。これは、残りのすべてのデータは通常、サーバーから更新できるためです。レプリケートされたエージェントファームの場合、レプリカエージェントはフェイルオーバーサーバーに接続する必要があります。

冗長性の目的で 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>\conf\teamcity-startup.properties ファイルに追加することを検討してください。これにより、空のデータベースで起動されたサーバーが、最初に来るユーザーにマシンへのアクセスを許可しなくなります。

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

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

最新の TeamCity バージョンを実行しており、数週間以内に新しくリリースされたバージョンにアップグレードする準備が整いました
TeamCity Web インターフェースへのアクセスは HTTPS を使用して保護されています（たとえば NGINX のようなプロキシサーバーの助けを借りて）。Web アプリケーションを保護するためのベストプラクティスは、TeamCity Web インターフェースに採用されています。例：HTTP プロトコルを使用してサーバーにアクセスすることは不可能です。リバースプロキシが Referer リクエストヘッダを削除しない
TeamCity サーバーマシンはエージェントを実行しません (少なくとも <TeamCity server's home directory> および <TeamCity Data Directory> の読み取りを許可されたユーザーの下)
TeamCity サーバーとエージェントのプロセスは、最小限の必要な権限で制限されたユーザーで実行されます。インストールディレクトリは、限られた OS ユーザーのセットのみが読み取りおよび書き込みできます。 conf\buildAgent.properties ファイルとサーバーログ、およびデータディレクトリは、サービスの管理者を表す OS ユーザーのみが読み取ることができます。これらの場所を読み取ると、エージェントまたはサーバーをそれぞれ引き継ぐことができるためです。
ゲストユーザーおよびユーザー登録が無効になっているか、ゲストおよびすべてのユーザーグループのロールが見直されている
管理者権限を持つ TeamCity ユーザーは重要なパスワードを持っています
LDAP などの外部認証が設定されている場合、組み込み認証モジュールは無効になります。
パスワードはビルドログに出力されず、ビルドアーティファクトにも保存されず、パスワード以外のパラメーターにも保存されません。

Here are some notes on different security-related aspects:

man-in-the middle concerns
- 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.
- between a TeamCity agent and the TeamCity server: see this section.
- between the TeamCity server and other external servers (version control, issue tracker, etc.): the general rules apply as for a client (the TeamCity server in the case) connecting to the external server, see the guidelines for the server in question.
users that have access to the TeamCity web UI: the specific information accessible to the user is defined via TeamCity user roles.
users who can change the code that is used in the builds run by TeamCity (including committers in any branches/pull requests if they are built on TeamCity):
- can do everything the system user, under whom the TeamCity agent is running, can do; have access to OS resources and other applications installed on the agent machines where their builds can run.
- can access and change source code of other projects built on the same agent, modify the TeamCity agent code, publish any files as artifacts for the builds run on the agent (which means the files can be then displayed in the TeamCity web UI and expose web vulnerabilities or can be used in other builds), etc.
- can impersonate a TeamCity agent (run a new agent looking the same to the TeamCity server).
- can do everything that users with the "View build configuration settings "permission for all the projects on the server can do (see below).
- can retrieve settings of the build configurations where the builds are run, including the values of the password fields.
- 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.
users with the "View build configuration settings" permission (the "Project developer" TeamCity role by default) can view all the projects on the server, but since TeamCity 9.0 there is a way to restrict this, see details in the corresponding issue TW-24904(英語)。
users with the" Edit project "permission (the "Project Administrator" TeamCity role by default) in one project, by changing settings can retrieve artifacts and trigger builds from any build configuration they have only the view permission for (TW-39209(英語)). The users might also be able to make the TeamCity server run any executable located on the server.
users with the "Change server settings" permission (the "System Administrator" TeamCity role by default): It is assumed that the users also have access to the computer on which the TeamCity server is running under the user account used to run the server process. Thus, the users can get full access to the machine under that OS user account: browse file system, change files, run arbitrary commands, etc.
TeamCity server computer administrators: have full access to TeamCity stored data and can affect TeamCity executed processes. Passwords that are necessary to authenticate in external systems (like VCS, issue trackers, etc.) are stored in a scrambled form in TeamCity Data Directory and can also be stored in the database. However, the values are only scrambled, which means they can be retrieved by any user who has access to the server file system or database.
Users who have read access to the TeamCity server logs (TeamCity server home directory) can escalate their access to TeamCity server administrator.
Users who have read access to <TeamCity Data Directory> can access all the settings on the server, including configured passwords.
Users who have read access to the build artifacts in <TeamCity Data Directory>/system/artifacts get the same permissions as users with the "View build runtime parameters and data" permission (in particular, with access to the values of all the password parameters used in the build).
TeamCity agent computer administrators: same as "users who can change code that is used in the builds run by TeamCity".
It is recommended to distribute projects among agents, so that one TeamCity agent would not run builds of several projects whose developers and administrators should not get access to each other's projects. The recommended way to distribute projects is to use the agent pools feature and make sure that the "Default" agent pool has no agents as a project can be assigned to the Default pool after a certain reconfiguration (i.e. when there is no other pool the project is assigned to).
When storing settings in VCS is enabled:
- any user who can access the settings repository (including users with "View file content" permission for the build configurations using the same VCS root) can see the settings and retrieve the actual passwords based on their stored scrambled form
- any user who can modify settings in VCS for a single build configuration built on the server, via changing settings can retrieve artifacts and trigger builds from any build configuration they have only view permission for (TW-39192(英語)).
- users who can customize build configuration settings on a per-build basis (e.g. one who can run personal builds when versioned settings are set to "use settings from VCS") via changing settings in a build can retrieve artifacts and trigger builds from any build configuration they have only view permission for (TW-46065(英語)).
Other:
- TeamCity web application vulnerabilities: the TeamCity development team makes a reasonable effort to fix any significant vulnerabilities (like cross-site scripting possibilities) once they are uncovered. Please note that any user that can affect build files ("users who can change code that is used in the builds run by TeamCity" or "TeamCity agent computer administrators") can make a malicious file available as a build artifact that will then exploit cross-site scripting vulnerability. (TW-27206(英語))
- TeamCity agent is fully controlled by the TeamCity server: since TeamCity agents support automatic updates download from the server, agents should only connect to a trusted server. An administrator of the server computer can force execution of arbitrary code on a connected agent.
- Binaries of the agent plugins installed on the server are available to anyone who can access the server URL

What Encryption is Used by TeamCity

TeamCity tries not to pass password values via the web UI (from a browser to the server) in clear text: instead, it uses RSA(英語) with 1024-bit key to encrypt them. However, it is recommended to use the TeamCity web UI only via HTTPS so this precaution should not be relevant. TeamCity stores passwords in the settings (where the original password value is necessary to perform authentication in other systems) in a scrambled form. The scrambling is done using 3DES with a fixed key, or using a custom key.

Configure Newly Installed MySQL Server

If MySQL server is going to be used with TeamCity in addition to the basic setup, you should review and probably change some of the MySQL server settings. If MySQL is installed on Windows, the settings are located in my.ini file which usually can be found under MySQL installation directory. For Unix-like systems the file is called my.cnf and can be placed somewhere under /etc directory. Read more about configuration file location in MySQL documentation(英語). Note: you'll need to restart MySQL server after changing settings in my.ini|my.cnf.

The following settings should be reviewed and/or changed:

InnoDB database engine

Make sure you're using InnoDB database engine for tables in TeamCity database. You can check what engine is used with help of this command:

show table status like '<table name>';

or for all tables at once:

show table status like '%';

max_connections

You should ensure max_connections parameter has a bigger value than the one specified in TeamCity <TeamCity Home Directory>/config/database.properties file.

innodb_buffer_pool_size and innodb_log_file_size

Specifying a too small value in innodb_buffer_pool_size may significantly affect performance:

# 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

We recommend to start with 2Gb and increase it if you experience slowness and have enough memory. After increasing buffer pool size you should also change size of the 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>;

Configure Newly Installed PostgreSQL Server

For better TeamCity server performance, it is recommended to change some of the parameters of the newly installed PostgreSQL server. You can read more about PostgreSQL performance optimization in PostgreSQL Wiki(英語).

The parameters below can be changed in the postgresql.conf file located in the in PostgreSQL's data directory.

shared_buffers

The default value of http://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-SHARED-BUFFERS(英語) parameter is too small and should be increased:

shared_buffers=512MB

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.

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

TeamCity が「知っている」ことを確認するにはクライアントがリソースにアクセスするために使用する実際の絶対 URL は、次のことを行う必要があります。

リバースプロキシを設定します。;
TeamCity にバンドルされている Tomcat サーバーを構成します。

これらの URL は、クライアントのリダイレクトやその他の応答で絶対 URL を生成するために使用されます。

注：内部 TeamCity サーバーは、外部アドレスによって外部から見えるのと同じコンテキスト（つまり、ホスト名の後の URL の一部）で動作する必要があります。TeamCity サーバーのコンテキスト変更手順も参照してください。
別のコンテキストでサーバーを実行する必要がある場合は、コンテキスト変更プロキシがこの事実を TeamCity から隠蔽する必要があることに注意してください。たとえば、サーバーリダイレクト URL と Cookie 設定パスを元の（外部）コンテキストにマップする必要があります。

プロキシサーバーの設定

プロキシは、一般的な Web セキュリティを念頭に置いて構成する必要があります。 Referer や Origin などのヘッダー、およびすべての不明なヘッダーは、変更されていない形式で TeamCityWeb アプリケーションに渡す必要があります。例：TeamCity は、クライアントによって追加された X-TC-CSRF-Token ヘッダーに依存しています。

Apache

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

<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 構成では、" RemoteIpValve "アプローチを使用して TeamCity サーバーを構成します。

バージョン 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 になる可能性があります）。
gzipContent- エンコーディングは完全にサポートされています。例：特定の IIS 構成では、UI に「データを読み込んでいます ...」と 500 の HTTP レスポンスが発生する可能性があります（関連する課題(英語)を参照）。

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).

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

Note that whenever the value of the Host header is changed by the proxy (while it is recommended to preserve the 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 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 the port configured in the connector is used only by the requests to the public URL configured.
Configure the 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 the "Connector" node in <TeamCity Home>/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.

<Connector port="8111" protocol="org.apache.coyote.http11.Http11NioProtocol"
               connectionTimeout="60000"
               useBodyEncodingForURI="true"
               socket.txBufSize="64000"
               socket.rxBufSize="64000"
               tcpNoDelay="1"
               proxyName="teamcity.public"
               proxyPort="400"
               secure="false"
               scheme="http"
               />

When the public server address is HTTPS, use the secure="true" and scheme="https" attributes. If these attributes are missing, TeamCity will show a respective health report.

"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」という行を追加します。

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

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

サーバーポートの変更

サーバーのインストール手順の対応するセクションを参照してください。

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

運用サーバーをアップグレードする前に、新しい TeamCity バージョンを試すことをお勧めします。通常の手順では、本番用の TeamCity インストールのコピーを作成してからアップグレードし、試してみて、すべての項目を確認したら、テストサーバーを削除してメインサーバーをアップグレードします。テストサーバーを起動したら、サーバーの URL を変更し、メール通知と Jabber 通知、および新しいサーバー上の他の機能を無効にしてください。

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

元のサーバーとコピーを保存したい場合は、ライセンスに関する考慮事項を必ず確認してください。

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

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

TeamCity バックアップを使用

すべてを含むバックアップを作成してください。（ビルドログをバックアップするオプションはスキップできます。アーティファクトを移動している場合は、下記を参照してください）。
すでに実行しているのと同じバージョンの新しい TeamCity サーバーをインストールします。確認しておいて：
- 適切な環境が構成されている (下記のメモを参照)
- サーバーは独自の <TeamCity Data Directory> と独自のデータベースを使用します ( <TeamCity Data Directory>config/database.properties ファイルを確認する)
バックアップを復元します。
<TeamCity Data Directory>/system/artifacts ディレクトリのコンテンツを古い場所から新しい場所に移動して、アーティファクト（これらはバックアップに含まれません）を移動します。アーティファクトのサイズが大きくなる可能性があるため、これには長い時間がかかる可能性があるため、それに応じて計画を立ててください。
必要な環境転送を実行してください。

手動コピー

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

問題が発生した場合に復元できるように、バックアップを作成します。
サーバーが稼働していないことを確認します。
クリーンインストールを実行するか、TeamCity バイナリ（ TeamCity Home Directory ）を新しい場所にコピーします（ temp および work サブディレクトリはコピー中に省略できます）。まったく同じ TeamCity バージョンを使用してください。コピー後にアップグレードする場合は、既存のバージョンを起動して実行してからアップグレードを実行してください。
<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 （オプション）は、新しいサーバーにコピーする必要はありません。起動時に再作成されますが、再構築に時間がかかる場合があります。(多少の減速が予想されます)
アーティファクトディレクトリは通常大きいです。サーバーを移動するときにサーバーのダウンタイムを最小限に抑える必要がある場合は、データをコピーするための一般的なアプローチを使用できます。元のサーバーの実行中に、rsync、robocopy などのツールを使用してデータをコピーします。同期データの量が減少するまで、同期実行を数回繰り返します。元のサーバーのシャットダウン後に最後の同期を実行します。サーバー移動の代替ソリューションは、古いデータアーティファクトディレクトリを新しいサーバーにアクセス可能にし、それをアーティファクトの 2 番目の場所として構成することです。次に、サーバーの実行中に、この 2 番目の場所からメインの場所にファイルをコピーします。コピー完了後、サーバーを再起動します。
TeamCity インストールで使用しているデータベースのコピーを、新しいスキーマまたは新しいデータベースサーバーに作成します。これは、データベース固有のツールまたはバンドルされた maintainDB ツールを使用して、データベースのデータをバックアップしてから復元することで実行できます。
新しい TeamCity インストールを構成して、適切な <TeamCity Data Directory> とデータベースを使用する ( .BuildServer/config/database.properties はデータベースのコピーを指する)
必要な環境転送を実行してください。

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>\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.

A copy of the server created for redundancy/backup purposes can use the same license as only one of the servers will be running at a time.
A copy of the server created for testing purposes requires an additional license. You can get the time-limited TeamCity evaluation license once from the official TeamCity download page. If you need an extension of the license or you have already evaluated the same TeamCity version, please contact our sales department.
A copy of the server intended to run at the same time as the main one regularly/for production purposes requires a separate license.

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>\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 インストールを新しいマシンに移動する

新しいハードウェアやクリーンな OS への既存の TeamCity のインストールを移動する必要がある場合は、同じ TeamCity Data Directory に新しいサーバーを接続し、古いサーバーを停止し、新しいマシン上で同じ TeamCity バージョンをインストールし、確認サーバーが使用することができます同じ環境。または、サーバーをあるマシンから別のマシンにコピーする手順に従うこともできます。

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

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

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

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

<TeamCity Data Directory> とデータベースは、常に単一の 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 があります。同じソースを使用し、同じビルド番号を取得します。
以下を実施：

ビルド構成 C を作成し、次にスナップショットの依存関係（A に C と B の C）を作成します。
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> で詳細を見る)
オープン API(英語) を使用してタスクを実行する TeamCityJava プラグインを作成します。

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 内から特定のツールを実行できます。特定のツールの使用方法を簡単にするために、それをメタランナーにラップするか、そのためのカスタムプラグインを書くことが可能です。

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

ディスク上の利用可能なバイナリファイルに対してデプロイタスクを実行するビルドスクリプトを書きます。（たとえば、Ant または MSBuild を使用してください。通常のデプロイトランスポートでは、デプロイヤーランナーを使用してください）。ビルドおよびレポート作成ツールと統合するも参照してください。便利な UI でスクリプトを再利用するためにメタランナーを使うことができます。
TeamCity でビルドスクリプトを実行して実際のデプロイを実行するビルド構成を作成します。デプロイを限定されたユーザーセットのみが表示または起動できるようにする場合は、ビルド構成を別の TeamCity プロジェクトに配置し、ユーザーがプロジェクトで適切な権限を持っていることを確認してください。
このビルド構成では、デプロイする必要のあるバイナリを生成するビルド構成へのアーティファクトの依存関係を構成します。
デプロイを自動的にトリガーする必要がある場合（最後の固定ビルドのうち最後に成功したものをデプロイする場合など）、デプロイするビルド構成で使用可能なトリガーの 1 つを構成するか、デプロイするバイナリを生成したビルドで「プロモート」アクションを使用します。
成果物の依存関係に加えてスナップショット依存関係の使用を検討し、ビルドチェーンタブをチェックしてビルドの概要を確認してください。この場合、成果物の依存関係は「同じチェーンからビルド」オプションを使用する必要があります。
デプロイをパラメーター化する必要がある場合（たとえば、異なる実行で異なるターゲットマシンを指定する場合）、カスタムビルド実行ダイアログを使用してビルドスクリプトにパラメーターを渡します。型付きパラメーターを使用して、カスタム実行ダイアログを使いやすくしたり、パスワードを処理したりすることを検討してください。
デプロイするビルドが手動で起動された場合は、ビルドスクリプトにコマンドを追加してデプロイされるビルドを固定してタグ付けすることも検討してください（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 レポートの 1 つを生成し、構成済みの XML レポート処理ビルド機能のサービスメッセージを介してインポートできます。

一般的なレポートの結果を表示するためのアプローチは、ビルドスクリプトで HTML レポートを生成し、それをアーカイブにパックして、ビルドアーティファクトとして公開することです。次に、ビルドの結果のタブとして HTML レポートを表示するようにレポートタブを構成します。

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

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

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

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

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

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

プロジェクトを復元するには、_trash ディレクトリでプロジェクトディレクトリを見つけて、それを通常のプロジェクト設定ディレクトリ <TeamCity Data Directory>/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 に公開します。そうすると、ビルド構成の統計タブにカバレッジチャートが表示され、ビルドを失敗させることができます。メトリックの変更によるビルドの失敗条件（たとえば、カバレッジが低下した場合にビルドに失敗する可能性があります）。

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

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

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

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

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

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

TeamCity Web UI のエージェントページに移動し、エージェントを選択します。
ビルドグリッドから一時的に削除するエージェントを無効にします。コメントを追加します（オプション）。特定の期間後にエージェントを自動的に有効にするには、対応するボックスをオンにして時間を指定します。
デバッグするビルドを選択。
カスタムランダイアログを開き、以下のオプションを指定します。エージェントドロップダウンで、無効化されたエージェントを選択します。b。通常のビルドとの交差を避けるために、パーソナルビルドとして実行オプションを選択することをお勧めします。
デバッグが完了したら、自動再有効化が設定されていない場合はエージェントを手動で有効化します。

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

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

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

ビルド設定にジャンプし、デバッグしたいものまでのビルドステップを無効にします。
デバッグするビルドを選択。
カスタムランダイアログを開き、ビルドをキューの先頭に置くを選択して優先順位を付けます。
デバッグが完了したら、ビルド手順を再度有効にします。

脆弱性

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

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>\logs ディレクトリの内容を定期的に確認し、古いファイルがそこに保存されていないことを確認することをお勧めします。また、デバッグログの収集などのカスタマイズセッションをログに記録した後、余分なログを削除する必要があります。logs\catalina.out ファイルが自動的にローテーションされない場合、既知の課題(英語)があります。ファイルを定期的にローテーションする自動手順を確立することをお勧めします。

カスタム

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

TeamCity リリースサイクル

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

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

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

EAP で利用可能 (早期アクセスプログラム) - 通常はメジャーリリースでのみ利用可能で、前のメジャーリリースの数か月後、通常は次のメジャーリリースの数か月前に開始されます。通常、新しい EAP リリースは月次または隔月ベースで公開(英語)されます。
一般提供予定 - 原則として、8 か月ごとにメジャーリリースがあります。メジャーリリースに続いて複数のバグ修正リリースがあります。（該当する場合）重大な課題に対するバグ修正リリースおよびサポートパッチは、リリースの「販売終了」まで提供されています。
販売終了 - 新しいメジャーバージョンのリリースとともに発生します。これ以降、バグ修正の更新やパッチは通常提供されません（例外は回避策のない重大な課題であり、同時に比較的簡単な修正と重要な理由でアップグレードできないことを可能にします）。これらのバージョンでは、限定的なサポートのみが提供されています。
サポート終了 - 2 つの新しいメジャーバージョンのリリースで発生します。現時点では、リリースに対する定期的なテクニカルサポートの提供を中止しています。

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

最終更新日 : 2020 年 11 月 24 日