0Pricing
Azure Fundamentals · 강의

Azure로 지속적 배포

배포 단계를 파이프라인에 추가해 빌드 아티팩트를 App Service 슬롯으로 푸시하고, 스모크 테스트를 실행하며, 승인 후 프로덕션으로 교체합니다.

Azure로 지속적 배포은(는) CoddyKit의 무료 Azure Fundamentals 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 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 환경을 반드시 참조해야 합니다. 환경에는 어떤 파이프라인 실행이 해당 환경에 배포되었는지와 현재 운영 중인 버전이 기록되며, 하나의 대시보드에서 승인 게이트, 검사 및 리소스 상태를 제공합니다.

# 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 작업은 웹 애플리케이션을 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 환경에 승인 게이트를 추가하십시오. 환경 설정으로 이동하여 승인을 추가하고, 승인해야 하는 사용자 또는 그룹을 지정합니다. 파이프라인이 해당 환경을 대상으로 하는 배포 작업에 도달하면 일시 중지되고 이메일 알림이 전송됩니다. 승인자는 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 모니터 메트릭을 조회하십시오. 배포 후 오류율이 높아지면 이후 파이프라인 진행을 차단하고 롤백을 실행하십시오. 웹훅 작업을 통해 Microsoft Teams 또는 슬랙으로 배포 알림을 보내 팀에서 배포 완료 여부와 현재 운영 중인 버전을 알 수 있도록 하십시오.

# 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 단계를 연결하고, Environments를 사용하는 배포 작업은 승인 게이트와 배포 추적 기능을 제공하며, 스테이징 배포 후 실행하는 스모크 테스트는 문제가 있는 릴리스가 운영 환경에 도달하지 않도록 방지합니다. 다음으로는 Azure에서 GitHub Actions를 살펴봅니다.

자주 묻는 질문

“Azure로 지속적 배포” 강의는 무료인가요?

네 — “Azure로 지속적 배포” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Azure Fundamentals 강의 전체를 잠금 해제할 수 있습니다. Azure Fundamentals 강의에는 총 4개의 강의가 포함되어 있습니다.

“Azure로 지속적 배포”에서 뭘 배우나요?

배포 단계를 파이프라인에 추가해 빌드 아티팩트를 App Service 슬롯으로 푸시하고, 스모크 테스트를 실행하며, 승인 후 프로덕션으로 교체합니다. 브라우저에서 직접 실행하는 실습 코드로 Azure Fundamentals을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Azure Fundamentals을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Azure Fundamentals은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“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(으)로 돌아가기