النشر المستمر إلى 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 يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- نظرة عامة على Azure DevOps Services
- إنشاء مسار CI باستخدام Azure Pipelines
- النشر المستمر إلى Azure
- GitHub Actions على Azure