使い方 ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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 を使用

• オープン 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 またはプラグイン(英語)でまだサポートされていないビルドツールまたはレポートを生成したりコードメトリクススを提供するツールがある場合、専用の統合がなくても 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 プラグインの開発(英語)を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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