Artifact trong phát triển ứng dụng: nó là gì, các loại và cách quản lý

Artifact trong phát triển là gì

Artifact (vật phẩm xây dựng) là kết quả của việc biên dịch mã nguồn, sẵn sàng để triển khai hoặc sử dụng như một phụ thuộc. Quá trình xây dựng chuyển đổi các tệp nguồn (Java, Kotlin, Swift, C++ và các ngôn ngữ khác) thành các gói nhị phân có thể chạy trên thiết bị hoặc máy chủ đích.

Khái niệm artifact không chỉ giới hạn ở các tệp thực thi. Ví dụ, một thư viện JAR là một artifact được sử dụng như phụ thuộc trong các dự án khác. Hình ảnh Docker là một artifact chứa ứng dụng và môi trường của nó. Ngay cả báo cáo độ phủ kiểm thử cũng có thể được coi là một artifact trong bối cảnh CI/CD.

Phát triển hiện đại trong các công ty lớn bao gồm việc quản lý hàng trăm nghìn artifact. Google DORA liên kết mức độ trưởng thành của quản lý artifact với hiệu quả DevOps tổng thể — các nhóm sử dụng registry artifact phát hành nhanh hơn và gặp ít vấn đề triển khai hơn.

Vòng đời của artifact

Mỗi artifact trải qua nhiều giai đoạn: tạo (xây dựng, biên dịch), xác thực (kiểm thử, kiểm tra bảo mật), lưu trữ (registry artifact), phân phối (xuất bản để tải xuống) và lưu trữ hoặc xóa (khi phiên bản trở nên lỗi thời).

Các loại artifact trong phát triển di động

Các nền tảng và công nghệ khác nhau tạo ra các định dạng artifact khác nhau. Hiểu các định dạng là cần thiết để cấu hình pipeline CI/CD chính xác và chọn hệ thống lưu trữ.

Artifact Android

APK (Android Package Kit) là định dạng gói cài đặt truyền thống. AAB (Android App Bundle) là định dạng hiện đại để xuất bản trên Google Play, chỉ chứa các tài nguyên cần thiết cho một thiết bị cụ thể. AAB giảm kích thước ứng dụng đã cài đặt trung bình 15-20% so với APK phổ thông.

Artifact iOS

IPA (iOS App Store Package) là một kho lưu trữ chứa mã và tài nguyên cho thiết bị iOS. XCArchive là một artifact trung gian được tạo bởi Xcode, từ đó IPA cuối cùng được xuất ra. dSYM là tệp ký hiệu gỡ lỗi cần thiết để biểu tượng hóa nhật ký sự cố.

Artifact dự án máy chủ và thư viện

JAR (Java ARchive) — cho thư viện Java/Kotlin. AAR (Android ARchive) — cho thư viện Android có tài nguyên. Hình ảnh Docker — artifact container cho microservice. Mỗi loại có registry riêng và quy tắc quản lý phiên bản riêng.

Artifact trong pipeline CI/CD

Artifact là cầu nối giữa các giai đoạn của pipeline. Mỗi giai đoạn tiêu thụ artifact từ giai đoạn trước và tạo ra artifact mới. Hiểu được luồng này là rất quan trọng để thiết lập một pipeline CI/CD hiệu quả.

Luồng artifact trong pipeline

Một luồng điển hình bao gồm: commit -> máy chủ xây dựng biên dịch mã và tạo artifact chưa tối ưu -> artifact kiểm thử được sử dụng để chạy kiểm thử -> nếu thành công, một artifact phát hành được tạo -> nó được ký và xuất bản trong registry artifact -> artifact được lấy từ registry để triển khai lên môi trường staging và sản xuất. Mỗi lần chuyển đổi giữa các giai đoạn đều đi kèm với kiểm tra tính toàn vẹn và xác nhận tuân thủ yêu cầu.

Artifact trung gian và cuối cùng

Pipeline có thể tạo nhiều artifact ở các giai đoạn khác nhau. Artifact gỡ lỗi chứa thông tin gỡ lỗi, chưa tối ưu được xây dựng nhanh để kiểm thử, artifact phát hành là phiên bản cuối cùng, đã được tối ưu hóa và làm rối. Hệ thống CI phải có khả năng phân biệt chúng và áp dụng chính sách lưu giữ phù hợp cho từng loại.

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 so với Artifact

Điều quan trọng là phân biệt giữa bộ nhớ đệm phụ thuộc và artifact xây dựng. Bộ nhớ đệm (bộ nhớ đệm Gradle, bộ nhớ đệm CocoaPods) tăng tốc các bản dựng lặp lại nhưng không nhằm mục đích triển khai. Artifact là sản phẩm cuối cùng, sẵn sàng để phân phối. Đặt TTL vài ngày cho bộ nhớ đệm và vài tuần hoặc vài tháng cho artifact.

Kho lưu trữ artifact

Artifact không nên được lưu trữ trên máy chủ xây dựng — có các hệ thống chuyên dụng cho mục đích này. Một Trình quản lý kho lưu trữ cung cấp lưu trữ tập trung, lập chỉ mục, kiểm soát truy cập và tích hợp với các công cụ CI/CD.

Các registry artifact phổ biến

JFrog Artifactory — một trình quản lý phổ quát hỗ trợ Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — một giải pháp thay thế mã nguồn mở hỗ trợ các định dạng chính. GitHub Packages — một registry tích hợp trong GitHub, thuận tiện cho các nhóm đã sử dụng GitHub. GitLab Container Registry — cho hình ảnh Docker.

Tiêu chí lựa chọn registry

Các yếu tố chính: định dạng được hỗ trợ, mô hình cấp phép (mã nguồn mở/doanh nghiệp), tích hợp với CI/CD hiện có, khả năng sao chép giữa các khu vực, sự sẵn có của chính sách dọn dẹp tự động cho các phiên bản cũ và báo cáo tuân thủ.

// Pipeline Jenkins — xuất bản APK lên 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)

Quản lý phiên bản và đặt tên

Một chiến lược quản lý phiên bản artifact phù hợp là rất quan trọng cho khả năng tái tạo bản dựng và theo dõi thay đổi. Nếu không có quản lý phiên bản, không thể xác định phiên bản mã nào đã gây ra sự cố trong sản xuất.

Quản lý phiên bản ngữ nghĩa (SemVer)

Tiêu chuẩn MAJOR.MINOR.PATCH: MAJOR thay đổi khi có thay đổi API không tương thích, MINOR khi bổ sung chức năng tương thích ngược, PATCH khi sửa lỗi tương thích ngược. Đối với CI/CD, siêu dữ liệu xây dựng được thêm vào phiên bản: 2.4.1+build.20260703.1. Điều này cho phép xác định chính xác commit nào đã tạo ra một artifact cụ thể và thời điểm nó được tạo.

Khả năng truy xuất — liên kết Git

Mỗi artifact nên chứa siêu dữ liệu về nguồn gốc của nó: SHA commit, số bản dựng CI, tên nhánh, ngày xây dựng. Thông tin này được ghi lại trong tệp kê khai artifact và cho phép tái tạo bối cảnh tạo ra nó bất kỳ lúc nào. Nếu không có khả năng truy xuất, làm việc với artifact trở thành việc đoán phiên bản, điều không thể chấp nhận được đối với hệ thống sản xuất có yêu cầu kiểm toán.

Đặt tên artifact

Quy ước đặt tên: {project}-{module}-{version}.{ext}. Ví dụ: messaging-sdk-2.4.1.aar hoặc app-release-2.4.1.apk. Máy chủ xây dựng có thể tự động tạo phiên bản dựa trên thẻ Git hoặc số bản dựng của hệ thống CI.

• Sử dụng thẻ Git làm nguồn phiên bản — điều này liên kết artifact với một trạng thái mã cụ thể
• Thêm SHA commit vào siêu dữ liệu để xác định chính xác trong quá trình gỡ lỗi
• Cấu hình chính sách lưu giữ — giữ lại N phiên bản mới nhất, lưu trữ phần còn lại

Snapshot so với Release

Trong registry artifact Maven/Gradle, phiên bản phát hành (cố định, không thể thay đổi) và phiên bản snapshot (đang phát triển, có thể ghi đè) được phân biệt. Trong pipeline CI/CD, artifact snapshot thuận tiện cho phát triển, nhưng trong sản xuất chỉ nên sử dụng phiên bản phát hành.

Bảo mật artifact

Artifact là một yếu tố chính của chuỗi cung ứng phần mềm. Việc xâm phạm artifact có thể dẫn đến mã độc xâm nhập vào sản xuất. Bảo mật artifact bao gồm nhiều cấp độ bảo vệ.

Ký số artifact

Tệp APK được ký bằng jarsigner hoặc apksigner; tệp IPA được ký bằng chứng chỉ Apple; hình ảnh Docker được ký bằng Content Trust (Notary) của Docker. Ký số đảm bảo tính toàn vẹn và xác nhận tác giả của artifact. Pipeline CI/CD nên bao gồm xác minh chữ ký cho tất cả các phụ thuộc bên thứ ba.

Quét lỗ hổng

Trước khi xuất bản, artifact được kiểm tra bằng các máy quét tự động: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Chúng phân tích các phụ thuộc được bao gồm, phiên bản của thư viện được sử dụng và các lỗ hổng CVE đã biết. Nếu phát hiện lỗ hổng nghiêm trọng, bản phát hành sẽ bị chặn ngay lập tức cho đến khi được nhà phát triển khắc phục.

Cấp độ chuỗi cung ứng

SLSA (Supply chain Levels for Software Artifacts) là một khung bảo mật xác định các cấp độ tin cậy từ SLSA 1 (cơ bản) đến SLSA 4 (tối đa). Máy chủ xây dựng phải tạo ra một chứng thực nguồn gốc (provenance attestation) — một tuyên bố được ký bằng mật mã về cách thức và từ mã nguồn nào artifact được xây dựng.