ビルド構成とデプロイ

始める前に

ビルドのデプロイは通常、外部リソースの更新を意味します。たとえば、インストーラーを本番 Web サイトにアップロードする、パッケージを公開する、イメージをレジストリにリリースするなどです。 このチュートリアルでは、ビルド構成を使用して TeamCity のこの概念を詳しく見ますが、デプロイタスクはパイプラインでも処理できます。

ビルド手順にも同様の柔軟性があります。 TeamCity には、さまざまな デプロイヤー: FTP サーバーへのファイルのアップロードなど、一般的なデプロイタスク向けのすぐに使えるステップが含まれています。 ただし、デプロイ構成は専用のデプロイヤーに限定されません。 ワークフローに合った任意のビルド手順を使用できます。

このチュートリアルでは、Docker イメージをデプロイするため、 Docker ビルドステップが自然な選択肢となります。 .NET アプリケーションの場合は、代わりに .NET ビルドステップを使用するのが一般的です。 さらに具体的な要件がある場合は、汎用的な コマンドライン (スクリプト) ステップに戻ることも可能です。

ステップ 1: デプロイ構成を作成する

1. 前のチュートリアル（パート 1、 パート 2 ）で作成したパイプラインを所有するプロジェクトの 一般 設定に移動します。

2. ビルド構成を作成 をクリックします。

3. このビルド構成では、Docker イメージを Docker Hub にアップロードするだけで、VCS に保存されているアプリケーションは処理しないため、リポジトリ (接続された VCS ルート) へのアクセスは必要ありません。 ビルドをセットアップする。 ページで、 リポジトリなし を選択します。

4. ビルド構成の名前を入力してください。

5. 作成 をクリックする前に、 さらに表示 をクリックして追加設定を表示し、構成タイプを「通常」から「デプロイ」に変更してください。

   

   TeamCity は三種類のビルド構成タイプをサポートしています：

   • 通常 — アプリケーションの構築および / またはテストを行うための一連のビルド手順。

   • デプロイ ―機能的には通常の構成と同一ですが、デプロイのワークフローに最適化された外観上の改善が施されています。

   • 複合 - ビルドチェーン の最終要素、またはその一部として設計されています。 この構成にはビルドステップを含められず、先行するビルドの結果を集約するダッシュボードとして機能するため、チェーンのステータスを単一の画面で追跡できます。

   ビルド構成タイプは、 一般 設定でいつでも変更できます。

   

6. 新しいビルド構成を、 前のチュートリアルで作成した「Docker イメージのビルド」パイプラインの後に実行されるように設定してください。 これにより、同じビルドチェーンの一部となります。

   ビルド構成は、パイプラインと同様に、上流要素への依存関係を追加することで、チェーンに追加されます。 ビルド構成設定で、 依存関係 タブを開き、 新しいスナップショット依存関係を追加 をクリックします。 すべての依存関係設定はデフォルト値のままにしておきます。 これらは、 ステップ 2: ビルドチェーンを構成する で説明されている設定と同じです。

   

7. 実際の CI/CD ワークフローでは、「イメージのビルド」と「イメージのプッシュ」は同じビルド構成またはパイプラインのビルドステップとして扱われることが多いでしょう。 このチュートリアルでは、これらを別々のステージに分割していますが、これが潜在的な問題につながる可能性があります。

   「Docker イメージのビルド」パイプラインは、Docker イメージをビルドし、ビルドエージェント上で実行されている Docker エンジンに格納します。 Docker イメージは、それを作成した Docker インスタンスにローカルに存在するため、別の Docker エンジンを使用する別のエージェントでは、このイメージを見つけることができません。 デプロイビルドが前のビルドで作成されたイメージをプッシュできるようにするには、両方のビルドを同じビルドエージェント上で実行する必要があります。

   ビルドチェーンが期待どおりに動作するようにするには、両方のビルドで同じ エージェント要件を設定してください。 最も簡単な方法は、 ステップ 3: アーティファクトを公開して交換する に示されているようにエージェント名を使用することです。

   # Build image pipeline jobs: Job1: name: Docker build ... runs-on: self-hosted: - requirement: exists name: ImageBuilderTool parameter: container.engine - requirement: equals name: Agent name parameter: teamcity.agent.name value: MyAgent1 ...
   // Deploy image configuration import jetbrains.buildServer.configs.kotlin.* object UploadDockerImage : BuildType({ name = "Upload Docker Image" type = BuildTypeSettings.Type.DEPLOYMENT dependencies { snapshot(BuildDockerImage) { reuseBuilds = ReuseBuilds.NO } } requirements { equals("teamcity.agent.name", "MyAgent1") }})

8. 新しいビルド構成にはまだビルド手順がありません。 それでも実行して、想定どおりにアップストリームのビルドチェーンが開始されることを確認してください。

   これにより、 デプロイ の構成が通常の構成とどのように異なるかを確認する機会にもなります。

   'デプロイ' ボタン

   最も顕著な違いは、右上隅にあるメインアクションボタンで、 実行 ではなく デプロイ という名称になっている点です。

   

   デプロイタスクは通常、外部リソースに影響します。NuGet パッケージのアップロード、本番環境の更新、GitHub リリースの公開などです。 デプロイ ラベルはシンプルなガードレールとして機能し、機密性の高いアクションを誤ってトリガーしにくくします。

   'デプロイ' セクション

   上流のビルドでは、下流のデプロイ構成が 概要 タブの デプロイ セクションに表示されます。

   

   このセクションでは、以下のことができます。

   • このビルドに関連するすべての下流のデプロイ構成を表示します。 例: 「アプリのビルド」パイプラインは、「ステージング環境へのデプロイ」と「本番環境へのデプロイ」の両方にデータを供給できます。 デプロイのいずれかが実行中の場合、そのステータスがここに表示されます。

   • 完了したアップストリームビルドからデプロイを開始します。 デプロイ構成がまだ実行されていない場合は、その名前の横にある デプロイ をクリックします。 初回実行後、このボタンは 再デプロイ に変わります。

     このボタンがあれば、一時停止してビルド結果を確認し、準備が整ったときにのみデプロイできるため、チェーン全体を再実行する必要がありません。

ステップ 2: ビルドステップを構成する

同じアップストリームビルドの結果を複数の場所にデプロイできます。 たとえば、ステージングサーバーや環境サーバーなどです。 最も簡単な方法は、個別の構成を作成することです。 このチュートリアルでは、より高度なアプローチ、つまり、パラメーター値に応じてアクションが変化する単一の構成を使用します。

1. Docker Hub アカウント内に二つのリポジトリを用意します: 一方は プライベート、もう一方は公開イメージ用です。 例: valrravn/teamcity-gs-private と valrravn/teamcity-gs-public。

2. Docker イメージパイプラインの構築を編集して、イメージが最初にプライベートリポジトリ用にタグ付けされるようにします。 これがデフォルトのデプロイの保存先になります。

   jobs: Job1: name: Docker build steps: - type: script script-content: >- docker build -f ./docker/Dockerfile -t valrravn/teamcity-gs-private:%build.number% .

3. ビルド構成設定で、 パラメーター タブを開き、以下のプロパティを持つ新しいパラメーターを作成します。

   • お名前：: deployment.target.

   • 値の型：: 選択. これにより、エディターが定義済みの値を持つコンボボックスになります。

   • 値：: プライベート. 別の値を選択しない限り、これが使用されるデフォルト値です。

   • 項目：: public、 プライベート、 both は別々の行に記述してください。 これらは選択可能な値です。 また、 label => value 構文を使用して、実際のパラメーター値とは異なるカスタム UI ラベルを追加することもできます。

   • 表示：: 確認. 通常、ユーザーは カスタムビルドを実行 ダイアログからのみパラメーターをオーバーライドできます。 確認パラメーターでは、ビルドが開始するたびにこのダイアログが開き、デプロイ前に値を選択できます。

   • ラベル と 説明： は、他の TeamCity ユーザーがこのパラメーターの制御内容を理解するのに役立つ任意のテキストです。

   object UploadDockerImage : BuildType({ name = "Upload Docker Image" type = BuildTypeSettings.Type.DEPLOYMENT params { select("deployment.target", "Private", label = "Upload to", description = "Choose the Docker Hub repository to which this image should be uploaded.", display = ParameterDisplay.PROMPT, options = listOf("Private repository" to "Private", "Public repository" to "Public", "Both")) } })

   TeamCity は今後、この構成を開始するたびにデプロイターゲットの選択を求めます。直接実行する場合でも、アップストリームビルドから デプロイ または 再デプロイ をクリックする場合でも同様です。

   

4. 保留中の変更を保存して、ビルド構成設定を閉じます。 親プロジェクトの設定を開き、 接続 ページに移動します。

5. 新しい Docker レジストリ接続を追加します。 TeamCity はこの接続を使用して Docker Hub で認証し、Docker イメージをプッシュします。

   

6. ビルド構成設定に戻り、 Docker レジストリ接続 ビルド機能を追加します。 前の手順で作成した Docker レジストリ接続を選択します。

7. 構成に Docker ビルドステップを追加し、以下のオプションを設定してください。

   • Docker コマンド：プッシュ

   • イメージのお名前：タグ：: valrravn/teamcity-gs-private:%dep.<BuildImagePipelineID>.build.number% (下記の注記を参照してください)

   • プッシュ後にエージェントからイメージを除去：: デプロイのオプションの 1 つがパブリックリポジトリとプライベートリポジトリの両方であるため、 無効 を使用します。 結果として、2 つの Docker ビルドステップが必要になります。 最初のステップが完了したら、次のステップのためにイメージを残しておく必要があります。

   import jetbrains.buildServer.configs.kotlin.* object UploadDockerImage : BuildType({ name = "Upload Docker Image" type = BuildTypeSettings.Type.DEPLOYMENT // ... steps { dockerCommand { name = "Push to private repo" id = "Push_to_private_repo" commandType = push { namesAndTags = "valrravn/teamcity-gs-private:%dep.GSFirstBuild_BuildDockerImage.build.number%" } } } // ... })

8. ビルドステップの設定で、 ステップ実行 を見つけて 条件を追加 | その他の条件…. をクリックします。 deployment.target does-not-equal public 条件を追加します。

   この条件では、以前に作成したパラメーターを使用して、ステップの実行タイミングを制御します。 Docker イメージは、ビルド開始時に「プライベート」または「両方」を選択した場合にのみ、プライベートリポジトリにプッシュされます。 詳細については、 ビルドステップ実行条件 を参照してください。

   steps { dockerCommand { conditions { doesNotEqual("deployment.target", "Public") } // ... }

9. デプロイのビルド構成を数回実行して、イメージがプライベートの Docker Hub リポジトリにアップロードされていること、それが「プライベート」または「両方」を選択した場合にのみ発生することを確認してください。

10. 手順 #7 と 8 を繰り返して、同様の Docker ステップを追加します。今回は公開イメージのアップロード用です。 プッシュ前にイメージを再タグ付けする コマンドライン (スクリプト) ステップも必要です。

    object UploadDockerImage : BuildType({ name = "Upload Docker Image" type = BuildTypeSettings.Type.DEPLOYMENT // ... steps { // ... script { // Change the image tag to match the public repository name = "Retag image" id = "Retag_image" conditions { doesNotEqual("deployment.target", "Private") } // The 'p' char is added before the build number // to better distinguish public and private versions scriptContent = "docker tag " + "valrravn/teamcity-gs-private:%dep.GSFirstBuild_BuildDockerImage.build.number% " + "valrravn/teamcity-gs-public:p%dep.GSFirstBuild_BuildDockerImage.build.number%" } dockerCommand { // Push the re-tagged image to the public repo id = "DockerCommand" conditions { doesNotEqual("deployment.target", "Private") } commandType = push { namesAndTags = "valrravn/teamcity-gs-public:p%dep.GSFirstBuild_BuildDockerImage.build.number%" } } } // ... })

11. ビルド構成を再度デプロイして、3 つのデプロイ宛先オプションすべてが期待どおりに動作することを確認してください。

    プライベートリポジトリ（デフォルトオプション、イメージにはビルド番号がタグ付けされています）:

    

    公開リポジトリ（ビルド番号と p 接頭辞でタグ付けされたイメージ）:

    

ステップ 3: デプロイ構成を保護する

最後に、デプロイの設定が誤って実行されないように確認しておきましょう。

構成を「デプロイ」に設定すると、「実行」ボタンのラベルが「デプロイ」に変更されるため、ある程度の注意喚起はできます。 しかし、機密性の高いビルド構成を保護するためのより確実な方法は、 ビルド承認 ビルド機能を構成することです。 この機能は、指定されたレビュー担当者 (個々の TeamCity ユーザーまたは ユーザーグループのメンバー) が明示的に実行を許可するまで、新しいビルドをキューに保持します。 期限内に承認されなかったビルドは自動的にキャンセルされます。 最初のチュートリアルで 信頼できないビルド を構成した場合、同様の動作を確認したことがあるかもしれません。

デプロイ構成を誰でも実行できるようにしつつ、何らかの確認ロジックも持たせたい場合は、TeamCity パラメーターの外観と動作の設定を活用して、カスタム確認プロンプトを作成できます。 RegEx 型の プロンプトパラメーターを追加すると、ユーザーが指定された単語を入力した場合にのみ設定が開始されます。