0Pricing
Azure Fundamentals · レッスン

Azure への継続的デプロイ

デプロイ ステージをパイプラインに追加してビルド成果物を App Service スロットにプッシュし、スモーク テストを実行して、承認後に本番環境へスワップします。

「Azure への継続的デプロイ」はCoddyKit上の無料Azure Fundamentalsレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

継続的デプロイとは

継続的デプロイ(CD)とは、CI テストに合格したすべての変更を、手動操作なしで自動的に本番環境へリリースする手法です。継続的デリバリーはその緩やかな形で、ステージング環境までのデプロイを自動化し、本番環境への移行前に人による承認ゲートを必要とします。どちらの手法も同じパイプライン基盤の上に構築されます。Azure Pipelines では、CI ステージの後にデプロイ用のステージを追加し、必要に応じて承認ゲート付きの Azure 環境を対象にすることで CD を実装します。

マルチステージ パイプライン: CI + CD

完全な CI/CD パイプラインには、少なくとも 3 つのステージがあります。Build(コンパイル、テスト、アーティファクトの公開)、Deploy to Staging(本番以外のスロットへのアーティファクトのデプロイ)、Deploy to Production(承認後のスロット切り替えまたはデプロイ)です。ステージ間では、パイプライン アーティファクト ストレージを介してアーティファクトを引き渡します。ステージング ステージでは統合テストまたはスモークテストを自動的に実行し、本番ステージでは手動承認を待ってから処理を続行します。

# azure-pipelines.yml: multi-stage CI/CD
trigger:
  branches:
    include: [main]

pool:
  vmImage: ubuntu-latest

stages:
- stage: Build
  jobs:
  - job: BuildApp
    steps:
    - script: npm ci && npm run build
    - task: PublishPipelineArtifact@1
      inputs: {targetPath: dist, artifactName: webapp}

- stage: DeployStaging
  dependsOn: Build
  jobs:
  - deployment: StagingDeploy
    environment: Staging
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs: {appName: myapp-staging, package: '$(Pipeline.Workspace)/webapp'}

- stage: DeployProduction
  dependsOn: DeployStaging
  jobs:
  - deployment: ProductionDeploy
    environment: Production   # Has manual approval gate
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs: {appName: myapp, package: '$(Pipeline.Workspace)/webapp'}

デプロイ ジョブと環境

デプロイ ステージには、通常の job ではなく deployment ジョブを使用します。デプロイ ジョブはデプロイ戦略(runOnce、rolling、canary)をサポートし、環境ごとのデプロイ履歴を追跡します。また、Azure DevOps の環境を参照する必要があります。環境には、どのパイプライン実行によってデプロイされたか、現在稼働しているバージョン、承認ゲート、チェック、リソースの正常性ステータスが 1 つのダッシュボードに記録されます。

# Deployment job with rolling strategy
- job: RollingDeploy
  strategy:
    rolling:
      maxParallel: 2     # Deploy to 2 targets at a time
      preDeploy:
        steps:
        - script: echo 'Pre-deploy checks'
      deploy:
        steps:
        - task: AzureWebApp@1
          inputs:
            appName: myapp
            package: '$(Pipeline.Workspace)/webapp'
      postRouteDeploy:
        steps:
        - script: curl -f https://myapp.azurewebsites.net/health

Azure App Service へのデプロイ

AzureWebApp@1 タスクは、Web アプリケーションを Azure App Service にデプロイします。特定のスロット(例: staging)へのデプロイ、ZIP パッケージ、Docker イメージ、JAR/WAR ファイルのデプロイをサポートしています。ステージング スロットにデプロイした後、AzureAppServiceManage@0 タスクを使用してステージング スロットを本番環境にスワップします。これは、App Service で推奨されるダウンタイムなしのデプロイ パターンです。

# Deploy to staging slot, then swap to production
steps:
- task: AzureWebApp@1
  displayName: 'Deploy to staging slot'
  inputs:
    azureSubscription: 'AzureProductionSC'
    appType: webAppLinux
    appName: myUniqueWebApp
    deployToSlotOrASE: true
    resourceGroupName: MyRG
    slotName: staging
    package: '$(Pipeline.Workspace)/webapp/app.zip'
    runtimeStack: 'NODE|18-lts'

- task: AzureAppServiceManage@0
  displayName: 'Swap staging into production'
  inputs:
    azureSubscription: 'AzureProductionSC'
    action: Swap Slots
    webAppName: myUniqueWebApp
    resourceGroupName: MyRG
    sourceSlot: staging

CD パイプラインでのスモークテスト

ステージング環境へのデプロイ後、スモークテストを実行します。これは、デプロイが成功し、アプリケーションが正しく応答していることを確認する最小限のテスト セットです。通常、スモークテストでは主要な API エンドポイントを呼び出し、期待されるステータス コードとレスポンス内容を検証します。スモークテストが失敗した場合、パイプラインは本番環境へのスワップや承認要求の前に停止し、壊れたリリースがユーザーに届くのを防ぎます。

# Smoke test step after staging deployment
- script: |
    MAX_RETRY=10
    COUNT=0
    until curl -sf https://myUniqueWebApp-staging.azurewebsites.net/health; do
      COUNT=$((COUNT+1))
      if [ $COUNT -ge $MAX_RETRY ]; then
        echo 'Health check failed after $MAX_RETRY attempts'
        exit 1
      fi
      echo 'Waiting for app to start... attempt '$COUNT
      sleep 10
    done
    echo 'App is healthy'
  displayName: 'Smoke test: health endpoint'

環境の承認ゲート

Azure DevOps の環境に承認ゲートを追加すると、デプロイの続行前に手動承認を必須にできます。環境の設定に移動して [Approvals] を追加し、承認が必要なユーザーまたはグループを指定します。パイプラインがその環境を対象とするデプロイ ジョブに到達すると一時停止し、メール通知が送信されます。承認者は Azure DevOps ポータルまたは通知メールのリンクからデプロイの詳細を確認し、承認または拒否できます。

# Pipeline YAML: deployment to production environment
# (Approval configured in Azure DevOps portal on 'Production' environment)
- stage: DeployProduction
  displayName: 'Deploy to Production'
  dependsOn: DeployStaging
  condition: succeeded('DeployStaging')
  jobs:
  - deployment: ProdDeploy
    environment: Production   # <-- Triggers approval gate configured in portal
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              appName: myapp-prod
              package: '$(Pipeline.Workspace)/webapp/app.zip'

Azure Kubernetes Service へのデプロイ

KubernetesManifest@0 タスクを使用して、コンテナー化されたアプリケーションを AKS にデプロイします。このタスクは Kubernetes の YAML マニフェストをクラスターに適用し、imagePullSecrets とカナリア デプロイを標準でサポートしています。Azure DevOps で構成した Kubernetes サービス接続を使用して AKS クラスターに接続します。タスクは内部で kubectl apply を使用し、ロールアウトが完了するまで待機してからステップを成功としてマークします。

# AKS deployment step in Azure Pipelines
- task: KubernetesManifest@0
  displayName: 'Deploy to AKS'
  inputs:
    action: deploy
    kubernetesServiceConnection: 'AKS-Production-SC'
    namespace: production
    manifests: |
      k8s/deployment.yaml
      k8s/service.yaml
    containers: 'mycontainerregistry.azurecr.io/myapp:$(Build.BuildId)'
    imagePullSecrets: acr-secret

イメージのタグ付け戦略

コンテナー イメージにはビルド ID($(Build.BuildId))またはGit コミット SHA($(Build.SourceVersion))でタグを付けます。これにより、実行中のコンテナーを、そのイメージをビルドした正確なコード リビジョンまで常に追跡できます。本番環境では latest タグを使用しないでください。Kubernetes がこのタグをキャッシュし、新しいバージョンをプルしない場合があるためです。具体的なイメージ タグはパイプライン変数として保存し、デプロイ時に envsubst または sed を使用して Kubernetes マニフェストに挿入します。

# Tag and push image with build ID in CI stage
- script: |
    IMAGE='mycontainerregistry.azurecr.io/myapp'
    TAG='$(Build.BuildId)'
    docker build -t $IMAGE:$TAG -t $IMAGE:latest .
    az acr login --name mycontainerregistry
    docker push $IMAGE:$TAG
    docker push $IMAGE:latest
    echo "##vso[task.setvariable variable=imageTag;isOutput=true]$TAG"
  name: BuildImage
  displayName: 'Build and push container image'

ロールバック戦略

本番環境へのデプロイに備えてロールバック戦略を定義し、不適切なリリースから迅速に復旧できるようにします。App Serviceでは、ロールバックとは本番スロットを以前のステージングバージョンに戻すことを意味します。AKSではkubectl rollout undoを使用します。専用のロールバックパイプラインを構築するか、Azure DevOpsポータルから手動で実行できるロールバックジョブを追加します。ロールバック手順を文書化し、定期的に練習してください。テストされていないロールバックは、ロールバックとはいえません。

# Rollback job triggered manually
- job: Rollback
  condition: and(failed(), eq(variables['Build.Reason'], 'Manual'))
  steps:
  # App Service rollback: swap production back to previous
  - task: AzureAppServiceManage@0
    inputs:
      azureSubscription: 'AzureProductionSC'
      action: Swap Slots
      webAppName: myUniqueWebApp
      resourceGroupName: MyRG
      sourceSlot: production  # Swap production back to staging version
      targetSlot: staging

デプロイ通知と監視

各本番デプロイの後に監視チェックを自動実行し、新しいバージョンが正常に動作していることを確認します。AzureMonitor@1パイプラインチェックを使用してAzure Monitorのメトリックを照会します。デプロイ後にエラー率が上昇した場合は、パイプラインの дальнейな進行を停止し、ロールバックを実行します。Webhookタスクを使用してMicrosoft TeamsまたはSlackにデプロイ通知を送信し、デプロイが完了したことと、現在稼働しているバージョンをチームに知らせます。

# Send Teams notification on deployment completion
- task: InvokeRestAPI@1
  displayName: 'Notify Teams channel'
  inputs:
    connectionType: connectedServiceName
    serviceConnection: 'TeamsWebhookSC'
    method: POST
    body: '{
      "text": "Deployed **$(Build.BuildId)** to Production. Committed by $(Build.RequestedFor). <br>View: https://myapp.contoso.com"
    }'
    waitForCompletion: false

CDのベストプラクティス

次の継続的デプロイのベストプラクティスに従ってください。頻繁にデプロイする(小さな単位に分けることでリスクを軽減できます)、フィーチャーフラグを使用する(デプロイとリリースを分離できます)、本番環境の前にすべての品質ゲートを自動化する、本番環境に近いステージングを実践する(環境の違いによってバグが見逃されるのを防ぎます)、自動ヘルスチェックでデプロイ期間を監視する、そして常にテスト済みのロールバック計画を用意することです。成熟したCDパイプラインにより、デプロイは大きなストレスを伴う作業ではなく、特別な出来事でもない通常の作業になります。

クイックチェック

このレッスンで扱ったMicrosoft Azure Fundamentals(AZ-900)の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、マルチステージYAMLパイプラインによってBuild、Staging、Productionの各ステージをアーティファクトの受け渡しとともに連結すること、Environmentを使用したデプロイジョブによって承認ゲートとデプロイの追跡が可能になること、そしてステージングへのデプロイ後にスモークテストを実行することで、壊れたリリースが本番環境に到達するのを防げることを学びました。次はAzureでのGitHub Actionsについて学びます。

よくある質問

「Azure への継続的デプロイ」レッスンは無料ですか?

はい。「Azure への継続的デプロイ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Azure Fundamentalsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Azure Fundamentalsコースには全4レッスンが含まれています。

「Azure への継続的デプロイ」で何を学びますか?

デプロイ ステージをパイプラインに追加してビルド成果物を App Service スロットにプッシュし、スモーク テストを実行して、承認後に本番環境へスワップします。 ブラウザで直接実行するハンズオンコードでAzure Fundamentalsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Azure Fundamentalsを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのAzure Fundamentalsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「Azure への継続的デプロイ」レッスンにはどのくらい時間がかかりますか?

ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAzure Fundamentalsレッスンでコードを書いて実行できますか?

はい。すべてのAzure Fundamentalsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. Azure DevOps Services の概要
  2. Azure Pipelines で CI パイプラインを構築
  3. Azure への継続的デプロイ
  4. Azure での GitHub Actions
← Azure Fundamentalsに戻る