Continuous Integration (CI) — ما هو، مبادئه وإعداد الأتمتة

ما هو Continuous Integration

Continuous Integration (CI) هي منهجية تطوير تقوم بأتمتة عملية دمج الكود من عدة مساهمين في قاعدة كود واحدة. تم تقديم المصطلح بواسطة Martin Fowler في أوائل العقد الأول من القرن الحادي والعشرين كمجموعة من الممارسات لمنع “جحيم التكامل” — وهي حالة يعمل فيها المطورون بمعزل عن بعضهم لأسابيع، وعند دمج التغييرات تنشأ تعارضات عديدة تتطلب أياماً من الحل اليدوي.

المشكلة التي يحلها CI

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

الأثر الاقتصادي لـ CI

وفقاً لـ IBM Systems Sciences Institute، تبلغ تكلفة إصلاح خطأ في مرحلة كتابة الكود 25 دولاراً، وفي مرحلة الاختبار 100 دولار، وفي مرحلة الإنتاج 2,500 دولار. ينقل CI اكتشاف العيوب إلى أقصى اليسار قدر الإمكان (shift left)، ليكتشف الأخطاء في مرحلة الإيداع عندما يكون إصلاحها مجانياً تقريباً. الفرق التي تستخدم CI تقضي في المتوسط 15% من وقتها في التصحيح مقابل 35% للفرق التي لا تستخدمه.

المبادئ الأساسية لـ Continuous Integration

حدد Martin Fowler الممارسات الرئيسية لـ CI التي تظل ذات صلة بغض النظر عن مجموعة التقنيات. اتباع هذه المبادئ يضمن أن CI يحقق قيمة بدلاً من أن يصبح عبئاً بيروقراطياً. يفرض تطوير التطبيقات المحمولة متطلبات إضافية، لكن الجوهر يبقى دون تغيير.

مستودع واحد

يتم تخزين كل كود المشروع في مستودع واحد بنظام تحكم إصدارات موحد (Git). مصدر الحقيقة الواحد يلغي الموقف الذي يتم فيه تطوير ميزة في fork ولا تتم مزامنتها مع قاعدة الكود الرئيسية لأسابيع. في المشاريع المحمولة، يعني هذا أن أجزاء Android وiOS وbackend يمكن أن تكون في مستودع واحد (مستودع أحادي) أو في مستودعات منفصلة بمخطط إصدارات مشترك.

بناء آلي

يجب أن يتم بناء المشروع بأمر واحد. بالنسبة لـ Android، هذا هو ./gradlew assembleDebug، وبالنسبة لـ iOS — xcodebuild أو fastlane build. سكريبت البناء يتحقق من قابلية التكرار: يجب أن يعطي البناء على خادم CI نفس نتيجة البناء على جهاز المطور. يتم إزالة أي اختلافات في البيئة باستخدام الحاويات أو IaC (Infrastructure as Code).

اختبارات آلية

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

// مثال لاختبار وحدة مع تقرير متوافق مع CI
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast والشفافية

نتائج CI علنية للفريق بأكمله: يرى الجميع أي إيداع كسر البناء. الشفافية تخلق ثقافة المساءلة: يتحقق المطورون من تغييراتهم قبل الدفع ويصلحون البناء المكسور خارج الدور. يرسل خادم CI إشعارات إلى Slack أو Telegram عند تغير حالة البناء.

مكونات نظام CI

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

خادم CI

المكون المركزي الذي يدير قائمة انتظار البناءات وتوزيع الموارد ونشر النتائج. يمكن أن يكون خادم CI سحابياً (GitHub Actions، GitLab CI، CircleCI) أو مستضافاً ذاتياً (Jenkins، TeamCity). يراقب الخادم التغييرات في المستودع عبر webhook أو polling ويشغل خط الأنابيب عند كل push أو pull request.

Runners والعملاء

Runners هي أجهزة افتراضية أو فعلية تنفذ مهام البناء. في CI السحابي، يتم توفير runners من قبل المزود ويتم الدفع حسب وقت الاستخدام. يتم تثبيت runners المستضافة ذاتياً على البنية التحتية الخاصة وتتطلب صيانة. تتطلب بناءات iOS runners بنظام macOS، وتتطلب بناءات Android Linux أو Windows.

القطع الأثرية والذاكرة المؤقتة

بعد البناء، يحفظ نظام CI القطع الأثرية (APK، IPA، تقارير الاختبارات) في مخزن — وهي متاحة للتنزيل والنشر. التخزين المؤقت للتبعيات (ذاكرة Gradle المؤقتة، ذاكرة CocoaPods المؤقتة) بين مرات التشغيل يسرع البناءات اللاحقة بمقدار 3–5 مرات.

Continuous Integration للتطبيقات المحمولة

يطور التطبيقات المحمولة متطلبات خاصة لـ CI تختلف عن مشاريع الويب أو backend. أوقات البناء الطويلة (3–15 دقيقة لـ Android، 5–20 دقيقة لـ iOS)، أنواع متعددة من القطع الأثرية (APK، AAB، IPA)، الحاجة إلى التوقيع والغموض — كل هذا يتطلب تهيئة مخصصة لخط أنابيب CI.

خط أنابيب CI لنظام Android

يتضمن CI النموذجي لنظام Android: الفحص (ktlint، detekt) والتحليل الثابت، اختبارات الوحدة باستخدام JUnit وMockK، بناء APK/AAB بنسختي debug وrelease، اختبارات الأجهزة على محاكٍ داخل CI، ونشر القطع الأثرية. تعمل ذاكرة Gradle المؤقتة على تسريع البناءات المتكررة — بدونها، يقوم كل بناء بتنزيل التبعيات من جديد، مما يضيع 3–5 دقائق.

خط أنابيب CI لنظام iOS

تتطلب CI لنظام iOS runner بنظام macOS لتجميع كود Swift/Objective-C. يشمل خط الأنابيب: تثبيت تبعيات CocoaPods أو SPM، SwiftLint للتحقق من الأسلوب، اختبارات الوحدة باستخدام XCTest، بناء IPA، توقيع الكود باستخدام Fastlane match، والرفع إلى TestFlight. runner مستضاف ذاتياً على Mac mini أو Mac في مركز بيانات هو بديل لـ runners السحابية بنظام macOS.

المشاريع عبر المنصات (Flutter، React Native)

يتم تجميع Flutter وReact Native إلى بناءات أصلية لكلتا المنصتين. يجب أن يدعم CI runnerين: Linux لبناءات Android وmacOS لبناءات iOS. الاستراتيجية المثلى هي خط أنابيب مقسم: بناء Android على runner Linux، بناء iOS على runner macOS، وبعد ذلك يتم دمج كلا القطعتين الأثرية في إصدار واحد.

مقارنة أدوات CI

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

GitHub Actions

مجاني للمستودعات العامة (2000 دقيقة/شهر). GitHub Actions يقدم نظاماً من الإجراءات الجاهزة لنظام Android (gradle/actions) ولنظام iOS (apple-actions). العيب هو أن runners macOS متاحة فقط في الخطط المدفوعة. مثالي للمشاريع مفتوحة المصدر والفرق الصغيرة التي تستخدم GitHub بالفعل.

Jenkins

خادم CI مستضاف ذاتياً ومفتوح المصدر. يتم تهيئة Jenkins عبر Groovy Pipeline ويدعم مئات الإضافات ويعمل على أي جهاز. يتطلب مهندس DevOps للتركيب والصيانة. شائع في قطاع المؤسسات حيث يكون التحكم في البنية التحتية أمراً بالغ الأهمية.

GitLab CI

CI/CD مدمج في GitLab ببنية runners مفتوحة. GitLab CI يسمح باستخدام runners خاصة (بما في ذلك macOS) في الخطة المجانية. تهيئة YAML أقوى من GitHub Actions ولكنها أصعب في التعلم. مناسب للفرق التي تستخدم GitLab كمنصة DevOps موحدة.

CircleCI

CI سحابي يركز على السرعة. CircleCI يدعم صور Docker وmacOS وAndroid، ويخزن التبعيات مؤقتاً تلقائياً. التسعير قائم على الائتمان — أغلى من GitHub Actions للفرق الصغيرة، ولكنه أسرع بفضل runners المحسّنة. موصى به للمشاريع الإنتاجية ذات متطلبات السرعة.

مثال على إعداد CI

لننظر في إعداد CI لمشروع Android باستخدام GitHub Actions. يقوم خط الأنابيب بالتحليل الثابت والبناء والاختبار عند كل push وpull request إلى الفرع الرئيسي. يستغرق التكوين الأدنى 15 دقيقة ولا يتطلب خدمات خارجية.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

يتكون خط الأنابيب من وظيفتين متوازيتين: lint (يقوم بالتحليل الثابت) وunit-tests (تعتمد على lint — إذا فشل الفحص، لا يتم تشغيل الاختبارات). تقوم وظيفة unit-tests برفع تقرير الاختبارات كقطعة أثرية — يمكن للفريق مراجعته في واجهة GitHub Actions دون تنزيل الملفات محلياً.

التحقق المحلي قبل CI

لتجنب فشل CI بسبب أخطاء بسيطة، قم بإعداد hook pre-push في Git أو مهمة Gradle تقوم بتشغيل نفس الفحوصات محلياً. على سبيل المثال: ./gradlew ktlintCheck detekt testDebugUnitTest. إذا استغرقت الفحوصات المحلية أكثر من 3 دقائق، قسّمها إلى سريعة (مدقق) وبطيئة (اختبارات)، وشغّل السريعة قبل كل إيداع والبطيئة فقط قبل الدفع.