0Pricing
Cloud & IT Cert Prep · درس

النشر المستمر إلى Azure

وسّع المسار بمرحلة نشر تدفع عنصر البناء إلى فتحة App Service، وتجري اختبارات الدخان، ثم تبدّل إلى الإنتاج بعد الموافقة.

النشر المستمر إلى Azure درس مجاني في Cloud & IT Cert Prep على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Cloud & IT Cert Prep، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.

ما هو النشر المستمر؟

يقوم النشر المستمر (CD) تلقائياً بإصدار كل تغيير يجتاز اختبارات CI إلى بيئة الإنتاج من دون تدخل يدوي. أما التسليم المستمر فهو الإصدار الأقل تشدداً — إذ يعمل على أتمتة النشر حتى بيئة التجهيز، ويتطلب بوابة موافقة بشرية قبل الوصول إلى بيئة الإنتاج. وتستند الممارستان كلتاهما إلى البنية الأساسية نفسها لخط الأنابيب. وفي Azure Pipelines، يُنفَّذ CD بإضافة مراحل للنشر بعد مرحلة CI، مع استهداف بيئات Azure وإضافة بوابات الموافقة حسب الحاجة.

خط أنابيب متعدد المراحل: CI + CD

يتضمن خط أنابيب CI/CD مكتمل ثلاث مراحل على الأقل: Build (الترجمة البرمجية، والاختبار، ونشر artifact)، وDeploy to Staging (نشر artifact إلى فتحة غير مخصصة للإنتاج)، وDeploy to Production (تبديل الفتحة أو النشر بعد الموافقة). وتمرر المراحل artifact إلى المرحلة التالية عبر وحدة تخزين artifacts الخاصة بخط الأنابيب. وتشغّل مرحلة التجهيز اختبارات التكامل أو اختبارات الدخان تلقائياً، بينما تنتظر مرحلة الإنتاج الموافقة اليدوية قبل المتابعة.

# 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)، وتتتبع سجل النشر لكل بيئة، كما يجب أن تشير إلى Environments في 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 لإجراء swap لفتحة التجهيز إلى بيئة الإنتاج — وهو أسلوب النشر المفضل من دون توقف لخدمة 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'

بوابات موافقة البيئة

أضف بوابات الموافقة إلى Environments في 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

انشر التطبيقات الموجودة في حاويات إلى AKS باستخدام مهمة KubernetesManifest@0. تطبق هذه المهمة بيانات YAML التعريفية الخاصة بـ Kubernetes على العنقود، مع دعم مدمج لـ imagePullSecrets وعمليات نشر canary. اتصل بعنقود AKS باستخدام اتصال خدمة Kubernetes المُكوّن في Azure DevOps. وتستخدم المهمة الأمر 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.BuildId)) أو SHA لالتزام Git ($(Build.SourceVersion)) على صور الحاويات، حتى تتمكن دائماً من تتبع حاوية قيد التشغيل إلى مراجعة التعليمات البرمجية الدقيقة التي أنشأتها. تجنب استخدام وسم latest في الإنتاج — إذ يخزنه Kubernetes مؤقتاً، وقد لا يجلب الإصدار الجديد. خزّن وسم الصورة المحدد كمتغير لخط الأنابيب، وأدخله في بيانات Kubernetes التعريفية وقت النشر باستخدام envsubst أو 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'

استراتيجيات التراجع

حدّد استراتيجية للتراجع عن عمليات النشر في بيئة الإنتاج حتى تتمكن من التعافي سريعًا من إصدار غير صالح. في 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 — فإذا ارتفعت معدلات الأخطاء بعد النشر، فأوقف تقدم المسار وشغّل التراجع. أرسل إشعارات النشر إلى Microsoft Teams أو Slack عبر مهام webhook حتى يعرف الفريق موعد اكتمال النشر والإصدار النشط حاليًا.

# 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 متعددة المراحل تربط بين مراحل الإنشاء والتدريج والإنتاج مع تمرير العناصر الاصطناعية، وأن مهام النشر مع Environments تتيح بوابات الموافقة وتتبع عمليات النشر، وأن اختبارات الدخان بعد النشر في بيئة التدريج تمنع وصول الإصدارات المعطّلة إلى بيئة الإنتاج. ننتقل بعد ذلك إلى استكشاف GitHub Actions على Azure.

الأسئلة الشائعة

هل درس «النشر المستمر إلى Azure» مجاني؟

نعم — نص درس «النشر المستمر إلى Azure» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Cloud & IT Cert Prep، انتقل إلى CoddyKit PRO. تتضمن دورة Cloud & IT Cert Prep 4 دروس في المجموع.

ماذا ستتعلم في «النشر المستمر إلى Azure»؟

وسّع المسار بمرحلة نشر تدفع عنصر البناء إلى فتحة App Service، وتجري اختبارات الدخان، ثم تبدّل إلى الإنتاج بعد الموافقة. تتمرن على Cloud & IT Cert Prep مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Cloud & IT Cert Prep؟

لا تُشترط خبرة سابقة. Cloud & IT Cert Prep على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.

كم من الوقت يستغرق درس «النشر المستمر إلى Azure»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Cloud & IT Cert Prep هذا؟

نعم. كل درس في Cloud & IT Cert Prep يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. نظرة عامة على Azure DevOps Services
  2. إنشاء مسار CI باستخدام Azure Pipelines
  3. النشر المستمر إلى Azure
  4. GitHub Actions على Azure
← العودة إلى Cloud & IT Cert Prep