অ্যাপ্লিকেশন ডেভেলপমেন্টে 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 তৈরি করতে হবে — একটি ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত বিবৃতি যে কীভাবে এবং কী কোড থেকে আর্টিফ্যাক্ট তৈরি করা হয়েছিল।