環境について

完了

デプロイ パイプラインを使用すると、デプロイ プロセスのステップを自動化できます。 多くの場合、複数の異なる環境でステップを実行する必要があります。 あなたの玩具会社では、変更を運用環境にデプロイする前に、コードへの変更を確認する必要があります。

このユニットでは、Azure Pipelines の環境が、どのようにワークフローのサポートに役立つかについて学びます。

複数の環境が必要な理由

デプロイ プロセスは、使用中のリソースも含む Azure リソースに対して変更を行います。 デプロイする変更が期待通りに動作するとは限らないため、リソースの変更にはリスクが伴います。 変更により、現在の設定が壊れるおそれすらあります。

問題のリスクを最小限に抑えるために、運用環境にデプロイする前に、安全な方法で変更を試してみるのは良いことです。 たとえば、変更を "非運用環境" にデプロイできます。

多くの組織は、運用環境にリリースする前に変更を積極的にデプロイする、複数の非運用環境を設定しています。 各非運用環境は特定の目的を果たし、多くの場合は次の環境に進む前に満たさなければならない特定の品質ゲートが定められています。 テストが失敗するなど、何かがうまくいかなかった場合はデプロイが停止します。 デプロイが各環境を通過していくことで、変更に対して自信を持つことができます。

一般的な環境には次のものがあります。

• 開発: 開発環境は通常、開発者が変更を試し、作業を迅速に繰り返すために使用します。

  多くの場合開発環境は、チーム メンバーが簡単にアイデアを試せるようにするため、最小限の制限しかありません。 開発環境を使用することにより、リソースに対する特定の構成設定をテストしたり、バックエンド データベースを持つ新しい Web サイトを安全に設定する方法を確認したりすることができます。 成功しないアイデアは捨てられるので、このような変更や試行の多くはデプロイ プロセスまで進まないでしょう。

  チームによっては、チーム メンバーそれぞれに対して別個の開発環境を設定することさえあります。そうすることで、新しい機能を試す際にお互いに妨害することを避けられるからです。

  開発環境は、サンドボックス環境と呼ばれることもあります。

• テスト: テスト環境は、変更に対して手動または自動のテストを実行することを目的としています。

  テスト環境は、継続的インテグレーション プロセスで使用できます。 変更をテスト環境にデプロイしたら、変更に対して自動テストを実行できます。 すべての自動テストに合格したら、変更をプロジェクトのメイン ブランチに安全にマージできます。 自動テストでは一般的に、主要なシステム機能や、新しくデプロイされたリソースのポリシー違反などをチェックします。

  また、パフォーマンスやセキュリティのテストなど、特定の種類のテスト専用の環境を作成することもできます。

• 統合: 統合環境では、他のシステムとの統合点をテストすることができます。

  統合環境で、エンドツーエンドのトランザクションをシミュレートできます。 このようなテストは自動で実行されることが多いものの、多くの組織はこの環境に対して手動のテストも実施しています。

  統合環境は、システム統合テスト (SIT) 環境と呼ばれることもあります。

• ユーザー受け入れテスト: ユーザー受入テスト (UAT) 環境は、通常は開発者ではなくビジネス上の利害関係者により、手動の検証のために使用されます。 手動の検証では、誰かがソリューションを使用してみて、期待通りに動作すること、必須のビジネス要件を満たしていることを確認します。 その人が変更を承認すると、デプロイが継続されます。

• 実稼働前: 実稼働前環境は、多くの場合運用環境のミラーであり、同じリソース SKU や構成を持ちます。 変更の適用前と後で、運用環境デプロイがどのように動作するかを検証するための最終チェックとして使用されます。 運用環境デプロイでダウンタイムが発生するかどうかを検証するためにも使用されます。

  実稼働前環境は、ステージング環境と呼ばれることもあります。

• 運用: 運用環境は、アプリケーションのエンド ユーザーが使用するものです。 できる限り保護し、稼働させ続けるべきライブ環境です。

  組織によっては、運用環境が複数ある場合もあります。 例として、地理的に異なるリージョンに運用環境が設定されていたり、異なるグループの顧客にサービスを提供するための運用環境が設定されているかもしれません。

• デモ: アプリケーションをエンド ユーザーに見せたり、トレーニングで使用したり、営業チームが特定の機能を潜在顧客に見せたりするために、デモンストレーション (デモ) 環境を作成することもできます。 さまざまな目的のために、複数のデモ環境を設定することも可能です。 デモ環境は多くの場合、仮の顧客データを持つ、運用環境を小型化したレプリカです。

組織内の環境

これらの環境をカスタマイズしたものが使用されることもあります。 ほんの少しの環境だけを使う組織もあれば、多くの環境を使用する組織もあるでしょう。 使用する環境の数と種類はデプロイするソリューション、ソリューションを構築しているチームの規模、ワークロードの重要性によって異なるでしょう。

ある場合には、単一の環境が、すでに説明した環境のいくつかの役割を担うこともあります。 またある場合には、複数の環境を、一部は並列、一部は直列に配置して、複雑なパイプラインをデプロイすることもあるでしょう。 必要でなくなった環境の削除やプロビジョニング解除を自動で行い、将来必要になったときに再デプロイしている組織もあります。

組織がどのような環境を使用するにせよ、その目標は、変更がデプロイ パイプラインを経るにつれ、その変更に対する自信を深めることです。 変更が品質の要件を満たさない場合、後続の環境へのその変更のデプロイをやめることができます。

あなたの玩具会社では、Web サイトのためにいくつかの基本的な環境を使用することに決めました。 運用環境に加えて、Test という名前の 1 つの非運用環境を作成します。

Bicep コードをテスト環境にデプロイしていくつかの基本的なテストを実行するために、パイプラインを更新します。 この取り組みがうまくいけば、コードを使って運用環境にデプロイします。

パイプラインの環境

Azure Pipelines にも、環境の概念があります。 Azure にある環境を表すために、Azure Pipelines 環境を作成します。 YAML ファイルでパイプラインを定義する場合、デプロイ ジョブを特定の環境にリンクします。 環境を使うことにより、パイプラインで他の機能も使用できます。

チェックと承認

Azure DevOps の環境では、チェックと承認を構成することができます。 パイプラインのジョブで環境が使用されるたびに、Azure DevOps は、ジョブの実行が開始される前にこれらのチェックと承認が成功することを確認します。

たとえば、運用環境で手動の承認を構成できます。 運用環境デプロイが開始される前に、指定された承認者がメール通知を受け取ります。 その人は、デプロイが開始する前にポリシーとプロシージャの条件が満たされていることを手動で確認できます。 たとえば、デプロイを承認する前に、承認者はすべてが期待通りに動作することを実稼働前環境でチェックするかもしれません。

さらに、最後のデプロイの後の実稼働前環境で自動のチェックを実行して、ログとエラー率を確認することもできます。 チェックにより、エラーの数が大幅に増加していないことを確認できたら、デプロイを続行することができます。

デプロイ履歴

Azure Pipelines は、環境へのデプロイの履歴を追跡します。 この履歴により、時間の経過とともに環境で発生したことを簡単に追跡できるようになります。 また、Azure Boards 作業項目の特定の機能要求まで、またはリポジトリ内のコミットまでデプロイをトレースすることも可能です。 この機能は、デプロイで問題が発生し、問題の原因になった変更を特定する必要がある場合に役立ちます。

セキュリティ

他のセキュリティ制御を環境に適用することができます。 特定の環境を使用できるパイプラインを制限できます。 または、運用環境を操作するセカンダリ パイプラインを誰かが誤って作成するのを防ぎます。

また、ユーザー アクセス許可を適用して、環境を管理できるユーザーを制御することもできます。 特定のアクセス許可を設定することにより、ユーザーに、新しい環境の作成、環境の修正、環境の表示、その環境へのデプロイの履歴の表示を許可することができます。

注意

パイプラインがまだ存在しない環境を参照している場合、Azure Pipelines は自動的にその環境を作成します。 この機能により、自動的に環境への管理者のアクセス許可を得ることになるため、Azure DevOps プロジェクトのセキュリティに影響を及ぼすことがあります。 環境のセキュリティに対するフル コントロールを手に入れつつ、誤って不必要なアクセス許可を取得してしまうことがないように、Azure DevOps Web インターフェイスを使用して自分自身で環境を作成するのが最善です。

デプロイ ジョブを環境にリンクする

デプロイ パイプライン定義では、デプロイ ジョブを指定する deployment プロパティを作成し、ジョブのデプロイ先の環境の名前を指定します。

- stage: DeployTest
  displayName: Deploy (Test Environment)
  jobs:
  - deployment: DeployWebsite
    environment: Test
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self

この例では、DeployWebsite という名前のジョブが Test 環境にリンクされています。

ヒント

ジョブには、"デプロイ戦略" など、このモジュールの範囲を超えるその他のプロパティもあります。 概要ユニットの詳細情報へリンクします。

環境とサービス接続

複数の環境を使用する場合、それぞれの環境を他から独立させる必要があります。 たとえば、開発環境の Web サイトは運用環境内のデータベースにアクセスできるべきではありません。

同じ原則が、デプロイ パイプラインにも当てはまります。 開発環境へのデプロイに使用するサービス接続は、運用環境にアクセスできるべきではありません。 この原則に従うことで、非運用環境デプロイが運用環境に影響を及ぼさないようにするための保護レイヤーをもう一つ加えることができます。

各環境に対して、別個のサービス接続を作成する必要があります。 各サービス接続では、その環境が使用するサブスクリプションとリソース グループにのみデプロイするための特定のアクセス許可を持つ、専用のサービス プリンシパルを使用する必要があります。

重要

デプロイ先の環境ごとに、別個のサービス プリンシパルとサービス接続を使用します。 サービス プリンシパルに、環境にデプロイするのに必要な最小限のアクセス許可だけを付与します。

Azure で環境を分離するのも良い方法です。 少なくとも、各環境に対して別個のリソース グループを作成する必要があります。 多くの場合、各環境に対して別個の Azure サブスクリプションを作成するとよいでしょう。 その後、各環境のサブスクリプション内で複数のリソース グループを作成できます。

ユーザーとサービス プリンシパルが、アクセスする必要がある環境だけにアクセスできるようにするために、Azure のロールの割り当てを適用します。 運用環境へのアクセスを、少数の人々と、その環境へのデプロイ サービス プリンシパルだけに限定するようにします。