الأرتيفكت في تطوير التطبيقات: ما هو، أنواعه وكيفية إدارته

ما هو الأرتيفكت في التطوير

الأرتيفكت (أرتيفكت البناء) هو نتيجة ترجمة الكود المصدري، جاهز للنشر أو الاستخدام كتبعية. تقوم عملية البناء بتحويل الملفات المصدرية (Java و Kotlin و Swift و C++ وغيرها) إلى حزم ثنائية يمكن تشغيلها على جهاز أو خادم هدف.

مفهوم الأرتيفكت يتجاوز الملفات التنفيذية. على سبيل المثال، مكتبة JAR هي أرتيفكت يُستخدم كتبعية في مشاريع أخرى. صورة Docker هي أرتيفكت يحتوي على التطبيق وبيئته. حتى تقرير تغطية الاختبارات يمكن اعتباره أرتيفكتًا في سياق CI/CD.

التطوير الحديث في الشركات الكبيرة يتضمن إدارة مئات الآلاف من الأرتيفكتات. Google DORA تربط نضج إدارة الأرتيفكتات بفعالية DevOps الشاملة — الفرق التي تستخدم سجلات الأرتيفكتات تصدر الإصدارات بشكل أسرع وتواجه مشكلات نشر أقل.

دورة حياة الأرتيفكت

يمر كل أرتيفكت بعدة مراحل: الإنشاء (البناء، الترجمة)، التحقق (الاختبار، فحوصات الأمان)، التخزين (سجل الأرتيفكتات)، التوزيع (النشر للتحميل)، و الأرشفة أو الحذف (عندما يصبح الإصدار قديمًا).

أنواع الأرتيفكتات في التطوير المحمول

المنصات والتقنيات المختلفة تولد تنسيقات أرتيفكت مختلفة. فهم التنسيقات ضروري لتكوين خط أنابيب CI/CD بشكل صحيح واختيار نظام التخزين.

أرتيفكتات Android

APK (Android Package Kit) هو تنسيق حزمة التثبيت التقليدي. AAB (Android App Bundle) هو تنسيق حديث للنشر على Google Play، يحتوي فقط على الموارد التي يحتاجها جهاز معين. AAB يقلل حجم التطبيق المثبت بمعدل 15-20% مقارنة بـ APK العالمي.

أرتيفكتات iOS

IPA (iOS App Store Package) هو أرشيف بالكود والموارد لأجهزة iOS. XCArchive هو أرتيفكت وسيط يتم إنشاؤه بواسطة Xcode، ومنه يتم تصدير IPA النهائي. dSYM هو ملف رموز التصحيح اللازم لترميز سجلات الأعطال.

أرتيفكتات مشاريع الخوادم والمكتبات

JAR (Java ARchive) — لمكتبات Java/Kotlin. AAR (Android ARchive) — لمكتبات Android مع الموارد. صور Docker — أرتيفكتات حاويات للخدمات المصغرة. كل نوع له سجله الخاص وقواعد إدارة الإصدارات.

الأرتيفكتات في خط أنابيب CI/CD

الأرتيفكتات هي الرابط بين مراحل خط الأنابيب. كل مرحلة تستهلك أرتيفكتات من المرحلة السابقة وتنتج أرتيفكتات جديدة. فهم هذا التدفق ضروري لإعداد خط أنابيب CI/CD فعال.

تدفق الأرتيفكتات في خط الأنابيب

يتضمن التدفق النموذجي: commit -> خادم البناء يترجم الكود وينشئ أرتيفكتًا غير محسن -> يتم استخدام أرتيفكت الاختبار لتشغيل الاختبارات -> عند النجاح، يتم إنشاء أرتيفكت إصدار -> يتم توقيعه ونشره في سجل الأرتيفكتات -> يتم سحب الأرتيفكت من السجل للنشر في بيئة الاختبار والإنتاج. كل انتقال بين المراحل يكون مصحوبًا بالتحقق من التكامل والامتثال للمتطلبات.

الأرتيفكتات الوسيطة والنهائية

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

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

الذاكرة المؤقتة vs الأرتيفكت

من المهم التمييز بين ذاكرة التخزين المؤقت للتبعيات وأرتيفكتات البناء. ذاكرة التخزين المؤقت (Gradle cache, CocoaPods cache) تسرع عمليات البناء المتكررة ولكنها ليست مخصصة للنشر. الأرتيفكتات هي المنتج النهائي الجاهز للتوزيع. حدد TTL لعدة أيام للذاكرة المؤقتة وأسابيع أو أشهر للأرتيفكتات.

مستودعات الأرتيفكتات

لا ينبغي تخزين الأرتيفكتات على خادم البناء — توجد أنظمة متخصصة لهذا الغرض. مدير المستودع يوفر تخزينًا مركزيًا وفهرسة والتحكم في الوصول والتكامل مع أدوات CI/CD.

سجلات الأرتيفكتات الشائعة

JFrog Artifactory — مدير عالمي يدعم Maven و Gradle و Docker و NuGet و npm و APT و YUM. Sonatype Nexus — بديل مفتوح المصدر يدعم التنسيقات الرئيسية. GitHub Packages — سجل مدمج في GitHub، مناسب للفرق التي تستخدم GitHub بالفعل. GitLab Container Registry — لصور Docker.

معايير اختيار السجل

العوامل الرئيسية: التنسيقات المدعومة، نموذج الترخيص (مفتوح المصدر/مؤسسي)، التكامل مع CI/CD الحالي، قدرات النسخ المتماثل بين المناطق، توفر سياسات التنظيف التلقائي للإصدارات القديمة وتقارير الامتثال.

// Jenkins pipeline — نشر APK في Artifactory
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

إدارة الإصدارات والتسمية

استراتيجية إدارة إصدارات الأرتيفكتات المناسبة ضرورية لإعادة إنتاجية البناء وتتبع التغييرات. بدون إدارة الإصدارات، من المستحيل تحديد إصدار الكود الذي تسبب في مشكلة في الإنتاج.

الإصدار الدلالي (SemVer)

معيار MAJOR.MINOR.PATCH: MAJOR يتغير مع تغييرات API غير متوافقة، MINOR مع إضافات وظائف متوافقة مع الإصدارات السابقة، PATCH مع إصلاحات الأخطاء المتوافقة مع الإصدارات السابقة. بالنسبة لـ CI/CD، تتم إضافة بيانات وصفية للبناء إلى الإصدار: 2.4.1+build.20260703.1. يتيح لك هذا تحديد أي commit أنتج أرتيفكتًا معينًا ومتى تم إنشاؤه بالضبط.

التتبع — الربط بـ Git

يجب أن يحتوي كل أرتيفكت على بيانات وصفية حول مصدره: SHA الـ commit، رقم بناء CI، اسم الفرع، تاريخ البناء. هذه المعلومات تُسجل في بيان الأرتيفكت وتتيح إعادة بناء سياق إنشائه في أي وقت. بدون التتبع، يصبح العمل مع الأرتيفكتات تخمينًا للإصدارات، وهو أمر غير مقبول لأنظمة الإنتاج ذات متطلبات التدقيق.

تسمية الأرتيفكتات

اتفاقية التسمية: {project}-{module}-{version}.{ext}. على سبيل المثال: messaging-sdk-2.4.1.aar أو app-release-2.4.1.apk. يمكن لخادم البناء إنشاء إصدار تلقائيًا بناءً على علامة Git أو رقم بناء نظام CI.

• استخدم علامة Git كمصدر للإصدار — هذا يربط الأرتيفكت بحالة كود محددة
• أضف SHA الـ commit إلى البيانات الوصفية للتحديد الدقيق أثناء التصحيح
• قم بتكوين سياسة الاحتفاظ — احتفظ بآخر N إصدارات، وأرشف الباقي

Snapshot vs Release

في سجلات أرتيفكتات Maven/Gradle، يتم تمييز إصدارات الإصدار (ثابتة، غير قابلة للتغيير) وإصدارات snapshot (التطوير الحالي، يمكن الكتابة فوقها). في خطوط أنابيب CI/CD، تكون أرتيفكتات snapshot مناسبة للتطوير، ولكن في الإنتاج يجب استخدام إصدارات الإصدار فقط.

أمان الأرتيفكتات

الأرتيفكتات عنصر رئيسي في سلسلة توريد البرمجيات. اختراق الأرتيفكت يمكن أن يؤدي إلى دخول كود ضار إلى الإنتاج. يشمل أمان الأرتيفكتات عدة مستويات من الحماية.

توقيع الأرتيفكتات

يتم توقيع ملفات APK باستخدام jarsigner أو apksigner؛ يتم توقيع IPA باستخدام شهادة Apple؛ يتم توقيع صور Docker باستخدام Content Trust (Notary) من Docker. يضمن التوقيع التكامل ويؤكد مؤلف الأرتيفكت. يجب أن يتضمن خط أنابيب CI/CD التحقق من توقيع جميع التبعيات الخارجية.

فحص الثغرات الأمنية

قبل النشر، يتم فحص الأرتيفكت بواسطة ماسحات ضوئية آلية: Snyk، Trivy، Sonatype Nexus IQ، GitHub Dependabot. تقوم بتحليل التبعيات المضمنة وإصدارات المكتبات المستخدمة وثغرات CVE المعروفة. في حالة اكتشاف ثغرة حرجة، يتم حظر الإصدار فورًا حتى يتم إصلاحها من قبل المطورين.

مستويات سلسلة التوريد

SLSA (Supply chain Levels for Software Artifacts) هو إطار أمان يحدد مستويات الثقة من SLSA 1 (أساسي) إلى SLSA 4 (أقصى). يجب على خادم البناء إنشاء شهادة إثبات المنشأ — بيان موقع تشفيريًا حول كيف ومن أي كود تم بناء الأرتيفكت.