パイプラインの作成と編集
パイプラインは、従来の ビルド構成や ビルドチェーンに代わる、ユーザー中心で簡素化された選択肢です。 TeamCity 2025.07 で導入され、2026.2 で一般提供となり、規模や複雑さを問わずあらゆるプロジェクトで完全にサポートされています。 クラシックなビルド構成の一部の高度な機能はまだ準備中です。予定されている内容については TeamCity Pipelines ロードマップ を参照してください。
パイプラインとビルド構成およびビルドチェーンの比較
パイプラインの作成に入る前に、ビルド構成とパイプラインの違い、およびそれぞれをいつ使うかを理解しておくことが重要です。 作成後は、パイプライン (またはそのジョブ) をビルド構成に変換できず、その逆もできないことに注意してください。 詳細については、 制限事項と特記事項 のセクションを参照してください。
- 親
ビルド構成とパイプラインはどちらも TeamCity プロジェクトに属します。 各プロジェクトには、無制限の数の構成とパイプラインを含めることができます。
- 子
ビルドはビルドステップを直接所有します。
パイプラインはジョブを所有し、ジョブは通常のビルドステップを所有します。
- サポートされている VCS タイプ
従来の TeamCity ビルド構成は Git、Subversion、Mercurial、TFS、Perforce をサポートしており、GitHub、GitLab、Bitbucket、Azure などの主要な VCS プロバイダーとの統合も備えています。
TeamCity Pipelines は GitHub、GitLab、Bitbucket Cloud との組み込み統合を提供します。 その他の Git リポジトリには、直接 URL 経由で接続できます。 Subversion、Mercurial、TFS、Perforce は現在サポートされていません。
- 実行モード
パイプラインは常に最初から最後まで実行され、コンパイル失敗や接続の問題などのエラーによって中断されない限り、すべてのジョブが実行されます。
ビルド構成は 条件付きステップ実行をサポートします。 例: 前のステップが失敗した場合にのみ実行されるステップを追加できます。
- 依存関係
ビルド構成とパイプラインはどちらも、異なる TeamCity プロジェクトにまたがる大規模な ビルドチェーンにリンクできます。
- コードとしての構成
パイプラインとビルド構成はどちらも、設定をコードとしてプロジェクトのソースコードのすぐ隣に保存できます。 どちらもブランチ設定をサポートしているため、各リポジトリブランチごとに独自の設定ファイルを持つことができます。
ビルド構成は XML または Kotlin DSL 形式で設定を保存します。 これらのファイルは TeamCity UI から編集できません。
パイプラインでは、TeamCity で直接編集できる YAML と、 自動生成された Kotlinに設定が保存されます。
- 制限事項
まとめると、パイプラインとビルド構成はどちらもプロジェクトが所有するものの、それぞれ異なるニーズに対応します。 パイプラインは、小規模プロジェクト（通常は 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 では、実行結果ページの アーティファクト タブにアーティファクトが表示されます。
ジョブでファイルを共有する相手を選択するには、ジョブの 出力ファイル セクションエントリにある関連するチェックボックスをオンにします。
依存関係
パイプラインで再構築された TeamCity の従来の概念として、依存関係もあります。 パイプラインでは、 スナップショット依存関係と アーティファクト依存関係が単一のオプションに統合されています。 ジョブをクリックして設定を確認し、どのジョブを先行させるかを選択し、そのジョブにそれらの出力をインポートするかどうかを決定します。
ビジュアルエディターで依存関係の行をクリックして、ファイルをインポートするかどうかを選択することもできます。
ウェブフック
クラシック TeamCity は、リポジトリの変更を検出する 2 つの方法をサポートしています: 定期ポーリングとウェブフック。 Webhook はほぼ瞬時に更新され、サーバー負荷も軽減されますが、手動での設定が必要です。 詳細については、 変更の収集 のセクションを参照してください。
パイプラインは、ポーリングメカニズムよりも高速で効率的な代替手段として、デフォルトで Webhook を使用します。 接続からパイプラインを作成すると、TeamCity はリポジトリ設定にウェブフックを自動的に登録します。 Webhook が削除された場合、または更新の配信に失敗した場合、ポーリングはフォールバックとして残ります。
実行ステータスを VCS に公開
コミットステータスパブリッシャー は、ビルドステータスを VCS 側に伝達する最も人気のある TeamCity ビルド機能の 1 つです。 HTTP 認証を使用してパイプラインを作成すると、この統合機能は自動的に利用可能になります。
下の図は、GitHub のリポジトリページに報告される TeamCity 実行ステータスを示しています。
ステータスアイコンをクリックすると詳細な説明が表示されます。 詳細 リンクのリンク先は、TeamCity サーバー上の対応するパイプライン実行です。
この統合を無効にするには、パイプラインをクリックして対応するリポジトリ設定を編集し、 ステータスをリポジトリに公開 をオフに切り替えます。
ジョブのデバッグ。
通常のパイプライン実行では、常にすべてのジョブが順番にトリガーされます。 パイプラインを設計している間は、ワークフロー全体をトリガーする前にジョブが動作することをすばやく確認する方法として、代わりに個々のジョブを実行して確認できます。
ジョブのデバッグを開始または停止するには、ジョブの省略記号ボタン(右上隅)をクリックし、対応するオプションを選択します。デバッグでは、保存されているかどうかにかかわらず、常にジョブの現在の設定が使用されます。
デバッグセッションの実行中、TeamCity はデバッグする各ジョブ用の個別のタブを含む デバッグ パネルを開きます。 各タブには、そのジョブのビルドログが表示され、そのジョブを実行したエージェントへのターミナルアクセスが提供されます。 パイプラインを再度編集するとすぐに、パネルとそのログは消えます。
これは実行自体がなくなったという意味ではありません。各デバッグ実行は 個人ビルドであり、後で設定エディターの外にあるパイプラインの概要画面で見つけることができます。
制限事項と特記事項
パイプラインは CI/CD ワークフローを構築するすべての人にとってデフォルトの選択肢になると考えていますが、現時点ではクラシックなビルド構成で利用できる一部の機能がありません。 今後のリリースで、パイプラインのツールセットを拡充し、特に要望の多い機能を追加するプランです。
- ビルド手順
汎用の コマンドライン (スクリプト) ステップに加えて、パイプラインジョブは Maven、 Gradle、 Node.js 向けの三つの専用ビルドステップをサポートしています。 ビルド構成に表示される単一の .NET ビルドステップは、build、clean、pack、publish など、単一目的のステップのセットとして利用できます。
その他のステップは必要に応じて有効化できます。 試すには、手順を確認するために Slack チャンネルに参加するか、 サポートにお問い合わせください。
- 接続
TeamCity パイプラインは現在、 GitHub OAuth、 GitLab、 Bitbucket Cloud 接続をサポートしています。
パイプラインを作成するために構成された接続は必要なく、 任意の Git リポジトリ URL から実行できることに注意してください。
- VCS ルート
パイプラインは内部的に VCS ルートを使用しますが、VCS ルート設定を直接公開するのではなく、簡略化された リポジトリ セクションを提供します。 そのため、クリーンおよびチェックアウトポリシー、カスタムポーリング間隔、サブモジュールの処理などのオプションは、パイプライン UI から設定できません。
ただし、従来の TeamCity UI で VCS ルートを作成して構成し、その後このルートからパイプラインを作成することはできます。
- ビルド機能
パイプラインは、CI/CD ルーチンを最もシンプルかつユーザーフレンドリーに構築できるように設計されています。 このゴールをサポートするために、主要な機能をパイプラインに直接統合し、個別に ビルド機能を設定する必要がなくなるように取り組んでいます。
たとえば、 コミットステータスパブリッシャー は接続の使用時に 自動的に有効になり 、レジストリ接続はパイプラインとジョブ設定内で 統合 として管理されます (個別の Docker レジストリ接続 および NPM レジストリ接続ビルド機能ではなく)。
従来のビルド機能の一部はジョブにも適用可能で、ビルド構成とほとんど、あるいは全く違いはありません。 これらの機能は ジョブ設定 | ビルド機能 で追加できます。
ビルド承認 などの一部のビルド機能は、機能の改善版としても、スタンドアロンのビルド機能としても、まだパイプラインでは利用できません。 皆様からのフィードバックを検討し、今後の対応の優先順位を決定し、最も要望の多かった機能を明確かつ一貫した方法で提供できるよう努めています。
- トリガー
TeamCity パイプラインでは現在、CI ルーチンを自動的に開始できる二種類の トリガーをサポートしています：
指定された日時に新しい実行を開始する スケジュールトリガー。
開始される VCS トリガーは、新しいコードの変更時に実行されます。
両方とも、パイプライン設定の パイプラインの自動実行 セクションで構成されます。
その他のトリガータイプ (たとえば、 ビルドトリガーを終了または GitHub がトリガーをチェックは現在サポートされていません)。