デプロイビルド構成
プロジェクトが構築されテストされたら、最終的なインフラストラクチャにデプロイする必要があることがよくあります。たとえば、NuGet ギャラリーにパッケージをアップロードしたり、DockerHub リポジトリにコンテナーを配信したり、ドキュメント Web サイトのソースを更新したりします。さまざまな CI/CD ソリューションでは、パイプラインのこの最後のステップに「デプロイ」ステージ、配信ターゲット、リリース、本番環境などのさまざまな用語を使用します。
TeamCity では、配信タスクは、通常のビルドルーチンを実行する同じ「ビルド構成」オブジェクトによって実行されます。ただし、ビルドと配信は異なるチームメンバーによってトリガーされる異なるタスクであるため、製品をデプロイする構成は、明示的に配備構成としてマークできます。
重要なポイント
デプロイ構成は、通常の構築ルーチンを実行する構成と、アプリを外部インフラストラクチャに配信する構成を区別するように設計されています。
デプロイ構成は、機能の点で通常の構成と変わりません。同じビルド機能を利用したり、同じビルドランナーを使用したりすることができます。
デプロイ構成が同じチェーン内の通常の構築 / テスト構成に従っている場合、十分な権限を持つ TeamCity ユーザーは通常の構成からデプロイを直接トリガーできます。
デプロイ構成では、個人用ビルドを実行できません。また、1 つのデプロイ構成に属する 2 つのビルドを同時に実行することはできません。
きめ細かいユーザー権限を設定するには、デプロイとビルド / テスト構成を異なるサブプロジェクトに分割することをお勧めします。
ビルド構成タイプを切り替えるには、「構成設定 | 一般」タブに移動します。
サンプル
このチュートリアルでは、コンポジットビルド構成記事で開発されたパイプラインを補足するデプロイ構成を作成します。

パイプラインの構築を作成する
コンポジットビルド構成の記事で説明されている手順に従って、複合「すべてビルド」構成で終わる 5 つの相互接続された構成のチェーンを作成します。

デプロイサブプロジェクトの作成
建物構成を編集して実行できる通常のプロジェクト開発者は、配信タスクを実行できないようにする必要があります。きめ細かいユーザー権限を設定し、配信関連のパラメーターと資格情報をメインの構築パイプラインから離れた場所に安全に保存するには、別のプロジェクトで配信構成を作成することをお勧めします。
管理 | <あなたのプロジェクト> に移動し、サブプロジェクトを作成するをクリックしてください。
手動タイルを選択して、特定の VCS リポジトリに関係のない空のプロジェクトを作成します。
サブプロジェクト名を「デプロイ構成」に設定します。
プロジェクトと配信ターゲットのタイプに応じて、デプロイ構成には異なる手順が含まれる場合があります。例: 構成では、
nuget pushコマンドを実行してパッケージを NuGet ギャラリーにアップロードする .NET ランナー、またはファイルを FTP サーバーまたは Windows 共有にアップロードするデプロイヤの 1 つを使用できます。このサンプルでは、デプロイ構成は Docker イメージを DockerHub レジストリにアップロードします。このため、レジストリアドレスとログイン資格情報を指定する Docker 接続を作成する必要があります。この接続は、このサブプロジェクトのすべての構成で使用できます。接続を作成するには、サブプロジェクトの接続タブに移動します。
以下の Kotlin コードは、最終的なセットアップを示しています。
最初のデプロイ構成を追加する
新しいサブプロジェクトの一般設定タブで、ビルド構成を作成するをクリックします。
手動オプションを選択し、構成名として「コンソールのデプロイ (Windows)」と入力します。
ビルド構成タイプを「デプロイ」に設定します。
バージョン管理設定で、VCS ルートを接続するをクリックし、すべての " 建てる ..." 構成で使用される同じルートを選択します。
「コンソールのデプロイ (Windows)」は「コンソールと Web のビルド (win-x64)」ビルド構成に依存しており、そのアーティファクトにアクセスできる必要があります。
建物の構成 | 依存関係に移動し、対応するスナップショットとアーティファクト (
bin => context) の依存関係を追加します。生成されたコンテナーをアップロードする必要があるため、デプロイサブプロジェクトの作成セクションで作成した Docker 接続を使用する Docker レジストリ接続ビルド機能を追加します。
構成に 3 つのビルドステップを追加します。
ステップ #1 — 必要な .NET ランタイムコンテナー(英語)イメージをプル (すでにプルされている場合は更新) する Docker ランナー。
ステップ #2 —
context/console.windows.dockerfileの命令を使用してイメージを構築する Docker ランナー。ステップ #3 — 新しく構築されたイメージを公開する別の Docker ランナーステップ。
最終的な構成セットアップは次のようになります。
配信設定を実行する
上記のコードは、デプロイビルド構成の最初の固有の機能を強調しています。つまり、そのデフォルト設定が通常の構成の設定とは異なります。
個人用ビルドのトリガーを許可するオプションは無効になっています。
複数のビルドが同じ配信先に同時にアクセスしようとすることによって引き起こされる潜在的な問題を回避するために、構成内の合計最大ビルド数は 1 に制限されています。
デプロイビルド構成のその他の独自の機能は次のとおりです。
デプロイビルドを開始するボタンは、実行ではなく配置と呼ばれます。

アーティファクトを生成した構成から直接、アーティファクトをデプロイできます。完了した通常ビルドの詳細を開き、「デプロイ」セクションの配置をクリックします。

デプロイビルドが開始されると、「デプロイ」セクションから進行状況を追跡できます。ビルドが完了すると、再デプロイボタンが表示されます。このボタンを使用すると、配信ルーチンを再実行できます。

ビルド構成のアーティファクトがすでにデプロイされている場合、以前のビルドは、デプロイ構成をトリガーすると新しい配信がオーバーライドされることをユーザーに警告します。

TeamCity プロジェクト、構成、個々のビルドの変更タブと変更ログタブでは、リビジョン番号をクリックして各変更に関する詳細情報を表示できます。パイプラインに配信構成がある場合、この変更の詳細ページにはデプロイタブが表示され、この変更がいつ初めて配信されたかをすぐに識別できます。

通常のビルド構成では、最新の変更を含むビルドが最初に表示されます。デプロイ構成では、ビルドが時系列に並べられます。
配信構成をさらに追加する
「コンソールのデプロイ (Windows)」構成設定に移動し、アクション | 構成のコピーをクリックして配信構成のコピーを 3 つ作成します。
新しいコピーを次のように変更します。
Web を導入する (Windows) —
context/web.linux.dockerfileからの指示を使用してイメージを構築し、このイメージを別の「docker_username/clock-web」レジストリにプッシュします。コンソールのデプロイ (Linux) — コンソールと Web を構築する (linux-x64) 構成に対するスナップショットとアーティファクトの依存関係があります。ビルドステップでは、異なる Linux ベースのイメージを使用します。
Web を導入する (Linux) — 上記の両方。
親 (最上位) プロジェクトに移動し、既存の「すべて構築」の横に新しいステップレス構成を作成します。この新しい構成を「すべてデプロイ」と呼び、そのタイプを「デプロイ」に設定します。
「すべてデプロイ」構成設定で、4 つの個別の「配置 ... 」構成すべてにスナップショット依存関係を追加します。
最終的には、すべての構築タスクとデプロイタスクを便利に実行するメインプロジェクトレベルで 4 つの独立したデプロイ構成と 2 つの構成が得られます。

この設定では、個々の " 建てる ..." 構成ビルドのビルド結果ページの「デプロイ」セクションに複数のオプションが表示されることに注意してください。ビルドが終了すると、関連するデプロイターゲットをトリガーできます。

すべての " デプロイする ..." 構成の最終構成を以下に示します。
ユーザー権限の設定
管理 | ユーザー管理セクションでは、プロジェクトごとのユーザーロールと権限を設定できます。次の例を考えてみましょう。
ユーザー「Alice」には、親プロジェクト全体に対する「プロジェクト開発者」ロールがあります。このロールは、「建物の構成」サブプロジェクトと「デプロイ構成」サブプロジェクトの両方で同じ権限を付与します。
ユーザー「Bob」は、「建物の構成」では「プロジェクト開発者」であり、「デプロイ構成 "」では「プロジェクト閲覧者」です。
この設定では、Alice はビルドとデプロイタスクをトリガーできますが、Bob は配信を開始できません。Bob が任意の " 建てる ..." 構成のビルド結果を参照すると、TeamCity は「デプロイ」セクションを表示しません。
TeamCity では現在、ビルド構成スコープにロールと権限を設定することはできません。そのため、Bob が「すべて構築」ビルドを実行できるようにしながらも、「すべてデプロイ」ビルドをトリガーできないようにする権限を設定することはできません。この問題を回避するには、これらの集約構成を対応するサブプロジェクトに移動します。
関連ページ:
コンポジットビルド構成
コンポジットビルド構成は、複数の通常のビルド構成をトリガーし、結果を 1 か所で追跡するように設計された「ステップレス」構成です。重要なポイント:複合構成では、実際の構築ルーチンは実行されません。複合構成では、依存関係からすべての情報が集約され、一元的な方法で表示されます。複合ビルドはビルドキュースロットを占有せず、エージェントを実行する必要もありません。ビルド構成タイプを切り替えるには、「構成設定 | 一般」タブに移動します。サンプル:このチュートリアルでは、複数のビルド構成を作成し、1...
.NET
TeamCity.NET ビルドステップを使用すると、.NET (Core) および .NET フレームワークを対象とするアプリケーションをビルド、テスト、デプロイできるほか、NuGet パッケージをダウンロードしてプッシュすることもできます。.NET ステップイン構成とパイプライン:クラシックビルド構成では、.NET は、選択したコマンドに応じて設定が変化する単一のビルドステップです。パイプラインでは、これらの各コマンドは個別のビルドステップとして使用できます。エージェント要件:.NET ス...
デプロイヤ
デプロイヤービルドランナーにより、TeamCity はアーティファクトを外部の場所にアップロードできるようになります。使用可能なデプロイヤーのリストについては、サイドバーを参照してください。2025 年 10 月 27 日 C# スクリプト SMB アップロード
接続を構成
TeamCity 接続は、外部サービスへのアクセスに必要な資格情報を保存します。このサードパーティサービスの種類に基づいて、2 つの主要な接続カテゴリがあります。VCS 接続これらの接続は、GitHub、GitLab、Bitbucket クラウドなどの VCS プロバイダーへのアクセスに必要な情報を保存します。これらの接続は、プロジェクト、ビルド構成、パイプラインを最も速く作成する方法を提供します。認証は自動的に処理されるため、リポジトリを選択するだけでビルドステップの設定を開始できます。接続が...
Kotlin DSL
TeamCity では、バージョン管理で設定を XML 形式で保存するだけでなく、DSL (Kotlin 言語に基づく) で設定を保存することもできます。バージョン管理に保存された DSL を使用すると、プログラムで設定を定義できます。Kotlin は静的に型指定されるため、IDE で自動補完機能を自動的に受け取ります。これにより、利用可能な API オプションの発見がはるかに簡単になります。TeamCity での Kotlin DSL の使用に関するブログ投稿シリーズと推奨リファクタリングの記...
Docker レジストリ接続
Docker レジストリ接続ビルド機能により、TeamCity はビルドの開始前に DockerHub またはその他のコンテナーレジストリに自動的にサインインできます。この機能を次の場所に追加します。TeamCity による Docker/Podman 操作 (たとえば、および) の監視と検出を許可します。ビルド前に認証されたレジストリに自動的にログインし、ビルド後にログアウトします。ローカル (Docker と Podman の両方) イメージをクリーンアップし、レジストリにプッシュ (Doc...