持续部署到 Azure
为管道添加部署阶段,将构建项目推送到应用服务槽位,运行冒烟测试,并在批准后交换到生产环境。
持续部署到 Azure 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。 这是第 3 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cloud & IT Cert Prep 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。
什么是持续部署
持续部署 (CD) 会在每次更改通过 CI 测试后,自动将其发布到生产环境,无需人工干预。持续交付是较为宽松的版本——它会自动完成部署到 Staging 环境的过程,但在部署到 Production 前需要人工审批门禁。这两种实践都建立在相同的 Pipeline 基础设施之上。在 Azure Pipelines 中,CD 的实现方式是在 CI 阶段之后添加部署阶段,并根据需要将其指向带有审批门禁的 Azure 环境。
多阶段 Pipeline:CI + CD
一个完整的 CI/CD Pipeline 至少包含三个阶段:Build(编译、测试、发布构建产物)、Deploy to Staging(将构建产物部署到非生产插槽)和 Deploy to Production(交换插槽,或在审批后部署)。各阶段通过 Pipeline 构建产物存储传递构建产物。Staging 阶段会自动运行集成测试或冒烟测试;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'}部署作业和环境
部署阶段应使用 deployment 作业,而不是常规的 job。部署作业支持部署策略(runOnce、rolling、canary),按环境跟踪部署历史,并且必须引用 Azure DevOps 的 Environments。环境会记录哪些 Pipeline 运行曾向其中部署、当前上线的版本,并在单一仪表板中提供审批门禁、检查和资源运行状况。
# 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 文件。部署到 Staging 插槽后,请使用 AzureAppServiceManage@0 任务将 Staging 插槽交换到 Production,这是 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 Pipeline 中的冒烟测试
部署到 Staging 后,请运行冒烟测试——这是一组用于验证部署成功且应用程序响应正常的最小测试集合。冒烟测试通常会调用关键 API 端点,并验证预期的状态代码和响应内容。如果冒烟测试失败,Pipeline 会在交换到 Production 或请求审批前停止,从而防止有问题的发布版本触达用户。
# 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 Environments,要求在部署继续之前完成人工签字批准。请进入环境设置并添加 Approvals,然后指定必须批准的用户或组。当 Pipeline 到达一个以该环境为目标的部署作业时,它会暂停并发送电子邮件通知。审批者可以在 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 和 canary 部署的支持。使用在 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))为容器镜像添加标记,这样您始终可以将正在运行的容器追溯到构建它的确切代码修订版本。请避免在 Production 中使用 latest 标记——Kubernetes 会缓存该标记,可能不会拉取新版本。将具体的镜像标记存储为 Pipeline 变量,并在部署时使用 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持续部署最佳实践
遵循以下持续部署最佳实践:频繁部署(小批量可降低风险)、使用功能标志将部署与发布解耦、在生产前自动执行所有质量门禁、练习与生产环境相似的暂存以避免差异掩盖错误、通过自动运行状况检查监视部署时段,并始终准备经过测试的回滚计划。成熟的持续部署流水线会让部署变成一件无需特别关注的事情,而不是高压力操作。
快速检查
测试您对本课 Microsoft Azure 基础知识(AZ-900)概念的理解。
课程回顾
本课您学习了:多阶段 YAML 流水线通过传递构件串联 Build、Staging 和 Production 阶段;带有 Environments 的部署作业支持审批门禁和部署跟踪;暂存部署后的冒烟测试可防止有问题的发布进入生产环境。接下来我们将探索 Azure 上的 GitHub Actions。
常见问题解答
「持续部署到 Azure」课时是免费的吗?
是的 — 「持续部署到 Azure」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Cloud & IT Cert Prep 课程的其余内容,请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。
「持续部署到 Azure」这节课中我会学到什么?
为管道添加部署阶段,将构建项目推送到应用服务槽位,运行冒烟测试,并在批准后交换到生产环境。 你通过在浏览器中直接运行的动手代码来练习 Cloud & IT Cert Prep,全天候 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 反馈 — 无需本地设置。