CI/CD لمشاريع Kotlin باستخدام GitHub Actions: دليل خطوة بخطوة

مقدمة: لماذا لا غنى عن CI/CD لتطوير Kotlin

تطوير Kotlin الحديث لا يقتصر فقط على كتابة كود موجز وآمن، بل يشمل أيضًا ضمان تسليمه المستمر. سواء كنت تقوم بإنشاء تطبيق خادم باستخدام Ktor، أو تطبيق Android، أو مشروع متعدد المنصات، فإن البناء والاختبار اليدويين سرعان ما يصبحان عنق زجاجة. CI/CD (التكامل المستمر / النشر المستمر) يقوم بأتمتة هذه العمليات، مما يقلل من خطر الخطأ البشري ويسرع إطلاق الميزات الجديدة.

GitHub Actions هي واحدة من أكثر الأدوات شيوعًا لتنفيذ CI/CD، خاصة إذا كان كودك مخزنًا بالفعل على GitHub. إنها تتكامل بشكل وثيق مع نظام Kotlin البيئي، وتدعم Gradle و Maven، وتسمح بمرونة في تكوين خطوط الأنابيب (pipelines) لتناسب أي احتياجات. في هذه المقالة، سنشرح كيفية إعداد دورة كاملة من البناء والاختبار والنشر لمشروع Kotlin باستخدام GitHub Actions.

أساسيات GitHub Actions: هيكل سير العمل (Workflow)

قبل كتابة الكود، دعنا نفهم المفاهيم الأساسية. سير العمل (Workflow) في GitHub Actions هو عملية آلية يتم تشغيلها بناءً على حدث معين (مثل push إلى فرع main). يتم وصف سير العمل في ملف YAML، يتم تخزينه في دليل .github/workflows/ الخاص بمستودعك.

الهيكل النموذجي لسير العمل يتضمن:

• name — اسم سير العمل (يظهر في واجهة GitHub).
• on — مشغلات التشغيل (مثل push, pull_request).
• jobs — مجموعة من المهام التي يتم تنفيذها بشكل تسلسلي أو متوازي.
• steps — الخطوات داخل المهمة (تثبيت JDK، تخزين التبعيات مؤقتًا، تشغيل الاختبارات).

بالنسبة لمشاريع Kotlin، الخطوة الأساسية هي تكوين الإصدار الصحيح من JDK (عادةً 11 أو 17 أو 21) واستخدام Gradle Wrapper (./gradlew)، الذي يضمن إمكانية تكرار البناء على أي جهاز.

الخطوة 1: البناء الأساسي واختبار مشروع Kotlin

لنبدأ بالأبسط: سير عمل يقوم بتشغيل الاختبارات عند كل push إلى main أو عند إنشاء Pull Request. هذا هو أساس أي CI/CD — ضمان أن الكود لم يكسر الوظائف الحالية.

قم بإنشاء ملف .github/workflows/ci.yml بالمحتوى التالي:

name: CI for Kotlin

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Cache Gradle packages
        uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-

      - name: Build with Gradle
        run: ./gradlew build

      - name: Run tests
        run: ./gradlew test

دعنا نشرح النقاط الرئيسية:

• actions/checkout@v4 — يقوم باستنساخ (clone) المستودع إلى بيئة التنفيذ (runner).
• actions/setup-java@v4 — يقوم بتثبيت JDK 17 (Temurin). يمكنك اختيار إصدار آخر إذا كان مشروعك يتطلب، على سبيل المثال، JDK 11 أو 21.
• actions/cache@v4 — يقوم بتخزين تبعيات Gradle مؤقتًا. هذا أمر بالغ الأهمية للسرعة: بدون التخزين المؤقت، سيقوم كل بناء بتنزيل جميع المكتبات من جديد (قد يستغرق 2-5 دقائق). التخزين المؤقت يسرع هذه العملية إلى بضع ثوانٍ.
• ./gradlew build — بناء كامل للمشروع (تجميع + اختبارات). إذا كنت تريد الاختبارات فقط، استخدم ./gradlew test.