使い方 ...

バンドルされていないバージョンの Java をインストールする

TeamCity サーバーを実行するには、Java SEJRE をインストールする必要があります。互換性のある JRE バージョンは TeamCity .exe インストーラーにバンドルされていますが、他のディストリビューションを使用する場合は個別にインストールする必要があります。

TeamCity は、次のようにサーバープロセスを実行する Java バージョンを選択します。

• デフォルトでは、TeamCity インストールにバンドルされた JRE ( <TeamCity Home> \jre ディレクトリが存在する) がある場合、それが TeamCity サーバープロセスの実行に使用されます。別の JRE を使用するには、TEAMCITY_JRE 環境変数を使用してそのパスを指定します。

• <TeamCity Home> \jre ディレクトリが存在しない場合、TeamCity はそれぞれ JRE または JVM (Java SDK) のインストールディレクトリを指す JRE_HOME または JAVA_HOME 環境変数を検索します。両方の変数が宣言されている場合は、JRE が使用されます。

Java インストールを更新するために必要な手順は、使用されるディストリビューションによって異なります。

TeamCity インストールにバンドルされた JRE ( <TeamCity Home> \jre ディレクトリがある) がある場合は、インストール手順に従って新しい JRE をインストールし、結果のディレクトリの内容をコピーして既存の <TeamCity Home> \jre ディレクトリの内容を置き換えて更新します。

<TeamCity Home> \buildAgent ディレクトリから TeamCity エージェントも実行する場合は、JRE の代わりに JDK (Java SDK) をインストールし、JDK インストールディレクトリの内容を <TeamCity Home> \jre にコピーします。

32 ビットから 64 ビットの Java に更新

TeamCity サーバーは 64 ビット JVM にバンドルされていますが、両方の 32- および 64 ビットバージョンで実行できます。

32 ビット Java を 64 ビット JVM に更新する必要がある場合は、32 ビットから 64 ビットに切り替えるとメモリ使用量がほぼ 2 倍になることに注意してください。32 ビット JVM の場合の少なくとも 2 倍のメモリを指定するようにしてください。メモリ設定を変更する方法を参照してください。

64 ビット Java に更新するには、バンドルバージョンの Java を使用するか、次のいずれかを使用します。

1. サーバーが使用する Java を更新します。

2. JVM メモリオプションを設定します。64 ビット JVM には -Xmx4g オプションを設定することをお勧めします。

バンドルされていないバージョンの Tomcat をインストールする

TeamCity サーバーディストリビューションには、現在のバージョンで正常に動作することがテストされた Tomcat バージョンが含まれています。別の Tomcat バージョンを使用することもできますが、他の組み合わせが正しく機能することは保証されていないことに注意してください。

バンドルされているものの代わりに別のバージョンの TomcatWeb サーバーを使用するには、Tomcat のアップグレード / パッチを実行する必要があります。

TeamCity で使用する Tomcat のバージョンをアップグレードする場合は、次のことをお勧めします。

• 現在の TeamCity ホームをバックアップします。

• Tomcat ディストリビューションにも存在する TeamCity ホームディレクトリから削除 / 移動します。

• Tomcat ディストリビューションを TeamCity ホームディレクトリに解凍します。

• 以前にバックアップ / 移動したディレクトリから TeamCity 固有のファイルを TeamCity ホームにコピーします。

  • Tomcat ディストリビューションには存在しない bin のファイル

  • デフォルトの Tomcat conf ディレクトリと TeamCity のディレクトリの違いを確認し、TeamCity 固有の設定で Tomcat ファイルを更新します (teamcity-* ファイル、および server.xml の一部)

  • デフォルトの Tomcat webapps/ROOT ディレクトリを削除し、TeamCity によって提供されたものと置き換えます。

macOS で TeamCity サーバーを自動起動する

このコンテンツは TeamCity サーバー記事の開始に移動されました。

TeamCity サーバーのインストールを自動化する

自動化された TeamCity サーバーのインストールには、.tar.gz ディストリビューションを使用します。

通常、それを解凍し、スクリプトにこのセクションに記載されている手順を実行させる必要があります。

事前構成されたサーバーをすぐに取得する場合は、以前に構成されたサーバーのファイルをデータディレクトリに配置します。新しいサーバーごとに、次のことを行う必要があります。

• 新しいデータベース（<Data Directory>\config\database.properties で構成されている）を指していることを確認します。

• ルート XML 要素に uuid 属性が含まれないように <Data Directory>\config\main-config.xml ファイルを変更します（新しい属性を生成できるようにします）。rootURL 属性に適切な値を設定します。

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

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

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

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

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

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

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

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

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

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

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

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

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

必要なビルドエージェントの数は、サーバーの使用パターン、ビルドのタイプ、チームサイズ、CI プロセスへのチームのコミットメントなどによって異なります。一般に、最善の方法は、3 つのエージェントから始めて、それらがサーバー上のプロジェクトをどのように処理するかを確認してから、将来の見積もりを行うことです。

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

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

• 各ビルドには、快適と思われるよりも多くの変更が含まれています（たとえば、ビルドの失敗の分析など）。

• さまざまな環境の必要性。

20 のビルド構成（ビルドのタイプ）ごとにエージェントが存在するパターンを見てきました。または、1 〜 2 人の開発者ごとのビルドエージェント。

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

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

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

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

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

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

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

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

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

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

TeamCity Web UI 用に HTTPS を構成する

TeamCity では、HTTPS アクセスを簡単に構成できるようになりました。ただし、大規模な公開 TeamCity インストールの場合は、HTTPS を処理し、HTTP TeamCity サーバーポートをアップストリームとして使用する NGINX や Apache などのリバースプロキシを TeamCity の前に設定することをお勧めします。

プロキシの HTTPS 関連の構成は、TeamCity に固有のものではなく、他の Web アプリケーションと同様に一般的です。推奨に従ってリバースプロキシを設定してください。一般的な Web アプリケーションのベストプラクティスが適用されます (TeamCity への http アクセスをまったく無効にするなど)。

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

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

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

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

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

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

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

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

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

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

サーバーポートの変更

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

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

本番サーバーをアップグレードする前に、新しい TeamCity バージョンを試すことをお勧めします。通常の手順は、本番 TeamCity インストールのコピーを作成し、それをアップグレードして試してみて、すべてがチェックされたら、テストサーバーを削除してメインサーバーをアップグレードすることです。テストサーバーを起動するときは、サーバーの URL を変更し、メール通知機能や新しいサーバーの他の機能を無効にすることを忘れないでください。

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

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

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

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

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

これを実行したい場合に備えて、設定を手動で移動する際の注意事項がいくつかあります。

簡単なファイルのコピーで、プロジェクトの設定やビルド構成を別のサーバーに移動できます。

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

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

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

TeamCity Data Directory から、対応するプロジェクト（.BuildServer\config\projects\<id>）とそのすべての親プロジェクトのディレクトリをターゲットサーバーの .BuildServer\config\projects にコピーします。これにより、プロジェクト設定、ビルド構成設定、プロジェクトで定義された VCS ルートが移動し、それらの間のリンクが保持されます。コピーされたものと同じ名前のファイルがターゲットサーバーにある場合、これは a）id が一致する場合に発生する可能性があります: 同じエンティティがターゲットサーバーにすでに存在します。この場合、衝突するファイルはコピーから除外できます。または b） ID の衝突: 異なるエンティティがたまたま同じ ID を持っています。この場合、一意性の要件を満たすために、ソースサーバーまたはターゲットサーバーのエンティティ ID を変更することで解決する必要があります。

親プロジェクトのセットは、Web UI またはディスク上のディレクトリ名（デフォルトでは同じ接頭辞が付けられます）に基づいて手動で識別されます。

注: ルートプロジェクトの設定をすべてのサーバー間で同期しておくと便利です (.BuildServer\config\projects_Root ディレクトリの内容を同期することによって)。例: これにより、すべてのサーバーでデフォルトのクリーンアップポリシーの設定が同じになります。

プロジェクトをコピーした後の手順は次のとおりです。

• ターゲットサーバー上にコピーされた親プロジェクト（存在する場合）の未使用データを削除します

• 「サーバーヘルス」レポートを使用して、コピーの結果として表示された重複する VCS ルートがあればそれを識別します。

• ソースサーバーでプロジェクトをアーカイブし、クリーンアップルールを調整する (必要に応じて、ビルドの履歴を見ることができるようにする)

上記のアプローチではコピーされないもの:

• 一時停止中のビルド構成のコメントとユーザー

• アーカイブされたプロジェクトのアーカイブユーザー

• グローバルサーバー設定（たとえば、Maven settings.xml profiles、handle.exe などのツール、外部変更ビューアー、ビルドキューの優先順位、課題追跡システム）。これらは .BuildServer\config ディレクトリのさまざまなファイルに保存され、ファイルレベルで、サーバー管理 UI で同じ設定を構成することによって同期する必要があります。

• エージェントプールとのプロジェクトの関連付け

• コピーされたものの親ではない他のプロジェクトからのテンプレート。この設定は TeamCity 8.0 では実際には推奨されておらず、レガシーとしてのみサポートされています。複数のプロジェクトで使用されているテンプレートは、共通の親プロジェクトまたはルートプロジェクトに移動する必要があります。

• エージェントにデータが構成されていない（エージェント上で実行が許可されているビルド構成）。

• ユーザー関連またはユーザーグループ関連の設定はありません (ロールや通知規則のように)

• ミュートや調査などの状態関連のデータはありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スナップショット依存関係またはアーティファクト依存関係によって接続されたビルドでは、次の依存関係プロパティへの参照を使用してビルド番号を共有できます: %dep.<btID>.system.build.number%

例: 同期してビルドしたいビルド構成「A」と「B」がある場合: 同じソースを使用し、同じビルド番号を取得します。
以下を実施:

1. ビルド構成「C」を作成し、依存関係のスナップショットを作成します: 「C」上の「A」と「C」上の「B」。

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

ここで、<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 環境変数を指定する必要があります。

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

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

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

ビルド番号はプレーンテキスト応答として返されます。
<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 リクエストまたはサービスメッセージの送信を介して) デプロイ中のビルドを固定およびタグ付けするコマンドをビルドスクリプトに追加することも検討してください。アーティファクトを生成したビルドのビルド番号を使用することもできます。

さらなる推奨事項

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

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

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

• タイトルを変更(英語)ビルド構成の「実行」ボタン。デプロイ構成のボタンのタイトルは自動的に「Deploy」に変わります。

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

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

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

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

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

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

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

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

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

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

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

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

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

データ収集

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

TeamCity でツール専用の UI を使用できるようにするレシピを作成することも検討できます。

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

TeamCity でデータを提示する

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

テストツールについては、まだサポートされていない場合は、ビルドからテスト関連のサービスメッセージを介して TeamCity にテストの進行状況を報告したり、ビルドでサポートされている XML レポートの 1 つを生成して、構成された XML レポート処理ビルド機能のサービスメッセージを介してインポートしたりすることができます。

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

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

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

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

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

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

TeamCity は、削除されたプロジェクト設定ディレクトリ (プロジェクト ID に基づいて名前が付けられます) を <TeamCity Data Directory> /config/_trash ディレクトリに移動し、ディレクトリに "<internal ID>" 接尾辞を追加します。

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

TeamCity は、削除されたプロジェクト / ビルド構成のデータベースに保存されたビルド履歴およびその他のデータを削除時間から 5 日間保持することに注意してください。構成可能なタイムアウト (デフォルトでは 5 日間) が経過した後、関連するすべてのデータ (ビルドとテストの履歴、変更など) は、次のクリーンアップ時に削除されます。

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

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

これは不可能です。

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

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

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

ライセンスの詳細については、こちらを参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• TeamCity トレイ通知機能のインストールディレクトリ（デフォルトでは C:\Program Files\JetBrains\TeamCity）から、次のコマンドを実行します。

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

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

Git OAuth Flow のカスタムコールバック URL を設定する

TeamCity VCS プロバイダーへの OAuth のような接続はコールバック URL を使用します。ユーザーが TeamCity にリポジトリへのアクセスを許可すると、VCS プロバイダーはユーザーをこの URL にリダイレクトします。

通常、このコールバック URL は通常の TeamCity サーバー URL に基づいています。たとえば、https://foo.bar.gg:8111 でホストされているサーバーの場合、コールバック URL は https://foo.bar.gg:8111/oauth/githubapp/accessToken.html のようになります。まれに、リダイレクト URL に別のドメインを使用したい場合は、システム管理者が teamcity.oauth.redirectRootUrlOverride 内部プロパティを指定できます。

個人ユーザーデータ処理

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

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

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