Azure Fundamentals · Lekcja

Ciągłe wdrażanie na platformie Azure

Rozszerz potok o etap wdrażania, który przesyła artefakt kompilacji do slotu App Service, wykonuje testy dymne i po zatwierdzeniu zamienia go na środowisko produkcyjne.

Ciągłe wdrażanie na platformie Azure to bezpłatna lekcja Azure Fundamentals na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Azure Fundamentals, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Czym jest ciągłe wdrażanie?

Ciągłe wdrażanie (CD) automatycznie udostępnia w środowisku produkcyjnym każdą zmianę, która przejdzie testy CI, bez ręcznej ingerencji. Ciągłe dostarczanie to łagodniejsza wersja tego podejścia — automatyzuje wdrażanie do środowiska staging i wymaga zatwierdzenia przez człowieka przed wdrożeniem do środowiska produkcyjnego. Obie praktyki opierają się na tej samej infrastrukturze potoku. W Azure Pipelines CD jest realizowane przez dodanie etapów wdrażania po etapie CI i kierowanie ich do środowisk platformy Azure z bramkami zatwierdzeń, jeśli są potrzebne.

Potok wieloetapowy: CI + CD

Kompletny potok CI/CD obejmuje co najmniej trzy etapy: Build (kompilowanie, testowanie i publikowanie artefaktu), Deploy to Staging (wdrażanie artefaktu do miejsca nieprodukcyjnego) oraz Deploy to Production (zamiana miejsc lub wdrożenie po zatwierdzeniu). Etapy przekazują artefakt dalej za pośrednictwem magazynu artefaktów potoku. Etap staging automatycznie uruchamia testy integracyjne lub testy dymne, a etap produkcyjny oczekuje na ręczne zatwierdzenie przed kontynuowaniem.

# 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'}

Zadania wdrażania i środowiska

W etapach wdrażania używaj zadań deployment, a nie zwykłych zadań job. Zadania wdrażania obsługują strategie wdrażania (runOnce, rolling, canary), śledzą historię wdrożeń dla poszczególnych środowisk i wymagają odwołania do środowisk Azure DevOps. Środowisko rejestruje, które uruchomienia potoku zostały do niego wdrożone, jaka wersja jest obecnie aktywna, a także udostępnia w jednym panelu bramki zatwierdzeń, kontrole i stan kondycji zasobów.

# 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

Wdrażanie do usługi Azure App Service

Zadanie AzureWebApp@1 wdraża aplikację internetową do usługi Azure App Service. Obsługuje wdrażanie do określonego miejsca (np. staging), wdrażanie pakietów ZIP, obrazów platformy Docker lub plików JAR/WAR. Po wdrożeniu do miejsca staging użyj zadania AzureAppServiceManage@0, aby zamienić miejsce staging na produkcyjne — jest to preferowany wzorzec wdrażania bez przestojów dla usługi 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

Testy dymne w potoku CD

Po wdrożeniu do środowiska staging uruchom testy dymne — minimalny zestaw testów sprawdzających, czy wdrożenie zakończyło się powodzeniem i czy aplikacja odpowiada prawidłowo. Testy dymne zwykle wywołują kluczowe punkty końcowe API i weryfikują oczekiwane kody stanu oraz treść odpowiedzi. Jeśli testy dymne zakończą się niepowodzeniem, potok zatrzymuje się przed zamianą na środowisko produkcyjne lub wysłaniem żądania zatwierdzenia, uniemożliwiając dotarcie uszkodzonego wydania do użytkowników.

# 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'

Bramki zatwierdzeń środowiska

Dodaj bramki zatwierdzeń do środowisk Azure DevOps, aby przed kontynuowaniem wdrożeń wymagane było ręczne zatwierdzenie. Przejdź do ustawień środowiska i dodaj opcję Approvals — określ użytkowników lub grupy, które muszą zatwierdzić wdrożenie. Gdy potok dotrze do zadania wdrażania kierowanego do tego środowiska, zostanie wstrzymany i wyśle powiadomienie e-mail. Osoby zatwierdzające mogą wyświetlić szczegóły wdrożenia oraz zatwierdzić je lub odrzucić w portalu Azure DevOps albo za pomocą łącza w wiadomości e-mail.

# 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'

Wdrażanie do usługi Azure Kubernetes Service

Wdrażaj aplikacje skonteneryzowane do AKS za pomocą zadania KubernetesManifest@0. Zadanie to stosuje manifesty YAML platformy Kubernetes do klastra, zapewniając wbudowaną obsługę imagePullSecrets i wdrożeń canary. Połącz się z klastrem AKS za pomocą połączenia usługi Kubernetes skonfigurowanego w Azure DevOps. Zadanie korzysta wewnętrznie z polecenia kubectl apply i oczekuje na ukończenie wdrażania, zanim oznaczy krok jako zakończony powodzeniem.

# 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

Strategia tagowania obrazów

Oznaczaj obrazy kontenerów za pomocą identyfikatora kompilacji ($(Build.BuildId)) lub SHA zatwierdzenia Git ($(Build.SourceVersion)), aby zawsze można było powiązać uruchomiony kontener z dokładną wersją kodu, na podstawie której został zbudowany. Unikaj używania tagu latest w środowisku produkcyjnym — Kubernetes buforuje go i może nie pobrać nowej wersji. Przechowuj konkretny tag obrazu jako zmienną potoku i wstrzykuj go do manifestów Kubernetes w czasie wdrażania za pomocą envsubst lub sed.

# 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'

Strategie wycofywania wdrożeń

Proszę zdefiniować strategię wycofywania wdrożeń produkcyjnych, aby można było szybko odzyskać sprawność po wdrożeniu wadliwej wersji. W przypadku App Service wycofanie wdrożenia oznacza przełączenie slotu produkcyjnego z powrotem na poprzednią wersję w slocie staging. W przypadku AKS należy użyć polecenia kubectl rollout undo. Proszę utworzyć dedykowany potok wycofywania wdrożenia albo dodać ręczne zadanie wycofywania, które można uruchomić z portalu Azure DevOps. Procedurę wycofywania należy udokumentować i regularnie przećwiczyć — niewypróbowane wycofanie wdrożenia nie jest wycofaniem wdrożenia.

# 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

Powiadomienia i monitorowanie wdrożeń

Po każdym wdrożeniu produkcyjnym należy automatycznie uruchomić kontrolę monitorowania, aby potwierdzić, że nowa wersja działa prawidłowo. Proszę użyć kontroli potoku AzureMonitor@1 do sprawdzania metryk w usłudze Azure Monitor — jeśli po wdrożeniu wskaźniki błędów są podwyższone, należy zablokować dalsze wykonywanie potoku i uruchomić wycofanie wdrożenia. Powiadomienia o wdrożeniach należy wysyłać do Microsoft Teams lub Slack za pomocą zadań webhook, aby zespół wiedział, kiedy wdrożenie zostało ukończone i jaka wersja jest aktywna.

# 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

Najlepsze praktyki ciągłego wdrażania

Należy stosować następujące najlepsze praktyki ciągłego wdrażania: wdrażać często (małe partie zmniejszają ryzyko), używać przełączników funkcji, aby oddzielić wdrożenie od udostępnienia funkcji, zautomatyzować wszystkie bramki jakości przed wdrożeniem na produkcję, korzystać ze środowiska staging podobnego do produkcyjnego, aby różnice nie maskowały błędów, monitorować okna wdrożeń za pomocą automatycznych kontroli kondycji oraz zawsze mieć przetestowany plan wycofania wdrożenia. Dojrzały potok CD sprawia, że wdrożenie staje się rutynową czynnością, a nie operacją wywołującą duży stres.

Szybki sprawdzian

Proszę sprawdzić swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

Podsumowanie lekcji

W tej lekcji nauczyli się Państwo, że: wielostagowe potoki YAML łączą etapy Build, Staging i Production, przekazując artefakty, zadania wdrażania ze środowiskami umożliwiają stosowanie bramek zatwierdzania i śledzenie wdrożeń, a testy dymne po wdrożeniu na środowisko staging zapobiegają przedostawaniu się wadliwych wydań na produkcję. W następnej części omówimy GitHub Actions na platformie Azure.

Często zadawane pytania

Czy lekcja „Ciągłe wdrażanie na platformie Azure” jest bezpłatna?

Tak — pełny tekst „Ciągłe wdrażanie na platformie Azure” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Azure Fundamentals, przejdź na CoddyKit PRO. Kurs Azure Fundamentals zawiera 4 lekcji w sumie.

Co nauczysz się w „Ciągłe wdrażanie na platformie Azure”?

Rozszerz potok o etap wdrażania, który przesyła artefakt kompilacji do slotu App Service, wykonuje testy dymne i po zatwierdzeniu zamienia go na środowisko produkcyjne. Ćwiczysz Azure Fundamentals z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Azure Fundamentals?

Nie wymagamy żadnego doświadczenia. Azure Fundamentals w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Ciągłe wdrażanie na platformie Azure”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Azure Fundamentals?

Tak. Każda lekcja Azure Fundamentals zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Przegląd usług Azure DevOps
Budowanie potoku CI za pomocą Azure Pipelines
Ciągłe wdrażanie na platformie Azure
GitHub Actions na platformie Azure

← Powrót do Azure Fundamentals