Azure への継続的デプロイ
デプロイ ステージをパイプラインに追加してビルド成果物を App Service スロットにプッシュし、スモーク テストを実行して、承認後に本番環境へスワップします。
「Azure への継続的デプロイ」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全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/healthAzure 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: stagingCD パイプラインでのスモークテスト
ステージング環境へのデプロイ後、スモークテストを実行します。これは、デプロイが成功し、アプリケーションが正しく応答していることを確認する最小限のテスト セットです。通常、スモークテストでは主要な 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: falseCDのベストプラクティス
次の継続的デプロイのベストプラクティスに従ってください。頻繁にデプロイする(小さな単位に分けることでリスクを軽減できます)、フィーチャーフラグを使用する(デプロイとリリースを分離できます)、本番環境の前にすべての品質ゲートを自動化する、本番環境に近いステージングを実践する(環境の違いによってバグが見逃されるのを防ぎます)、自動ヘルスチェックでデプロイ期間を監視する、そして常にテスト済みのロールバック計画を用意することです。成熟したCDパイプラインにより、デプロイは大きなストレスを伴う作業ではなく、特別な出来事でもない通常の作業になります。
クイックチェック
このレッスンで扱ったMicrosoft Azure Fundamentals(AZ-900)の概念について、理解度を確認します。
レッスンのまとめ
このレッスンでは、マルチステージYAMLパイプラインによってBuild、Staging、Productionの各ステージをアーティファクトの受け渡しとともに連結すること、Environmentを使用したデプロイジョブによって承認ゲートとデプロイの追跡が可能になること、そしてステージングへのデプロイ後にスモークテストを実行することで、壊れたリリースが本番環境に到達するのを防げることを学びました。次はAzureでのGitHub Actionsについて学びます。
よくある質問
「Azure への継続的デプロイ」レッスンは無料ですか?
はい。「Azure への継続的デプロイ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Cloud & IT Cert Prepコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
「Azure への継続的デプロイ」で何を学びますか?
デプロイ ステージをパイプラインに追加してビルド成果物を App Service スロットにプッシュし、スモーク テストを実行して、承認後に本番環境へスワップします。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Cloud & IT Cert Prepを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのCloud & IT Cert Prepは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「Azure への継続的デプロイ」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このCloud & IT Cert Prepレッスンでコードを書いて実行できますか?
はい。すべてのCloud & IT Cert Prepレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。