एप्लिकेशन डेवलपमेंट में 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 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 — 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। यह आपको यह निर्धारित करने की अनुमति देता है कि किस 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 जोड़ें डीबगिंग के दौरान सटीक पहचान के लिए मेटाडेटा में
• प्रतिधारण नीति कॉन्फ़िगर करें — नवीनतम 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 उत्पन्न करना चाहिए — एक क्रिप्टोग्राफिक रूप से हस्ताक्षरित बयान कि आर्टिफैक्ट कैसे और किस कोड से बनाया गया था।