ツイートはてブ LINE Pocket

コンポジットビルド構成

コンポジットビルド構成は、複数の通常のビルド構成をトリガーし、結果を 1 か所で追跡するように設計された「ステップレス」構成です。

重要なポイント

複合構成では、実際の構築ルーチンは実行されません。
複合構成では、依存関係からすべての情報が集約され、一元的な方法で表示されます。
複合ビルドはビルドキュースロットを占有せず、エージェントを実行する必要もありません。
ビルド構成タイプを切り替えるには、「構成設定 | 一般」タブに移動します。

サンプル

このチュートリアルでは、複数のビルド構成を作成し、1 つのビルドチェーンにバインドし、チェーンの最上位のビルド構成を複合構成に変換することでどのようにメリットが得られるかを学びます。

サンプルプロジェクトを作成する

この手順では、空のビルド構成を含むプロジェクトと、さまざまなプラットフォームで .NET/.NET フレームワークプロジェクトをビルド、テスト、公開する 5 つのビルド構成を含むサブプロジェクトを作成します。

GitHub リポジトリ (またはそのフォーク) からプロジェクトを作成します: TeamCity DotNet サンプル(英語)。プロジェクトをインポートするときは、設定をインポートせず、プロジェクトを最初から作成するオプションを選択します。
ビルド構成名を「すべて構築」に設定します。
TeamCity がリポジトリをスキャンした後は、TeamCity によって提案される手順を選択しないでください。実際の構築タスクは個別の構成で実行します。この最初に作成された構成は、後ですべてのタスクを一度にトリガーするために使用されます。
プロジェクト設定を開きます。
サブプロジェクトの作成をクリックします。このサブプロジェクトは、ステップ 1 と同じ GitHub リポジトリをターゲットにする必要があります。
サブプロジェクトはルートプロジェクトと同じリポジトリを使用するため、TeamCity は、重複を作成するのではなく、両方のプロジェクトが同じ VCS ルートを共有することを提案します。同意するよう求められたら、「これを使って」をクリックします。
新しい「建物の構成」サブプロジェクトで、5 つのビルド構成を作成します。すべての構成は、手順 1 と同じリポジトリをターゲットとし、共有 VCS ルートを使用する必要があります (手順 5 を参照)。
- テストの実行 (Linux) — Linux の .NET SDK コンテナー(英語)内で "Clock.Tests" C# プロジェクトをテストする単一の .NET ランナーを含む構成。
- テストの実行 (Windows) — 必要な .NET SDK がインストールされている Windows エージェント上で「Clock.Tests」C# プロジェクトをテストする単一の .NET ランナーを含む構成。
- デスクトップの構築 (Windows) — 「Clock.Desktop」および「Clock.Desktop.Uwp」プロジェクトで「msbuild」コマンドを実行する単一の .NET ランナーを含む構成。
- コンソールと Web を構築する (win-x64) — 2 つの .NET ステップを含む構成。
  - 1 つのステップでは、「win-x64」ランタイムオプションを使用して、「Clock.Console」プロジェクトで「publish」コマンドを実行します。このステップの出力ディレクトリは「bin/Clock.Console/win-x64」に設定されます。
  - 別のステップでは、「Clock.Web」プロジェクトで「publish」コマンドを実行します。このステップのランタイムオプションは「win-x64」、出力ディレクトリは「bin/Clock.Web/win-x64」です。
- コンソールと Web を構築する (linux-x64) — 前の構成と同じですが、.NET ステップのランタイム設定と出力ディレクトリ設定はそれぞれ「linux-x64」と「bin/<ProjectName>/linux-x64」に設定されています。
これらのビルド構成は単一のビルドチェーンの一部となるため、TeamCity がリモートリポジトリの変更を検出するたびに 5 つのビルド構成すべてを個別に開始するために、ビルドトリガーを自動的に追加する必要はありません。ビルド設定 |Triggers に移動し、すべての構成のトリガーを無効にするか削除します (最上位プロジェクトが所有する「すべて構築」構成を除く)。
両方の「コンソールと Web の構築」構成で「bin」フォルダーを公開する必要があります。そのためには、これらの構成で bin => bin アーティファクトパスを指定します。公開されたアーティファクトは、後でデプロイ構成で使用されます。

最終的には、ビルドステップを実行する 5 つの独立したビルド構成と、空の「すべて構築」構成が作成されます。各構成を実行して、正常に終了することを確認します。以下の Kotlin コードは、5 つのビルド構成すべてと、その親 TeamCity プロジェクトの設定を示しています。

project {
    buildType(Building_1)
    subProject(Building)
}

object Building_1 : BuildType({
    id("Building")
    name = "Build All"
    
    vcs {
        root(DslContext.settingsRoot)
        showDependenciesChanges = true
    }

    triggers {
        vcs {
        }
    }
    
})


object Building : Project({
    name = "Building Configurations"
    buildType(Building_BuildConsoleWebLinuxX64)
    buildType(Building_BuildConsoleWebWinX64)
    buildType(Building_BuildDesktopWindows)
    buildType(Building_RunTestsLinux)
    buildType(Building_RunTestsWindows)
})

object Building_RunTestsLinux : BuildType({
    name = "Run Tests (Linux)"

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        dotnetTest {
            name = "Tests (Linux)"
            projects = "Clock.Tests/Clock.Tests.csproj"
            dockerImage = "mcr.microsoft.com/dotnet/sdk:7.0"
            dockerImagePlatform = DotnetTestStep.ImagePlatform.Linux
        }
    }

    triggers {
        vcs {
            enabled = false
        }
    }

    requirements {
        matches("teamcity.agent.jvm.os.family", "Linux")
    }
})

object Building_RunTestsWindows : BuildType({
    name = "Run Tests (Windows)"

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        dotnetTest {
            name = "Test (Win)"
            projects = "Clock.Tests/Clock.Tests.csproj"
            sdk = "7"
        }
    }

    triggers {
        vcs {
            enabled = false
        }
    }

    requirements {
        matches("teamcity.agent.jvm.os.family", "Windows")
    }
})

object Building_BuildDesktopWindows : BuildType({
    name = "Build Desktop (Windows)"

    artifactRules = """
        bin/Clock.Desktop/win/**/*.* => bin/Clock.Desktop.zip
        bin/Clock.Desktop.Uwp/win/**/*.* => bin/Clock.Desktop.Uwp.zip
    """.trimIndent()

    params {
        param("system.PublishDir", "../bin/Clock.Desktop/win/")
        param("system.AppxPackageDir", "../bin/Clock.Desktop.Uwp/win/")
    }

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        dotnetMsBuild {
            name = "Build Desktop (Win)"
            projects = """
                Clock.Desktop/Clock.Desktop.csproj
                Clock.Desktop.Uwp/Clock.Desktop.Uwp.csproj
            """.trimIndent()
            version = DotnetMsBuildStep.MSBuildVersion.V17
            targets = "Restore;Rebuild;Publish"
            sdk = "7"
        }
    }

    triggers {
        vcs {
            enabled = false
        }
    }
    
    requirements {
        matches("teamcity.agent.jvm.os.family", "Windows")
    }
})

object Building_BuildConsoleWebWinX64 : BuildType({
    name = "Build console & web (win-x64)"
    artifactRules = "bin => bin"

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        dotnetPublish {
            name = "Build Console (win-x64)"
            projects = "Clock.Console/Clock.Console.csproj"
            runtime = "win-x64"
            outputDir = "bin/Clock.Console/win-x64"
        }
        dotnetPublish {
            name = "Build web"
            projects = "Clock.Web/Clock.Web.csproj"
            runtime = "win-x64"
            outputDir = "bin/Clock.Web/win-x64"
        }
    }

    triggers {
        vcs {
            enabled = false
        }
    }
    
    requirements {
        exists("DotNetCoreSDK7.0_Path")
        exists("DotNetCoreRuntime7.0_Path")
    }
})

object Building_BuildConsoleWebLinuxX64 : BuildType({
    name = "Build console & web (linux-x64)"
    artifactRules = "bin => bin"

    vcs {
        root(DslContext.settingsRoot)
    }

    steps {
        dotnetPublish {
            name = "Build console"
            projects = "Clock.Console/Clock.Console.csproj"
            runtime = "linux-x64"
            outputDir = "bin/Clock.Console/linux-x64"
            args = "/p:PublishTrimmed=true /p:PublishSingleFile=true"
        }
        dotnetPublish {
            name = "Build web"
            projects = "Clock.Web/Clock.Web.csproj"
            runtime = "linux-x64"
            outputDir = "bin/Clock.Web/linux-x64"
        }
    }

    triggers {
        vcs {
            enabled = false
        }
    }

    requirements {
        exists("DotNetCoreSDK7.0_Path")
        exists("DotNetCoreRuntime7.0_Path")
    }
})

ビルドチェーンのセットアップ

この手順では、単一のチェーンにビルド構成をバインドするスナップショットの依存関係を作成します。

「デスクトップを構築する (Windows) 構成設定で、依存関係タブに切り替えて、新しいスナップショット依存関係を追加するをクリックします。「テストの実行 (Windows)」ビルド構成をチェックして、このビルド構成を起動する前にテストを実行するように TeamCity に指示します。
手順 1 を繰り返して、両方の「コンソールと Web を構築 ...」構成のスナップショット依存関係を設定します。これらは、対応する「テストを実行 ...」構成に依存する必要があります。
「すべて構築」構成設定で、3 つの " 建てる ..." 構成すべてにスナップショット依存関係を追加します。
3 つの " 建てる ..." 構成はアーティファクトを公開します。最上位の「すべて構築」構成からこれらにアクセスできるようにするには、アーティファクトの依存関係を作成する必要があります。
<ビルド全設定> | 依存関係に移動し、新しいアーティファクト依存関係を追加するをクリックして、3 つの " 建てる ..." 構成すべてに依存関係を作成します。各アーティファクト依存関係のアーティファクトのルール設定は **/*.* => . である必要があります。
「すべて構築」構成が個々の " 建てる ..." 構成によって生成されたアーティファクトにアクセスできるようになったため、その一般設定に bin/**/*.* => . アーティファクト公開ルールを追加します。

以下の Kotlin コードは、最終的なチェーンセットアップを示しています。

object Building_1 : BuildType({
    id("Building")
    name = "Build All"
    artifactRules = "bin/**/*.* => ."

    // ...

    dependencies {
        dependency(Building_BuildConsoleWebLinuxX64) {
            snapshot {
            }

            artifacts {
                artifactRules = "**/*.* => ."
            }
        }
        dependency(Building_BuildConsoleWebWinX64) {
            snapshot {
            }

            artifacts {
                artifactRules = "**/*.* => ."
            }
        }
        dependency(Building_BuildDesktopWindows) {
            snapshot {
            }

            artifacts {
                artifactRules = "**/*.* => ."
            }
        }
    }
})

object Building_BuildDesktopWindows : BuildType({
    name = "Build Desktop (Windows)"
    artifactRules = """
        bin/Clock.Desktop/win/**/*.* => bin/Clock.Desktop.zip
        bin/Clock.Desktop.Uwp/win/**/*.* => bin/Clock.Desktop.Uwp.zip
    """.trimIndent()

    // ...

    dependencies {
        snapshot(Building_RunTestsWindows) {
        }
    }
})

object Building_BuildConsoleWebWinX64 : BuildType({
    name = "Build console & web (win-x64)"
    artifactRules = "bin => bin"

    // ...
    
    dependencies {
        snapshot(Building_RunTestsWindows) {
        }
    }
})

object Building_BuildConsoleWebLinuxX64 : BuildType({
    name = "Build console & web (linux-x64)"
    artifactRules = "bin => bin"
    
    // ...

    dependencies {
        snapshot(Building_RunTestsLinux) {
        }
    }
})

複合構成の作成

構成設定の一般タブでビルド構成タイプを選択できます。このサンプルチェーンでは、「すべて構築」構成タイプを「複合」に変更できます。

通常のビルド構成と比較すると、複合構成には次のような違いがあります。

アイコン

TeamCity では、通常の構成と複合構成を区別できるようにさまざまなアイコンを使用しています。

ナビゲーションバーで:

ビルド構成 | チェーンページで:

ナビゲーションバーで:

ビルド構成 | チェーンページで:

構成設定

複合ビルド構成は、他のビルドによって生成された結果を集約します。実際の構築ルーチンを実行するように設計されていません。そのため、複合構成設定にはビルドステップまたはエージェントの要件タブが表示されません。

複合ビルドの開始とキャンセル

複合ビルド構成には実行する実際のビルドステップがないため、ビルドキュー内のスロットを占有しません。

同時に実行する複合ビルドの数を制限すると、すべての依存関係にも影響します。例: 現在の制限が 1 で、複合ビルドが実行されているとします。その場合、キューに入れられた別の複合ビルドに属するすべての依存関係ビルドは、進行中のビルドが完了するまで待機します。

複合ビルドを停止するかキューから削除すると、ビルドチェーン全体が停止または削除されます。

結果の集計

ビルドチェーンの最初の依存関係が開始されると、複合ビルドは実行中として表示されます。ビルドのステータステキスト、期間、進行状況インジケーターには、このチェーンのすべての通常のビルドの集約されたパラメーターが反映されます。

チェーンのビルドが失敗した場合、複合ビルドにそれが反映されるため、問題を即座に特定できます。

複合ビルドのテストタブはテストを集約し、合格、失敗、ミュート、無視されたすべてのテストを 1 か所に表示します。同じことが、コードカバレッジまたはコードインスペクション / コード重複分析の結果にも当てはまります。

アーティファクト

通常のビルドも複合ビルドも、ビルドからのアーティファクトをチェーンに集約しません。通常のビルドによって生成されたアーティファクトを複合ビルドのアーティファクトタブに表示するには、対応するアーティファクトの依存関係を追加し、必要なアーティファクトルールを設定します ( ビルドチェーンのセットアップセクションの手順 4 および 5 を参照)。

複合構成には独自のアーティファクトがないため、依存関係構成でアーティファクトのクリーンアップポリシーを設定する必要があります。

複合ビルドのグループ化

プロジェクト | ビルドチェーンページには、複合構成で終わるビルドチェーンのすべての部分を 1 つの視覚要素に折りたたむことができるグループ複合ビルドオプションが表示されます。

2026 年 3 月 08 日

関連ページ：

プロジェクトの作成と編集

TeamCity では、実際のビルドタスクはビルド構成とパイプラインによって実行されます。ただし、どちらもプロジェクト内に配置する必要があります。このトピックでは、プロジェクトを作成するさまざまな方法を説明します。ルートプロジェクトと設定の継承：始める前に、すべての TeamCity サーバーには、ルートプロジェクトと呼ばれる削除不可能な組み込みプロジェクトが含まれていることにご注意ください。すべての新しいプロジェクトはこのプロジェクトの子として作成されますが、ビルド構成やパイプラインを直接ホ...

ビルド構成の作成と編集

ビルド構成とパイプラインは、実際の CI/CD ルーチンを表します。ビルド構成には、一連のビルドステップ（ビルド実行中に実行される基本操作）と、これらのステップの実行に必要な設定が格納されます。これらの設定には以下が含まれます。構成の動作をすばやく変更できるパラメーター。特定の条件が満たされたときに TeamCity が自動的に新しいビルドを開始できるようにするトリガー。構成の機能を拡張する機能を構築します。特定のビルドエージェントで構成ビルドを実行できるようにするエージェント要件。その他。ビル...

ビルドチェーンを作成

ビルドチェーンまたはパイプラインは、連続して実行されるビルド構成のシーケンスです。TeamCity では、これらの構成は異なるプロジェクトに属し、あるビルドから別のビルドにファイル（アーティファクト）を渡すことができます。このチュートリアルでは、次のプロジェクトの設定手順を説明します。上記のパイプラインは、次のステージを循環します。1 — サンプル Spring Boot アプリケーションの構築 2 — このアプリの Docker イメージの作成 3 および 4 — 2 セットの並列テストの実行...

.NET

TeamCity.NET ビルドステップを使用すると、.NET (Core) および .NET フレームワークを対象とするアプリケーションをビルド、テスト、デプロイできるほか、NuGet パッケージをダウンロードしてプッシュすることもできます。.NET ステップイン構成とパイプライン：クラシックビルド構成では、.NET は、選択したコマンドに応じて設定が変化する単一のビルドステップです。パイプラインでは、これらの各コマンドは個別のビルドステップとして使用できます。エージェント要件：.NET ス...

プロジェクト管理者ガイド

このセクションでは、プロジェクト管理に焦点を当てます。TeamCity プロジェクトとビルド構成の作成、ビルドステップの設定、依存関係チェーンの構成などについて説明します。基本的な TeamCity ワークフロー：次のダイアグラムは、基本的な TeamCity ワークフローを示しています。TeamCity サーバーはリポジトリの変更を検出しました。サーバーはこの変更をデータベースに書き込みます。ビルド構成に添付されたトリガーは、データベース内の関連する変更を検出し、ビルドを開始します。トリガー...

VCS ルートの設定

VCS ルートは、TeamCity ←→ VCS リポジトリ通信の基礎です。この不可欠な要素は、リポジトリのチェックアウト、コードソースのタグ付け、ビルドステータスの VCS への返信など、さまざまな操作を実行するために必要な VCS プロバイダーへの接続を定義します。VCS ルートには次の情報が保存されます。TeamCity がリモートファイルをプルおよびプッシュするために使用する URL を取得してプッシュします。ブランチ情報: TeamCity が追跡する必要があるリポジトリブランチのリスト...