操作方法

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

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

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

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

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

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

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

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

32 ビット Java から 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 Home をバックアップします。

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

• Tomcat ディストリビューションを TeamCity Home ディレクトリにアンパックします。

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

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

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

  • デフォルトの Tomcat webapps/ROOT ディレクトリを削除し、TeamCity が提供するものに置き換えます

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

このコンテンツは TeamCity サーバーの起動に関する記事に移動しました。

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

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

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

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

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

• ルート XML 要素に uuid 属性を持たないように <データディレクトリ>\config\main-config.xml ファイルを変更します (新しいものを生成できるようにするため)。 rootURL 属性に適切な値を設定します。

管理者パスワードの取得

空のデータベースで最初に起動すると、TeamCity は管理者セットアップページを表示します。このページでは、完全な管理権限を持つユーザーを作成できます (System Administrator ロールを割り当てます)。

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

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

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

レプリケーション / クラスタリング環境で TeamCity をセットアップ

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

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

データに関しては、TeamCity サーバーはデータベースとファイルストレージ (データディレクトリ) の両方を使用します。 TeamCity データの保存について詳しくは、 TeamCity データバックアップ と TeamCity データディレクトリ のページを閲覧できます。 基本的に、ディスク上の TeamCity データディレクトリと TeamCity が使用するデータベースはどちらも一貫した状態を維持する必要があるため、一緒にレプリケートする必要があります。
常に単一の 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) ペイロードを送信した場合、サーバーは関連するスタックトレースを含む "Unexpected error" ページを表示します。 このスタックトレースによって環境に関する機密情報が公開されるのを防ぐため、スタックトレースの表示を無効にすることをお勧めします。 そのためには、 teamcity.web.runtimeError.showStacktrace 内部プロパティを 偽 に設定してください。

TeamCity ウェブ UI の HTTPS を構成

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

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

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

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

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

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

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

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

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

プロキシは TeamCity サーバーの応答を一切キャッシングしないように構成する必要があることに注意してください。たとえば Squid を使用している場合は、 squid.conf ファイルに「cache deny all」行を追加します。

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

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

サーバーポートの変更

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

アップグレード前に新しい TeamCity バージョンを試用

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

すべてのデータを含む TeamCity サーバーのコピーを作成

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

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

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

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

必要になった場合に備えて、設定を手動で移動する際の注意事項をいくつか示します

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

二台の TeamCity サーバー (ソースとターゲット) は、まったく同じバージョン (同じビルド) である必要があります。

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

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

TeamCity データディレクトリ から、対応するプロジェクト (.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 データディレクトリ に接続して、サーバーが 同じ環境を使用していることを確認できます。 または、サーバーをあるマシンから別のマシンに コピーする手順に従うこともできます。

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

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

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

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」です。 このアプローチは、 Snapshot Dependencies スナップショット依存関係オプションをオフに設定してビルドの再利用を無効にした場合に最も効果的です。

依存関係プロパティについての 続きを読む。

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

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

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

構成エラーによりビルドが多すぎる場合にビルドキューをクリア

キューに入っているビルドを持つビルド構成を一時停止してみてください。 ビルド構成を一時停止すると、そのすべてのビルドがキューから除去されます。
また、単一のダイアログでビルドキューから多数のビルドを削除することもできます。

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

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

• REST API を使用

• ディスク上の設定ファイルを直接変更する (<TeamCity データディレクトリ> でさらに詳しく見る)

• オープン API を使用してタスクを実行する TeamCity Java プラグインを作成します。

Cucumber Reporter を Ant ビルドにアタッチ

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

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

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

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

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

TeamCity でアプリケーションのデプロイを設定

TeamCity には、ビルドスクリプト / ビルドランナーで構成された実際のデプロイロジックを使用して、デプロイのオーケストレーション部分を処理する複数の機能があります。 TeamCity はさまざまな汎用ビルドツールをサポートしているため、特定のツールを TeamCity 内から実行できます。 特定のツールの使用を容易にするために、それをレシピにラップするか、そのためのカスタムプラグインを作成することができます。

詳細については、次の記事を参照してください: ビルド構成とデプロイ、 デプロイビルド構成。

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

1. ディスク上で利用可能なバイナリファイルに対してデプロイタスクを実行するビルドスクリプトを作成します。 (たとえば、これには Ant または MSBuild を使用します。 一般的なデプロイトランスポートには デプロイヤーランナーを使用します)。 ビルドツールとレポートツールとの統合も参照してください。 レシピを使用して、便利な UI でスクリプトを再利用できます。

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

3. このビルド構成では、デプロイする必要があるバイナリを生成するビルド構成への アーティファクト依存関係を構成します。

4. デプロイを自動的にトリガーする必要がある場合 (たとえば、最後に固定されたビルドの最後に成功したビルドをデプロイする場合)、デプロイするビルド構成で利用可能なトリガーの 1 つを構成するか、デプロイするバイナリを生成したビルドで「デプロイ」アクションを使用します。

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

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

7. デプロイ中のビルドが手動でトリガーされる場合は、(REST API リクエストまたは サービスメッセージの送信を介して) デプロイ中のビルドを固定およびタグ付けするコマンドをビルドスクリプトに追加することも検討してください。 アーティファクトを生成したビルドの ビルド番号を使用することもできます。

さらなる推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ビルドツールとレポートツールとの統合

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

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

データ収集

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

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

高度な統合では、ツールの構成と実行を簡単にするために、カスタムの TeamCity プラグインを Java で開発できます。

TeamCity でのデータ表示

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

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

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

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

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

TeamCity にカバレッジ結果をインポートも参照してください。

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

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

TeamCity は、削除されたプロジェクト設定ディレクトリ (プロジェクト id にちなんだお名前が付けられているもの) を <TeamCity データディレクトリ>/config/_trash ディレクトリに移動し、ディレクトリに "<内部 ID>" サフィックスを追加します。

プロジェクトを復元するには、 _trash ディレクトリでプロジェクトディレクトリを見つけ、通常のプロジェクト設定ディレクトリ: <TeamCity データディレクトリ>/config/projects に移動し、その際にディレクトリのお名前から ".projectN" サフィックスを除去します。
サーバーの実行中にこれを行うことができ、復元されたプロジェクトは自動的に検出されます。

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

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

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

これは不可能です。

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

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

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

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

「データディレクトリ (NNN) とデータベース (MMM) のデータフォーマットが一致しません」エラーから復旧

TeamCity の起動時に「データディレクトリ (NNN) とデータベース (MMM) のデータフォーマットが一致しません。」エラーが発生する場合、データベースまたは TeamCity データディレクトリのどちらかが最近不整合な状態に変更されたため、一緒に使用できないことを意味します。 データベースとデータディレクトリの場所を再確認し、サーバーが以前にデータを保存していた場所でない場合は変更してください。

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

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

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

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

1. TeamCity ウェブ 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 Tray Notifier のインストールディレクトリ (デフォルトでは C:\Program Files\JetBrains\TeamCity) から、次のコマンドを実行します：

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

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

Git OAuth フロー用のカスタムコールバック 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 インスタンスを少なくともこのバージョンに更新してください。