CI/CD لمشاريع Kotlin: GitHub Actions من الألف إلى الياء

مدرب بايثون أونلاين للمبتدئين

تعلم Python بسهولة دون إرهاق نظري. حل مهام عملية مع التحقق التلقائي واكتب الكود مباشرة في المتصفح.

ابدأ الدورة

مقدمة إلى CI/CD لـ Kotlin باستخدام GitHub Actions

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

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



أساسيات GitHub Actions: الهيكل والتركيب (Syntax)

قبل الخوض في خصوصيات Kotlin، من المهم فهم المفاهيم الأساسية لـ GitHub Actions. يتم وصف خط الأنابيب (Pipeline) في ملفات YAML، والتي يتم تخزينها في دليل .github/workflows/ الخاص بمستودعك.



العناصر الأساسية لـ Workflow

  • Event (حدث): المشغل الذي يبدأ خط الأنابيب (push, pull_request, release وغيرها).
  • Job (مهمة): مجموعة من الخطوات التي يتم تنفيذها على مشغل واحد (runner) (جهاز افتراضي).
  • Step (خطوة): إجراء محدد — تنفيذ أمر، تشغيل سكريبت، أو استخدام action جاهز.
  • Runner: بيئة التنفيذ (Ubuntu, Windows, macOS).


الهيكل الأساسي لملف kotlin-ci.yml:

name: Kotlin CI

on: push: branches: [ main, develop ] 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: Build with Gradle run: ./gradlew build


إعداد CI لـ Kotlin: البناء، الاختبارات، والتحليل (Linting)

المرحلة الأولى والأكثر أهمية هي التكامل المستمر (Continuous Integration). إنها تضمن أن كل كود جديد يمر بعملية الترجمة ولا يكسر الاختبارات الموجودة.



التخزين المؤقت لتبعيات Gradle (Caching)

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

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


تشغيل الاختبارات والتحقق من الأسلوب (Style)

سنضيف خطوات لتشغيل اختبارات الوحدة (unit tests) ومدقق الكود (linter) مثل detekt أو ktlint. سيساعد هذا في الحفاظ على جودة الكود.

- name: Run tests  run: ./gradlew test

- name: Run linter run: ./gradlew detekt


مثال على Workflow CI كامل لمشروع Kotlin

jobs:  test:    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: Cache Gradle        uses: actions/cache@v3        with:          path: ~/.gradle/caches          key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle.kts') }}      - name: Build and test        run: ./gradlew check


Continuous Deployment: النشر التلقائي لتطبيقات Kotlin

بعد التكامل الناجح، تأتي مرحلة النشر. بالنسبة لمشاريع Kotlin، قد يعني هذا نشر مكتبة على Maven Central، أو نشر الخدمة الخلفية على خادم، أو بناء ملف APK لنظام Android.



نشر خدمة خلفية على Ktor

لنفترض أن لدينا تطبيق Kotlin على إطار العمل Ktor. نريد نشره تلقائيًا

المدونات

توصيات الكتب