GitHub أم GitLab: أين يعيش خط البناء

GitHub وGitLab يستضيفان Git، والنسخة المسحوبة من أحدهما هي المخزن نفسه بالسجل نفسه. والاختيار يدور على ما حول المستودع: أين تعيش البلاغات، وأين يعمل البناء، وكيف تُصاغ الصلاحيات، وأين يقف التنصيب كله. وهذا الأخير هو ما يجب أن تختبره الشركة أولًا، لأن السؤال الذي يحسم علاقة مع مورّد ليس أي المنتجين يعرض المراجعة أجمل، بل من يستطيع إخراج المستودع، وهل يحتاج إذنًا لذلك.

هل تختارون Git أصلًا؟

لا. Git بروتوكول ونموذج بيانات، يمكن تنفيذه بحرية، ونسخة كاملة من المستودع تتسع في git clone واحد. لو كان التحكم في الإصدارات هو الحاجة الوحيدة، لكانت أي منصتين اعتمادًا زائدًا: مستودع عارٍ على خادم تملكونه يكفي.

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

ماذا يضع كل منتج حول المستودع؟

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

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

ولا فارق في الجودة بينهما. الفارق هل يريد العمل أن يتوزع على تكاملات متخصصة، أم يبقى في نظام واحد بمجموعة دخول واحدة.

ماذا يتغير حين تستضيفونه عندكم؟

يتغير من يحمل الشيفرة وسجلات البناء، وفي أي بلد تقع. وهذا سؤال إقامة بيانات قبل كل شيء: مدقّق، أو عميل في القطاع العام، أو سياسة مجموعة، قد يشترط أن تقع الشيفرة وخط البناء على بنية تتحكم فيها الشركة، ولا قائمة ميزات تحسم ذلك.

ويتغير التحكم أيضًا. منفّذوكم يصلون إلى قاعدة بيانات داخلية؛ وإيقاع التحديثات لكم؛ والعطل لكم، وكذلك الترقية التي تكسر تكاملًا. والتنصيب الذاتي يحتاج مسؤولًا، ونسخة احتياطية استعادها أحد مرة، ونافذة صيانة اتُّفق عليها لا افتُرضت.

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

ماذا ينكسر عند الانتقال؟

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

والذي لا ينتقل هو كل ما تعلّق بها. أرقام البلاغات تُعاد، فتصير رسالة إيداع تقول #412 تشير إلى بلاغ آخر، ويبقى الرابط نصًا صحيح الشكل خاطئ المعنى. والتعليقات تفقد مرفقاتها وإحالاتها، والوسوم والمراحل تُترجم ترجمة ناقصة، وطلبات الدمج المفتوحة تُعاد يدويًا في الغالب. وملفات خط البناء YAML متشابهة بمفاتيح مختلفة، فيُعاد بناؤها واختبارها لا نسخها. وبُنية الفرق والصلاحيات قلّ أن تنتقل واحدًا بواحد.

والأمر نفسه في الاتجاهين، ولهذا فإن «يمكننا الانتقال دائمًا» صحيح فقط إذا انتقل أحدهم بمستودع صغير مرة وقاس المدة.

من يستطيع تصدير المستودع، وبإذن من؟

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

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

والأفضل أن يكون التصدير مجدولًا لا متذكَّرًا. مرة كل ثلاثة أشهر، إلى تخزين تملكه الشركة، تكفي لتصير المسألة نظرية.

كيف يبدو الفارق حيث يهم؟

البعد	GitHub	GitLab
مركز الثقل	شبكة المساهمين والمكتبات والتكاملات	تطبيق واحد من الطلب إلى النشر
الاستضافة الذاتية	منتج خادم منفصل	المنتج نفسه، قابل للتنصيب
ما لا يُرحَّل	أرقام البلاغات والتعليقات ومفاتيح خط البناء	الأمر نفسه، في المواضع نفسها
ما تتحققون منه أولًا	من يملك المنظمة ويستطيع تصديرها	أي تنصيب تشغّلونه، ومن يديره

كيف تقرر الشركة؟

1. اكتبوا ما يستعمله الفريق خارج Git: متتبع البلاغات، وخط البناء، وسجل الحزم، والويكي، ومراجعة الشيفرة، وفحص الأمان.
2. اكتبوا من سيعمل فيه — موظفون ومستقلون ووكالات وموظفو العميل — وهل لديهم حسابات أصلًا.
3. اكتبوا شرط إقامة البيانات إن وُجد، بجملة يقبلها مدقّق، واعتبروه قيدًا لا تفضيلًا.
4. نفّذوا اختبار التصدير على مستودع حقيقي قبل الاختيار.
5. اختاروا بحسب القيد الذي لا يُتفاوض عليه، ثم احسموا التكاملات التي يعتمد عليها الفريق.
6. سجّلوا الخروج كتابةً: من يصدّر، وبأي صيغة، وكم مرة، وإلى أين تذهب النسخة.

أين يخطئ الفريق؟

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

ما لا يغطيه هذا الرأي

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

نعمل على المنصتين، ولا نعيد بيع أي منهما ولا نتقاضى عمولة، فما فوق ليس توصية بمورّد.

نبني خط البناء ومخرج الطوارئ معًا، في حساب العميل، حتى يكون الرحيل إجراءً لا حادثًا.