ایپلیکیشن ڈویلپمنٹ میں Artifact: یہ کیا ہے، اقسام اور کیسے منظم کریں

ڈویلپمنٹ میں Artifact کیا ہے

آرٹیفیکٹ (بلڈ آرٹیفیکٹ) سورس کوڈ کی ترتیب کا نتیجہ ہے، تعیناتی یا انحصار کے طور پر استعمال کے لیے تیار۔ بلڈ کا عمل سورس فائلوں (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 جامع APK کے مقابلے میں انسٹال شدہ ایپلیکیشن کے سائز کو اوسطاً 15-20% کم کرتا ہے۔

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

کیشے بمقابلہ آرٹیفیکٹ

انحصار کیشے اور بلڈ آرٹیفیکٹ کے درمیان فرق کرنا ضروری ہے۔ کیشے (Gradle کیشے، CocoaPods کیشے) بار بار بلڈ کو تیز کرتا ہے لیکن تعیناتی کے لیے نہیں ہے۔ آرٹیفیکٹ حتمی پروڈکٹ ہیں، تقسیم کے لیے تیار۔ کیشے کے لیے کئی دنوں کا 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 — Artifactory میں APK شائع کرنا
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۔ یہ آپ کو یہ تعین کرنے کی اجازت دیتا ہے کہ کس کمٹ نے ایک مخصوص آرٹیفیکٹ بنایا اور یہ کب تخلیق ہوا۔

ٹریس ایبلٹی — Git لنک

ہر آرٹیفیکٹ کو اپنی اصلیت کے بارے میں میٹا ڈیٹا رکھنا چاہیے: کمٹ SHA، CI بلڈ نمبر، برانچ کا نام، بلڈ کی تاریخ۔ یہ معلومات آرٹیفیکٹ مینی فیسٹ میں ریکارڈ کی جاتی ہیں اور کسی بھی وقت اس کی تخلیق کے سیاق و سباق کو دوبارہ تشکیل دینے کی اجازت دیتی ہیں۔ ٹریس ایبلٹی کے بغیر، آرٹیفیکٹ کے ساتھ کام کرنا ورژن کا اندازہ لگانے میں بدل جاتا ہے، جو آڈٹ کی ضروریات والے پروڈکشن سسٹمز کے لیے ناقابل قبول ہے۔

آرٹیفیکٹ کا نام دینا

نام دینے کی روایت: {project}-{module}-{version}.{ext}۔ مثال کے طور پر: messaging-sdk-2.4.1.aar یا app-release-2.4.1.apk۔ بلڈ سرور Git ٹیگ یا CI سسٹم بلڈ نمبر کی بنیاد پر خود بخود ورژن بنا سکتا ہے۔

• Git ٹیگ کو ورژن ماخذ کے طور پر استعمال کریں — یہ آرٹیفیکٹ کو ایک مخصوص کوڈ کی حالت سے جوڑتا ہے
• کمٹ SHA کو میٹا ڈیٹا میں شامل کریں — ڈبگنگ کے دوران درست شناخت کے لیے
• برقرار رکھنے کی پالیسی ترتیب دیں — تازہ ترین N ورژن رکھیں، باقی آرکائیو کریں

Snapshot بمقابلہ Release

Maven/Gradle آرٹیفیکٹ رجسٹریوں میں، ریلیز ورژن (مقررہ، ناقابل تبدیلی) اور سنیپ شاٹ ورژن (موجودہ ترقی، اوور رائٹ کیے جا سکتے ہیں) میں فرق کیا جاتا ہے۔ CI/CD پائپ لائنوں میں، سنیپ شاٹ آرٹیفیکٹ ترقی کے لیے آسان ہیں، لیکن پروڈکشن میں صرف ریلیز ورژن استعمال کرنے چاہئیں۔

آرٹیفیکٹ سیکیورٹی

آرٹیفیکٹ سافٹ ویئر سپلائی چین کا ایک اہم عنصر ہیں۔ آرٹیفیکٹ سے سمجھوتہ پروڈکشن میں نقصان دہ کوڈ کے داخل ہونے کا سبب بن سکتا ہے۔ آرٹیفیکٹ سیکیورٹی میں کئی تحفظ کی سطحیں شامل ہیں۔

آرٹیفیکٹ پر دستخط

APK فائلوں پر jarsigner یا apksigner سے دستخط کیے جاتے ہیں؛ IPA فائلوں پر Apple سرٹیفکیٹ سے دستخط کیے جاتے ہیں؛ Docker امیجز پر Docker کے Content Trust (Notary) سے دستخط کیے جاتے ہیں۔ دستخط سالمیت کی ضمانت دیتا ہے اور آرٹیفیکٹ کے مصنف کی تصدیق کرتا ہے۔ CI/CD پائپ لائن میں تمام تیسرے فریق کے انحصار کے دستخط کی تصدیق شامل ہونی چاہیے۔

کمزوریوں کا اسکیننگ

اشاعت سے پہلے، آرٹیفیکٹ خودکار اسکینرز کے ذریعے چیک کیا جاتا ہے: Snyk، Trivy، Sonatype Nexus IQ، GitHub Dependabot۔ وہ شامل انحصار، استعمال شدہ لائبریریوں کے ورژن اور معروف CVE کمزوریوں کا تجزیہ کرتے ہیں۔ اگر کوئی سنگین کمزوری پائی جاتی ہے، تو ڈویلپرز کے ذریعے اسے ٹھیک کرنے تک ریلیز فوری طور پر روک دی جاتی ہے۔

سپلائی چین کی سطحیں

SLSA (Supply chain Levels for Software Artifacts) ایک سیکیورٹی فریم ورک ہے جو SLSA 1 (بنیادی) سے SLSA 4 (زیادہ سے زیادہ) تک اعتماد کی سطحوں کی وضاحت کرتا ہے۔ بلڈ سرور کو provenance attestation تیار کرنا چاہیے — ایک خفیہ نگاری سے دستخط شدہ بیان کہ آرٹیفیکٹ کیسے اور کس کوڈ سے بنایا گیا۔