一般的な依存関係の概念

このページでは、例に基づいて、TeamCity で依存関係がどのように機能するかについての一般的な考え方を示します。依存関係の説明については、ビルド構成の依存関係を参照してください。

多くの場合、あるビルドの出力を別のビルドで使用するだけでなく、同じソースで複数のビルドを順次または並列に実行すると便利です。典型的な例を考えてみましょう。本番ビルドを取得する前に、Windows と macOS でテストする必要があるクロスプラットフォームプロジェクトがあります。この単純なケースに最適なワークフローは次のとおりです。

プロジェクトをコンパイルしてください。
同じソースで Windows と macOS で同時にテストを実行します。
テストが両方の OS で合格した場合は、もちろん、同じソースでリリース版をビルドします。

これは TeamCity のビルド設定間に依存関係を設定することで簡単に実現できます。

ここで、compile、テスト (勝つ)、テスト (mac)、pack setup はビルド構成であり、当然テストはコンパイルに依存するため、コンパイルが準備できるまで待機する必要があります。

共通の概念

TeamCity では、相互接続された一連のビルド構成をビルドチェーンと呼びます。その仕組みの詳細に入る前に、ここに示されているダイアグラム（序論のダイアグラムを含む）の凡例を明確にしておきましょう。


	ビルド構成
	スナップショットの依存関係は 2 つのビルド構成間のものです。矢印は、ビルド構成をトリガーする順序、つまりビルドチェーンフローを示しており、B が A より先に実行されることを意味します。ただし、依存関係は逆方向に構成されています (A スナップショットは B に依存します)。矢印がこのように描かれているのは、TeamCity UI にはビルドチェーンの視覚的表現があり、これは常にビルドチェーンフローに従って表示されるためです。通常、スナップショット依存関係を追加するときは、同じ構成から「同じチェーンからビルド」オプションを使用してアーティファクト依存関係も追加し、以前のビルド結果を転送してビルドでも使用します。
	アーティファクトの依存関係。矢印はアーティファクトの流れを示し、依存関係は反対方向に構成されています。

お気づきのとおり、TeamCity には 2 種類の依存関係があります。アーティファクト依存関係とスナップショット依存関係です。簡単に言うと、前者では 1 つのビルドの出力を別のビルドで使用できるようになり、後者では同じソースで複数のビルド構成から特定の順序でビルドをトリガーできます。
これら 2 つの依存関係は、多くの場合一緒に構成されます。これは、アーティファクト依存関係はビルドのトリガー方法に影響を与えないのに対し、スナップショット依存関係自体はアーティファクトを再利用しないため、場合によってはそのうちの 1 つだけが必要になることがあるためです。

依存関係はビルド設定の専用ページで設定されます。

それでは、アーティファクトとスナップショットの依存関係で何ができるのか、それらがどのように機能するのかを見てみましょう。

アーティファクトの依存関係

アーティファクト依存関係により、あるビルドの出力 (またはその一部) を別のビルドで再利用できます。

ビルド構成 A に B へのアーティファクト依存関係がある場合、A のビルドが開始される前に、B のアーティファクトがビルドエージェントにダウンロードされます。アーティファクトルールを柔軟に調整して、取得するアーティファクトと、配置する正確な場所を構成できることに注意してください。

何らかの理由で TeamCity ではなくコードベースと一緒にアーティファクトの依存関係情報を格納する必要がある場合は、ビルドスクリプトでアーティファクトを取得するように Ivy Ant のタスクを設定できます。

スナップショット依存関係とアーティファクト依存関係の両方が構成されていて、アーティファクト依存関係設定で ' 同じチェーンから構築する ' オプションが選択されている場合、TeamCity はアーティファクトが同一ソースビルドからダウンロードされることを保証します。

スナップショットの依存関係

スナップショット依存関係は、2 つのビルド構成間の依存関係であり、両方のビルド構成から特定の順序でビルドを起動し、同じソーススナップショット (同じ瞬間に対応するソースリビジョン) が使用されるようにします。

スナップショットの依存関係によって相互接続された複数のビルドがある場合、それらはビルドチェーンを形成します。

いつビルドチェーンを作成するか

ビルドチェーンを作成する最も一般的なユースケースは、プロジェクトの同じテストスイートを異なるプラットフォームで実行することです。たとえば、リリースビルドが必要で、テストが異なるプラットフォームや環境で正しく実行されることを確認したい場合などです。この目的のために、TeamCity に最初に統合ビルドを実行するように指示し、統合ビルドが成功した場合にリリースビルドを実行するように指示することができます。

もう 1 つのケースは、テストの実行に時間がかかりすぎるため、テストを別々のビルド構成に抽出する必要がある場合ですが、それらが同じソーススナップショットを使用していることも確認する必要があります。

TeamCity UI でチェーンをビルドする

スナップショットの依存関係が定義され、少なくとも 1 つのビルドチェーンがトリガーされると、関連するビルド構成のプロジェクトホームページとホームページにビルドチェーンタブが表示され、すべてのビルドチェーンの視覚的な表現と、最初に取得した同じソースセットを使用して任意のチェーンステップを手動で再実行する方法が提供されます。

スナップショットの依存関係の仕組み

スナップショットの依存関係がどのように機能するかを理解するには、モジュールの依存関係を考えてみてください。これらの概念は似ているからです。しかし、まずは基本から始めましょう。ビルドチェーンがあると仮定します。

A1 のビルドがトリガーされると、ビルドチェーン A1...AN 全体がビルドキューに追加されますが、その逆ではない ! - ビルド AN がトリガーされると、ビルドチェーンの他の部分には影響せず、AN のみが実行されます。
ビルドは AN から A1 まで順次を実行します。ビルド A（k-1）は、ビルド Ak が正常に終了するまで開始されません。
チェーンのすべてのビルドは同じソースのスナップショットを使用します。つまり、ソースのリビジョンを明示的に指定して、ビルドチェーンがキューに追加された時点で計算されます。

それでは詳細と例を見てみましょう。

例 1

追加オプションなしの、単純なスナップショット依存関係を持つビルドチェーンがあると仮定しましょう。

ビルド A がトリガーされたときに起こること

TeamCity はビルドチェーン全体を解決し、すべてのビルド (A、B、C) をキューに入れます。TeamCity はビルドが厳密な順序で実行されることを認識しているため、ビルド B が完了するまでビルド A は実行されず、ビルド C が完了するまでビルド B は実行されません。
依存関係設定により、このデフォルトの動作を変更し、上流のビルドが失敗したりまったく開始されなかった場合でも下流のビルドを実行できるようにすることができます。
ビルドがキューに追加されると、TeamCity はビルドチェーン全体の変更のチェックを開始し、同期します。すべてのビルドは同じソーススナップショットから開始する必要があります。
スナップショットの依存関係に接続されているビルド構成が同じ VCS ルートのセットを共有している場合、すべてのビルドは同じソースで実行されることに注意してください。それ以外の場合、VCS ルートが異なると、VCS の変更は同じ時点に対応します。
ビルド C が完了すると、ビルド B が開始され、これが繰り返されます。ビルド C が失敗した場合、TeamCity はデフォルトではチェーンからのビルドをさらに実行しませんが、この動作は構成可能です。

ビルド B がトリガーされたときに起こること

ビルドチェーン B → C でも同じプロセスが実行されます。ビルド A は影響を受けず、実行されません。

例 2

最後のビルド A がトリガーされると、TeamCity はビルドチェーンを解決し、合計 3 つのビルドをキューに入れます。A、B1、B2。B1 と B2 の両方が準備されるまでビルド A は開始されません。
この場合、どのビルドでも問題はありません - B1 または B2 - 最初に開始されます。少なくとも 2 つの互換性のあるアイドル状態のエージェントがある場合、これらのビルドは並行して実行できます。最初の例と同様に、すべてのビルドがキューに追加されると、TeamCity はビルドチェーン全体の変更をチェックし、同期します。

高度なスナップショット依存関係の設定

ビルドを再利用する

ビルドチェーンに属するすべてのビルドはキューに入れられます。しかし、ビルドチェーンからのすべてのビルドの実行を強制する代わりに、TeamCity は、必要なソーススナップショットを使用した完了済みのビルドなど、適切なビルドがすでに存在するかどうかを確認できます。一致するキュー内のビルドは実行されず、キューから削除されます。そして、TeamCity は依存関係を適切なビルドにリンクします。これを有効にするには、スナップショットの依存関係オプションを設定する際に「適切なものがあれば、新しいビルドを実行しないでください」を選択してください。

ビルドの再利用方法を制御できるもう 1 つのオプションは " 適切なビルドから成功したビルドのみを使用する " です。これは適切なビルドがある場合に役立ちますが、成功しません。通常、チェーンでビルドに失敗した場合、TeamCity は残りのチェーンを処理しません。ただし、このオプションを有効にすると、TeamCity はこれらのソース上でこの失敗したビルドをもう一度実行します。これはいつ役に立ちますか？例: ビルド失敗が VCS に接続するときの問題によって引き起こされたとき。

強制改訂の同期をオフにする

スナップショット依存関係を作成するときに " リビジョン同期を強制する " オプションを無効にすると、TeamCity は、ビルドがある部分から別の部分にプロモートされたときに、チェーン部分に対して異なるリビジョンを使用することができます（ビルドチェーンでさらに読む）。

デプロイチェーンの例を見てみましょう:

次のビルド構成

D: コンパイル
C: integration testing
B: システムテスト
A: デプロイ

ここでは、ビルド B のスナップショット依存関係では " リビジョン同期を強制する " オプションが無効になっていますが、C と A にはこのオプションが有効（デフォルト状態）のスナップショット依存関係があります。これらの設定に基づいて、TeamCity は B と A の間だけでなく D と C の間でもリビジョンを同期させますが、チェーンパーツ D-C と B-A に対して異なるリビジョンを使うことができます。

この例では、D と C にリビジョン 1、B にリビジョン 2、A にリビジョン 3 があります。

統合テスト C をスキップしながら最新のデプロイ構成 A を使用して古いコンパイルビルド D を実行する場合は、ビルド D を直接 B にプロモートできます。TeamCity はリビジョン 1 を使用して D を実行します。それから B を新しい A のリビジョンと同期させ、リビジョン 3 を使って B と A を実行します。

チェーンのさまざまなビルド構成の依存関係に対してこのオプションを有効または無効にすることで、セットアップをより細かく制御し、より柔軟にすることができます。

リビジョン間の競合を防ぐには、依存ビルド (A) が複数の直接依存ビルド (B) および (C) とリビジョンを同期する必要があり、これらのビルドが他のビルド (D) に対するスナップショット依存関係で「リビジョン同期を強制する」オプションの状態が異なるチェーンを構成しないようにしてください。
代わりに次の有効なチェーンを使用してください。

同期は D-B-A ビルドフローでは有効ですが、D-C-A では無効です。

同期は D-B および D-C で有効になりますが、B-A および C-A では無効になります。

同じエージェントでビルドを実行する

このオプションは、ビルドチェーンからのビルドがシステム環境を変更し、次のビルドがそのシステム状態に依存しているため、同じビルドエージェントで実行する必要がある場合に設計されています。

依存関係が失敗した場合のビルド動作

依存関係が失敗した場合の最終的なビルド動作を構成することができます。

スナップショット依存関係の変更をトリガー

VCS ビルドトリガーには、ビルドチェーンのトリガー動作を変更する別のオプションがあります。このオプションを有効にすると、最終ビルドではなく依存関係で変更が検出された場合でも、ビルドチェーン全体がトリガーされます。

例からビルドチェーンを見てみましょう: pack setup — 依存 — tests — 依存 — compile

pack setup 構成で VCS トリガーを設定すると、通常、TeamCity が pack setup の変更を検出すると、ビルドチェーン全体がトリガーされます。compile の変更は、compile のみをトリガーし、チェーン全体はトリガーしません。compile の VCS 変更でチェーン全体をトリガーする場合は、チェーン、pack setup の最終ビルド構成に、「スナップショット依存関係の変更をトリガー」オプションを有効にした VCS トリガーを追加します。これにより、ビルドの実行順序は変更されませんが、スナップショット依存関係のいずれかに変更があった場合にのみ、ビルドチェーン全体がトリガーされます。この設定では、compile または tests ビルド構成に VCS トリガーは必要ありません。

依存関係からの変更

スナップショット依存関係のあるビルド構成の場合、ビルド構成設定のバージョン管理セクションでスナップショットの依存関係からの変更を表示するオプションを切り替えることができます。

この設定を有効にすると、変更ログタブと保留中の変更タブ、ビルド履歴、問題ログにアップストリームビルド構成の変更が表示されます。また、この設定により、アップストリーム構成にコミットされた変更に基づいて、ビルド構成トリガーが自動的に新しいビルドを開始できるようになります。

スナップショットの依存関係からの変更を表示するオプションはデフォルトの動作を指定します。この設定に関係なく、ユーザーはビルド変更リストを表示する際に、対応するチェックボックスを切り替えることで、他の構成 / リポジトリからの変更を含めるか除外するかを選択できます。

依存ビルドのパラメーター

TeamCity は、現在のビルドが依存するビルドによって提供されるプロパティを使用する機能を提供します (スナップショットまたはアーティファクトの依存関係経由)。ビルド A がビルド B に依存している場合、ビルド B からビルド A にプロパティを渡すことができます。つまり、プロパティはビルドチェーンフローの方向にのみ渡すことができ、その逆はできません。
以前のビルドのパラメーターをチェーンで使用する方法の詳細については、依存関係プロパティセクションを参照してください。

ビルドを並行して実行する

ビルドチェーンは、無数の並列および順次接続を持つことができます。次の場合、ビルドは互いに並行して実行されます。

これらの各ビルドには、同じ依存関係ビルドに対する独自のスナップショット依存関係があります。これらのビルドは、依存関係のビルドが終了するとすぐに開始できるようになります。
サーバーには十分な数の無料ビルドエージェントがあります。エージェントがビジーの場合、TeamCity は、エージェントの負荷に応じて、これらのビルドを次々に実行します。

構成のセキュリティ保護

TeamCity は、スナップショットとアーティファクトの依存関係を介して構成をリンクすることをサポートしており、複雑なマルチプロジェクトビルドチェーンを実現します。ただし、これは外部プロジェクトの開発者が依存関係を使用してビルドをトリガーし、他のチームが所有する構成からアーティファクトをインポートできることも意味します。

プロジェクトに機密性の高い構成やリソースを大量に消費する構成が含まれている場合は、次の方法で保護できます。

厳格なユーザー権限を設定してください。プロジェクトのプロジェクトビューアーロールを持つユーザーは誰でも、自分の構成でこのプロジェクトへの依存関係を作成できます。これにより、外部ユーザーは、直接実行する権限がなくても、構成を利用できるようになります。
ユーザー権限が制限されているからといって、外部プロジェクトが設定に完全にアクセスできないという保証はありません。TeamCity UI では、プロジェクト管理者は参照できないプロジェクトへの依存関係を作成することはできません。ただし、ターゲット設定 ID がわかっている場合は、バージョン管理された設定から作成できます。
import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.buildSteps.script object Build2 : BuildType({ name = "External project configuration" dependencies { snapshot(AbsoluteId("TargetBuildConfigID")) { } } })
ビルド承認機能を使用してください。これにより、他のチームは引き続き構成に依存関係を追加できますが、新しいビルドは指定されたチームメンバーによって承認されるまでキューに保持されます。
このオプションでは、外部プロジェクトがアーティファクトの依存関係のみを使用している場合、アーティファクトのインポートがブロックされません。
プロジェクト設定のプロジェクトの分離タブで、きめ細かなアクセス権限を設定できます。アーティファクトとスナップショットの依存関係を、任意のプロジェクトから許可することも、許可リストに登録したプロジェクトのみに制限することもできます。プロジェクトがリストに含まれていない場合、そのプロジェクトの構成ビルドは開始されません。このオプションの詳細については、以下のプロジェクトの分離セクションを参照してください。

プロジェクトの分離

プロジェクト分離オプションは、プロジェクト設定の対応するタブで使用できます。

信頼できるプロジェクトのみモードは、ターゲットプロジェクトとそのサブプロジェクトを分離し、他の (外部) プロジェクトが所有するビルド構成がスナップショットやアーティファクトの依存関係を介してこの分離されたブランチにアクセスするのを防ぎます。

デフォルトの信頼関係

プロジェクトを信頼できるプロジェクトのみモードに切り替えると、すべてのサブプロジェクトが相互に信頼される分離されたプロジェクトブランチが生成されます。

例: 次のプロジェクト階層を考えてみましょう。

Root Project
   │
   ├── Project A
   │     │
   │     ├── Project A1
   │     └── Project A2
   │
   └── Project B ("Only trusted projects" enabled)
         │
         ├── Project C
         └── Project D
               │
               ├── Project D1
               └── Project D2

プロジェクト B は「信頼できるプロジェクトのみ」モードに設定されており、「B → C、D → D1、D2」のブランチが分離されています。他のすべてのプロジェクトが制限の少ない「すべてのプロジェクト」モードに設定されている場合、この設定は以下のようになります。

「B → C、D → D1、D2」チェーンのすべての構成は、互いに自由に依存できます。これには、トップダウンとボトムアップの両方の依存関係が含まれます。
// Horizontal dependency object C_BuildConfig : BuildType({ name = "Configuration from Project C" dependencies { // Configurations from sibling projects C and D snapshot(D_BuildConfig) {} } }) // Top-down dependency object C_BuildConfig : BuildType({ name = "Configuration from Project C" dependencies { // Projects trust their direct and indirect parents snapshot(D1BuildConfig) {} } }) // Bottom-up dependency object D1BuildConfig : BuildType({ name = "Configuration from Project D1" dependencies { // Projects trust their direct and indirect children snapshot(B_BuildConfig) {} } })
サブプロジェクトを「信頼できるプロジェクトのみ」モードに切り替えることで、トップダウンの依存関係を制限できます。例: プロジェクト D がこのモードの場合、「D → D1、D2」チェーンはさらに分離され、「B → D」の依存関係が防止されます。
プロジェクト A、A1、A2 から分離されたプロジェクトへの依存関係は失敗します。外部プロジェクトを許可リストに追加することで、この問題を解決できます。
object A2BuildConfig : BuildType({ name = "Configuration from Project A2" dependencies { // A2 cannot trigger isolated D1, the build will fail snapshot(D1BuildConfig) {} } })
逆は当てはまりません。A は分離されていないため、プロジェクト B、C、D、D1、D2 の構成は A、A1、A2 に依存する可能性があります。
object D1BuildConfig : BuildType({ name = "Configuration from Project D1" dependencies { // D1 can trigger non-isolated A2 snapshot(A2BuildConfig) {} } })

信頼できるプロジェクトリスト

分離されたブランチの外部にあるプロジェクトがこれらの分離されたプロジェクトへの依存関係を持つことを許可するには、新しい信頼できるプロジェクトを追加するをクリックし、必要なプロジェクトをリストに追加します。プロジェクトは、その許可リストをすべての直接および間接の子に伝播します。上記の例では、プロジェクト D がプロジェクト A を信頼している場合、後者はプロジェクト D、D1、D2 が所有する構成に対してスナップショットとアーティファクトの依存関係を持つことができます。

プロジェクトの分離ページでは、信頼できる依存関係を、このプロジェクトレベルで明示的に宣言されたものと、親プロジェクトから継承されたものの 2 つのテーブルに分割します。

子プロジェクトは親プロジェクトから信頼できるプロジェクトリストを継承するため、独立したブランチの最上位プロジェクト（上記の例ではプロジェクト B）に信頼できるプロジェクトを追加することをお勧めします。これにより、クリーンでメンテナンスしやすい設定を維持できます。

プロジェクトを信頼できるプロジェクトのみモードに切り替えると、TeamCity は、このプロジェクト（およびそのサブプロジェクト）に依存するビルドは、それらのプロジェクトを許可リストに追加しないと失敗するという警告を表示します。現在依存しているプロジェクトを信頼できるプロジェクトに追加するチェックボックスをオンにすると、TeamCity が現在のプロジェクト階層をスキャンし、このリストを事前に入力します。

設定の継承

プロジェクトに分離を強制する親がない場合、プロジェクトの分離ページにはすべてのプロジェクトと信頼できるプロジェクトのみの 2 つのモードが提供されます。

それ以外の場合、直接または間接の親が 2 番目のモードを使用する場合、すべてのプロジェクトオプションは親プロジェクトから設定を継承するに置き換えられます。

この継承モードでは、プロジェクトは次のものを信頼します。

その直接的および間接的な子プロジェクト。
直接および間接の親プロジェクト (分離を継承する親まで)。
親プロジェクトの許可リストに含まれるプロジェクト。各サブプロジェクトは、さらに独自の信頼できるプロジェクトのリストを定義できます（詳細については、信頼できるプロジェクトリストを参照してください）。

プロジェクトの分離とバージョン設定

信頼モード設定と信頼済みプロジェクトのリストはバージョン設定に保存されません。また、UI 経由でプロジェクト設定を編集できるようにするオプションを無効にしたバージョン設定を使用しても、TeamCity UI でプロジェクトの分離設定がブロックされることはありません。

これにより、信頼ポリシーは、リモート構成ファイル (通常のプロジェクト開発者がアクセスできる) の変更ではなく、TeamCity UI を介してプロジェクト管理者によってのみ変更できるようになります。

依存関係の使用に関するその他の注意

チェーンをビルドしてクリーンアップする

デフォルトでは、TeamCity はチェーンの一部であるビルドをクリーンアップから保護しますが、このオプションをオフにすることもできます。詳細についてはクリーンアップの説明を参照してください。

アーティファクトの依存関係とクリーンアップ

アーティファクトが他のビルドによってダウンロードされ、これらのビルドがまだクリーンアップされていない場合、アーティファクトはクリーンアップされない可能性があります。アーティファクトの依存関係が構成されたビルド構成の場合、この構成によって他のビルドからダウンロードされたアーティファクトをクリーンアップできるかどうかを指定できます。この設定は、クリーンアップポリシーページで使用できます。

チェーンでパーソナルビルドを実行する

ビルドチェーンの一部である個人用ビルドを実行すると、そのビルドの依存関係にあるすべてのビルドも個人用ビルドとして実行されます。
ただし、依存関係設定で適切なビルドの再利用を有効にすると、TeamCity は可能な限りチェーンを最適化しようとします。個人的な依存関係ビルドを実行しても価値がないか、チェックアウトルールに矛盾する場合、TeamCity は代わりに完成した非個人的なビルドを使用します。

2025 年 7 月 10 日