パイプラインの作成と編集

パイプラインとビルド構成とチェーン

パイプラインの作成に進む前に、ビルド構成とパイプラインの違い、それぞれをいつ使用するかを理解することが重要です。パイプライン（またはパイプライン内のジョブ）を一度作成すると、ビルド構成に変換することはできません。また、その逆も同様です。詳しくは制限事項と特記事項セクションを参照してください。

親

ビルド構成とパイプラインはどちらも TeamCity プロジェクトが所有します。各プロジェクトには、無制限の数の構成とパイプラインを含めることができます。

子

• ビルドはビルドステップを直接所有します。

• パイプラインはジョブを所有し、ジョブは通常のビルドステップを所有します。

サポートされている VCS タイプ

• クラシック TeamCity ビルド構成は、Git、Subversion、Mercurial、TFS、Perforce をサポートし、GitHub、GitLab、Bitbucket、Azure などの主要な VCS プロバイダーとの統合を実現します。

• TeamCity パイプラインは、GitHub、GitLab、Bitbucket Cloud との統合機能を内蔵しています。その他の Git リポジトリには、直接 URL 経由で接続できます。Subversion、Mercurial、TFS、Perforce は現在サポートされていません。

実行モード

• パイプラインは常に最初から最後まで実行され、コンパイル失敗や接続の問題などのエラーによって中断されない限り、すべてのジョブが実行されます。

• ビルド構成は条件付きステップ実行をサポートします。例: 前のステップが失敗した場合にのみ実行されるステップを追加できます。

依存関係

• 現在、パイプラインは同じパイプライン内のジョブ間の依存関係のみをサポートしており、より大きなシーケンスにリンクすることはできません。

• ビルド構成は、異なる TeamCity プロジェクト間でビルドチェーンを形成できます。

コードとしての構成

パイプラインとビルド構成はどちらも、設定をコードとしてプロジェクトのソースコードのすぐ隣に保存できます。どちらもブランチ設定をサポートしているため、各リポジトリブランチごとに独自の設定ファイルを持つことができます。

• ビルド構成は XML または Kotlin DSL 形式で設定を保存します。これらのファイルは TeamCity UI から編集できません。

• パイプラインは設定を YAML 形式で保存し、TeamCity で直接編集できます。

Kotlin DSL のサポートは、将来のパイプラインのバージョンで計画されています。ただし、ビルド構成に YAML サポートを追加する予定は現時点ではありません。

制限

• ビルド構成は TeamCity のコアコンポーネントであり、広範な機能とカスタマイズオプションを提供します。

• TeamCity 2025.07 で導入されたパイプラインは、CI/CD ワークフローを最も直感的に設計する方法を提供することに重点を置いています。ただし、現時点ではビルド構成で利用できる機能の一部が欠落しています。たとえば、ほとんどのビルドステップをサポートしておらず、追加のビルド機能もありません。

まとめると、パイプラインとビルド構成はどちらもプロジェクトが所有するものの、それぞれ異なるニーズに対応します。パイプラインは、小規模プロジェクト（通常は 10 – 15 ビルドまで）におけるシンプルな CI/CD ワークフローに最適です。以下の場合は、代わりにビルド構成を選択してください。

• プロジェクトには、10 – 15 シーケンシャルビルドよりも複雑なワークフローが含まれます。

• パイプラインでまだ利用できない高度な機能 ( ビルド承認など) を必要とする経験豊富なユーザーです。

• どのビルドのチェーン構成をいつ、どのように実行するかを細かく制御する必要があります。

パイプラインの作成と設定

プロジェクトにパイプラインを追加するには、プロジェクトヘッダーまたは TeamCity サイドバーの + ボタンを使用します。

TeamCity は、このパイプラインで処理するリモートリポジトリを選択するように求めます。既存の Git VCS ルート、VCS ホスティングへのサポートされている接続、または Git URL を手動で入力できます。デフォルトのブランチおよびブランチの仕様は、通常のビルド構成と同じルールに従います。詳細については、デフォルトブランチおよび共通仕様構文を参照してください。既存のルートを選択した場合、ブランチの設定は無効になります。編集するには、ルート設定を変更してください。

新しいパイプラインには必ず空のジョブがあります。ジョブタイルをクリックして設定を表示するか、対応する領域をクリックして新しいジョブを追加できます。

グローバルパイプライン設定を表示するには、ビジュアルエディターでハイライトされた領域をクリックします。

パイプラインジョブを必要な順序に並べ替えるには、ジョブを選択し、依存関係セクションでその上流ジョブを確認します。ビジュアルエディターを使用して、あるジョブから別のジョブに行をドラッグ & ドロップすることもできます。

基本的な操作の詳細については、パイプライン設定およびジョブ設定を参照してください。

共用ファイル

ジョブは実行中に生成されたファイルを共有できます。これらのファイルは、下流のジョブまたは TeamCity ユーザー（あるいはその両方）と共有できます。

• 下流ジョブと共有されるファイル。この場合、現在のジョブに続くジョブは共有ファイルをインポートし、独自のスクリプトで使用できます。

  以下のサンプルは、最初のジョブによって作成され共有されるファイルで動作する 3 つのジョブのパイプラインを示しています。

  jobs: Job1: name: Create file steps: - type: script script-content: touch output.txt files-publication: - path: output.txt share-with-jobs: true publish-artifact: false Job2: name: Modify file dependencies: - Job1: files: - output.txt steps: - type: script script-content: 'echo "Modified by Job #2" >> output.txt' Job1_2: name: Print file dependencies: - Job2 steps: - type: script script-content: cat output.txt

  共有ファイルは、「.shared_files.zip」アーカイブ内の隠しアーティファクトとして表示されます。

• ユーザーと共有されたファイル（アーティファクト）。これらは、従来のビルド構成で生成されたビルドアーティファクトと同一です。TeamCity では、実行結果ページのアーティファクトタブにアーティファクトが表示されます。

ジョブでファイルを共有する相手を選択するには、ジョブの出力ファイルセクションエントリにある関連するチェックボックスをオンにします。

依存関係

Pipelines で再構築されたもう一つの古典的な TeamCity 概念は依存関係です。Pipelines では、スナップショットとアーティファクトの依存関係が 1 つのオプションに統合されています。ジョブをクリックして設定を確認し、どのジョブを先行させるかを選択し、そのジョブにそれらの出力をインポートするかどうかを決定します。

ビジュアルエディターで依存関係の行をクリックして、ファイルをインポートするかどうかを選択することもできます。

Web フック

Classic TeamCity は、リポジトリの変更を検出するために、定期的なポーリングと Webhook の 2 つの方法をサポートしています。Webhook はほぼ瞬時に更新され、サーバー負荷も軽減されますが、手動での設定が必要です。詳細については、変更の収集のセクションを参照してください。

パイプラインは、ポーリングメカニズムよりも高速で効率的な代替手段として、デフォルトで Webhook を使用します。接続からパイプラインを作成すると、TeamCity はリポジトリ設定に Webhook を自動的に登録します。Webhook が削除された場合、または更新の配信に失敗した場合、ポーリングはフォールバックとして残ります。

実行ステータスを VCS に公開する

ステータス発行者のコミットは、TeamCity の最も人気のあるビルド機能の一つで、ビルドステータスを VCS 側に伝達します。HTTP 認証を使用してパイプラインを作成すると、この統合機能は自動的に利用可能になります。

下の図は、GitHub のリポジトリページに報告された TeamCity 実行ステータスを示しています。

ステータスアイコンをクリックすると詳細な説明が表示されます。詳細リンクをクリックすると、TeamCity サーバー上で実行されている対応するパイプラインが表示されます。

この統合を無効にするには、パイプラインをクリックして対応するリポジトリ設定を編集し、リポジトリにステータスを公開するをオフに切り替えます。

制限事項と特記事項

TeamCity パイプラインは早期アクセス段階にあり、TeamCity のコア機能を基盤としていますが、現時点では従来のビルド構成で利用可能な一部の機能が欠落しています。今後のリリースでは、パイプラインツールセットを拡張し、最もご要望の多かった機能を追加する予定です。

ビルドステップ

TeamCity パイプラインジョブは、Maven、Gradle、Node.js の 3 つの専用ビルドステップをサポートします。

クラシックビルド構成の他のステップタイプはまだサポートされていませんが、スクリプトステップ (クラシック TeamCity のコマンドライン (スクリプト) に相当) は柔軟な代替手段を提供します。例: .NET ビルドステップを使用する代わりに、スクリプトステップを追加して dotnet build コマンドを実行できます。

接続

TeamCity パイプラインは現在、GitHub OAuth、GitLab、Bitbucket クラウド接続をサポートしています。

パイプラインを作成するために構成された接続は必要なく、任意の Git リポジトリ URL から実行できることに注意してください。

VCS ルート

パイプラインは内部的に VCS ルートを使用しますが、VCS ルート設定を直接公開するのではなく、簡略化されたリポジトリセクションを提供します。そのため、クリーンおよびチェックアウトポリシー、カスタムポーリング間隔、サブモジュールの処理などのオプションは、パイプライン UI から設定できません。

ただし、従来の TeamCity UI で VCS ルートを作成して構成し、このルートからパイプラインを作成することはできます。

機能を構築する

パイプラインは、CI/CD ルーチンを最もシンプルかつユーザーフレンドリーに構築できるように設計されています。このゴールをサポートするために、主要な機能をパイプラインに直接統合し、個別にビルド機能を設定する必要がなくなるように取り組んでいます。

たとえば、ステータス発行者のコミットは接続の使用時に自動的に有効になり、レジストリ接続はパイプラインとジョブ設定内で統合として管理されます (個別の Docker レジストリ接続および NPM レジストリ接続ビルド機能ではなく)。

従来のビルド機能の一部はジョブにも適用可能で、ビルド構成とほとんど、あるいは全く違いはありません。これらの機能はジョブ設定 | 機能を構築するで追加できます。

• ビルドファイルクリーナー (Swabra)

• 空きディスク容量

• ビルドキャッシュ

• XML レポート処理

ビルド承認などの一部のビルド機能は、機能の改善版としても、スタンドアロンのビルド機能としても、まだパイプラインでは利用できません。皆様からのフィードバックを検討し、今後の対応の優先順位を決定し、最も要望の多かった機能を明確かつ一貫した方法で提供できるよう努めています。

トリガー

TeamCity パイプラインは現在、CI ルーチンを自動的に開始できるようにする 2 種類のトリガーをサポートしています。

• 指定された日時に新しい実行を開始するスケジュールトリガー。

• 開始される VCS トリガーは、新しいコードの変更時に実行されます。

両方とも、パイプライン設定の自動実行パイプラインセクションで構成されます。

その他のトリガータイプ (たとえば、ビルドトリガーを終了または GitHub がトリガーをチェックは現在サポートされていません)。