CI/CD بالطريقة الصحيحة: خطوط أنابيب Azure DevOps وGitHub Actions لـ .NET وFlutter

خط الأنابيب الجيد غير مرئي: يدفع المهندسون الكود، وتعمل الاختبارات، وتتحدث بيئة التجريب خلال دقائق، ويصبح إصدار الإنتاج ضغطة زر مع مسار تراجع. أما خط الأنابيب السيئ فطقس ليلة الجمعة. إليك المخطط الذي نركّبه في كل مشروع — على Azure DevOps أو GitHub Actions، أيهما تستخدم مؤسستك.

المراحل الخمس

1. البناء — استعادة الحزم، الترجمة، وإنتاج أداة بإصدار محدد مرة واحدة. لا تُعِد البناء لمرحلة لاحقة أبدًا.
2. الاختبار — اختبارات الوحدات والتكامل مع التغطية؛ فشل سريع.
3. الفحص — تحليل ساكن (SonarQube)، فحص ثغرات التبعيات، وكشف الأسرار.
4. النشر إلى التجريب — تلقائي على main، مع اختبارات دخان وترحيلات قاعدة البيانات.
5. الترقية إلى الإنتاج — موافقة يدوية، نشر أزرق/أخضر أو تبديل فتحات، وتراجع تلقائي عند فشل فحوص الصحة.

واجهة .NET على GitHub Actions

# .github/workflows/api.yml — build, test, deploy a .NET API to Azure
name: api
on: { push: { branches: [main] } }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with: { dotnet-version: '9.0.x' }
      - run: dotnet restore
      - run: dotnet build --no-restore -c Release
      - run: dotnet test --no-build -c Release --collect:"XPlat Code Coverage"
      - run: dotnet publish src/Api -c Release -o out
      - uses: azure/webapps-deploy@v3
        with:
          app-name: ishtar-api-prod
          slot-name: staging
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
          package: out

النشر إلى فتحة تجريب ثم التبديل هو التفصيل الجوهري: تُسخَّن النسخة الجديدة، وتنجح فحوص الصحة، ويكون التبديل لحظيًا وقابلًا للتراجع.

تطبيق Flutter على Azure DevOps

تضيف خطوط أنابيب الهاتف التوقيع والتسليم إلى المتاجر. نحتفظ بالأسرار (مخازن المفاتيح، الشهادات، مفاتيح API) في الملفات الآمنة ومجموعات المتغيرات لخط الأنابيب — لا في المستودع أبدًا — ونحقن إعدادات البيئة عبر --dart-define.

# azure-pipelines.yml — Flutter app build stage
stages:
- stage: Build
  jobs:
  - job: Android
    pool: { vmImage: 'ubuntu-latest' }
    steps:
    - task: FlutterInstall@0
    - script: flutter pub get && flutter test
    - script: flutter build appbundle --release --dart-define=ENV=prod
    - publish: build/app/outputs/bundle/release/app-release.aab
      artifact: android

مرحلة ثانية ترفع الحزمة إلى المسار الداخلي في Google Play وملف IPA إلى TestFlight، فيتلقى المختبرون كل تغيير مدمج تلقائيًا.

البنية التحتية ككود

تُعرَّف البيئات في Terraform (أو Bicep على Azure) وتُطبَّق بخطوط الأنابيب نفسها. بيئة جديدة — عرض توضيحي لعميل محتمل، أو منطقة لسوق جديد — طلب دمج، لا أسبوع من النقر.

ممارسات تصنع الفرق

• التطوير على الفرع الرئيسي مع فروع قصيرة العمر ومراجعات إلزامية.
• الإصدار الدلالي مختوم في الأداة ومعروض في شاشة «حول» في التطبيق.
• ترحيلات قاعدة البيانات في خط الأنابيب، تُنفَّذ قبل تبديل التطبيق، ومتوافقة عكسيًا لإصدار واحد.
• أعلام الميزات ليكون النشر والإطلاق قرارين منفصلين.
• بوابات المراقبة — لا يُعد النشر «مكتملًا» حتى تستقر معدلات الأخطاء وزمن الاستجابة عشر دقائق.

النتيجة

الفرق التي نجهّزها بهذه الطريقة تشحن إلى الإنتاج عدة مرات في الأسبوع بحوادث أقل من الفرق التي تشحن شهريًا. خط الأنابيب ليس عبئًا — إنه أسرع ميزة ستبنيها في حياتك.

جميع المقالات