Azure Pipelines を使用してリリースパイプラインを計画する

6 分

このセクションでは、Andy と Mara と共に、Azure Pipelines で実行される基本的な CD パイプラインの計画を追っていきます。

完了したら、チームの他のメンバーにデモを行います。パイプラインは POC として機能します。知識を深め、Tim や Amita からフィードバックを得るにつれて、これに改善と拡張を加えていきます。

基本的な CD パイプラインにはどのような部分がありますか。

基本的な CD パイプラインには、プロセスを実行するための "トリガー" と、少なくとも 1 つの "ステージ" (デプロイフェーズ) が含まれています。ステージは、"ジョブ" で構成されます。ジョブとは、アプリケーションのビルド、テスト、またはデプロイの方法を定義する一連のステップです。

Diagram that shows a hand-drawn illustration of an artifact moving to a deployment environment.

Andy: ビルド成果物は既にあります。これは、既存のビルドパイプラインによって作成される .zip ファイルです。しかしながら、これをライブ環境にデプロイするにはどうすればよいでしょうか?

パイプラインステージとは

"ステージ" とは、独立して実行でき、さまざまなメカニズムでトリガーできるパイプラインの一部です。メカニズムとしては、前のステージの成功、スケジュール、または手動のトリガーも使用できます。次のモジュールでは、これらのメカニズムについてさらに学習します。

Mara: たとえば、アプリをビルドするステージと、テストを実行する別のステージがあるかもしれません。

Diagram that shows a hand-drawn illustration of a deployment pipeline that contains two stages, Build and Deploy.

Mara: パイプラインのビルドステージに対しては、タスクを既に定義しました。デプロイステージは、環境にビルドをデプロイするタスクを含め、似ているようにすることができます。

問題は、成果物をどこにデプロイする必要があるかです。

環境とは

アプリケーションまたはサービスが実行されている場所を指すために "環境" という用語を使用することが考えられます。たとえば、"運用環境" とは、エンドユーザーがアプリケーションにアクセスする場所である場合があります。

この例では、運用環境は次のものが考えられます。

物理マシンまたは仮想マシン (VM)。
Kubernetes などのコンテナー化された環境。
Azure App Service などの管理サービス。
Azure Functions などのサーバーレス環境。

成果物は環境にデプロイされます。 Azure Pipelines を使用すると、オンプレミスかクラウドかにかかわらず、ほぼすべての種類の環境に簡単にデプロイできます。

Azure Pipelines では、"環境" という用語には 2 つ目の意味があります。ここでの "環境" とは、Kubernetes クラスター、App Service インスタンス、仮想マシンなど、デプロイ環境の抽象的な表現です。

Azure Pipelines 環境には、変更のソースを特定するのに役立つデプロイ履歴が記録されます。 Azure Pipelines 環境を使用して、パイプラインの 1 つのステージから別のステージへ成果物がどのように昇格されるかを制御する、セキュリティチェックと方法を定義することもできます。環境に含まれる内容は、成果物をどのように処理するかによって異なります。成果物をテストする環境は、エンドユーザー向けに成果物をデプロイする環境とは異なる方法で定義される可能性が高いでしょう。

Azure Pipelines 環境を定義する方法の 1 つとして、YAML ファイルがあります。 YAML ファイルには、成果物をデプロイする Azure Pipelines 環境を指定する environment セクションが含まれています。

リリースパイプラインを計画するときに、アプリケーションまたはサービスを実行する場所を決定する必要があります。 Andy と Mara がどのように決定するか、聞いてみましょう。

Andy: 大まかに言えば、どのような種類の環境が必要でしょうか。オンプレミスにデプロイしますか、それともクラウドにデプロイしますか。

Mara： ラボで私たち用の VM を作成してくれるように Tim に依頼することもできますが、彼はいつもハードウェアが不足している状況です。クラウドを使用すれば、私たち自身で POC をすばやく簡単に設定できます。

Andy: 同感です。しかし、考慮できるクラウドオプションは多数あり、私たちは Azure Pipelines を使用してそのいずれにもデプロイを行うことができます。どれを試しましょうか。

Mara: ゲームを開発しているチームは、Azure を使用してバックエンドシステムの一部をホストしています。設定はすばやく済み、気に入っているようです。クラウドのために Azure を使い続けるべきだと思います。

Andy: OK、それは理にかなっています! しかし、Azure には多くのコンピューティングオプションが用意されています。どれを選びましょうか。

Andy は、次のオプションをホワイトボードに列挙します。

仮想マシン
コンテナー
Azure App Service
サーバーレスコンピューティング

Note

これらの各コンピューティングオプションの詳細については、このモジュールの最後に記載されています。

Mara: 現在はコンテナーとサーバーレスコンピューティングに人気があります。 VM と比較すると、どちらもリソースに関して軽量です。また、置き換えやスケールアウトも簡単にできます。どちらも興味深いのですが、2 つの新しいテクノロジを同時に学習することには不安を感じます。パイプラインの構築だけに集中した方がよいと思います。

Andy: 私も同意見です。これで、VM または App Service が残ります。基幹業務アプリ、つまり何らかの特有の環境へのフルアクセスを必要とするアプリをクラウドに移行する場合には、VM の方が適した選択肢だと思います。私たちはそこまで重要なことを行おうとはしていません。

Mara: これで App Service が残りますね。私もそれを選びます。 Azure DevOps と連携するように設計されており、利点があります。 Web アプリ用のサービスとしてのプラットフォーム (PaaS) 環境なので、私たちの負担が大幅に軽減されます。インフラストラクチャについて心配する必要がなくなります。また、セキュリティ機能も用意されており、負荷分散と自動スケーリングも実行できます。

Andy: App Service が私たちに必要なもののようですね。 App Service を使用しましょう。いずれにしても、私たちは概念実証を作成しようとしているにすぎません。後で他のことを試したくなったら、いつでもコンピューティングオプションを変更できます。

Azure Pipelines でデプロイステップはどのように実行されるか

Azure Pipelines では、アプリケーションをデプロイするには、まずターゲット環境で認証する必要があります。 Azure Pipelines には、さまざまな認証メカニズムが用意されています。使用するものは、デプロイを行うターゲット環境によって異なります。これらのメカニズムの詳細については、このモジュールの最後に記載されています。

Andy: ビルド成果物があり、パイプラインのステージでビルドとデプロイを行うことがわかっています。また、デプロイのターゲット環境も定義しました。それは App Service です。ここで知りたいのは、Azure Pipelines は App Service でどのように認証されるのかということです。これは、Tim の懸念事項の 1 つになるでしょう。プロセスが安全であることを保証する必要があります。

Andy と Mara は、少し調査した後、App Service への Azure Pipelines のデプロイを可能にする一般的な手順を考え出します。

ターゲットデプロイ環境をパイプライン構成で指定します。
その環境へのアクセスを Azure Pipelines で認証する方法を用意します。
Azure Pipelines タスクを使用して、ビルド成果物をその環境にデプロイします。

Mara: 私たちの調査によれば、ターゲット環境を指定し、それに対するアクセスを認証するために、"サービス接続" を作成する必要があります。サービス接続を定義すると、すべてのタスクで使用できるようになります。次に、組み込みのタスクである DownloadPipelineArtifact を使用して、ビルド成果物をパイプラインエージェントと AzureWebApp にダウンロードして、アプリケーションを Azure App Service にデプロイする必要があります。

ジョブと戦略とは

既存のビルドパイプラインでは、ビルドエージェント、パイプライン変数、およびソフトウェアをビルドするために必要なタスクが定義されています。

パイプラインのデプロイ部分には、これらの同じ要素が含まれています。通常、デプロイ構成では、1 つまたは複数のジョブ、パイプライン環境、および戦略も定義します。パイプライン環境については以前に学習しました。

このモジュールの後半で実行する構成の例を次に示します。この構成によって、Space Game Web サイトが App Service にデプロイされます。

- stage: 'DeployDev'
  displayName: 'Deploy to dev environment'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: 'Release Pipeline'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            displayName: 'Azure App Service Deploy: website'
            inputs:
              azureSubscription: 'Resource Manager - Tailspin - Space Game'
              appName: '$(WebAppName)'
              package: '$(Pipeline.Workspace)/drop/$(buildConfiguration)/*.zip'

ジョブ

"ジョブ" とは、1 つの単位として順番に実行される一連のステップ (またはタスク) です。既定では、ステージで job キーワードが使用されていない場合でも、各パイプラインステージに 1 つのジョブがあります。

ジョブは、エージェントプール、コンテナー、または Azure DevOps サーバーで直接実行できます。ここに示したジョブの例は、Microsoft によってホストされている Ubuntu エージェントで実行されます。

各ジョブを実行する条件を指定できます。ここに示したジョブの例では、条件は定義されていません。既定では、ジョブは、他のどのジョブにも依存していない場合、または依存しているすべてのジョブが正常に完了した場合に実行されます。

また、複数のジョブを並列または順番に実行することもできます。例として既存のビルドパイプラインを使用すると、並列ジョブを使用して、Windows、Linux、macOS の各エージェントで同時にソフトウェアをビルドできます。

"デプロイジョブ" は、デプロイステージで重要な役割を果たす特別な種類のジョブです。デプロイジョブにより、Azure Pipelines でのデプロイの状態が記録され、監査証跡が提供されます。デプロイジョブは、デプロイ戦略を定義するのにも役立ちます。これは、この後すぐに行います。

方法

"戦略" では、アプリケーションのロールアウトの方法を定義します。ブルーグリーンやカナリアなどの戦略の詳細については、今後のモジュールで学習します。ここでは、runOnce 戦略を使用して、パイプラインから Space Game パッケージをダウンロードし、Azure App Service にデプロイします。

Azure Pipelines から Azure にどのように接続するか

仮想マシンや App Service などの Azure リソースにアプリをデプロイするには、"サービス接続" が必要です。サービス接続は、次の 2 つの方法のいずれかを使用して、Azure サブスクリプションへのセキュリティで保護されたアクセスを提供します。

サービスプリンシパルの認証
Azure リソースのマネージド ID

これらのセキュリティモデルの詳細については、このモジュールの最後で説明しますが、要約すると次のようになります。

"サービスプリンシパル" は、Azure リソースにアクセスできる制限付きロールの ID です。サービスプリンシパルは、ユーザーに代わって自動タスクを実行できるサービスアカウントと考えることができます。
Azure リソースのマネージド ID は、サービスプリンシパルの操作のプロセスを簡略化する Microsoft Entra ID の機能です。マネージド ID は Microsoft Entra テナントに存在するため、Azure インフラストラクチャでは、自動的にサービスを認証し、アカウントを管理できます。

マネージド ID はサービスプリンシパルを扱うプロセスを単純化します。ただし、このモジュールでは、サービスプリンシパル認証を使用します。これは、サービス接続が自動的に Azure リソースを検出し、ユーザーに代わって適切なサービスプリンシパルロールを割り当てることができるからです。

計画

Andy と Mara は開始する準備ができました。次のことを行おうとしています。

既存の Azure Pipelines ビルド構成を基に構築します。
成果物を作成するビルドステージを定義します。
App Service に成果物をデプロイするデプロイステージを定義します。

Diagram that shows a hand-drawn illustration of a deployment pipeline that contains two stages. The deployment stage deploys the artifact to App Service.

Andy: この図は正しいでしょうか。 Azure Pipelines を使用して、Azure App Service にデプロイします。これを行うには、ビルド成果物を、デプロイステージへの入力として取り込みます。このタスクをデプロイステージで行うと、成果物がダウンロードされ、サービス接続を使用してその成果物が App Service にデプロイされます。

Mara: そういうことですね。それでは、始めましょう。

自分の知識をチェックする

あなたは、新しい Web アプリについてすばらしいアイデアを持っています。ラップトップで動作しているコードはありますが、続行する前にチームからのフィードバックがほしいと考えます。アプリをチームと共有できるように Azure にデプロイする最も迅速な方法はどれですか?

Azure Pipelines に CI/CD パイプラインを構築する。

Visual Studio を使用してアプリを右クリック発行する。

xcopy を実行して、Azure で実行されている仮想マシン (VM) に Web アプリをアップロードします。

Azure App Service にデプロイするには、Azure Pipelines でどのリソースが必要になりますか?

ビルド成果物とサービス接続。

ホスト名と SSH キー。

ホスト名および暗号化されたユーザー名とパスワード。

タスク、ステージ、ジョブの関係について正しく説明しているのは、次のうちどれですか?

タスクは、ジョブの別名です。ステージには、タスクまたはジョブのいずれかを含めることができます。

ステージはジョブに分割され、ジョブはタスクに分割されます。

ステージはタスクに分割されます。各ステージの実行時にジョブがスケジュールされます。

作業を確認する前にすべての問題に回答する必要があります。

続行

Azure Pipelines を使用してリリース パイプラインを計画する