GitLab — الأساسيات، الميزات وCI/CD

ما هو GitLab؟

GitLab — هي منصة DevOps كاملة مفتوحة المصدر بموجب ترخيص MIT. على عكس GitHub، الذي يجمع خدمات متنوعة من خلال التكاملات، يوفر GitLab أداة واحدة لدورة حياة التطوير بأكملها: من إدارة الكود ومراجعة الكود إلى CI/CD والمراقبة والأمان والنشر. لا تتطلب المنصة خدمات طرف ثالث لمعظم مهام DevOps.

بدأت قصة GitLab في عام 2011 كمشروع داخلي لمطورين أوكرانيين. صدر الإصدار العام الأول في سبتمبر 2011، وفي عام 2015 أصبح GitLab أول مشروع على GitLab.com، وأطلق الاستضافة السحابية. في عام 2017، أجرى GitLab عملية ترحيل مؤلمة ولكنها مفيدة — نقل البنية التحتية بأكملها من Azure إلى Google Cloud، والتي تمت مباشرة على الهواء مباشرة وتم توثيقها في سلسلة من المقالات.

تتكون بنية GitLab من ثلاثة مكونات رئيسية: GitLab Rails (تطبيق ويب على Ruby on Rails)، وGitLab Shell (معالجة عمليات Git عبر SSH)، وGitaly (خادم gRPC للوصول إلى بيانات Git). يتم توفير CI/CD عبر GitLab Runner — تطبيق منفصل يُثبت على خوادم البناء وينفذ المهام في بيئات معزولة (Docker، Kubernetes، VirtualBox).

GitLab CI/CD: pipelines و runners

GitLab CI/CD — هو نظام مدمج للتكامل والتسليم المستمرين، وهو ميزة رئيسية للمنصة. على عكس GitHub Actions، تم دمج GitLab CI/CD في البنية منذ البداية ولا يتطلب إعدادًا منفصلاً: كل مشروع يحصل تلقائيًا على CI/CD بعد إضافة ملف .gitlab-ci.yml إلى جذر المستودع.

يتكون الـ pipeline من مراحل يتم تنفيذها بالتسلسل أو بالتوازي: build → test → deploy. تحتوي كل مرحلة على مهمة أو أكثر يتم تنفيذها على الـ runners. إذا فشلت مهمة في مرحلة ما، يتم وضع علامة فشل على المرحلة بأكملها، ولا يتم تشغيل المراحل اللاحقة افتراضيًا. فيما يلي مثال لـ pipeline لمشروع جوّال:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

يدعم GitLab Runner عدة منفذين: Docker (موصى به)، Kubernetes، SSH، VirtualBox، وParallels. الخيار الأكثر شيوعًا هو منفذ Docker، الذي يشغل كل مهمة في حاوية منفصلة. يمكن تسجيل runner كمخصص لمشروع واحد أو كمشترك لمجموعة كاملة. يوفر GitLab.com runners مشتركة مجانية بحد أقصى 2000 دقيقة شهريًا.

ميزات CI/CD المتقدمة

GitLab CI/CD يدعم التشغيل اليدوي (when: manual)، والتشغيل المؤجل (when: delayed)، والتنفيذ المتوازي (parallel: 5)، والمصفوفات (matrix)، والـ pipelines الديناميكية (child pipelines)، والـ pipelines متعددة المستويات (parent-child). يتيح ذلك بناء سيناريوهات معقدة: على سبيل المثال، إنشاء pipeline ديناميكي لكل وحدة في مستودع أحادي أو تشغيل بنيات موازية لمعماريات Android المختلفة (arm64، x86_64).

GitLab ضد GitHub: الاختلافات الرئيسية

GitLab و GitHub — هما المنافسان الرئيسيان في سوق منصات Git، لكن فلسفتهما وبنيتهما تختلفان جوهريًا. GitHub يركز على المجتمع المفتوح، والنظام البيئي للتكاملات، والوظائف الاجتماعية (النسخ، النجوم). GitLab يركز على دورة DevOps الشاملة ويوفر جميع الأدوات بشكل جاهز: من التخطيط إلى المراقبة.

الفرق المعماري الرئيسي: GitLab — هو تطبيق متجانس واحد يقوم المطور بتثبيته بالكامل. جميع الميزات (CI/CD، Container Registry، Security Scanning، Pages) مدمجة وتعمل فورًا بعد التثبيت. GitHub هو منصة بواجهة API حيث تُنفذ معظم الميزات من خلال التكامل مع خدمات الطرف الثالث: Travis CI، CircleCI، Jenkins، SonarQube. يقارن الجدول أدناه الخصائص الرئيسية:

الاختيار بين GitLab و GitHub يعتمد على احتياجات الفريق. إذا كانت الأولوية هي النشر السريع بدون تكوين ومجتمع مفتوح — اختر GitHub. إذا كنت بحاجة إلى تحكم كامل في البنية التحتية، واستضافة ذاتية، وأمان مدمج — فإن GitLab هو الأفضل. وفقًا لاستطلاع Stack Overflow (2024)، يستخدم 90% من المطورين GitHub، و33% يستخدمون GitLab (غالبًا كلتا المنصتين معًا).

Self-Managed GitLab: التثبيت على الخادم الخاص بك

Self-Managed GitLab (المعروف سابقًا بـ On-Premises) يسمح بتثبيت المنصة على الخادم الخاص بك والتحكم الكامل في البيانات والبنية التحتية ووقت التشغيل. هذا مهم بشكل خاص للمؤسسات ذات متطلبات الامتثال: القطاع المالي، المؤسسات الحكومية، المنظمات الطبية حيث لا يمكن تخزين البيانات على خوادم طرف ثالث.

تثبيت GitLab مدعوم على Ubuntu، Debian، CentOS وعبر Docker. تشمل حزمة Omnibus الرسمية جميع المكونات: خادم الويب (NGINX)، قاعدة البيانات (PostgreSQL)، التخزين المؤقت (Redis)، معالج Git (Gitaly)، والعمليات الخلفية. الحد الأدنى من المتطلبات: 4 جيجابايت من RAM و 2 CPU لفريق يصل إلى 100 شخص. للتثبيتات الكبيرة ذات التحميل العالي، يُوصى بتقسيم المكونات عبر خوادم منفصلة.

# تثبيت GitLab CE على Ubuntu عبر Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# تثبيت الحزمة
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# عرض الحالة
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab ليس لديه حدود لدقائق CI/CD — جميع الـ runners مملوكة للمنظمة، وقوتها محدودة فقط بالأجهزة الخاصة بك. تتوفر أيضًا Geo-replication للمناطق، وسجلات التدقيق، والحظر بواسطة IP، والتكامل مع موفري LDAP/SAML المؤسسيين. يصدر GitLab تحديثات كل شهر (في اليوم 22) بميزات جديدة وإصلاحات أمنية.

أدوات الأمان المدمجة في GitLab

الأمان في GitLab مدمج على مستوى المنصة ويتضمن عدة ماسحات ضوئية تعمل في كل مرحلة من مراحل الـ pipeline. SAST (Static Application Security Testing) يحلل الكود المصدري بحثًا عن الثغرات الأمنية دون تنفيذ التطبيق، ويدعم أكثر من 15 لغة بما في ذلك Java وKotlin وSwift وPython وJavaScript. DAST (Dynamic Application Security Testing) يختبر تطبيق الويب قيد التشغيل بحثًا عن الثغرات من الداخل.

أدوات إضافية: Container Scanning يتحقق من صور Docker بحثًا عن الثغرات في الطبقات الأساسية؛ Dependency Scanning يحلل تبعيات المشروع ويحذر من CVE المعروفة؛ Secret Detection يجد مفاتيح API وكلمات المرور والرموز الملتزمة عن طريق الخطأ؛ Fuzz Testing يقوم باختبار آلي ببيانات غير صالحة للعثور على أخطاء غير واضحة. تُعرض جميع نتائج الفحص في لوحة أمان موحدة (Security Dashboard).

يوفر GitLab أيضًا Compliance — أدوات للامتثال للمتطلبات التنظيمية. تعرض لوحة الامتثال (Compliance Dashboard) حالة الامتثال لجميع المشاريع، ويسجل Audit Events كل إجراء للمسؤول والمطور، وتسمح Compliance Frameworks بتطبيق سياسات التكوين إجباريًا لمجموعات محددة من المشاريع. وهذا يجعل GitLab خيارًا شائعًا في البيئات المؤسسية ذات متطلبات الأمان الصارمة.

سجل الحاويات و Dependency Proxy

GitLab Container Registry — هو سجل Docker مدمج مع CI/CD. بعد بناء صورة Docker في pipeline، يمكن نشرها فورًا في السجل باستخدام متغيرات البيئة CI_REGISTRY و CI_REGISTRY_USER. يدعم السجل التخزين المؤقت من النوع pull-through، والوسم، وسياسات التنظيف، وفحص الثغرات مباشرة في السجل.

Dependency Proxy — آلية تخزين مؤقت للحاويات والصور من السجلات الخارجية (Docker Hub، Quay، GCR). عندما يطلب pipeline صورة مثل ubuntu:latest، يتحقق GitLab أولاً من ذاكرة التخزين المؤقت — إذا كانت الصورة قد تم تنزيلها بالفعل، فلا يتم تنزيلها مرة أخرى. هذا يقلل الحمل على السجلات الخارجية، ويسرّع الـ pipelines، ويحمي من حدود معدل Docker Hub.

لمطوري التطبيقات المحمولة، يوفر GitLab GitLab Pages لاستضافة التوثيق وتقارير الاختبار. بعد تشغيل الاختبارات، يمكن نشر القطع الأثرية (تقارير HTML، لقطات الشاشة، السجلات) كـ Pages ومشاركة الرابط مع فريق ضمان الجودة. هذا أكثر ملاءمة من رفع التقارير إلى التخزين السحابي لأن كل شيء يبقى ضمن نفس مشروع GitLab.

API و Webhooks في GitLab

API GitLab (REST و GraphQL) يوفر الوصول إلى جميع موارد المنصة: المشاريع، المستخدمين، الـ pipelines، Merge Requests، السجل. تُستخدم API للأتمتة: إنشاء مشروع من قالب، تعيين مراجع، الحصول على حالة الـ pipeline. Webhooks تسمح بإرسال إشعارات HTTP إلى الأنظمة الخارجية عند الأحداث: push، merge، إنشاء Issue. تتكامل Webhooks مع Mattermost وSlack وTelegram وأنظمة المراقبة الداخلية.

GitLab Pages لتوثيق التطبيقات المحمولة

GitLab Pages تنشر تلقائيًا المواقع الثابتة من المستودع. للمشاريع المحمولة، Pages مفيدة لاستضافة توثيق API وتقارير تغطية الاختبارات ونتائج تحليل lint. النشر يحدث تلقائيًا بعد pipeline ناجح —只需 إضافة خطوة نشر مع النشر في Pages. النتيجة متاحة على https://namespace.gitlab.io/project-name.