Azure Fundamentals · पाठ

Azure पर सतत परिनियोजन

परिनियोजन चरण जोड़कर पाइपलाइन का विस्तार करें, जो बिल्ड आर्टिफैक्ट को App Service स्लॉट में भेजे, स्मोक परीक्षण चलाए और अनुमोदन मिलने पर उसे प्रोडक्शन में स्वैप करे।

पाठ 3, कुल 4 में से13 चरण

Azure पर सतत परिनियोजन, CoddyKit पर Azure Fundamentals का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Azure Fundamentals सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

सतत परिनियोजन क्या है

सतत परिनियोजन (CD) CI परीक्षणों में सफल होने वाले हर बदलाव को बिना मैन्युअल हस्तक्षेप के अपने-आप प्रोडक्शन में रिलीज़ करता है। सतत डिलीवरी इसका अपेक्षाकृत नरम रूप है — यह स्टेजिंग पर्यावरण तक परिनियोजन को स्वचालित करता है और प्रोडक्शन से पहले मानवीय अनुमोदन द्वार की आवश्यकता रखता है। दोनों प्रक्रियाएँ एक ही Pipeline आधारभूत संरचना पर बनी हैं। Azure Pipelines में CD को CI चरण के बाद परिनियोजन के चरण जोड़कर लागू किया जाता है, जो आवश्यकतानुसार अनुमोदन द्वार वाले Azure पर्यावरणों को लक्षित करते हैं।

बहु-चरण Pipeline: CI + CD

एक पूर्ण CI/CD Pipeline में कम से कम तीन चरण होते हैं: Build (कम्पाइल, परीक्षण, आर्टिफैक्ट प्रकाशित करना), स्टेजिंग में परिनियोजन (आर्टिफैक्ट को गैर-प्रोडक्शन स्लॉट में परिनियोजित करना) और प्रोडक्शन में परिनियोजन (स्लॉट बदलना या अनुमोदन के बाद परिनियोजित करना)। चरण, Pipeline आर्टिफैक्ट संग्रहण के माध्यम से आर्टिफैक्ट को आगे भेजते हैं। स्टेजिंग चरण एकीकरण या Smoke परीक्षण अपने-आप चलाता है; प्रोडक्शन चरण आगे बढ़ने से पहले मैन्युअल अनुमोदन की प्रतीक्षा करता है।

# 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 के पर्यावरण का संदर्भ देना आवश्यक बनाते हैं। कोई पर्यावरण यह दर्ज करता है कि उसमें किन 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 कार्य किसी वेब एप्लिकेशन को 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 Pipeline में Smoke परीक्षण

स्टेजिंग में परिनियोजन के बाद Smoke परीक्षण चलाएँ — ये परीक्षणों का न्यूनतम समूह होते हैं, जो यह सत्यापित करते हैं कि परिनियोजन सफल रहा और एप्लिकेशन सही ढंग से प्रतिक्रिया दे रहा है। Smoke परीक्षण आम तौर पर मुख्य API एंडपॉइंट को कॉल करते हैं और अपेक्षित स्थिति कोड तथा प्रतिक्रिया सामग्री की जाँच करते हैं। यदि Smoke परीक्षण विफल होते हैं, तो प्रोडक्शन में स्वैप करने या अनुमोदन माँगने से पहले Pipeline रुक जाती है, जिससे खराब रिलीज़ उपयोगकर्ताओं तक पहुँचने से बचती है।

# 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 जोड़ें — उन उपयोगकर्ताओं या समूहों को निर्दिष्ट करें जिन्हें अनुमोदन देना है। जब 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

इमेज टैगिंग रणनीति

कंटेनर इमेज को Build ID ($(Build.BuildId)) या Git कमिट SHA ($(Build.SourceVersion)) से टैग करें, ताकि आप चल रहे कंटेनर को उस सटीक कोड संशोधन तक हमेशा ट्रेस कर सकें जिससे वह बनाया गया था। प्रोडक्शन में 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'

रोलबैक रणनीतियाँ

Production deployments के लिए रोलबैक रणनीति निर्धारित करें, ताकि खराब release से जल्दी उबर सकें। App Service में रोलबैक का अर्थ है production slot को पिछले staging version पर वापस स्वैप करना। AKS के लिए kubectl rollout undo का उपयोग करें। एक समर्पित रोलबैक pipeline बनाएँ या ऐसा manual रोलबैक job जोड़ें जिसे Azure DevOps portal से शुरू किया जा सके। रोलबैक प्रक्रिया का दस्तावेज़ बनाएँ और नियमित रूप से उसका अभ्यास करें — जिस रोलबैक का परीक्षण न किया गया हो, वह वास्तव में रोलबैक नहीं है।

# 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

Deployment सूचनाएँ और निगरानी

हर production deployment के बाद, नए version के स्वस्थ होने की पुष्टि करने के लिए स्वचालित रूप से monitoring जाँच चलाएँ। Azure Monitor metrics से जानकारी लेने के लिए AzureMonitor@1 pipeline जाँच का उपयोग करें — यदि deployment के बाद error rates बढ़ी हुई हों, तो pipeline की आगे की प्रगति रोक दें और रोलबैक शुरू करें। webhook tasks के माध्यम से deployment सूचनाएँ Microsoft Teams या Slack पर भेजें, ताकि team को पता रहे कि deployment कब पूरा हुआ और कौन-सा version सक्रिय है।

# 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 की सर्वोत्तम कार्यप्रणालियाँ

निरंतर deployment की इन सर्वोत्तम कार्यप्रणालियों का पालन करें: बार-बार deploy करें (छोटे batches जोखिम कम करते हैं), deployment और release को अलग रखने के लिए feature flags का उपयोग करें, production से पहले सभी quality gates को स्वचालित करें, अंतर के कारण bugs छिप न जाएँ इसलिए production-जैसा staging environment बनाएँ, स्वचालित health checks से deployment windows की निगरानी करें, और हमेशा परीक्षित रोलबैक योजना रखें। एक परिपक्व CD pipeline deployment को अत्यधिक तनावपूर्ण operation के बजाय ऐसी सामान्य प्रक्रिया बना देती है जिस पर विशेष ध्यान नहीं जाता।

त्वरित जाँच

इस lesson में Microsoft Azure Fundamentals (AZ-900) की अवधारणाओं की अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

Lesson का पुनरावलोकन

इस lesson में आपने सीखा: multi-stage YAML pipelines, artifact passing के साथ Build, Staging और Production stages को जोड़ती हैं; Environments वाले deployment jobs approval gates और deployment tracking सक्षम करते हैं; और staging deployment के बाद किए गए smoke tests, खराब releases को production तक पहुँचने से रोकते हैं। अब हम Azure पर GitHub Actions का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Azure Fundamentals सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 30
पाठ: 120

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “Azure पर सतत परिनियोजन” पाठ निःशुल्क है?

हाँ—“Azure पर सतत परिनियोजन” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Azure Fundamentals पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“Azure पर सतत परिनियोजन” में मैं क्या सीखूँगा?

परिनियोजन चरण जोड़कर पाइपलाइन का विस्तार करें, जो बिल्ड आर्टिफैक्ट को App Service स्लॉट में भेजे, स्मोक परीक्षण चलाए और अनुमोदन मिलने पर उसे प्रोडक्शन में स्वैप करे। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Azure Fundamentals का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Azure Fundamentals शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Azure Fundamentals शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।

“Azure पर सतत परिनियोजन” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Azure Fundamentals पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Azure Fundamentals पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← Azure Fundamentals पर वापस जाएँ