環境を作成してターゲットにする
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
環境は、パイプラインからのデプロイを対象にできるリソースのコレクションです。 環境名の一般的な例として、開発、テスト、QA、ステージング、運用があります。 Azure DevOps 環境は、パイプラインがソフトウェアをデプロイする論理ターゲットを表します。
Azure DevOps 環境は、クラシック パイプラインでは使用できません。 クラシック パイプラインの場合、デプロイ グループは同様の機能を提供します。
環境には次の利点があります。
特長 | 説明 |
---|---|
デプロイ履歴 | パイプライン名と実行の詳細は、環境とそのリソースへのデプロイについて記録されます。 同じ環境またはリソースをターゲットとする複数のパイプラインのコンテキストでは、環境のデプロイ履歴は、変更のソースを特定するのに役立ちます。 |
コミットと作業項目の追跡可能性 | 環境をターゲットとするパイプライン実行内のジョブを表示します。 環境に新しくデプロイされた コミットと作業項目を表示することもできます。 追跡可能性により、コード変更 (コミット) または機能/バグ修正 (作業項目) が環境に到達したかどうかを追跡することもできます。 |
診断リソースの正常性 | アプリケーションが必要な状態で機能しているかどうかを検証します。 |
セキュリティ | 環境をターゲットにできるユーザーとパイプラインを指定して、環境をセキュリティで保護します。 |
環境はリソースのグループ化ですが、リソース自体は実際のデプロイ ターゲットを表します。 現在、Kubernetes リソースと仮想マシン リソースの種類がサポートされています。
YAML パイプラインを作成し、存在しない環境を参照すると、操作を実行しているユーザーが認識され、アクセス許可を割り当てることができる場合、Azure Pipelines によって環境が自動的に作成されます。 Azure Pipelines に環境 (例: 外部コード エディターからの YAML 更新) を作成するユーザーに関する情報がない場合、環境がまだ存在しなければ、パイプラインは失敗します。
前提条件
- 環境を追加するには、環境の作成者ロール が必要です。
環境の作成
組織
https://dev.azure.com/{yourorganization}
にサインインし、プロジェクトを選択します。[パイプライン] >[環境]>[環境の作成] を選択します。
環境の情報を入力し、[作成] を選択します。 リソースは、後で既存の環境に追加できます。
パイプラインを使用して環境を作成し、環境にデプロイすることもできます。 詳細については、「攻略ガイド」をご覧ください。
ヒント
空の環境を作成し、デプロイ ジョブから参照できます。 これにより、環境に対するデプロイ履歴を記録できます。
デプロイ ジョブから環境をターゲットとする
デプロイ ジョブは、順番に実行されるステップのコレクションです。 次の YAML スニペットに示すように、デプロイ ジョブを使用して、環境全体 (リソースのグループ) をターゲットにすることができます。 リソース名が指定されているため、パイプラインは myVM マシンで実行されます。
- stage: deploy
jobs:
- deployment: DeployWeb
displayName: deploy Web App
pool:
vmImage: 'Ubuntu-latest'
# creates an environment if it doesn't exist
environment:
name: 'smarthotel-dev'
resourceName: myVM
resourceType: virtualMachine
strategy:
runOnce:
deploy:
steps:
- script: echo Hello world
デプロイ ジョブから環境内の特定のリソースをターゲットにする
デプロイのターゲットを環境内の特定のリソースに限定することができます。 その後、環境内の特定のリソースについてのデプロイ履歴を記録できます。 デプロイ ジョブの手順では、デプロイ ジョブのターゲットとなるリソースからサービス接続の詳細が自動的に継承されます。
environment:
name: 'smarthotel-dev.bookings'
strategy:
runOnce:
deploy:
steps:
- task: KubernetesManifest@0
displayName: Deploy to Kubernetes cluster
inputs:
action: deploy
namespace: $(k8sNamespace)
manifests: $(System.ArtifactsDirectory)/manifests/*
imagePullSecrets: $(imagePullSecret)
containers: $(containerRegistry)/$(imageRepository):$(tag)
# value for kubernetesServiceConnection input automatically passed down to task by environment.resource input
実行中の環境の詳細
パイプラインの特定の実行のデプロイ ジョブのターゲットとなるすべての環境は、パイプラインの実行の詳細の [環境] タブにあります。
AKS プライベート クラスターを使用している場合、[環境] タブは使用できません。
承認
承認チェックを使用することにより、ステージを実行するタイミングを手動で制御します。 承認チェックを使用して、運用環境へのデプロイを制御します。 リソース所有者はチェックを利用して、パイプラインのステージがリソースを消費するタイミングを制御できます。 環境などのリソースの所有者は、そのリソースを消費するステージが開始される前に満たす必要がある承認とチェックを定義できます。
環境での手動承認チェックがサポートされています。 詳細については、承認に関するページを参照してください。
作成者、Administrator、およびユーザー ロールは、承認とチェックを管理できます。 閲覧者ロールでは承認とチェックを管理できません。
デプロイ履歴
環境内のデプロイ履歴ビューには、次の利点があります。
特定の環境をターゲットとするすべてのパイプラインからのジョブを表示します。 たとえば、それぞれ独自のパイプラインを持つ 2 つのマイクロ サービスが、同じ環境にデプロイされています。 デプロイ履歴の一覧は、この環境に影響を与えるすべてのパイプラインを特定するのに役立ち、各パイプラインによるデプロイのシーケンスを視覚化するのにも役立ちます。
ジョブの詳細をドリルダウンして、環境にデプロイされたコミットと作業項目の一覧を表示します。 コミットと作業項目の一覧は、デプロイ間の新しい項目です。 最初の一覧にはすべてのコミットが含まれており、次の一覧には変更だけが含まれます。 複数のコミットが同じ pull request に関連付けられている場合、作業項目と変更タブに複数の結果が表示されます。
複数の作業項目が同じ pull request に関連付けられている場合、作業項目タブに複数の結果が表示されます。
セキュリティ
ユーザーのアクセス許可
ユーザーのアクセス許可を使用して環境を作成、表示、使用、管理できるユーザーを制御します。 作成者 (スコープ: すべての環境)、閲覧者、ユーザー、Administratorの 4 つのロールがあります。 特定の環境のユーザーのアクセス許可パネルでは、継承されるアクセス許可を設定したり、各環境のロールをオーバーライドしたりできます。
- 承認する特定の環境に移動します。
- >[セキュリティ] を選択して設定を表示します。
- [ユーザーのアクセス許可]、[+追加]、[ユーザーまたはグループ] を選択し、適切なロールを選択します。
Role | 説明 |
---|---|
Creator | グローバル ロール。環境ハブのセキュリティ オプションから使用できます。 このロールのメンバーは、プロジェクトに環境を作成できます。 既定では、共同作成者がメンバーとして追加されます。 環境がまだ存在しない場合に YAML パイプラインをトリガーするために必要です。 |
Reader | このロールのメンバーは、環境を表示できます。 |
User | このロールのメンバーは、YAML パイプラインを作成または編集するときに環境を使用できます。 |
Administrator | このロールのメンバーは、アクセス許可の管理、環境の作成、管理、表示、使用を行うことができます。 特定の環境の場合、その作成者は既定では管理者として追加されます。 管理者は、すべてのパイプラインへの環境へのアクセスを開くこともできます。 |
重要
環境を作成するときは、作成者のみが管理者ロールを持っています。
ロール | 説明 |
---|---|
Creator | グローバル ロール。環境ハブのセキュリティ オプションから使用できます。 このロールのメンバーは、プロジェクトに環境を作成できます。 既定では、共同作成者がメンバーとして追加されます。 環境がまだ存在しない場合に YAML パイプラインをトリガーするために必要です。 |
Reader | このロールのメンバーは、環境を表示できます。 |
User | このロールのメンバーは、YAML パイプラインを作成または編集するときに環境を使用できます。 |
Administrator | このロールのメンバーは、環境の使用に加えて、環境の他のすべてのロールのメンバーシップを管理できます。 既定では、作成者がメンバーとして追加されます。 |
パイプラインのアクセス許可
パイプラインのアクセス許可を使用して、環境へのデプロイのためにすべてのパイプラインまたは選択したパイプラインを承認します。
- 環境またはリソースで [アクセスを開く] を削除するには、[パイプラインのアクセス許可] で [アクセス許可を制限する] を選択します。
- 特定のパイプラインを環境または特定のリソースにデプロイできるようにするには、+ を選択し、パイプラインの一覧から選択します。
次のステップ
よくあるご質問
Q: 環境を作成しようとするとエラー メッセージが発生するのはなぜですか?
A: "Access denied: {User} needs Create permissions to do the action" (アクセスが拒否されました: <ユーザー> がアクションを実行するには作成アクセス許可が必要です) というメッセージが表示される場合は、組織レベルのアクセス許可を確認してください。 [組織の設定]>[ユーザー] に移動し、利害関係者ロールを持っているかどうかを確認します。 利害関係者ロールでは環境を作成できません。 アクセス レベルを変更してから、環境を作成できるかどうかを確認してください。 詳しくは、「ユーザーとアクセス許可の管理に関する FAQ」をご覧ください。ユーザー>
Q: 次のエラーが発生するのはなぜですか: "ジョブ XXXX: 環境 XXXX が見つかりませんでした。 The environment does not exist or has not been authorized for use" (環境が存在しないか、使用を承認されていません) ?
A: エラーの考えられる原因のいくつかを次に示します。
YAML パイプラインを作成し、YAML ファイルに存在しない環境を参照すると、Azure Pipelines によって環境が自動的に作成される場合があります。
- Azure Pipelines の Web エクスペリエンスで YAML パイプライン作成ウィザードを使用し、まだ作成されていない環境を参照します。
- Azure Pipelines の Web エディターを使用して YAML ファイルを更新し、存在しない環境への参照を追加した後にパイプラインを保存します。
次のフローでは、Azure Pipelines には、環境を作成するユーザーに関する情報がありません。別の外部コード エディターを使用して YAML ファイルを更新し、存在しない環境への参照を追加し、手動または継続的インテグレーション パイプラインをトリガーします。 この場合、Azure Pipelines はユーザーを識別できません。 以前は、すべてのプロジェクトの共同作成者を環境のAdministratorロールに追加することで、このケースを処理していました。 その後、プロジェクトのメンバーは、これらのアクセス許可を変更し、他のユーザーが環境にアクセスできないようにすることができます。
変数を使用して環境を作成するか、templateContext を使用してプロパティをテンプレートに渡すことができます。 ランタイム パラメーターは実行時に展開されるため、環境を作成するときには機能しません。
利害関係者アクセス レベルのユーザーは、利害関係者にはリポジトリへのアクセス権がないため、環境を作成できません。
関連記事
フィードバック
https://aka.ms/ContentUserFeedback。
近日公開予定: 2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub イシューを段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、以下を参照してください:フィードバックの送信と表示