TeamCity 2020.1ヘルプ

依存関係を構築する

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

導入

多くの場合、あるビルドの出力を別のビルドで使用したり、同じソース上でいくつかのビルドを順番に実行したりすると便利です。典型的な例を考えてください。本番ビルドを取得する前に、WindowsとmacOSでテストする必要があるクロスプラットフォームプロジェクトがあります。この単純なケースのための最良のワークフローは以下の通りです。

  1. プロジェクトをコンパイルしてください。

  2. 同じソースでWindowsとmacOSで同時にテストを実行する

  3. テストが両方のOSで合格した場合は、もちろん、同じソースでリリース版をビルドします。

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

compile test pack

コンパイルテスト (勝つ)テスト (mac)、およびパック設定はビルド構成であり、当然テストはコンパイルに依存します。つまり、コンパイルの準備ができるまで待機する必要があります。

基本

一般にビルドパイプラインと呼ばれ、TeamCityでは同様の概念がビルドチェーンと呼ばれます。TeamCityでこれがどのように機能するかについて詳しく説明する前に、ここで紹介する図の背景にある凡例を明確にしましょう(はじめに紹介したものも含めて)

buildConfiguration

ビルド構成

dependency.png

スナップショットの依存関係 between 2 build configurations. Note that the arrow shows the sequence of triggering build configurations, the build chain flow, meaning that B is executed before A. However, the dependencies are configured in the opposite direction (A snapshot-depends on B). The arrows are drawn this way because in the TeamCity UI you can find the visual representation of build chains which are always displayed according to the build chain flow.
Typically, when adding a snapshot dependency, you also add an artifact dependency with the "build from the same chain" option from the same configuration to transfer the previous build results and use them in the build as well.

artifactDependency.png

成果物の依存関係。矢印は成果物の流れを示し、依存関係は反対方向に構成されています。

As you noticed, there are 2 types of dependencies in TeamCity: artifact dependencies and snapshot dependencies. In two words, the first one allows using the output of one build in another, while the second one can trigger builds from several build configurations in a specific order, but on the same sources.
These two dependencies are often configured together because an artifact dependency doesn't affect the way builds are triggered, while a snapshot dependency itself doesn't reuse artifacts, and sometimes you may need only one of those.

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

それでは、成果物とスナップショットの依存関係で何ができるのか、それらがどのように機能するのかを見てみましょう。

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

成果物の依存関係により、あるビルド(またはその一部)の出力を別のビルドで再利用することができます。

artifactDependency

ビルド構成ABに成果物依存関係を持っている場合、Aのビルドが開始される前にBの成果物がビルド・エージェントにダウンロードされます。どのアーティファクトを取得し、どこに正確に配置するかを構成するために、アーティファクトルールを柔軟に調整できます。

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

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

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

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

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

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

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

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

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

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

Build chain example

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

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

a1 a2 an

  1. A1のビルドがトリガーされると、ビルドチェーン A1 ... AN全体がビルドキューに追加されますが、その逆ではない!-ビルドANがトリガーされると、ビルドチェーンの他の何にも影響せず、ANのみが実行されます。

  2. ビルドはANからA1まで順次を実行します。ビルドA(k-1)は、ビルドAkが正常に終了するまで開始されません。

  3. チェーンのすべてのビルドは同じソースのスナップショットを使用します。つまり、ソースのリビジョンを明示的に指定して、ビルドチェーンがキューに追加された時点で計算されます。

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

例1

次のようなチェーンを追加オプションなしで作成したとしましょう - 単純なスナップショット依存関係。

ABC

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

  1. TeamCityは、ビルドチェーン全体を解決し、すべてのビルド(A、B、C)をキューに入れます。TeamCityは、ビルドが厳密な順序で実行されることを認識しているため、ビルドBが正常に終了するまでビルドAを実行しません。ビルドCが正常に終了するまでビルドBを実行します。

  2. When the builds are added to the queue, TeamCity starts checking for changes in the entire build chain and synchronizes them - all builds have to start with the same sources snapshot.
    Note that if the build configurations connected with a snapshot dependency share the same set of VCS roots, all builds will run on the same sources. Otherwise, if the VCS roots are different, changes in the VCS will correspond to the same moment in time.

  3. ビルドCが終了すると、ビルドBが開始されます。ビルドCが失敗した場合、TeamCityはデフォルトでチェーンからさらにビルドを実行しませんが、この動作は設定可能です。

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

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

例2

B1 B2 A

When the final build A is triggered, TeamCity resolves the build chain and queues all builds - A, B1 and B2. Build A won't start until both B1 and B2 are ready.
In this case it doesn't matter which build - B1 or B2 - starts first. As in the first example, when all builds are added to the queue, TeamCity checks for changes in the entire build chain and synchronizes them.

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

ビルドを再利用する

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

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

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

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

デプロイ チェーンの例を調べてみましょう。

dis enf rev sync

次のビルド構成

  • 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を実行します。

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

To prevent conflicts between revisions, avoid configuring chains where the dependent build (A) must synchronize revisions with its several direct dependency builds (B) and (C), and these builds have different states of the " リビジョン同期を強制する " option in their snapshot dependencies on some other build (D).
Use the following valid chains instead:

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

valid snap flow1

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

valid snap flow2

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

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

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

依存関係が失敗した場合は、最終的なビルド動作を設定できます。

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

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

例からビルドチェーンを取りましょう。pack setup - 依存 - tests - 依存 - compile

compile test pack

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

依存関係からの変更

スナップショット依存関係を持つビルド構成では、これらの依存関係からの変更を推移的に表示できるようにすることができます。この設定は "スナップショットの依存関係からの変更を表示する"と呼ばれ、ビルド構成管理ページのバージョン管理設定ステップの詳細オプションで利用できます。

この設定を有効にすると、ビルド構成の保留中の変更、ビルド履歴内の変更、変更ログ、および発行ログが影響を受けます。依存関係からの変更は deps_changes_marker.gifでマークされています。例:

changes popup

この設定を有効にすると、"保留中の変更がある場合にのみビルドを開始する"オプションを持つスケジュールトリガーは、依存関係からの変更も考慮します。

依存ビルドのパラメータ

TeamCity provides the ability to use properties provided by the builds the current build depends on (via a snapshot or artifact dependency). When build A depends on build B, you can pass properties from build B to build A, i.e. properties can be passed only in the direction of the build chain flow and not vice versa.
For the details on how to use parameters of the previous build in chain, refer to the 依存関係プロパティ section.

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

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

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

成果物の依存関係とクリーンアップ

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

関連ページ:

依存ビルド

TeamCityでは、1つのビルド構成は1つ以上の構成に依存できます。2種類の依存関係を指定できます。スナップショットの依存関係、成果物の依存関係、Anartifact dependencyis just a way to get artifacts produced by one build in...

ビルド・チェーン

ビルドチェーンは、スナップショット依存関係によって相互接続された一連のビルドです。ビルドチェーンは「パイプライン」と呼ばれることもあります。リビジョンの同期を有効にしてスナップショットの依存関係とリンクされたビルドチェーンの一部は、ソースの同じスナップショットを使用します。一般的なユースケース:ビル...

ビルドキュー

ビルドキューは、トリガーされて開始されるのを待っているビルドのリストです。エージェントがアイドル状態になるとすぐに、TeamCityはそれらを互換性のあるビルドエージェントに配布します。キュービルドは、エージェント上で開始された時点でエージェントに割り当てられます。ビルドがビルドキューで待機している...

デプロイビルド構成

TeamCityは、デプロイタイプのビルド構成を提供します。一部の環境へのデプロイを実行するビルド構成は、このタイプでマークできます。これらは通常、結果がデプロイされるビルドにスナップショットまたはアーティファクトの依存関係があるビルド構成です。Aftercreating a build confi...

VCSトリガーの設定

TeamCityが設定されたVCSルートで新しい変更を検出するたびに、VCSは自動的に新しいビルドを開始し、保留中の変更にその変更を表示します。ビルド構成に追加できるVCSトリガーは1つだけです。デフォルト設定の新しいVCSトリガーは、ビルド設定に保留中の変更があるとビルドをトリガーします。バージョ...

スケジュールトリガーの設定

スケジュールトリガーを使用すると、構成のビルドを実行する時間を設定できます。現在のプロジェクト設定のスケジュールを構築するセクションには、構成されたビルド時間が表示されます。ビルド構成に複数のスケジュールトリガーを追加できます。トリガー条件:このセクションの設定は、自動ビルドトリガーの時間やその他の...