TeamCity 2019.1ヘルプ

依存関係を構築する

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

このページで:

導入

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

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

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

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

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

compile test pack

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

基本

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

buildConfiguration

ビルド構成

dependency.png

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

artifactDependency.png

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

お気づきのとおり、TeamCityには2つのタイプの依存関係があります。成果物依存関係とスナップショット依存関係です。つまり、最初のビルドではあるビルドの出力を別のビルドで使用することができ、2番目のビルドでは複数のビルド構成から特定の順序で同じソースでビルドを開始できます。
これら2つの依存関係は、アーティファクト依存関係がビルドのトリガー方法に影響を与えず、スナップショット依存関係自体がアーティファクトを再利用しないため、多くの場合一緒に設定されます。

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

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

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

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

artifactDependency

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

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

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

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

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

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

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

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

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

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

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

Build-Chains1.png
さらに学習したい方に

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

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

a1 a2 an

  1. If a build of A1 is triggered, the whole build chain A1...AN is added to the build queue, but その逆ではない! - if build AN is triggered, it doesn't affect anything else in the build chain, only AN is run.

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

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

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

例1

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

ABC

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

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

  2. ビルドがキューに追加されると、TeamCityはビルドチェーン全体の変更のチェックを開始し、同期します - すべてのビルドは同じソーススナップショットから開始する必要があります。
    スナップショット依存関係に関連付けられているビルド設定が同じVCSルートセットを共有している場合、すべてのビルドが同じソースで実行されます。そうではなく、VCSルートが異なる場合、VCSの変化は同じ時間に対応します。

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

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

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

例2

B1 B2 A

最終ビルドAがトリガーされると、TeamCityはビルドチェーンを解決し、すべてのビルド-A、B1、およびB2をキューに入れます。ビルドAは、B1とB2の両方の準備ができるまで開始されません。
この場合、どのビルド(B1またはB2)が最初に開始されるかは関係ありません。最初の例のように、すべてのビルドがキューに追加されると、TeamCityはビルドチェーン全体の変更をチェックし、同期します。

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

ビルドを再利用する

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

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

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

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

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

dis enf rev sync

次のビルド構成

  • D: コンパイル

  • C: 統合テスト

  • 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) に対するスナップショットの依存関係で、"リビジョン同期を強制する" オプションの状態が異なります。
代わりに次の有効なチェーンを使用してください。

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

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

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

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

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

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


関連ページ:

依存ビルド

TeamCityでは、1つのビルド構成は1つ以上の構成に依存できます。2種類の依存関係を指定できます。スナップショットの依存関係、成果物の依存関係、成果物の依存関係は、あるビルドによって生成された成果物を別のビルドに移すための単なる方法です。対応するスナップショットの依存関係がない場合は、ビルド構成...

ビルド・チェーン

このページで:一般的なユースケース、ビルドチェーンの設定、ビルドチェーンからキュービルドを停止/削除する、チェーン部品間のリビジョン同期を無効にする、チェーン視覚表現を構築するビルド構成設定の依存関係ページ、プロジェクトホームページとビルド構成ホームページのチェーンのビルドタブ、ビルド結果ページの依...

ビルドキュー

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

デプロイビルド構成

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

VCSトリガーの設定

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

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

トリガー条件日時サンプル、使用されたcron形式の簡単な説明、VCSの変更、VCSトリガールール一般的な構文、トリガルールの例、変更をビルド、追加オプションクリーンチェックアウトを実施する、すべての有効で互換性のあるエージェントでビルドをトリガー、ビルドキューの最適化設定、