Artifact ในการพัฒนาแอปพลิเคชัน: คืออะไร ประเภทและวิธีจัดการ

Artifact ในการพัฒนาคืออะไร

อาร์ติแฟกต์ (อาร์ติแฟกต์บิลด์) คือผลลัพธ์ของการคอมไพล์โค้ดต้นฉบับ พร้อมสำหรับการปรับใช้หรือใช้เป็น dependency กระบวนการบิลด์แปลงไฟล์ต้นฉบับ (Java, Kotlin, Swift, C++ และอื่นๆ) เป็นแพ็คเกจไบนารีที่สามารถทำงานบนอุปกรณ์เป้าหมายหรือเซิร์ฟเวอร์ได้

แนวคิดของอาร์ติแฟกต์นั้นกว้างกว่าไฟล์ที่ปฏิบัติการได้ ตัวอย่างเช่น ไลบรารี JAR คืออาร์ติแฟกต์ที่ใช้เป็น dependency ในโปรเจกต์อื่นๆ อิมเมจ 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 -> เซิร์ฟเวอร์บิลด์คอมไพล์โค้ดและสร้างอาร์ติแฟกต์ที่ไม่ได้ปรับแต่ง -> อาร์ติแฟกต์ทดสอบใช้สำหรับรันการทดสอบ -> เมื่อสำเร็จ จะสร้างอาร์ติแฟกต์รุ่น -> ลงชื่อและเผยแพร่ใน รีจิสทรีอาร์ติแฟกต์ -> ดึงอาร์ติแฟกต์จากรีจิสทรีเพื่อปรับใช้ใน staging และ production การเปลี่ยนผ่านแต่ละครั้งระหว่างขั้นตอนจะมาพร้อมกับการตรวจสอบความสมบูรณ์และการตรวจสอบการปฏิบัติตามข้อกำหนด

อาร์ติแฟกต์ระหว่างกลางและสุดท้าย

ไปป์ไลน์สามารถสร้างอาร์ติแฟกต์หลายรายการในขั้นตอนต่างๆ อาร์ติแฟกต์ดีบัก มีข้อมูลดีบัก ที่ไม่ได้ปรับแต่ง จะถูกบิลด์อย่างรวดเร็วสำหรับการทดสอบ อาร์ติแฟกต์รุ่นเป็นเวอร์ชันสุดท้ายที่มีการปรับแต่งและการทำให้สับสน ระบบ 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 อาร์ติแฟกต์

สิ่งสำคัญคือต้องแยกความแตกต่างระหว่างแคช dependency และอาร์ติแฟกต์บิลด์ แคช (แคช 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 — การเผยแพร่ 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, ชื่อสาขา, วันที่บิลด์ ข้อมูลนี้ จะถูกบันทึกใน manifest ของอาร์ติแฟกต์และช่วยให้สร้างบริบทการสร้างขึ้นใหม่ได้ทุกเมื่อ หากไม่มีการติดตาม การทำงานกับอาร์ติแฟกต์จะกลายเป็นการเดาเวอร์ชัน ซึ่งไม่สามารถยอมรับได้สำหรับระบบโปรดักชันที่มีข้อกำหนดการตรวจสอบ

การตั้งชื่ออาร์ติแฟกต์

ธรรมเนียมการตั้งชื่อ: {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 จะแยกความแตกต่างระหว่าง รุ่น release (คงที่, ไม่เปลี่ยนแปลงได้) และรุ่น snapshot (การพัฒนาปัจจุบัน, สามารถเขียนทับได้) ในไปป์ไลน์ CI/CD อาร์ติแฟกต์ snapshot สะดวกสำหรับการพัฒนา แต่ในโปรดักชันควรใช้เฉพาะรุ่น release เท่านั้น

ความปลอดภัยของอาร์ติแฟกต์

อาร์ติแฟกต์เป็นองค์ประกอบสำคัญของห่วงโซ่อุปทานซอฟต์แวร์ การประนีประนอมอาร์ติแฟกต์ อาจทำให้โค้ดที่เป็นอันตรายเข้าสู่โปรดักชัน ความปลอดภัยของอาร์ติแฟกต์รวมถึงหลายระดับการป้องกัน

การลงชื่ออาร์ติแฟกต์

ไฟล์ APK ลงชื่อด้วย jarsigner หรือ apksigner; ไฟล์ IPA ลงชื่อด้วยใบรับรอง Apple; อิมเมจ Docker ลงชื่อด้วย Content Trust (Notary) ของ Docker การลงชื่อรับประกันความสมบูรณ์และยืนยันผู้สร้างอาร์ติแฟกต์ ไปป์ไลน์ CI/CD ควรรวมการตรวจสอบลายเซ็นของ dependency บุคคลที่สามทั้งหมด

การสแกนช่องโหว่

ก่อนเผยแพร่ อาร์ติแฟกต์จะถูกตรวจสอบโดยสแกนเนอร์อัตโนมัติ: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot พวกเขาวิเคราะห์ dependency ที่รวมอยู่ เวอร์ชันของไลบรารีที่ใช้ และช่องโหว่ CVE ที่รู้จัก หากตรวจพบช่องโหว่ร้ายแรง การเผยแพร่จะถูกบล็อกทันทีจนกว่านักพัฒนาจะแก้ไข

ระดับห่วงโซ่อุปทาน

SLSA (Supply chain Levels for Software Artifacts) คือกรอบงานความปลอดภัยที่กำหนดระดับความเชื่อถือจาก SLSA 1 (พื้นฐาน) ถึง SLSA 4 (สูงสุด) เซิร์ฟเวอร์บิลด์ต้อง สร้างการรับรองแหล่งที่มา (provenance attestation) — คำแถลงที่ลงนามด้วยการเข้ารหัสเกี่ยวกับวิธีการและจากโค้ดใดที่อาร์ติแฟกต์ถูกสร้างขึ้น