使い方...

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 Server 2008 R2 x64 での 12Gb メモリ、1Gb ネットワークアダプター、3 台の HDDRAID1 ディスク (一般に、アーティファクト、ログおよびキャッシュ記憶域用、データベース記憶域用)

サーバー負荷特性

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 を超える同時実行ビルドを定期的に超える場合は、いくつかのノード設定の使用を検討してください。

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

空のデータベースで最初に起動すると、TeamCity は管理者設定ページを表示します。このページでは、完全な管理権限を持つユーザーを作成できます（システム管理者ロールを割り当てる）。

システムへのアクセスを回復したいがシステム管理者ロールを持つユーザーとしてログインできない場合は、スーパーユーザーとしてログインして既存の管理者アカウントのパスワードを変更するか、システム管理者ロールを持つ新しいアカウントを作成します。

REST API を使用して既存のユーザーにシステム管理者のロールを追加することもできます。

組み込み認証を使用していて、正しいメールが指定されている場合は、ログインページからパスワードをリセットできます。

外部データベース容量の見積もり

必要な容量は TeamCity の使用方法によって大きく異なるため、外部データベースを設定または移行するときに正確な数値を提供することは非常に困難です。

データベースのサイズとデータベースのパフォーマンスは、考慮すべき重要な側面です。

データベースサイズ

データベースのサイズは次の要素によって異なります。

毎日いくつのビルドが開始されているか
ビルドから報告されたテストの数
clean-up の規則 (保存方針)
清掃スケジュール

データスペースの初期サイズは 4 GB にすることをお勧めします。内部データベースから移行する場合、現在の内部データベースのサイズを少なくとも 2 倍にすることをお勧めします。例: JetBrains の内部 TeamCity サーバーの外部データベース（REDO ログファイルなし）のサイズは約 50 GB です。データベースを自動的に拡張するように設定すると、必要に応じてファイルサイズを所定の制限まで増やすことができ、ディスクスペースを監視する手間を最小限に抑えることができます。

ほとんどの場合、REDO ログ（下の表を参照）および UNDO ファイルに 1 GB を割り当てるだけで十分です。

データベースパフォーマンス

以下の要因を考慮に入れる必要があります。

データベースの種類 (RDBMS)
エージェント数 (これは実際には並行して実行されているビルドの数を意味します)
すべてのユーザーによって開かれた Web ページの数
clean-up の規則 (保存方針)

（TeamCity サーバーと RDBMS が同じホストを共有している場合でも） TeamCity Data Directory とデータベースのデータファイルを物理的に異なるハードディスクに配置することをお勧めします。

特に多数のエージェント（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 が使用するデータベースの両方が一貫した状態を維持する必要があるため、一緒に複製する必要があります。
常に単一の TeamCity サーバーインスタンスのみがデータベースとデータディレクトリを使用する必要があります。

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

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

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

TeamCity セキュリティノート

このセクションの内容は、専用の記事に移動されました。

新しくインストールした 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>/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

TeamCity のような書き込みが多いアプリケーションでは、チェックポイント関連のパラメーター(英語)の一部を変更することをお勧めします。

PostgreSQL 9.5 以降の場合:

max_wal_size = 1500MB
checkpoint_completion_target=0.9

バージョン PostgreSQL 9.5 より前の場合:

checkpoint_segments=32
checkpoint_completion_target=0.9

synchronous_commit

TeamCity が PostgreSQL データベースを使用する唯一のアプリケーションの場合は、http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT(英語) パラメーターを無効にすることをお勧めします。

synchronous_commit=off

プロキシサーバーの背後に TeamCity をセットアップする

このセクションでは、TeamCity サーバーの WebUI の前にインストールされるリバースプロキシサーバーの推奨セットアップについて説明します。

例を考えてみましょう。
TeamCity サーバーはローカル 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 などのヘッダー、およびすべての不明なヘッダーは、変更されていない形式で TeamCity Web アプリケーションに渡す必要があります。例: 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 レスポンスが発生する可能性があります（関連する問題(英語)を参照）。

他のサーバー

リクエスト（アップロード）およびレスポンス（ダウンロード）のサイズとタイムアウト（コードベースとアーティファクトのサイズに応じて少なくとも数十分とギガバイト）に対して適切な（高い）制限を設定して、パフォーマンスの高いプロキシを必ず使用してください。

UI をすばやくリフレッシュするのに役立つため、WebSocket プロトコルで動作できるプロキシを使用することをお勧めします。

通常、TeamCity サーバーを「認識」するように構成する必要があります。クライアントが使用する元の URL について、クライアントがアクセスできる正しい絶対 URL を生成できます。これを実現するための推奨される方法は、元の Host ヘッダーを TeamCity に渡すことです。別の方法は、X-Forwarded-Host ヘッダーを元の Host ヘッダーの値に設定することです。

Host ヘッダーの値がプロキシによって変更され（元の Host ヘッダー値を保持することをお勧めします）、元の Host 値を持つ X-Forwarded-Host ヘッダーが提供されない場合は常に、Origin ヘッダーと Referer ヘッダーの値をマップする必要があることに注意してください。対応して、元の Host ヘッダー値が含まれている場合（含まれていない場合は、TeamCity CSRF の保護を回避しないように設定しないでください）。

以下のセクションから適切な方法を選択し、それに応じてプロキシを設定してください。

TeamCity Tomcat の設定

TeamCity Tomcat 構成の場合、2 つのオプションがあります。

パブリック URL の詳細がハードコードされたサーバー構成で専用の「コネクター」ノードを使用し、コネクターで構成されたポートが、構成されたパブリック URL への要求によってのみ使用されることを確認してください。
期限のある要求ヘッダーを渡すようにプロキシを構成します: Host または X-Forwarded-Host （元の要求ホスト）、X-Forwarded-Proto （元の要求プロトコル）、X-Forwarded-Port （元の要求ポート）、および TeamCity Tomcat 構成の "RemoteIpValve" を設定します。

専用の「コネクター」ノードアプローチ

設定されたポートが設定されたパブリック URL にのみ要求を受信している場合、このアプローチは任意のプロキシ設定で使用できます。

teamcity.public:400 へのすべての要求を TeamCity サーバー（以下の例では 8111 ）の専用ポートにリダイレクトするようにプロキシサーバーを設定し、「コネクター」を変更します。以下のように <TeamCity Home>/conf/server.xml ファイルのノード。「コネクター」に注意してください。このように構成されたポートには、構成されたプロキシのアドレスを介してのみアクセスできる必要があります。TeamCity ポートにも直接アクセスできるようにする場合は、別の「コネクター」を使用します。そのための専用の port 値を持つノード。

<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"
               />

パブリックサーバーアドレスが HTTPS の場合は、secure="true" 属性と scheme="https" 属性を使用します。これらの属性が欠落している場合、TeamCity はそれぞれのヘルスレポートを表示します。

"RemoteIpValve" アプローチ

このアプローチは、プロキシサーバーが X-Forwarded-Proto、X-Forwarded-Port 要求ヘッダーを元の URL の値に設定する場合に使用できます。また、ほとんどのセットアップでは重要ではありませんが、このアプローチを使用して、元のクライアント IP が TeamCity サーバーに正しく渡されるようにすることができます。これは、レガシーエージェントの双方向通信にとって重要です。

conf\server.xml ファイルの Tomcat メイン <Host> ノードに以下を追加します（Tomcat ドキュメント(英語)も参照）。

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

また、プロキシサーバーの IP アドレスのみに一致する正規表現で internalProxies 属性を指定することをお勧めします。例: internalProxies="192\.168\.0\.1"

スタックトレースを非表示にする

TeamCity サーバーにアクセスできるユーザーが無効なクロスサイトスクリプティング（XSS）ペイロードを送信すると、サーバーは関連するスタックトレースを含む「予期しないエラー」ページを表示します。このスタックトレースを介して環境に関する機密情報が公開されないようにするには、その表示を無効にすることができます。そのためには、teamcity.web.runtimeError.showStacktrace 内部プロパティを false に設定します。

TeamCity Web UI 用に HTTPS を構成する

TeamCity は、HTTPS アクセスのすぐに使用できるサポートを提供していません（TW-12976(英語) を参照）。HTTPS を処理し、アップストリームとして HTTP TeamCity サーバーポートを使用する TeamCity の前に Nginx や Apache などのリバースプロキシを設定することを強くお勧めします。プロキシの HTTPS 関連の構成は、TeamCity に固有のものではなく、他の Web アプリケーションと同様に一般的です。推奨事項に従ってリバースプロキシを構成してください。一般的な Web アプリケーションのベストプラクティスが適用されます（TeamCity への http アクセスを完全に無効にするなど）。

小規模サーバーの場合は、内部トムキャット手段(英語)を介して HTTPS をセットアップできますが、CPU 負荷が大幅に増加する可能性があるため、これはお勧めできません。

自己署名証明書を使用しながら HTTPS 経由で TeamCity サーバーにアクセスするようにクライアントを構成するには、関連する手順を確認してください。

発信接続にプロキシサーバーを使用するように TeamCity を構成する

このセクションでは、発信 HTTP 接続にプロキシサーバーを使用するように TeamCity を構成する方法について説明します。プロキシの背後にある TeamCity を Amazon EC2 クラウドエージェントに接続するには、このセクションを参照してください。

TeamCity サーバーは、問題トラッカーなどの他のサービスへの特定の発信 HTTP 接続にプロキシサーバーを使用できます。

TeamCity をプロキシサーバーにポイントするには、次の内部プロパティを設定します。

# 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

TeamCity サーバーに接続するためにプロキシを使用するように TeamCity エージェントを構成する

このセクションでは、TeamCity エージェントからサーバーへの接続用のプロキシサーバーの構成について説明します。

TeamCity エージェント側で、 buildAgent.properties ファイルの以下のプロパティを使用して TeamCity サーバーに接続するためのプロキシを指定します。

## 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 Data Directory> とデータベースを使用するように新しい TeamCity インストールを構成します（.BuildServer/config/database.properties はデータベースのコピーを指します）。
必要な環境転送を実行してください。

環境移転

既存の TeamCity インストール用に特別に変更されている場合は、関連環境を転送することを検討してください。これには以下が含まれます。

適切に設定された設定、グローバルおよびファイルシステムの権限で TeamCity サーバープロセスを実行するために適切な OS ユーザーアカウントを使用する
同じ TeamCity プロセス起動オプションを使用してください。具体的には、TEAMCITY_ で始まる環境変数をチェック / コピーしてください。
絶対パスを使用して TeamCity Web UI で構成されたすべてのファイル / 設定がアクセス可能であることを確認してください
デフォルトの SSH キー、キャッシュされた VCS アクセス認証情報などの OS レベルのユーザー / マシン設定に依存している場合は、それらも転送します
ネットワーク構成など、マシンに関連する特別な設定や例外の複製を検討する
TeamCity インストールにパッチが適用されている場合（GroovyPlug プラグイン、MS SQL Server 統合セキュリティ認証用のネイティブドライバー）、同じ変更をインストールコピーに適用します。
OS スタートアップ（Windows サービスなど）で TeamCity を実行する場合は、新しいマシンで同じ構成が実行されていることを確認してください。
<TeamCity Home>\conf\teamcity-startup.properties ファイルの設定を確認して転送します
<TeamCity Home>\conf\server.xml のカスタム設定を検討してください

ライセンスの問題

1 つの TeamCity ライセンスを、実行中の 2 つのサーバーで同時に使用することはできません。

冗長性 / バックアップ目的で作成されたサーバーのコピーは、一度に 1 つのサーバーのみが実行されるため、同じライセンスを使用できます。
テスト目的で作成されたサーバーのコピーには、追加のライセンスが必要です。TeamCity の公式ダウンロードページから、期間限定の TeamCity 評価ライセンスを 1 回取得できます。ライセンスの延長が必要な場合、または同じ TeamCity バージョンをすでに評価している場合は、当社のセールス部門にお問い合わせください。
定期的に / 運用目的でメインサーバーと同時に実行することを目的としたサーバーのコピーには、別のライセンスが必要です。

コピーしたサーバーのチェックリスト

コピーを作成している場合（この方法でサーバーを移動するのではなく）、以下のチェックリストに従うことが重要です。

新しいサーバーが元のサーバーとは別のデータディレクトリと別のデータベースを使用するように構成されていることを確認します。サーバーのグローバル設定の「アーティファクトディレクトリ」設定も確認してください。
「uuid」を削除してサーバーの一意の ID を変更します。最初の開始前の <TeamCity Data Directory>\config\main-config.xml ファイルの XML からの属性。
同じライセンスキーが複数のサーバーで使用されていないことを確認します（ライセンスの詳細）。
管理 | グローバル設定ページのサーバー URL をサーバーの実際の URL に更新します。
新しいサーバーで正常に認証できることを確認し、必要に応じてスーパーユーザーアクセスを使用します。
VCS サーバー、発行追跡サーバー、メールおよび Jabber サーバー、その他のサーバーアクセスシステムにアクセスできることを確認します。
イベントを TeamCity サーバーにプッシュするように構成されているシステム（VCS フック、自動ビルドトリガー、モニターなど）が更新されて、新しいサーバーについて認識されていることを確認します。
インストールされているプラグインのリストを確認して、設定を変更する必要があるかどうかを判断します。
新しいエージェントをインストールして（または既存のエージェントから選択して）新しいサーバーに接続するように設定します（新しいサーバー URL を使用）。
必要に応じて、サーバーから読み取るクライアント（アーティファクトのダウンロード、サーバーの REST API、NuGet フィードなどを使用）が再設定されていることを確認します。

テストサーバーを作成する場合は、ユーザーと本番システムが影響を受けないことを確認する必要があります。通常、これは次のことを行う必要があることを意味します。

Email、Jabber（Administration> Notifier セクション）を無効にし、場合によってはカスタムの Notifier を設定したり、新しいサーバーが通知を送信しないように設定を変更したりします。
メールの確認を無効にします（Administration> Authentication セクション）。
本番環境を変更する（デプロイするなど）ビルドを実行しないでください。これには通常、非ローカルリポジトリにデプロイする Maven ビルドも含まれます。ビルドキューを一時停止すると、ビルドが開始されないようにすることができます。
クラウド統合を無効にします（メインサーバーに干渉しないようにするため）。
外部のアーティファクトストレージを無効にします（そうしないと、ビルドおよびサーバーのクリーンアップを実行 / 削除すると、運用サーバーで使用されるストレージに影響します）。
Docker レジストリのクリーンアップを無効にします（またはサーバーのクリーンアップを無効にします）。
Commit Status Publishing を無効にします。
TeamCity イベントに基づいて、コピーされていない他のシステムにデータをプッシュするプラグインを無効にします。
VCS にプロジェクト設定を保存する機能を無効にします。teamcity.versionedSettings.enabled=false 内部プロパティを設定します。
VCS による変更間隔の確認（サーバー全体のデフォルトで VCS ルートでオーバーライドされる）を大幅に増やすか、VCS ルートの設定を変更して本番サーバーに接続しないようにすることを検討してください。TW-47324(英語) も参照してください。

サーバーをあるマシンから別のマシンに移動する方法については、以下のセクションも参照してください。

TeamCity プロジェクトをあるサーバーから別のサーバーに移動する

既存のデータを使用せずにデータを新しいサーバーに移動する必要がある場合は、サーバーを移動するかコピーしてから、新しいサーバーでは不要なデータを削除することをお勧めします。

新しいサーバー上の既存のデータとデータを結合する必要がある場合は、ほとんどの関連データを含むプロジェクトをあるサーバーから別のサーバーに移動するための専用の機能があります。プロジェクトインポート。

設定を実行したい場合に備えて、設定を手動で移動する際の注意事項を次に示します。

TeamCity 8.0 以降、簡単なファイルコピーで、プロジェクトの設定またはビルド構成を別のサーバーに移動できます。以前の TeamCity バージョンについては、コメント(英語)を参照してください。

2 台の TeamCity サーバー（ソースとターゲット）は、まったく同じバージョン（同じビルド）でなければなりません。

すべてのプロジェクト、ビルド構成、両方のサーバーの VCS ルートで使用されるすべての識別子は一意である必要があります。そうでない場合は、Web UI を介して変更できます。同じ ID を持つエンティティが異なるサーバーに存在する場合、それらのエンティティは同じであると見なされます。たとえば、これは、すべてのサーバーでグローバルな VCS ルートセットを持つ場合に便利です。

プロジェクトとそのすべてのビルド構成の設定をあるサーバーから別のサーバーに移動するには、次の手順を実行します。

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 profiles、handle.exe などのツール、外部変更ビューアー、ビルドキューの優先順位、問題追跡システム）。これらは .BuildServer\config ディレクトリのさまざまなファイルに保存され、ファイルレベルで、またはサーバー管理 UI で同じ設定を構成することによって同期する必要があります。
エージェントプールとのプロジェクトの関連付け
コピーされたものの親ではない他のプロジェクトからのテンプレート。この設定は TeamCity 8.0 では実際には推奨されておらず、レガシーとしてのみサポートされています。複数のプロジェクトで使用されているテンプレートは、共通の親プロジェクトまたはルートプロジェクトに移動する必要があります。
エージェントにデータが構成されていない（エージェント上で実行が許可されているビルド構成）。
ユーザー関連またはユーザーグループ関連の設定はありません (ロールや通知規則のように)
ミュートや調査などの状態関連のデータはありません。

TeamCity インストールを新しいマシンに移動する

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

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

サーバーをあるマシンから別のマシンに移動するときに、既存のライセンスキーを使用できます（同時に 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 エージェントは、ビルドの前にディレクトリを作成し、ビルドの直後にそれを削除します。

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

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

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

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

REST API を使用
ディスク上の設定ファイルを直接変更する ( <TeamCity Data Directory> で詳細を見る)
オープン 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 内から特定のツールを実行できます。特定のツールの使用方法を簡単にするために、それをメタランナーにラップするか、そのためのカスタムプラグインを書くことが可能です。

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

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

さらなる推奨事項

ターゲット環境ごとに別々のビルド構成をセットアップする
ビルドのバイナリ生成とビルド / タスクのデプロイ間のナビゲーションには、ビルドの依存関係タブを使用します。
必要に応じて、「プロンプト」表示モードのパラメーターを使用して、ビルドの実行時に「確認(英語)」を要求します
ビルド構成の「タイトルを変更(英語)」「実行」ボタン

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

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

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>/config/_trash ディレクトリに移動し、ディレクトリに "<internal ID>" サフィックスを追加します。

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

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

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

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

これは不可能です。

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

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

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 アップグレードを実行する必要があります。

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

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

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

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

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

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

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

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 データディレクトリのアーカイブファイルに保存されます）> \ system \ artifacts ***。teamcity \ properties ディレクトリ）。

ユーザーの削除およびその他のデータのクリーニングの後、検索インデックスから削除されたユーザーのキャッシュされた可能性のあるデータを整理するために必ず検索インデックスをリセットしてください。

ユーザー関連のデータを保持できる場所は他にもいくつかあります

ユーザーに「プロジェクトの編集」権限がある場合は、フルネーム / ユーザー名を次の場所に表示できます。

いくつかの監査エントリ（2017.2.1 より前の TeamCity バージョンで保存） - TW-52215(英語)
「保留中の永続的タスクが完了するのを待つ」ビルドログ行の一部のビルドログ（2017.2.1 より前の TeamCity バージョンで保存） - TW-52872(英語)
UI で変更を行ったユーザーのバージョン付き設定ストア名を格納しているリポジトリにコメントをコミットします

VCS 関連データ内の VCS ユーザ名:

VCS での変更は UI に表示されるか、データベースに保存されます。
サーバーおよびエージェント上のローカル .git リポジトリクローン内

ユーザー名は、VCS ルート、issue tracker、データベースアクセスなど、さまざまな統合で設定されたアクセス資格情報にも表示されることがあります。(これらは 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 インストールを評価する必要があります。

最終更新日: 2021 年 2 月 26 日