Artifact در توسعه اپلیکیشن: چیست، انواع و نحوه مدیریت

Artifact در توسعه چیست

Artifact (مصنوع بیلد) — نتیجه کامپایل کد منبع است، آماده برای استقرار یا استفاده به عنوان وابستگی. فرآیند بیلد فایل‌های منبع (Java, Kotlin, Swift, C++ و غیره) را به بسته‌های باینری تبدیل می‌کند که می‌توانند روی دستگاه هدف یا سرور اجرا شوند.

مفهوم مصنوع فراتر از فایل‌های اجرایی است. به عنوان مثال، کتابخانه JAR — مصنوعی است که به عنوان وابستگی در پروژه‌های دیگر استفاده می‌شود. تصویر Docker — مصنوعی حاوی اپلیکیشن و محیط آن. حتی گزارش پوشش تست نیز می‌تواند در زمینه CI/CD مصنوع محسوب شود.

توسعه مدرن در شرکت‌های بزرگ شامل مدیریت صدها هزار مصنوع است. Google DORA بلوغ مدیریت مصنوعات را با کارایی کلی DevOps مرتبط می‌داند — تیم‌هایی که از رجیستری‌های مصنوعات استفاده می‌کنند، سریع‌تر انتشار می‌دهند و کمتر با مشکلات استقرار مواجه می‌شوند.

چرخه عمر مصنوع

هر مصنوع چندین مرحله را طی می‌کند: ایجاد (بیلد، کامپایل)، اعتبارسنجی (تست، بررسی امنیتی)، ذخیره‌سازی (رجیستری مصنوعات)، توزیع (انتشار برای دانلود) و بایگانی یا حذف (زمانی که نسخه قدیمی می‌شود).

انواع مصنوعات در توسعه موبایل

پلتفرم‌ها و فناوری‌های مختلف فرمت‌های متفاوتی از مصنوعات تولید می‌کنند. درک فرمت‌ها برای پیکربندی صحیح پایپ‌لاین CI/CD و انتخاب سیستم ذخیره‌سازی ضروری است.

مصنوعات اندروید

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 — فایل اشکال‌زدایی لازم برای نمادسازی لاگ‌های crash.

مصنوعات پروژه‌های سروری و کتابخانه‌ای

JAR (Java ARchive) — برای کتابخانه‌های Java/Kotlin. AAR (Android ARchive) — برای کتابخانه‌های اندروید همراه با منابع. تصاویر Docker — مصنوعات کانتینری برای میکروسرویس‌ها. هر نوع رجیستری و قوانین مدیریت نسخه خاص خود را دارد.

مصنوعات در پایپ‌لاین CI/CD

مصنوعات — حلقه اتصال بین مراحل پایپ‌لاین هستند. هر مرحله مصنوعات مرحله قبل را مصرف می‌کند و مصنوعات جدیدی تولید می‌کند. درک این جریان برای پیکربندی CI/CD کارآمد حیاتی است.

جریان مصنوعات در پایپ‌لاین

جریان معمول شامل: commit ← سرور بیلد کد را کامپایل کرده و یک مصنوع بهینه‌نشده ایجاد می‌کند ← مصنوع تست برای اجرای تست‌ها استفاده می‌شود ← در صورت موفقیت، یک مصنوع انتشار ایجاد می‌شود ← امضا شده و در رجیستری مصنوعات منتشر می‌شود ← از رجیستری، مصنوع برای استقرار در staging و production برداشته می‌شود. هر انتقال بین مراحل با بررسی یکپارچگی و مطابقت با الزامات همراه است.

مصنوعات میانی و نهایی

پایپ‌لاین می‌تواند چندین مصنوع در مراحل مختلف ایجاد کند. مصنوعات Debug حاوی اطلاعات اشکال‌زدایی هستند، بهینه‌نشده — سریع برای تست ساخته می‌شوند، مصنوعات انتشار — نهایی، با بهینه‌سازی و مبهم‌سازی. سیستم 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

Cache vs Artifact

تمایز بین کش وابستگی‌ها و مصنوعات بیلد مهم است. کش (Gradle cache, CocoaPods cache) بیلدهای تکراری را تسریع می‌کند اما برای استقرار طراحی نشده است. مصنوعات — محصول نهایی آماده برای توزیع. برای کش TTL چند روزه تنظیم کنید، برای مصنوعات — هفته‌ها یا ماه‌ها.

ذخیره‌گاه‌های مصنوعات

مصنوعات نباید روی سرور بیلد ذخیره شوند — برای این منظور سیستم‌های تخصصی وجود دارند. Repository Manager ذخیره‌سازی متمرکز، نمایه‌سازی، کنترل دسترسی و یکپارچه‌سازی با ابزارهای CI/CD را فراهم می‌کند.

رجیستری‌های محبوب مصنوعات

JFrog Artifactory — مدیر جهانی پشتیبان Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — جایگزین متن‌باز با پشتیبانی از فرمت‌های اصلی. GitHub Packages — رجیستری داخلی در GitHub، مناسب برای تیم‌هایی که قبلاً از GitHub استفاده می‌کنند. GitLab Container Registry — برای تصاویر Docker.

معیارهای انتخاب رجیستری

عوامل اصلی: فرمت‌های پشتیبانی شده، مدل مجوز (open-source/enterprise)، یکپارچه‌سازی با CI/CD موجود، امکان تکرار بین مناطق، وجود سیاست‌های پاکسازی خودکار نسخه‌های قدیمی و گزارش‌های انطباق.

// Pipeline Jenkins — انتشار 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)

نسخه‌بندی و نام‌گذاری

استراتژی صحیح نسخه‌بندی مصنوعات برای تکرارپذیری بیلدها و ردیابی تغییرات حیاتی است. بدون نسخه‌بندی نمی‌توان تعیین کرد کدام نسخه از کد باعث مشکل در تولید شده است.

Semantic Versioning (SemVer)

استاندارد MAJOR.MINOR.PATCH: MAJOR با تغییرات ناسازگار API تغییر می‌کند، MINOR — با افزودن قابلیت سازگار با عقب، PATCH — با رفع‌های سازگار با عقب. برای CI/CD فراداده بیلد به نسخه اضافه می‌شود: 2.4.1+build.20260703.1. این امکان تعیین دقیق این را فراهم می‌کند که کدام commit مصنوع خاص را ایجاد کرده و چه زمانی ساخته شده است.

قابلیت ردیابی — ارتباط با Git

هر مصنوع باید فراداده‌ای درباره منشأ خود داشته باشد: commit SHA، شماره بیلد CI، نام شاخه، تاریخ بیلد. این اطلاعات در مانیفست مصنوع ثبت می‌شود و امکان بازیابی زمینه ایجاد آن را در هر لحظه فراهم می‌کند. بدون قابلیت ردیابی، کار با مصنوعات به حدس زدن نسخه‌ها تبدیل می‌شود که برای سیستم‌های تولیدی با الزامات حسابرسی غیرقابل قبول است.

نام‌گذاری مصنوعات

قرارداد نام: {project}-{module}-{version}.{ext}. به عنوان مثال: `messaging-sdk-2.4.1.aar` یا `app-release-2.4.1.apk`. سرور بیلد می‌تواند به طور خودکار نسخه را بر اساس تگ Git یا شماره بیلد CI تولید کند.

• از تگ Git به عنوان منبع نسخه استفاده کنید — این مصنوع را با وضعیت خاصی از کد مرتبط می‌کند
• commit SHA را به فراداده برای شناسایی دقیق در مرحله اشکال‌زدایی اضافه کنید
• خط‌مشی retention تنظیم کنید — N نسخه آخر را نگه دارید، بقیه را بایگانی کنید

Snapshot vs Release

در رجیستری‌های مصنوعات Maven/Gradle بین نسخه‌های release (ثابت، تغییرناپذیر) و نسخه‌های snapshot (توسعه جاری، قابل بازنویسی) تمایز قائل می‌شوند. در پایپ‌لاین‌های CI/CD، مصنوعات snapshot برای توسعه مناسب هستند، اما در تولید فقط باید از نسخه‌های release استفاده شود.

امنیت مصنوعات

مصنوعات — عنصر کلیدی زنجیره تأمین نرم‌افزار (software supply chain) هستند. به خطر افتادن مصنوع می‌تواند منجر به نفوذ کد مخرب به تولید شود. امنیت مصنوعات شامل چندین سطح حفاظت است.

امضای مصنوعات

فایل‌های 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 (حداکثر) را تعریف می‌کند. سرور بیلد باید provenance attestation — گواهی امضا شده رمزنگاری درباره نحوه و اینکه از چه کدی مصنوع ساخته شده است — ایجاد کند.