مقارنة GitHub Actions و GitLab CI للخلفية والويب والموبايل

المشاكل الشائعة في CI متعدد التطبيقات

عندما يبني مستودع واحد خلفية، تطبيق ويب، وتطبيقات موبايل، يتوقف CI عن أن يكون "فقط تشغيل اختبارات". يصبح مُنظّم مرور لحزم أدوات مختلفة، أوقات بناء مختلفة، وقواعد إصدار مختلفة.

الألم الأكثر شيوعًا بسيط: تغيير صغير واحد يُطلق كمية كبيرة من العمل. تعديل في الوثائق يبدّل توقيع iOS، أو تعديل في الخلفية يجبر على إعادة بناء الويب بالكامل، وفجأة كل مرج يصبح بطيئًا ومحفوفًا بالمخاطر.

في إعدادات متعددة التطبيقات تظهر بعض المشاكل مبكرًا:

• تباين الـ runner: إصدارات الـ SDK تختلف بين الآلات، لذلك تتصرف البنايات بشكل مختلف بين CI والمحلي.
• انتشار الأسرار: مفاتيح API، شهادات التوقيع، وبيانات المتاجر تتكرر عبر وظائف وبيئات.
• ارتباك الكاش: مفتاح كاش خاطئ يُنتج بناءات قديمة، لكن عدم وجود كاش يجعل كل شيء بطيئًا.
• قواعد إصدار مختلطة: الخلفيات تريد نشرات متكررة، بينما إصدارات الموبايل محجوزة وتحتاج فحوصًا إضافية.
• قابلية قراءة خط الأنابيب: التكوين يكبر إلى جدار من الوظائف لا يرغب أحد في لمسه.

لهذا السبب، الاختيار بين GitHub Actions وGitLab CI يصبح أكثر أهمية في المونوربو مقارنةً بمشاريع تطبيق واحد. تحتاج طرقًا واضحة لتقسيم العمل حسب المسار، مشاركة الآرتيفاكتس بأمان، ومنع الوظائف المتوازية من التداخل.

مقارنة عملية تختصر في أربعة أمور: إعداد وتوسيع الـ runners، تخزين وتحديد نطاق الأسرار، الكاش والآرتيفاكتس، ومدى سهولة التعبير عن "بناء ما تغيّر" بدون تحويل خط الأنابيب إلى حساء قواعد هش.

هذا الأمر يتعلق بالموثوقية وسهولة الصيانة اليومية، ليس بمنصة لها تكاملات أكثر أو واجهة أجمل. ولا يغني عن قرارات أدوات البناء الخاصة بك (Gradle، Xcode، Docker، إلخ). يساعدك فقط على اختيار CI الذي يجعل المحافظة على بنية نظيفة أسهل.

كيف تُنظّم GitHub Actions وGitLab CI

الفرق الأكبر هو كيف تنظّم كل منصة خطوط الأنابيب وإعادة الاستخدام، ويبدأ ذلك يهم عندما تشترك خلفية، ويب، وموبايل في نفس المستودع.

GitHub Actions يخزن الأتمتة في ملفات YAML تحت .github/workflows/. تُشغّل الـ workflows عند أحداث مثل push، pull request، جداول، أو تشغيل يدوي. GitLab CI يتمحور حول ملف .gitlab-ci.yml في جذر المستودع، مع ملفات قابلة للإدراج، وغالبًا تُشغّل الأنابيب عند pushes، merge requests، جداول، ووظائف يدوية.

GitLab مُصمّم حول المراحل. تحدد مراحل (build, test, deploy)، ثم تُعيّن وظائف للمراحل التي تعمل بالترتيب. GitHub Actions مبني حول workflows التي تحتوي على وظائف. الوظائف تعمل متوازية افتراضيًا، وتضيف تبعيات عندما يجب أن تنتظر وظيفة أخرى.

لتشغيل نفس المنطق عبر أهداف كثيرة، الـ matrix في GitHub مناسب طبيعيًا (iOS مقابل Android، إصدارات Node متعددة). GitLab يمكنه عمل fan-out مشابه باستخدام الوظائف المتوازية والمتغيرات، لكن غالبًا ستجد نفسك توصل قطعًا أكثر بنفسك.

إعادة الاستخدام تظهر بشكل مختلف أيضًا. في GitHub، الفرق عادة تميل لاستخدام reusable workflows وcomposite actions. في GitLab، إعادة الاستخدام غالبًا تأتي من include، قوالب مشتركة، وanchors/extends في YAML.

الموافقات والبيئات المحمية تختلف أيضًا. GitHub يستخدم عادة بيئات محمية مع مراجعين مطلوبين وسرّيات بيئية بحيث تتوقف نشرات الإنتاج حتى الموافقة. GitLab يدمج عادة الفروع/العلامات المحمية، البيئات المحمية، والوظائف اليدوية حتى يمكن لأدوار محددة فقط تشغيل النشر.

إعداد الـ runner وتنفيذ الوظائف

إعداد الـ runner هو المكان الذي تبدأ فيه المنصتان أن تشعرا مختلفتين في الاستخدام اليومي. كلاهما يمكنه تشغيل وظائف على hosted runners (لا تدير الآلة) أو self-hosted runners (تملك الآلة، التحديثات، والأمان). الـ hosted أبسط للبدء؛ الـ self-hosted غالبًا يُستخدم للسرعة، أدوات خاصة، أو الوصول لشبكات داخلية.

تقسيم عملي في كثير من الفرق هو: runners لينكس للخلفية والويب، وmacOS فقط عندما تحتاج لبناء iOS. Android يمكن تشغيله على لينكس، لكنه مُكلف لذا حجم الـ runner ومساحة القرص مهمة.

Hosted مقابل self-hosted: ما الذي تديره

الـ hosted مناسب عندما تريد إعدادًا متوقعًا بدون صيانة. الـ self-hosted منطقي عندما تحتاج إصدارات Java/Xcode محددة، كاشات أسرع، أو وصول داخلي.

إذا اخترت self-hosted، حدّد أدوار الـ runners مبكرًا. معظم المستودعات تعمل جيدًا مع مجموعة صغيرة: runner عام على لينكس للخلفية/الويب، runner لينكس أقوى لأعمال Android، runner macOS لتجميع وتوقيع iOS، وrunner منفصل لوظائف النشر مع أذونات أكثر صرامة.

اختيار الـ runner المناسب لكل وظيفة

كلا النظامين يسمحان باستهداف الـ runners (تسميات في GitHub، tags في GitLab). اربط التسمية بنمط العمل، مثل linux-docker, android, أو macos-xcode15.

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

القدرة والأذونات كذلك نقاط ألم متكررة، خاصة مع توفر macOS وتكلفته. قاعدة جيدة افتراضيًا: runners البناء يمكنها البناء، runners النشر يمكنها النشر، وبيانات الاعتماد الإنتاجية تعيش في أصغر مجموعة ممكنة من الوظائف.

الأسرار والمتغيرات البيئية

الأسرار هي المكان الذي تصبح فيه خطوط أنابيب متعددة التطبيقات خطرة. الأساسيات متشابهة (تخزن الأسرار في المنصة، تُحقن وقت التشغيل)، لكن تحديد النطاق يختلف.

GitHub Actions عادةً تحدد الأسرار على مستوى المستودع والمنظمة، مع طبقة Environment إضافية. تلك البيئة مفيدة عندما يحتاج الإنتاج إلى بوابة يدوية ومجموعة منفصلة من القيم عن staging.

GitLab CI يستخدم متغيرات CI/CD على مستوى المشروع، المجموعة، أو المثيل. يدعم أيضًا متغيرات مقيدة بالبيئة، بالإضافة إلى حماية مثل "protected" (متاحة فقط على فروع/تاجات محمية) و"masked" (مخفية في السجلات). هذه الضوابط مفيدة عندما يخدم مونوربو فرقًا متعددة.

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

في خطوط أنابيب تجمع backend + web + mobile، عادةً تتضمن الأسرار بيانات اعتماد السحابة، عناوين قواعد البيانات ومفاتيح الطرف الثالث، مواد التوقيع (شهادات/بروفايلات iOS، keystore وكلمات مرور Android)، توكنات الريجستري (npm، Maven، CocoaPods)، وتوكنات الأتمتة (مزودي بريد/رسائل، روبوتات chat).

لبيئات متعددة (dev, staging, prod)، احتفظ بالأسماء متناسقة واستبدل القيم بنطاق البيئة بدل نسخ الوظائف. هذا يبقي دوران المفاتيح والتحكم في الوصول قابلًا للإدارة.

بعض القواعد التي تمنع معظم الحوادث:

• فضّل الاعتماد على بيانات اعتماد قصيرة العمر (مثل OIDC لمزودي السحابة عندما يتوفر) بدل المفاتيح طويلة العمر.
• استخدم مبدأ الأقل امتياز: هويات نشر منفصلة للخلفية، الويب، والموبايل.
• قم بإخفاء الأسرار وتجنّب طباعة المتغيرات البيئية، حتى في حالات الفشل.
• قيد أسرار الإنتاج للفروع/التاجات المحمية ومع وجود مراجعين مطلوبين.
• لا تخزن الأسرار في آرتيفاكتس البناء، حتى مؤقتًا.

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

الكاش والآرتيفاكتس لتسريع البنايات

معظم خطوط الأنابيب البطيئة بطيئة لسبب واحد ممل: تنزيل وإعادة بناء نفس الأشياء مرارًا وتكرارًا. الكاش يتجنب العمل المكرر. الآرتيفاكتس تحل مشكلة مختلفة: الاحتفاظ بمخرجات محددة من تشغيل معيّن.

ما يجب كاشه يعتمد على ما تبنيه. الخلفيات تستفيد من كاش الاعتماديات وكاش المترجم (مثل cache لموديولات Go). بناءات الويب تستفيد من كاش مدراء الحزم وكاش أدوات البناء. بناءات الموبايل عادة تحتاج Gradle بالإضافة إلى كاش Android SDK على لينكس، وCocoaPods أو Swift Package Manager على macOS. كن حذرًا مع كاش مخرجات iOS العدوانية (مثل DerivedData) إلا إذا فهمت المقايضات.

كلا المنصتين تتبّع نفس النمط الأساسي: استعادة الكاش في بداية الوظيفة، وحفظ الكاش المحدث في النهاية. الاختلاف اليومي هو التحكم. GitLab يجعل سلوك الكاش والآرتيفاكت صريحًا في ملف واحد، بما في ذلك انتهاء الصلاحية. GitHub Actions يعتمد غالبًا على actions منفصلة للكاش، وهو مرن لكن أسهل لأن يُخطئ في التكوين.

مفاتيح الكاش أهم في المونوربو. المفاتيح الجيدة تتغير عندما تتغير المدخلات، وتبقى ثابتة خلاف ذلك. يجب أن تقود ملفات القفل (go.sum, pnpm-lock.yaml, yarn.lock, وما شابه) المفتاح. يساعد أيضًا تضمين هاش للمجلد الخاص بالتطبيق الذي تبنيه بدل المستودع كله، والاحتفاظ بكاش منفصل لكل تطبيق حتى لا تبطل تغييرات غير مرتبطة كل شيء.

استخدم الآرتيفاكتس للمخرجات التي تريد الاحتفاظ بها من تشغيل محدد: حزم الإصدارات، APK/IPA، تقارير الاختبارات، ملفات التغطية، وبيانات وصف البناء. الكاشات تحسينات تجريبية؛ الآرتيفاكتس سجلات.

إذا بقيت البنايات بطيئة، ابحث عن كاشات ضخمة، مفاتيح تتغير كل تشغيل (الطوابع الزمنية وSHA للالتزامات شائعة)، ومخرجات مخزنة لا تُعاد استخدمها عبر الـ runners.

ملاءمة المونوربو: عدة خطوط أنابيب بدون فوضى

المونوربو يصبح فوضويًا عندما كل دفع يُشغّل اختبارات الخلفية، بناءات الويب، وتوقيع الموبايل، حتى لو غيرت README فقط. النمط النظيف هو: كشف ما تغيّر، وتشغيل الوظائف الضرورية فقط.

في GitHub Actions، يعني هذا غالبًا workflows منفصلة لكل تطبيق مع فلاتر مسارات حتى يعمل كل workflow فقط عندما تتغير الملفات في منطقته. في GitLab CI، يعني هذا غالبًا ملف أنبوب واحد يستخدم rules:changes (أو child pipelines) لإنشاء أو تخطي مجموعات الوظائف بناءً على المسارات.

الحزم المشتركة هي المكان الذي يكسر فيه الثقة. إذا تغيّر packages/auth، قد يحتاج كل من الخلفية والويب لإعادة البناء حتى لو لم تتغير مجلداتهما. عامل المسارات المشتركة كمشغلات لعدة خطوط أنابيب وحافظ على حدود الاعتماد واضحة.

خريطة مشغلات بسيطة تقلل المفاجآت:

• وظائف الخلفية تعمل عند تغيّر backend/** أو packages/**.
• وظائف الويب تعمل عند تغيّر web/** أو packages/**.
• وظائف الموبايل تعمل عند تغيّر mobile/** أو packages/**.
• تغييرات الوثائق فقط تشغل فحص سريع (تنسيق، تدقيق إملائي).

وازي ما يمكن (اختبارات الوحدة، اللينت، بناء الويب). سلِّس ما يجب التحكم به (نشرات، إصدارات المتاجر). كلٌ من needs في GitLab واعتمادات الوظائف في GitHub تساعدك على تشغيل الفحوصات السريعة مبكرًا وإيقاف الباقي عند الفشل.

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

خطوة بخطوة: خط أنابيب نظيف للخلفية والويب والموبايل

خط أنابيب متعدد التطبيقات ومنظم يبدأ بتسمية توضح النية. اختر نمطًا واحدًا والتزم به حتى يتمكن الناس من مسح السجلات ومعرفة ما الذي شُغّل.

نمط واحد يبقى قابلًا للقراءة:

• خطوط الأنابيب: pr-checks, main-build, release
• البيئات: dev, staging, prod
• الآرتيفاكتس: backend-api, web-bundle, mobile-debug, mobile-release

من هناك، اجعل الوظائف صغيرة وروّج فقط لما نجح في الفحوصات الأولى:

1. PR checks (كل طلب سحب): شغّل اختبارات سريعة ولينت فقط للتطبيقات التي تغيّرت. للخلفية، بنِ قطعة قابلة للنشر (صورة حاوية أو باقة سيرفر) واحفظها حتى لا تُعاد بناؤها لاحقًا.

2. Web build (PR + main): ابنِ الويب إلى باقة ثابتة. في PRs احتفظ بالمخرجات كآرتيفاكت (أو انشرها إلى بيئة معاينة إذا كانت متاحة). على main، أنتج باقة مرقمة مناسبة لـ dev أو staging.

3. Mobile debug builds (PR فقط): ابنِ APK/IPA للـ debug. لا توقّع للإصدار. الهدف هو تغذية راجعة سريعة وملف يمكن للمختبرين تثبيته.

4. Release builds (tags فقط): عندما يُدفع تاج مثل v1.4.0، شغّل كل البنايات، بناءات موقعة للموبايل، وأنشئ مخرجات جاهزة للمتاجر واحتفظ بملاحظات الإصدار مع الآرتيفاكتس.

5. الموافقات اليدوية: ضع الموافقات بين staging و prod، ليس قبل الاختبارات الأساسية. المطورون يمكنهم تشغيل البنايات، لكن فقط الأدوار المعتمدة يمكنها النشر إلى الإنتاج والوصول إلى أسرار الإنتاج.

الأخطاء الشائعة التي تهدر الوقت

الفرق غالبًا تضيع أسابيع بسبب عادات سير العمل التي تخلق بناءات متقلبة بصمت.

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

الأسرار مصدر آخر لهدر الوقت. مفاتيح توقيع الموبايل والشهادات سهلة الإهمال. خطأ شائع هو تخزينها على نطاق واسع جدًا (متاحة لكل فرع ووظيفة) أو تسريبها عبر سجلات مطبوعة. قيد مواد التوقيع على الفروع/التاجات المحمية، وتجنّب أي خطوة تطبع قيم سرية (حتى بسلسلة base64).

الكاش يمكن أن يتراجع عندما يقوم الفريق بكاشة مجلدات ضخمة أو يخلط بين الكاش والآرتيفاكتس. كاش فقط المدخلات المستقرة. احتفظ بالمخرجات التي تحتاجها لاحقًا كآرتيفاكتس.

أخيرًا، في المونوربو، تشغيل كل خط أنابيب على كل تغيير يحرق دقائق وصبر الناس. إذا غيّر أحدهم README وأعدت بناء iOS وAndroid والخلفية والويب، سيفقد الناس الثقة في CI.

قائمة تحقق سريعة تساعد:

• استخدم قواعد مبنية على المسارات حتى تعمل فقط التطبيقات المتأثرة.
• فصل وظائف الاختبار عن وظائف النشر.
• حافظ على مفاتيح التوقيع مقيدة لخطوط إصدار.
• كاش المدخلات الصغيرة والمستقرة، ليس مجلدات البناء الكاملة.
• خطط سعة runner متوقعة لبناءات الموبايل الكبيرة.

فحوصات سريعة قبل الالتزام بمنصة واحدة

قبل الاختيار، قم ببعض الفحوصات تعكس كيف تعمل فعليًا. توفر عليك هذه الفحوص من اختيار أداة تبدو لطيفة لتطبيق واحد لكنها مؤلمة عند إضافة بناءات موبايل وبيئات متعددة وإصدارات.

ركز على:

• خطة الـ runner: مستضافة، ذاتية الاستضافة، أم مزيج. بناءات الموبايل غالبًا تدفع الفرق نحو مزيج لأن iOS يحتاج macOS.
• خطة الأسرار: أين تعيش الأسرار، من يمكنه قراءتها، وكيف يعمل الدوران. يجب أن تكون شروط الإنتاج أكثر صرامة من staging.
• خطة الكاش: ما الذي تكاشه، أين يخزن، وكيف تُشكّل المفاتيح. إن كان المفتاح يتغير عند كل التزام، ستدفع الثمن بدون تسريع فعلي.
• خطة المونوربو: فلاتر المسارات وطريقة نظيفة لمشاركة الخطوات الشائعة (lint، اختبارات) بدون نسخ/لصق.
• خطة الإصدار: تاجات، موافقات، وفصل البيئات. كن صريحًا بمن يمكنه الترقية إلى الإنتاج وما الدليل المطلوب.

اختبر تلك الإجابات بمشهد صغير. في مونوربو يحوي backend Go، ويب Vue، وتطبيقين موبايل: تغيير وثائق يجب أن يفعل القليل جدًا؛ تغيير في الخلفية يجب أن يشغل اختبارات الخلفية ويبني آرتيفاكت API؛ تغيير في واجهة الموبايل يجب أن يبني Android وiOS فقط.

إذا لم تستطع وصف ذلك التدفق على صفحة واحدة (المشغلات، الكاشات، الأسرار، الموافقات)، نفذ تجربة أسبوعية قصيرة على كلا المنصتين باستخدام نفس المستودع. اختر ما يبدو مملًا ومتوقعًا.

مثال: تدفق واقعي للبناء والإصدار في مونوربو

تخيل مستودعًا واحدًا بثلاث مجلدات: backend/ (Go)، web/ (Vue)، وmobile/ (iOS وAndroid).

يوميًا تريد تغذية راجعة سريعة. عند الإصدارات تريد بنايات كاملة، توقيع، وخطوات نشر.

انقسام عملي:

• فروع الميزة: شغّل lint + اختبارات الوحدة للأجزاء التي تغيّرت، ابنِ الخلفية والويب، وخياريًا شغّل بناء Android debug. تجاهل iOS إلا إذا كنت تحتاجه فعلًا.
• تاجات الإصدار: شغّل كل شيء، أنشئ آرتيفاكتس مرقمة، وقّع تطبيقات الموبايل، وادفع الصور/البينات لمخزن الإصدارات.

اختيار الـ runner يتغير بمجرد دخول الموبايل. بنى Go وVue سعيدة على لينكس. iOS يتطلب macOS runners، وهذا قد يؤثر على القرار أكثر من أي شيء آخر. إذا أردتم تحكمًا كاملًا في آلات البناء، GitLab CI مع self-hosted قد يكون أسهل لإدارته كأسطول. إذا فضّلتم أقل عمل عملياتي وإعدادًا سريعًا، الـ hosted runners في GitHub مريحة، لكن دقائق macOS وتوفرها تصبح جزءًا من تخطيطكم.

الكاش هو المكان الذي توفر فيه الوقت الحقيقي، لكن أفضل كاش يختلف بتطبيق. لـ Go، اكاش تنزيل الموديولات وكاش البناء. لـ Vue، اكاش متجر مدير الحزم وأعد البناء فقط عند تغيّر ملفات القفل. للموبايل، اكاش Gradle وAndroid SDK على لينكس؛ اكاش CocoaPods أو SwiftPM على macOS، وتوقّع كاشات أكبر ومزيد من الإبطال.

قاعدة قرار تقاوم التجربة: إذا كان كودك مستضافًا بالفعل على منصة واحدة، ابدأ هناك. غيّر فقط إذا أجبرتِك الـ runners (خاصة macOS)، الأذونات، أو الامتثال.

الخطوات التالية: اختر، وحدد معايير، وأتمتة بأمان

اختر الأداة التي تتطابق مع مكان وجود كودك وفريقك. في معظم الأحيان، الفرق تظهر في الاحتكاك اليومي: المراجعات، الأذونات، ومدى سرعة تشخيص بناء معطل.

ابدأ بسيطًا: خط أنابيب واحد لكل تطبيق (backend، web، mobile). بعد الاستقرار، اسحب الخطوات المشتركة إلى قوالب قابلة لإعادة الاستخدام لتقليل النسخ/اللصق بدون طمس ملكية الأجزاء.

دوّن نطاقات الأسرار كما تكتب من يملك مفاتيح مكتب. أسرار الإنتاج لا ينبغي أن تكون قابلة للقراءة من كل فرع. ضبط تذكير للدوران (ربع سنوي أفضل من أبدًا)، واتفق على كيفية إلغاء الوصول في حالات الطوارئ.

إذا كنت تبني باستخدام مولد no-code ينتج كودًا حقيقيًا، عامل التوليد/التصدير كخطوة CI من الدرجة الأولى. على سبيل المثال، AppMaster (appmaster.io) يولّد backends بـ Go، تطبيقات ويب بـ Vue3، وتطبيقات موبايل بـ Kotlin/SwiftUI، لذلك يمكن أن يعيد الخط الأنابيب توليد الكود عند التغيير ثم يبني الأهداف المتأثرة فقط.

عندما تحصل على تدفق يثق به فريقك، اجعله الافتراضي للمستودعات الجديدة وابقه مملًا: مشغلات واضحة، runners متوقعة، أسرار مضبوطة، وإصدارات تعمل فقط عندما تقصد ذلك.