CI/CD والنشر على متاجر التطبيقات

مقدمة إلى مفاهيم CI/CD لتطبيقات الجوال

16 دقيقة الدرس 5 من 12

مقدمة إلى مفاهيم CI/CD لتطبيقات الجوال

التكامل المستمر (CI) والتسليم المستمر (CD) هما ممارستان هندسيتان تُؤتمتان الرحلة من كوميت المطور إلى إصدار الإنتاج. بالنسبة لتطبيقات الجوال — حيث يمر كل إصدار بمراجعة متجر المنصة — لا يعدّ CI/CD رفاهية؛ بل هو شبكة أمان تكتشف التراجعات مبكراً، وتفرض بوابات جودة الكود، وتقضي على الخطوات اليدوية المعرضة للخطأ.

في مشروع Flutter، يربط CI/CD سير عملك التطويري المحلي بمتجر App Store وGoogle Play، ويتولى كل شيء من تشغيل flutter analyze على كل طلب سحب إلى رفع ملف .aab موقع تلقائياً إلى Play Store بعد الدمج في فرع main.

ملاحظة: CI وCD متمايزان لكنهما متكاملان. CI يتحقق من أن الكود الجديد يتكامل بنظافة مع قاعدة الكود الموجودة (فحص، اختبار، بناء). CD يأخذ البناء الذي تم التحقق منه ويسلمه إلى المستخدمين النهائيين أو المختبرين، إما بشكل مستمر (كل بناء أخضر) أو عند الطلب. يشكلان معاً خط أنابيب.

لماذا يهم CI/CD في Flutter

إصدار تطبيق Flutter بدون أتمتة عملية بطيئة وهشة. يجب على المطور تشغيل الاختبارات يدوياً، وبناء متغيرات الإصدار لكل من iOS وAndroid، وتوقيع كل ملف ثنائي بالشهادة والمخزن الصحيحين، ثم الرفع إلى TestFlight وPlay Console. تجاوز أي خطوة — أو تشغيلها من الجهاز الخطأ — يمكن أن يكسر إصداراً أو يشحن كوداً غير موقع.

الاتساق: يعمل خط الأنابيب في بيئة نظيفة وقابلة للتكرار على كل كوميت، مما يزيل مفاجآت "يعمل على جهازي".
السرعة: تصل ردود الفعل على الكود المكسور في دقائق لا ساعات، مما يبقى الإصلاحات صغيرة وغير مكلفة.
الأمان: كل ملف بناء يُنشأ من كوميت معروف، موقع بهوية خاضعة للرقابة، وقابل للمراجعة — وليس مجمعاً على حاسوب شخص ما.
الثقة: يمكن للفرق الإصدار بشكل أكثر تواتراً لأن كل إصدار يتم التحقق منه تلقائياً.

مراحل خط الأنابيب الخمس

يشغّل خط أنابيب Flutter CI/CD في الإنتاج عادةً خمس مراحل متسلسلة. كل مرحلة هي بوابة: إذا فشلت، يتوقف خط الأنابيب ولا تعمل المراحل التالية.

المرحلة 1 — الفحص (Lint)

يبدأ خط الأنابيب بالتحليل الساكن. يكتشف flutter analyze أخطاء الأنواع، وواجهات برمجة التطبيقات المهجورة، والاستيرادات غير المستخدمة، وانتهاكات الأسلوب المحددة في analysis_options.yaml. الفحص رخيص وسريع — عادةً أقل من 30 ثانية — لذا يعمل كمرشح أول، يرفض الكود المكسور بوضوح قبل حدوث أي تجميع.

مرحلة الفحص (مقتطف YAML من GitHub Actions)

- name: Lint
  run: |
    flutter pub get
    flutter analyze --fatal-infos --fatal-warnings

المرحلة 2 — الاختبار (Test)

تعمل اختبارات الوحدة واختبارات الودجت واختبارات التكامل بعد ذلك. مجموعة سريعة من اختبارات الوحدة والودجت تعمل على كل كوميت؛ يمكن تقييد الاختبارات الأثقل (التي قد تحتاج جهازاً أو محاكياً) لدمج طلبات السحب. الحد الأدنى هو تغطية كاملة للوحدات والودجات قبل محاولة أي بناء.

مرحلة الاختبار

- name: Run tests
  run: flutter test --coverage

- name: Upload coverage
  uses: codecov/codecov-action@v4
  with:
    files: coverage/lcov.info

المرحلة 3 — البناء (Build)

بمجرد أن يكون الكود نظيفاً والاختبارات ناجحة، يُجمّع خط الأنابيب ملفات الإصدار. بالنسبة لـ Android هذا يعني flutter build appbundle --release؛ بالنسبة لـ iOS يعني flutter build ipa --release. تُحقن إعدادات البناء (النكهة، مفاتيح dart-define، أرقام الإصدار) عبر متغيرات البيئة — ولا تُكتب مباشرة في ملف خط الأنابيب.

المرحلة 4 — التوقيع (Sign)

يجب توقيع ملفات الإصدار تشفيرياً قبل التوزيع. بالنسبة لـ Android، يُخزن المخزن وكلمات مروره كـأسرار CI ويُشار إليها وقت البناء. بالنسبة لـ iOS، يُخزن ملف تعريف التوفير والشهادة في سلسلة مفاتيح CI أو يُدار بواسطة أداة مثل Fastlane Match. يجب أن يحدث التوقيع داخل بيئة CI — وليس في سلسلة المفاتيح الشخصية للمطور.

تحذير: لا تُرسل مخازن المفاتيح أو شهادات .p12 أو ملفات تعريف التوفير إلى مستودعك أبداً. خزّنها كأسرار CI مشفرة (أسرار GitHub Actions، متغيرات GitLab CI/CD، إلخ) وحقنها في وقت التشغيل. يمكن لمخزن مفاتيح مسرّب أن يُستخدم لنشر تحديثات ضارة لتطبيقك.

المرحلة 5 — التوزيع (Distribute)

يُرفع البناء الموقع إلى هدف توزيع: Firebase App Distribution أو TestFlight للمختبرين الداخليين، وPlay Store / App Store Connect للإنتاج. تُؤتمت أدوات مثل Fastlane أو أدوات CLI الرسمية (bundletool، altool) خطوة الرفع.

استراتيجيات الفروع ومحفزات خط الأنابيب

لا تحتاج كل فرع إلى خط الأنابيب الكامل. تربط استراتيجية شائعة أسماء الفروع بعمق خط الأنابيب:

فروع الميزات: تشغيل الفحص والاختبارات فقط — ردود فعل سريعة بدون تكلفة بناء.
طلبات السحب إلى develop: الفحص، الاختبار، وبناء تصحيح — يضمن أن طلب السحب يُجمَّع على الفرع الهدف.
الدمج في develop: خط أنابيب كامل بما في ذلك بناء موقع يُوزع على المختبرين الداخليين عبر Firebase App Distribution.
الدمج في main / العلامات: خط أنابيب كامل ببناء موقع للإنتاج يُرفع لمراجعة المتجر.

نصيحة: استخدم علامات Git (مثل v1.2.3) لتشغيل إصدارات المتجر. هذا يفصل قرار الإصدار عن حدث الدمج ويمنحك مساراً تدقيقياً واضحاً لما نُشر بالضبط في الإنتاج.

أدوات CI/CD الرئيسية لـ Flutter

تُستخدم عدة منصات وأدوات بشكل شائع في خطوط أنابيب Flutter:

GitHub Actions: مجاني للمستودعات العامة، متكامل بإحكام مع طلبات سحب GitHub، نظام بيئي واسع من إجراءات السوق. الخيار الأكثر استخداماً لمشاريع Flutter.
Codemagic: منصة CI أولى لـ Flutter مع توقيع iOS مدمج، إدارة توقيع الكود، ونشر بنقرة واحدة على App Store / Play Store.
Fastlane: مجموعة أدوات أتمتة مبنية على Ruby مع مسارات للبناء والتوقيع والاختبار والنشر. تعمل مع أي منصة CI وهي قوية بشكل خاص لتعقيد توقيع iOS.
GitLab CI: مفضلة في البيئات المستضافة ذاتياً أو المؤسسية؛ مفاهيم خط أنابيب مطابقة، مخطط YAML مختلف.
Bitrise: CI أولى للجوال مع محرر سير عمل بصري؛ يتعامل مع خطوات Flutter والأصلية معاً.

الخلاصة

يحوّل CI/CD إصدارات Flutter من احتفالية يدوية محفوفة بالمخاطر إلى عملية آلية وقابلة للتكرار. يعمل خط الأنابيب ذو المراحل الخمس — الفحص → الاختبار → البناء → التوقيع → التوزيع — كسلسلة من بوابات الجودة. تتحكم استراتيجيات الفروع في المراحل التي تعمل ومتى، موازنةً بين ردود الفعل السريعة على فروع الميزات والتحقق الشامل قبل الإنتاج. تخزين أوراق اعتماد التوقيع كأسرار مشفرة — وليس في المستودع أبداً — هو شرط أمني غير قابل للتفاوض. مع وجود خط أنابيب سليم، يمكن لفريقك الشحن بثقة، مع العلم أن كل ملف إصدار قد بُني واختُبر ووُقِّع في بيئة خاضعة للرقابة وقابلة للمراجعة.

النقطة الرئيسية: CI/CD ليس أداة واحدة — بل هو انضباط. الهدف هو جعل كل خطوة من الكوميت إلى الإصدار آلية وقابلة للمراجعة وقابلة للتكرار. بالنسبة لـ Flutter تحديداً، أكبر المكاسب هي اكتشاف أخطاء التحليل قبل المراجعة، وتشغيل الاختبارات على كل كوميت، وأتمتة خطوات التوقيع والتوزيع المعقدة التي يسهل الخطأ فيها يدوياً.