TeamCity 2019.1ヘルプ

使い方...

このページ：

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

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

  • TFSとVCSの統合

  • VSSとVCSの統合

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

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

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

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

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

64ビットOSをインストールすることを選択した場合、TeamCityは64ビットJDK（サーバーとエージェントの両方）で実行できます。ただし、TeamCityに1Gbを超えるメモリを提供する必要がない限り、推奨される方法は64ビットOS下でも32ビットJVMを使用することです。私たちの経験によると、64ビットJVMを使用してもパフォーマンスはそれほど向上しません。同時に、メモリ要件はほぼ2の規模まで増加します。メモリ構成に関する注記を参照してください。

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の一時ディレクトリー）と .BuildServer/system の使用量の合計です。TeamCityサーバーの性能はディスクシステムの性能に大きく依存します。TeamCityは .BuildServer/system に大量のデータを保存するため（特にVCSのキャッシュとビルド結果）、ディスクへのアクセスが速いことが重要です（特に複数のスレッドでファイルを読み書きする、属性を持つファイルをリストする）。データディレクトリーをネットワークドライブに保存する予定がある場合は、ディスクのパフォーマンスを確実に向上させることが特に重要です。

  • ネットワーク：これは主に、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 Server 2008 R2下の12 Gbメモリ、64 GB、1 Gbネットワークアダプタ、3 HDD RAID 1ディスク (一般に、成果物、ログおよびキャッシュ記憶域用、データベース記憶域用)

サーバー負荷特性

  • 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個もの同時ビルド（Linux上で実行される8コア、32 GBの総メモリ、および別の同等のマシン上で実行されるMySQLサーバー）で正常に機能していました。各ビルドによって生成されるサーバーの負荷は、ビルドによって生成されるデータ量（ビルドログ、テスト番号と失敗の詳細、インスペクション / duplicates issue numberなど）によって異なります。データ量を合理的に制限しながら（大量の出力をビルド成果物として公開し、標準出力に出力しない、インスペクションプロファイルを調整して最も重要なインスペクションヒットの限られたセットを報告するなど）、より多くの同時ビルドを処理できます。
さらに多くのエージェント/並列ビルドが必要な場合は、複数ノードのセットアップを使用することをお勧めします。かなりの量のエージェントが必要な場合は、複数のTeamCityインスタンスを別々に使用し、それらの間でプロジェクトを分散することを検討することをお勧めします。常にTeamCityのパフォーマンス向上に取り組んでおり、大規模なTeamCityインストールを実行している組織と緊密に連携してパフォーマンスの課題を研究し、より大きな負荷を処理するためにTeamCityを改善します。TeamCityが処理できる最大エージェント数(英語)に関する関連記事も参照してください。

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

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

それらのいくつかはエージェントとサーバーの間でバイナリを転送することを含むため、トラフィックは主に設定に依存します。
エージェントとサーバー間のトラフィックの最も重要な流れは次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • <、 TeamCity Data Directory 、>/system/caches directoryの良好な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

Redo Log

MS SQL Server

トランザクション・ログ

PostgreSQL

WAL (先読みログ)

MySQL + InnoDBとPercona

Redo Log

PostgreSQL：多くのクエリ最適化機能を備えた9.2+バージョンを使用することをお勧めします。PostgreSQLのドキュメント(英語)のwrite-ahead-log（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 WindowsインストーラTeamCity 2017.2以降は継承可能な権限を使用しないようにTeamCityインストールディレクトリーの権限を変更し、ディレクトリーへのアクセスを管理者ユーザーグループおよびサービスが実行するように構成されているaccrountに明示的に許可します。同様に 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サーバーとエージェントのプロセスは、最小限の必要な権限で限られたユーザーで実行されます。インストールディレクトリーは、限られた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でパスワード値をクリアテキストで渡さないようにし、暗号化するために1024ビットキーのRSAを使用します。ただし、TeamCity Web UIはHTTPS経由でのみ使用することをお勧めします。そのため、この注意事項は関係ありません。TeamCityはパスワードを設定（他のシステムで認証を実行するために元のパスワード値が必要な場合）にスクランブル形式で保存します。スクランブルは、固定キーを持つ3DESを使用して行われます。

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

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

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

InnoDBデータベースエンジン

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

show table status like '<table name>';

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

show table status like '%';

max_connections

max_connections パラメータには、TeamCity、<、 TeamCity Home Directory 、>/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 and laterの場合：

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のドキュメント(英語)も参照）。

<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 Web UI用にHTTPSを構成する

TeamCityは、HTTPSアクセスをすぐにはサポートしません（TW-12976(英語)を参照）。TeamCityの前にNginxやApacheのようなリバースプロキシを設定し、HTTP TeamCityサーバーポートをHTTPSとして使用することを強くお勧めします。upstream.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サーバーに渡すことです。

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

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

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

TeamCityエージェント側で、 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バックアップを使用

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

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

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

  4. < TeamCity Data Directory >/system/artifacts ディレクトリーの内容を古い場所から新しい場所に移動して、成果物（これらはバックアップに含まれません）を移動します。成果物はサイズが大きくなる可能性があるため、これには長時間かかることがあるため、それに応じて計画を立てます。

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

手動コピー

バンドルされたバックアップ機能を使用したくない場合や、プロセスを手動で制御する必要がない場合は、サーバーのコピーを手動で作成するために必要な一般的な手順について説明します。

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

  2. サーバーが稼働していないことを確認してください。

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

  4. コピー < TeamCity Data Directory >フルコピーが不要な場合は、以下の項目を参照してください。

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

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

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

    • ビルド成果物およびビルド・ログ（テスト失敗の詳細を含む）を新規サーバーに保存したい場合は.BuildServer/system/artifacts （オプション）

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

    • さまざまなプラグインの状態を保持したい場合は.BuildServer/system/pluginData （オプション）

    • .BuildServer/system/caches と .BuildServer/system/caches （オプション）は、新しいサーバーにコピーする必要はありません。起動時に再作成されますが、再構築にはしばらく時間がかかることがあります。（若干時間がかかります）。

  5. Artifactsディレクトリーは通常大きく、サーバーを移動した場合にサーバーのダウンタイムを最小限に抑える必要がある場合は、元のサーバーが停止している間にrsync、robocopy、または類似のツールを使用してデータをコピーできます。実行。同期されるデータ量が少なくなるまで、同期実行を数回繰り返します。元のサーバーがシャットダウンした後に最終同期を実行します。サーバーを移動するための別の解決策は、古いデータ成果物ディレクトリーを新しいサーバーからアクセス可能にし、それを成果物の 2番目の場所として構成することです。次に、サーバーの稼働中にこの2番目の場所からメインの場所にファイルをコピーし、コピーが完了したらサーバーを再起動します。

  6. TeamCityインストールが使用しているデータベースのコピーを新しいスキーマまたは新しいデータベースサーバーに作成します。これは、データベース固有のツールまたはバンドルされているmaintainDBツールを使用して、データベースデータをバックアップしてから復元することで実行できます。

  7. 適切な < TeamCity Data Directory > とデータベースを使用するように、新しいTeamCityインストールを構成します: ( .BuildServer/config/database.properties はデータベースのコピーを指する)

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

環境移転

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

  • 適切に設定された設定、グローバルおよびファイルシステムの権限でTeamCityサーバープロセスを実行するために適切なOSユーザーアカウントを使用する

  • 同じTeamCityプロセス起動オプションを使用してください。具体的には、TEAMCITY\_で始まる環境変数をチェック/コピーしてください。

  • 絶対パスを使用してTeamCity Web UIで構成されたすべてのファイル/設定がアクセス可能であることを確認してください

  • デフォルトのsshキー、キャッシュされたVCSアクセス認証情報などのOSレベルのユーザー/マシン設定に依存している場合は、それらも転送します。

  • ネットワーク設定など、マシンに関する特別な設定や例外を複製することを検討してください。

  • TeamCityインストールに何らかの方法でパッチが適用されている場合（GrrovyPlugプラグイン、MS SQL Server統合セキュリティ認証用のネイティブドライバ）、インストールコピーに同じ変更を適用します。

  • OSを起動した状態でTeamCityを実行する場合（例：Windowsサービス）、新しいマシンで同じ設定が実行されていることを確認してください

  • < TeamCity Home >\conf\teamcity-startup.properties ファイルの設定の確認と転送

  • <のカスタム設定を検討してください TeamCity Home >\conf\server.xml

ライセンスの課題

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

  • 冗長性/バックアップ目的で作成されたサーバーのコピーは、一度に1つのサーバーのみが実行されるため、同じライセンスを使用できます。

  • テスト目的で作成されたサーバーのコピーには追加のライセンスが必要です。公式TeamCity ダウンロードページ(英語)から一度限りのTeamCity 評価ライセンスを得ることができます。ライセンスの延長が必要な場合、またはすでに同じ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ビルドも含まれます。ビルドキューを一時停止することで、ビルドが開始されないようにすることができます。

  • クラウド統合を無効にします（メインサーバーに干渉しないようにするため）。

  • 外部アーティファクトストレージを無効にします（ビルドを実行または削除したり、サーバーのクリーンアップを実行したりすると、運用サーバーで使用される可能性があるストレージに影響します）。

  • Gitレジストリのクリーンアップを無効にします（またはサーバー上のクリーンアップを無効にします）。

  • コミットステータスの発行を無効にする、* TeamCityイベントに基づいて他のコピーされていないシステムにデータをプッシュするプラグインを無効にする* プロジェクト設定をVCSに保存する機能を無効にする：set 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が一致した場合に発生する可能性があります。同じエンティティがすでにターゲットサーバーに存在する場合、衝突ファイルはコピーから除外されます。：異なるエンティティが偶然同じ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.&lt;btID&gt;.system.build.number%。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さらなる推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データ収集

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

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

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

TeamCityでデータを提示する

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

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

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

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

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

補償内容のインポートはTeamCityになりますも参照してください。

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

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

TeamCityは、削除されたプロジェクト設定ディレクトリー（プロジェクトIDの後に名前が付けられています）を < TeamCity Data Directory >/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アップグレードを実行する必要があります。

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

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

  1. TeamCity Web UIのエージェントページに移動して、エージェントを選択してください。

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

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

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

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

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

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

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

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

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

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

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

脆弱性

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

Heartbleed、ShellShock

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

POODLE

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

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

GHOST

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

FREAK

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

Apache Struts

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

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

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

WindowsのTomcat

CVE-2017-12615、CVE-2017-12616およびCVE-2017-12617の記述の言葉遣いに基づいて、WindowsにインストールされたTeamCityサーバーは、攻撃の潜在的な対象です。ただし、脆弱性の分析では、関連するTomcatの設定がすべてのTeamCityバージョンで無効になっているため、デフォルトのTeamCityインストールではこれらの潜在的な脆弱性を悪用することはできません。

必要に応じて、TeamCityにバンドルされているTomcatを7.0.82 バージョンにアップグレードして、Tomcatコードから脆弱性を排除することもできます。

トムキャットCVE-2018-8037

TeamCityバージョン2018.1は、正式なTomcat発表の前にTeamCityコードベースで特定され解決されていたため、この脆弱性の影響を受けません（実際、TeamCityインストールで課題が発見され、修正に関してTomcatチームと協力しました）。以前のバージョンのTeamCityは脆弱であるため、TeamCity 2018.1 +へのアップグレードが必要です。

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

issue trackerの詳細も見てください。

個人ユーザーデータ処理

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にメンションすることに注意してください。

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

TeamCityリリースサイクル

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

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

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

  • EAPで利用可能 (早期アクセス・プログラム) - 通常はメジャーリリースでのみ利用可能で、前のメジャーリリースから数か月後、通常次のメジャーリリースの数か月前に始まります。通常、新しいEAPリリースは毎月または隔月で発行(英語)されます。

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

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

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

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

カスタムチャートトラブルシューティング

関連ページ：

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

このページはTeamCityが動作するソフトウェア関連の環境をカバーします。ハードウェア関連の注意事項については、このセクションを参照してください。本セクション:プラットフォーム (オペレーティング・システム)TeamCityサーバー、ビルド・エージェント、Windowsトレイ通知機能、Web ブラ...

REST API

一般情報一般的な使用箇所、REST認証、スーパーユーザーアクセス、REST APIのバージョン、URLの構造、ロケーター、サポートされているHTTPメソッド、応答フォーマット完全および部分的な回答、ログイン、CORSのサポート、APIクライアントの推奨事項、TeamCityデータエンティティ要求プロ...

メタランナーを使う

メタランナーを使用すると、ビルド構成からビルドステップ、要件、およびパラメータを抽出し、それらからビルドランナーを作成できます。このビルドランナーは、他のビルド構成またはテンプレートのビルドステップで他のビルドランナーとして使用できます。基本的に、メタランナーはあるビルド構成からの一連のビルドステッ...

ビルドエージェントの設定とメンテナンス

このページ：TeamCityエージェントの詳細を表示する接続済み/切断済みUIを介したエージェントの有効化/無効化、プール、パラメータレポート、行列と統計、クラウド、差分、TeamCityエージェントの詳細を表示する：TeamCity Web UIのエージェントページには、TeamCityエージェン...

リモート・デバッグ

リモート・デバッグは、ローカルの開発者マシン上のIDEからTeamCityエージェントマシン上のテストをリモートでデバッグできるようにする機能です。この機能は、エージェント環境が何らかの点で固有であり、テストが失敗し、問題をローカルで再現するのが困難な場合に役立ちます。IntelliJベースのIDE...