使い方...

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、8Gbのメモリ、高速ネットワーク接続、高速で信頼性の高い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を超える同時実行ビルドを定期的に超える場合は、いくつかのノード設定の使用を検討してください。

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

空のデータベースで最初に起動すると、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はメインサーバーの単一インスタンスのみをサポートしますが、現在のデータに対して表示専用のUIを提供し、エージェントから実行中のビルドデータを収集するためにセカンダリノードを追加することは可能です。すべてのノードが同じ 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 Home Directory >\conf\teamcity-startup.properties ファイルに teamcity.installation.completed=true 行を追加することを検討してください。これにより、空のデータベースで起動したサーバーが最初に来るユーザーにマシンへのアクセスを許可できなくなります。

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などの外部認証が設定されている場合、組み込み認証モジュールは無効になります。
パスワードはビルドログに出力されず、ビルドアーティファクトにも保存されず、パスワード以外のパラメータにも保存されません。

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

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

中間者の懸念
- TeamCityサーバーとユーザーのWebブラウザの間：TeamCityサーバーにはHTTPSを使用することをお勧めします。ログイン中、TeamCityはユーザーのログインパスワードを中程度の暗号化レベルの暗号化形式で送信します。
- TeamCityエージェントとTeamCityサーバーの間：このセクションを参照してください。
- TeamCityサーバーと他の外部サーバー（バージョン管理、課題トラッカーなど）の間：外部サーバーに接続するクライアント（この場合TeamCityサーバー）に関して一般的な規則が適用されます。課題のサーバーのためのガイドラインを参照してください。
TeamCity Web UIにアクセスできるユーザー：ユーザーがアクセスできる特定の情報はTeamCity ユーザーロールを介して定義されます。
TeamCityによって実行されるビルドで使用されるコードを変更できるユーザー（TeamCityでビルドされている場合はブランチ / pull要求のコミッターも含む）：
- TeamCityエージェントが実行されているシステムユーザーが実行できるすべてのことを実行できます。ビルドを実行できるエージェントマシンにインストールされているOSリソースおよびその他のアプリケーションにアクセスできます。
- 同じエージェント上でビルドされた他のプロジェクトのソースコードにアクセスして変更したり、TeamCityエージェントコードを変更したり、ビルド用の成果物として任意のファイルをエージェント上で実行したりできます（つまり、TeamCity Web UIに表示してWebを公開できます）脆弱性または他のビルドで使用することができます）、など
- TeamCityエージェントになりすますことができます（TeamCityサーバーと同じように見える新しいエージェントを実行します）。
- サーバー上のすべてのプロジェクトに対して「ビルド構成設定の表示」権限を持つユーザーができることはすべて実行できます（下記参照）。
- パスワードフィールドの値を含む、ビルドが実行されるビルド構成の設定を取得できます。
- サーバー上の任意のビルドからアーティファクトをダウンロードできます。
  したがって、必要な一連の権限のみを持つOSアカウントでTeamCityエージェントを実行し、エージェントプール機能を使用して、異なるアクセスセットを必要とするプロジェクトが同じエージェント上に構築されないようにすることをお勧めします。
「ビルド構成設定の表示」権限（デフォルトでは「プロジェクト開発者」TeamCityロール）を持つユーザーは、サーバー上のすべてのプロジェクトを表示できますが、TeamCity 9.0ではこれを制限する方法があるため、対応する課題TW-24904(英語)の詳細を参照してください。
1つのプロジェクトで「プロジェクトの編集」権限（デフォルトでは「プロジェクト管理者」TeamCityロール）を持つユーザーは、設定を変更することで、成果物を取得し、表示権限のみを持つビルド構成からビルドをトリガーできます（TW-39209(英語)）。また、ユーザーはTeamCityサーバーにサーバー上の任意の実行可能ファイルを実行させることができます。
"サーバー設定の変更"権限を持つユーザー（デフォルトでは "システム管理者" TeamCityロール）：ユーザーは、サーバープロセスの実行に使用されるユーザーアカウントでTeamCityサーバーが実行されているコンピューターにもアクセスできると見なされます。ユーザーはそのOSユーザーアカウントでマシンへのフルアクセスを得ることができます。ファイルシステムの閲覧、ファイルの変更、任意のコマンドの実行など。
TeamCityサーバーコンピューター管理者：TeamCity保存データへのフルアクセスを持ち、TeamCity実行プロセスに影響を及ぼす可能性があります。外部システム（VCS、課題追跡システムなど）で認証するために必要なパスワードは、TeamCityデータディレクトリにスクランブル形式で保存され、データベースに保存することもできます。ただし、値はスクランブルされているだけなので、サーバーファイルシステムまたはデータベースにアクセスできるすべてのユーザーが値を取得できます。
TeamCityサーバーログ（TeamCityサーバーホームディレクトリ）への読み取りアクセス権を持つユーザーは、TeamCityサーバー管理者へのアクセス権を段階的にプルアップすることができます。
< TeamCity Data Directory > への読み取りアクセス権を持つユーザーは、構成されたパスワードを含む、サーバー上のすべての設定にアクセスできます。
< TeamCity Data Directory >/system/artifacts のビルドアーティファクトへの読み取りアクセス権を持つユーザーは、「ビルドランタイムパラメーターとデータの表示」権限を持つユーザーと同じ権限を取得します（特に、ビルドで使用されるすべてのパスワードパラメーターの値へのアクセス権を持ちます）。
TeamCityエージェントコンピューター管理者：「TeamCityによって実行されるビルドで使用されるコードを変更できるユーザー」と同じです。
1つのTeamCityエージェントが、開発者と管理者が互いのプロジェクトにアクセスできないようにする複数のプロジェクトのビルドを実行しないように、プロジェクトをエージェント間で分散することをお勧めします。プロジェクトを配布するための推奨される方法は、エージェントプール機能を使用し、特定の再設定後にプロジェクトをデフォルトプールに割り当てることができるように「デフォルト」エージェントプールにエージェントがないようにすることです。に割り当てられています。
設定をVCSに保存することが有効になっている場合：
- 設定リポジトリにアクセスできるすべてのユーザー（同じVCSルートを使用してビルド設定の「ファイル内容の表示」権限を持つユーザーを含む）は、設定を確認し、保存されているスクランブル形式に基づいて実際のパスワードを取得できます。
- 設定の変更を介して、サーバー上に構築された単一のビルド構成用にVCSの設定を変更できるユーザーは、表示権限のみを持つすべてのビルド構成から成果物を取得してビルドをトリガーできます（TW-39192(英語)）。
- ビルドの設定を変更することで、ビルドごとにビルド構成設定をカスタマイズできるユーザー（バージョン対応の設定が「VCSの設定を使用する」に設定されているときに個人用ビルドを実行できるユーザーなど）それらは（TW-46065(英語)）の表示権限のみを持っています。
その他:
- TeamCity Webアプリケーションの脆弱性：TeamCity開発チームは、発見された重要な脆弱性（クロスサイトスクリプティングの可能性など）を修正するために合理的な努力を払います。ビルドファイルに影響を与える可能性のあるユーザー（ "TeamCityによって実行されるビルドで使用されるコードを変更できるユーザー"または "TeamCityエージェントのコンピューター管理者"）は悪意のあるファイルをビルドアーティファクトとして利用可能にし、それを悪用します。サイトスクリプティングの脆弱性。( TW-27206(英語) )
- TeamCityエージェントはTeamCityサーバーによって完全に制御されます。TeamCityエージェントはサーバーからの自動更新ダウンロードをサポートしているため、エージェントは信頼できるサーバーにのみ接続する必要があります。サーバーコンピューターの管理者は、接続されたエージェント上で任意のコードの実行を強制することができます。
- サーバーにインストールされているエージェントプラグインのバイナリは、サーバーのURLにアクセスできる人なら誰でも利用できます。

TeamCityが使用する暗号化

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

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

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

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

InnoDBデータベースエンジン

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

show table status like '<table name>';

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

show table status like '%';

max_connections

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および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サーバーのWeb UIの前にインストールされるリバースプロキシサーバーの推奨設定について説明します。プロキシレベルでHTTPSを設定することをお勧めしますが、これらの手順の範囲外です。プロキシサーバーのドキュメントを参照してください。

例を考えてみましょう：
TeamCityサーバーはURL（ローカルURL）：http://teamcity.local:8111/tc(英語)にインストールされます。
それは、URL（パブリックURL）：http://teamcity.public:400/tc(英語)として外部に表示されます。

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

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

プロキシサーバーの設定

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

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構成では、TeamCityサーバーを構成するために"RemoteIpValve" アプローチを使用してください。

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

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

よくある設定ミス

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

ドット（ "。"記号）で始まるパスを持つURLがサポートされています (隠されたアーティファクトへのパスは ".teamcity" ディレクトリを含みます)
コロン（ ":"記号）を含むURLがサポートされています（多くのTeamCityリソースはコロンを使用します）。関連IISの設定(英語)症状：「このビルドにはユーザー定義の成果物はありません」というビルドに成果物がありません。アーティファクトがあってもテキスト。
最大応答時間/時間はそれほど制限的ではありません (TeamCityは遅いクライアントに大きなファイルを提供できるため、応答はサイズがGb、時間が数時間になる可能性があります。)
gzip Content-Encodingは完全にサポートされています。たとえば特定のIIS構成では、UIに500個のHTTPレスポンスがあり、"データの読み込み中..."が表示されることがあります。(関連する課題(英語)を参照してください)

他のサーバー

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

WebSocketプロトコルと連携できるプロキシを使用することをお勧めします。これにより、UIのリフレッシュが早くなります。

一般に、TeamCityサーバーは、クライアントが使用している元のURLを「認識」し、クライアントからアクセス可能な正しい絶対URLを生成できるように構成する必要があります。それを達成するための推奨する方法はTeamCityにオリジナルの "Host" ヘッダを渡すことです。代替方法は、「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 ファイルの "Connector" ノードを次のように変更します。このように設定された "Connector" ポートは設定されたプロキシのアドレス経由でのみアクセス可能であるべきです。TeamCityポートも直接アクセス可能にしたい場合は、専用の port 値を持つ別の "Connector" ノードを使用してください。

<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" 属性を使用してください。

"RemoteIpValve" アプローチ

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

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

<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は、TeamCityサーバーが課題追跡システムなどの他のサービスに対して行う特定の発信HTTP接続にプロキシサーバーを使用できます。

TeamCityをプロキシサーバーにポイントさせるにはTeamCity 2017.1.5以降次のサーバー内部プロパティが利用可能です（以前のバージョンについては以下の代替アプローチを参照してください）。

# 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のどのバージョンでも機能するもう1つの方法は、起動時にスペースで区切られた追加のJVMオプションをTeamCityサーバーに渡すことです。

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

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

このセクションでは、TeamCityエージェントとサーバー間の接続（TeamCity 2017.1以降）用のプロキシサーバーの構成について説明します。

TeamCityエージェント側で、 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インストールを構成して、適切な < TeamCity Data Directory > およびデータベースを使用する ( .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バージョンを既に評価している場合は、弊社のセールス部門にお問い合わせください。
定期的に/運用目的でメインサーバーと同時に実行することを目的としたサーバーのコピーには、別のライセンスが必要です。

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

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

新しいサーバーが元のサーバーとは別のデータディレクトリと別のデータベースを使用するように構成されていることを確認します。サーバーのグローバル設定の「アーティファクトディレクトリ」設定も確認してください。
最初の起動の前に、< TeamCity Data Directory >\config\main-config.xml ファイルのXMLから "uuid" 属性を削除して、サーバーの固有IDを変更します。
同じライセンスキーが複数のサーバーで使用されていないことを確認します（ライセンスの詳細）。
管理上でサーバー 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ルートの設定を変更することを検討してください。TeamCity 10.0.3以降、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プロファイル、ツール（例：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 > とデータベースは、常に1つのTeamCityインスタンスによって使用されるべきであることに注意してください。同じデータを使用するように新しい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(英語)を使用してタスクを実行する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との連続デプロイ

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

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

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つのエージェントがサーバーインスタンスにバインドされます。ユーザーはこれらのエージェントに料金を支払わず、ライセンスキーはありません。
Enterpriseサーバーの場合、エージェントの数はパッケージによって異なり、エージェントはサーバーライセンスキーにバインドされます。

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

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

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

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

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

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

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

カバレッジHTMLレポートをTeamCityアーティファクトとして公開：ほとんどのツールはカバレッジレポートをHTML形式で生成します。アーティファクトとしてパブリッシュし、レポートタブをTeamCityで表示するように設定できます。成果物がルート成果物ディレクトリに公開され、その名前が coverage.zip で index.html ファイルがある場合は、レポートタブが自動的に表示されます。外部ツールの実行に関しては、ビルドおよびレポート作成ツールと統合するを確認してください。
カバレッジレポートからカバレッジ統計を抽出し、サービスメッセージを使用してTeamCityに統計値を公開します。その場合は、ビルド構成のStatisticsタブにカバレッジチャートが表示されます。メトリクスの変更時に失敗条件を構築します（たとえば、カバレッジが低下した場合は失敗します）。

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

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

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

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

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

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

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バージョンの順序は、以前のリリースダウンロード(英語)ページにリストされています。