Cloud & IT Cert Prep · درس

سير عمل المطوّر من البداية إلى النهاية

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

دورة عمل المطور الحديثة في Azure

يربط سير عمل المطور الحديث في Azure بين التحكم بالمصدر، والتكامل والنشر المستمرين CI/CD، والبنية الأساسية للحاويات، وقابلية الرصد ضمن حلقة داخلية سلسة تبدأ من إرسال التعليمات البرمجية وتصل إلى بيئة إنتاج يمكن رصدها. وتشمل المكونات الأساسية: GitHub (المصدر)، وGitHub Actions (مسار البناء والنشر)، وAzure Container Registry (مخزن الصور)، وAzure Container Apps (بيئة التشغيل)، وApplication Insights (قابلية الرصد). ينتقل كل تغيير تلقائيًا من حاسوب المطور إلى الإنتاج خلال دقائق، مع وجود بوابات جودة في كل خطوة.

الخطوة 1: التحكم بالمصدر واستراتيجية الفروع

نظّم التعليمات البرمجية في مستودع GitHub باستخدام استراتيجية التطوير المستند إلى الفرع الرئيسي أو استراتيجية تفريع GitFlow. بالنسبة إلى معظم الخدمات المصغّرة، يقلل التطوير المستند إلى الفرع الرئيسي (فروع ميزات قصيرة العمر تُدمج يوميًا في main) من تعارضات التكامل ويحافظ على بساطة المسار. استخدم قواعد حماية الفروع على main لطلب مراجعات طلبات السحب واجتياز فحوصات CI قبل الدمج. ويضمن ملف CODEOWNERS أن التغييرات التي تطرأ على الخدمات المهمة تتطلب موافقة كبار المهندسين في الفريق المعني.

# Example .github/CODEOWNERS
# Require payments-team review for any changes under /src/payments/
/src/payments/ @payments-team
/infrastructure/   @platform-team

الخطوة 2: التكامل المستمر باستخدام GitHub Actions

يعمل مسار CI مع كل طلب سحب. ومن سير العمل المعتاد: سحب التعليمات البرمجية ← استعادة التبعيات ← تشغيل اختبارات الوحدة ← تشغيل اختبارات التكامل ← بناء صورة Docker ← دفعها إلى Azure Container Registry. تُوسَم الصورة باستخدام SHA لالتزام git لتسهيل التتبّع. استخدم المصادقة المستندة إلى OIDC من GitHub Actions إلى Azure (عبر هوية موحّدة) لتجنب تخزين أسرار أساسيات خدمة Azure في GitHub — وهي مكافئ للهوية المُدارة لمسارات CI.

# .github/workflows/ci.yml (abbreviated)
name: CI
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to ACR
        uses: azure/docker-login@v1
        with:
          login-server: myacr.azurecr.io
          username: ${{ secrets.AZURE_CLIENT_ID }}
          password: ${{ secrets.AZURE_CLIENT_SECRET }}
      - name: Build and push image
        run: |
          docker build -t myacr.azurecr.io/myapi:${{ github.sha }} .
          docker push myacr.azurecr.io/myapi:${{ github.sha }}

الخطوة 3: النشر المستمر إلى بيئة الاختبار

بعد نجاح مسار CI عند الدمج في main، ينشر مسار CD تلقائيًا إلى بيئة الاختبار. يحدّث المسار وسم صورة Container App إلى SHA الذي بُني حديثًا، وينتظر حتى تصبح المراجعة الجديدة سليمة، ثم يشغّل اختبارات الدخان مقابل عنوان URL لبيئة الاختبار. تتحقق اختبارات الدخان من أن نقاط نهاية API المهمة تُرجع الاستجابات المتوقعة. وإذا فشلت اختبارات الدخان، يتراجع المسار عن النشر بتحويل حركة الإدخال مرة أخرى إلى المراجعة السابقة من دون أي تدخل يدوي.

# CD stage: update Container App to new image
- name: Deploy to staging
  uses: azure/cli@v2
  with:
    azcliversion: latest
    inlineScript: |
      az containerapp update \
        --name myapi-staging \
        --resource-group myRG \
        --image myacr.azurecr.io/myapi:${{ github.sha }}

- name: Run smoke tests
  run: |
    STAGING_URL=$(az containerapp show --name myapi-staging \
      --resource-group myRG \
      --query 'properties.configuration.ingress.fqdn' -o tsv)
    curl -f https://$STAGING_URL/health || exit 1

الخطوة 4: بوابة الموافقة على الإنتاج

بعد التحقق من بيئة الاختبار، يتوقف مسار CD عند بوابة موافقة. تتيح حماية البيئات في GitHub Actions تكوين مراجعين مطلوبين لبيئة production. يرسل المسار إشعارًا إلى مهندس المناوبة عبر Slack، فيراجع نتائج اختبارات بيئة الاختبار، والفروقات، وأي حوادث مفتوحة قبل الموافقة. ولا يتابع المسار نشر صورة SHA نفسها إلى الإنتاج إلا بعد الموافقة. وتُعد هذه الخطوة التي تتضمن تدخلًا بشريًا مهمةً للخدمات ذات الزيارات المرتفعة أو الخاضعة للضوابط التنظيمية.

# In GitHub: create 'production' environment with required reviewers
# .github/workflows/cd.yml (abbreviated)
jobs:
  deploy-production:
    environment:
      name: production
      url: https://myapi.contoso.com
    needs: deploy-staging
    steps:
      - name: Deploy to production
        uses: azure/cli@v2
        with:
          inlineScript: |
            az containerapp update \
              --name myapi \
              --resource-group myRG \
              --image myacr.azurecr.io/myapi:${{ github.sha }}

الخطوة 5: قابلية الرصد في الإنتاج

بمجرد النشر إلى الإنتاج، توفّر Application Insights رؤيةً آنية. وتتتبع حزمة App Insights SDK (أو القياس التلقائي لبيئات التشغيل المدعومة): معدلات الطلبات، ومعدلات الفشل، وزمن الاستجابة (الإشارات الذهبية الثلاث)، واستدعاءات التبعيات (لقواعد البيانات وService Bus وواجهات API الأخرى)، والاستثناءات مع تتبعات المكدس الكاملة. وتعرض خريطة التطبيق بصريًا كيفية استدعاء الخدمات بعضها بعضًا، وتبرز التبعيات الأكثر مساهمة في حالات الفشل أو زيادة زمن الاستجابة.

# Python: Add Application Insights SDK
from opencensus.ext.azure.log_exporter import AzureLogHandler
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer

tracer = Tracer(
  exporter=AzureExporter(connection_string='InstrumentationKey=<key>'),
  sampler=ProbabilitySampler(1.0)
)

ربط عمليات النشر بالتتبعات

استخدم Application Insights Annotations لتمييز أحداث النشر في مخططات المقاييس. عند إنشاء تعليق توضيحي لإصدار (من خلال إجراء GitHub Actions azure/appinsights-annotation)، يظهر كخط عمودي في جميع مخططات مقاييس App Insights. ويوضح ذلك فورًا ما إذا كانت زيادة مفاجئة في زمن الاستجابة أو معدل الأخطاء مرتبطة بنشر حديث، ما يقلل بدرجة كبيرة متوسط الوقت اللازم لتشخيص المشكلة (MTTD) أثناء الحوادث.

# Create a release annotation in Application Insights
- name: Annotate release in App Insights
  uses: azure/appinsights-annotation@v1
  with:
    appInsightsResourceName: myAppInsights
    resourceGroupName: myRG
    releaseName: '${{ github.run_id }}-${{ github.sha }}'

التراجع التلقائي عند ارتفاع معدل الأخطاء

لإنشاء أكثر المسارات مرونة، طبّق التراجع التلقائي. بعد النشر إلى الإنتاج، ينتظر المسار 10 دقائق ثم يستعلم من Application Insights عن معدل الأخطاء. وإذا تجاوز معدل الأخطاء حدًا قابلًا للتهيئة (مثلًا، >5%)، يتراجع المسار تلقائيًا عن النشر بتحديث حركة إدخال Container App لتوجيه 100% منها إلى المراجعة السابقة. يقلل نمط النشر التدريجي هذا من نطاق تأثير النشر السيئ، ويتيح للفرق النشر بثقة حتى عند إجراء تغييرات معقدة أو حساسة.

# Query App Insights error rate via REST (abbreviated)
QUERY='requests | where timestamp > ago(10m) | summarize failed = countif(success == false), total = count() | extend errorRate = round(100.0 * failed / total, 2)'
RESULT=$(az monitor app-insights query \
  --apps myAppInsights \
  --resource-group myRG \
  --analytics-query "$QUERY" \
  --query 'tables[0].rows[0][2]' -o tsv)
if [ $(echo '$RESULT > 5' | bc -l) -eq 1 ]; then
  echo 'Error rate $RESULT% - rolling back!'
  az containerapp ingress traffic set --name myapi --resource-group myRG --revision-weight stable=100
fi

إنتاجية المطور: التطوير المحلي باستخدام المحاكيات

ينبغي أن يتمكن المطورون من تشغيل المجموعة الكاملة واختبارها محليًا من دون الاتصال بموارد Azure الإنتاجية. استخدم Azure Storage Emulator (Azurite) لتخزين الكائنات الثنائية وقوائم الانتظار محليًا، وCosmos DB Emulator لاختبار قواعد البيانات محليًا، وService Bus Emulator للمراسلة المحلية. ويمكن لمتغير البيئة AZURE_ENVIRONMENT=local تبديل DefaultAzureCredential لاستخدام سلاسل اتصال تشير إلى المحاكيات، بينما تستخدم التعليمات البرمجية نفسها الهوية المُدارة في Azure. ويتولى Docker Compose تنسيق جميع التبعيات المحلية من خلال أمر docker compose up واحد.

# docker-compose.yml for local development
services:
  azurite:
    image: mcr.microsoft.com/azure-storage/azurite
    ports:
      - '10000:10000'
      - '10001:10001'
  cosmos-emulator:
    image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator
    ports:
      - '8081:8081'

الأمان في سير عمل المطور

ادمج الأمان في كل مرحلة من مراحل سير عمل المطور: يفحص Dependabot التبعيات بحثًا عن الثغرات الأمنية في طلبات السحب؛ وتكتشف GitHub Advanced Security (فحص التعليمات البرمجية باستخدام CodeQL) ثغرات مثل حقن SQL والأسرار المضمّنة في التعليمات البرمجية؛ ويتكامل Microsoft Defender for DevOps مع GitHub لعرض توصيات أمان Azure إلى جانب تغييرات التعليمات البرمجية؛ ويفحص فحص الثغرات الأمنية في ACR Defender صور الحاويات بحثًا عن ثغرات CVE في نظام التشغيل وطبقة التطبيق بعد كل عملية دفع. وتظهر نتائج الأمان في صورة تعليقات على طلبات السحب، بحيث تُعالج قبل الدمج.

جمع كل العناصر معًا

سير عمل المطور الكامل هو حلقة ملاحظات مستمرة: يرسل المطور التعليمات البرمجية، ثم يبني CI صورة الحاوية ويختبرها، وتُدفع الصورة إلى ACR مع استخدام SHA الالتزام وسمًا لها، وينشر CD إلى بيئة الاختبار ويشغّل اختبارات الدخان، ويوافق أحد الأشخاص على النشر إلى الإنتاج، ثم ينشر المسار إلى الإنتاج وينشئ تعليقًا توضيحيًا للإصدار، وتراقب Application Insights معدلات الأخطاء مع تنفيذ تراجع تلقائي إذا جرى تجاوز الحدود. ويضمن استخدام البنية الأساسية كتعليمة برمجية (Bicep أو Terraform) في المستودع نفسه أن تكون إعدادات المسار وContainer App والمراقبة جميعها خاضعة للتحكم بالإصدارات إلى جانب تعليمات التطبيق البرمجية.

تحقق سريع

اختبر مدى فهمك لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

مراجعة الدرس

تعلّمت في هذا الدرس أن سير عمل المطور من البداية إلى النهاية يربط بين التحكم بالمصدر في GitHub، وCI/CD في GitHub Actions، وAzure Container Registry، وContainer Apps، وApplication Insights، وأن التعليقات التوضيحية للإصدارات تربط بين عمليات النشر وتغيّرات المقاييس لتشخيص الحوادث بسرعة أكبر، وأن التراجع التلقائي المستند إلى استعلامات معدل الأخطاء يقلل نطاق تأثير عمليات النشر السيئة. في الخطوة التالية، ننتقل إلى التحضير للاختبار من خلال مراجعة شاملة لمفاهيم السحابة وبنية Azure.

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

هل درس «سير عمل المطوّر من البداية إلى النهاية» مجاني؟

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

ماذا ستتعلم في «سير عمل المطوّر من البداية إلى النهاية»؟

اربط GitHub Actions CI/CD وAzure Container Registry وContainer Apps وApplication Insights في حلقة داخلية متكاملة للمطوّر، بدءاً من الالتزام البرمجي ووصولاً إلى بيئة إنتاج قابلة للمراقبة تتمرن على Cloud & IT Cert Prep مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

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

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

كم من الوقت يستغرق درس «سير عمل المطوّر من البداية إلى النهاية»؟

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

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

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

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

← العودة إلى Cloud & IT Cert Prep