GitLab CI: خطوط الأنابيب والتكامل المستمر

ما هو GitLab CI؟

GitLab CI هو جزء من تطبيق GitLab الموحد DevSecOps، الذي يشمل التكامل المستمر والتسليم والنشر. بدأ النظام كمشروع منفصل في 2012 ولكن تم دمجه لاحقاً مباشرة في GitLab. المبدأ الأساسي هو التكوين كرمز من خلال ملف .gitlab-ci.yml في جذر المستودع. يتوفر GitLab CI في كل من النسخة السحابية SaaS والنسخة المدارة ذاتياً.

لتطوير التطبيقات المحمولة، يقدم GitLab CI أتمتة بناء APK و IPA، وتشغيل الاختبارات الآلية، وتحليل الكود الثابت، وتوقيع التطبيقات، والنشر في المتاجر. المنصة تدعم صور Docker للبيئات المخصصة، مما يتيح التثبيت المسبق لـ Android SDK و NDK و Xcode والأدوات الأخرى. يعمل Container Registry المدمج على تبسيط تخزين وتوزيع الصور داخل الفريق.

هندسة GitLab CI: Runners و Pipelines و Stages

تتكون هندسة GitLab CI من ثلاثة مكونات رئيسية. GitLab Runner هو وكيل ينفذ الوظائف. يمكن أن تكون الـ Runners مشتركة (يوفرها GitLab)، أو جماعية (لمجموعة مشاريع)، أو محددة (لمشروع واحد). يتم تسجيل كل runner مع مشغل: Shell أو Docker أو Kubernetes أو VirtualBox. يدعم GitLab Runner التوسع التلقائي للتعامل مع الأحمال القصوى.

Pipeline هو مجموعة من stages يتم تنفيذها بالتسلسل. ضمن stage واحدة، يتم تشغيل الوظائف بالتوازي. هيكل نموذجي لمشروع محمول: build → test → deploy. إذا فشلت وظيفة في stage test، لا يتم تشغيل deploy. يمكن تكوين تشغيل يدوي (when: manual) للنشر. كما يتم دعم مشغلات pipelines متعددة المشاريع لسيناريوهات CI/CD المعقدة عبر المستودعات.

مشغلات GitLab Runner

مشغل Docker هو الأكثر شيوعاً لـ CI/CD للتطبيقات المحمولة. كل وظيفة تعمل في حاوية Docker نظيفة، مما يضمن العزل وإمكانية التكرار. لبناء Android، تُستخدم صورة android-sdk مع SDK مثبت مسبقاً؛ ولـ iOS، يُستخدم runner macOS مع مشغل Shell.

تكوين .gitlab-ci.yml للمشاريع المحمولة

يحدد ملف .gitlab-ci.yml pipeline بتنسيق YAML. الأقسام الرئيسية تشمل: image (صورة Docker)، stages (قائمة المراحل)، variables (متغيرات البيئة)، before_script (أوامر قبل كل وظيفة) والوظائف مع أقسام script و artifacts و cache. يدعم GitLab CI include — إدراج ملفات YAML خارجية لإعادة استخدام التكوينات المشتركة بين المشاريع.

يمكن تعيين المتغيرات في GitLab CI على مستويات متعددة: عالمياً في واجهة المستخدم، وفي ملف التكوين، وفي إعدادات المجموعة والمشروع. أولوية المتغيرات تتبع تسلسلاً هرمياً: متغيرات المشغل لها الأولوية القصوى، تليها متغيرات CI/CD من واجهة المستخدم، ثم من .gitlab-ci.yml. يمكن حماية المتغيرات، مما يجعلها متاحة فقط للفروع والعلامات المحمية.

المتغيرات الأساسية والصورة

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

وظيفة بناء مع القطع الأثرية

تقوم وظيفة generate-apk ببناء مشروع Gradle وتحفظ APK كقطعة أثرية. القطع الأثرية تُنقل بين stages — يمكن لوظيفة deploy استخدام APK من مرحلة build. يتم تكوين مدة الاحتفاظ بالقطع الأثرية عبر expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI مقابل GitHub Actions: الفروقات الرئيسية

عند الاختيار بين GitLab CI و GitHub Actions لمشروع محمول، تعتبر البنية التحتية للفريق عاملاً رئيسياً. GitLab CI يوفر Container Registry مدمج لتخزين صور Docker مع Android SDK. يعتمد GitHub Actions على GitHub Packages أو السجلات الخارجية. كما أن GitLab لديه SAST (اختبار أمان التطبيقات الثابت) مدمج لتحليل ثغرات الكود.

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

من منظور CI/CD المحمول: GitLab CI مناسب أكثر للشركات التي تستخدم بالفعل GitLab Self-Managed وتحتاج إلى runners مستضافة ذاتياً مع Docker/Kubernetes. GitHub Actions أكثر ملاءمة للفرق الصغيرة على GitHub السحابي التي تقدر الإجراءات الجاهزة وسهولة الإعداد.

مقارنة الميزات

مثال على pipeline لمشروع Android

يتضمن pipeline كامل لنظام Android: lint، اختبارات الوحدة، البناء، والنشر إلى Firebase App Distribution. يستخدم pipeline صورة Docker مع Android SDK، وتخزين Gradle مؤقتاً، وتنفيذ متوازٍ لـ lint و test في نفس المرحلة. هذا النهج يقلل الوقت الإجمالي لـ pipeline لأن مهام lint و test مستقلة عن بعضها البعض.

بالنسبة لمشاريع iOS، يختلف هيكل pipeline بسبب الحاجة إلى runner macOS وتوقيع الكود. pipeline iOS النموذجي يشمل: تثبيت CocoaPods أو SPM، تشغيل الاختبارات على المحاكي، أرشفة مشروع Xcode، تصدير IPA، والرفع إلى TestFlight. يستخدم GitLab CI لنظام iOS runners macOS — إما runners SaaS من GitLab مع حدود زمنية أو runner مستضاف ذاتياً على Mac Mini أو MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

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

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

تحسين وقت البناء في GitLab CI

يتطلب تحسين خطوط أنابيب البناء المحمول في GitLab CI الاهتمام بالتفاصيل. التكوين المناسب لـ cache و artifacts يمكن أن يقلل وقت البناء عدة مرات. لتحليل الأداء، يوفر GitLab CI/CD Analytics — لوحة تحكم بمقاييس مدة pipelines، وحمل runners، والاختناقات. حلل هذه المقاييس بانتظام للعثور على فرص التحسين. يؤدي تكوين resource_group إلى منع تشغيل pipeline المتوازي — مفيد لمنع تعارضات النشر.

استراتيجية الفروع لـ CI مهمة أيضاً. يوصى بتشغيل pipeline الكامل فقط لفروع main و release، وبالنسبة لفروع الميزات — فقط lint واختبارات الوحدة. هذا يوفر دقائق الـ runners ويسرع التغذية الراجعة للمطورين. يدعم GitLab CI workflow:rules — قواعد شرطية لتضمين أو استثناء الوظائف بناءً على الفرع أو الملفات المعدلة أو متغيرات البيئة.

التخزين المؤقت للتبعيات هو طريقة التسريع الأساسية. يخزن GitLab CI مؤقتاً .gradle و Pods و node_modules بين مرات التشغيل. يتضمن مفتاح التخزين المؤقت $CI_COMMIT_REF_SLUG أو تجزئة ملف lock. ينخفض وقت بناء مشروع Android من 10–15 إلى 2–4 دقائق مع التخزين المؤقت المناسب. يمكن أن يكون التخزين المؤقت موزعاً — يدعم GitLab cache:key مع الرجوع إلى المفاتيح السابقة.

صورة Docker مع أدوات مثبتة مسبقاً توفر وقت التثبيت. يوصى بإنشاء صورة مخصصة مع Android SDK و NDK ومستوى API المطلوب. يؤدي التنفيذ المتوازي للوظائف (lint, test, assemble) في مراحل مختلفة إلى تقليل الوقت الإجمالي لـ pipeline. سياسات السحب للصور (if-not-present) تسرع بدء الوظائف. يمكن أيضاً استخدام وكيل تبعيات لتخزين الصور مؤقتاً على مستوى مثيل GitLab.

جانب آخر مهم للتحسين هو استخدام القطع الأثرية بين المراحل. الملفات الثقيلة مثل APK و IPA يجب نقلها عبر dependency بدلاً من إعادة بنائها في كل وظيفة. للمشاريع الكبيرة ذات العشرات من الوحدات، يُوصى بتمكين Gradle Build Cache على مستوى pipeline وتكوين cache عن بعد على تخزين مشترك. يجب تعيين timeout لكل وظيفة بناءً على وقت البناء المتوقع — وهذا يمنع تعليق العمليات.

مثال مع التخزين المؤقت وسياسة السحب

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present