Artifact dalam pengembangan aplikasi: apa itu, jenis dan cara mengelola

Apa itu Artifact dalam pengembangan

Artifact (artefak build) — adalah hasil kompilasi kode sumber, siap untuk digunakan atau sebagai dependensi. Proses build mengubah file sumber (Java, Kotlin, Swift, C++, dan lainnya) menjadi paket biner yang dapat dijalankan di perangkat target atau server.

Konsep artefak melampaui file yang dapat dieksekusi. Misalnya, library JAR — adalah artefak yang digunakan sebagai dependensi di proyek lain. Image Docker — artefak yang berisi aplikasi dan lingkungannya. Bahkan laporan cakupan tes dapat dianggap sebagai artefak dalam konteks CI/CD.

Pengembangan modern di perusahaan besar mencakup manajemen ratusan ribu artefak. Google DORA menghubungkan kematangan manajemen artefak dengan efektivitas DevOps secara keseluruhan — tim yang menggunakan registry artefak merilis lebih cepat dan lebih jarang menghadapi masalah saat penerapan.

Siklus hidup artefak

Setiap artefak melewati beberapa tahap: pembuatan (build, kompilasi), validasi (pengujian, pemeriksaan keamanan), penyimpanan (registry artefak), distribusi (publikasi untuk diunduh), dan pengarsipan atau penghapusan (ketika versi sudah usang).

Jenis artefak dalam pengembangan mobile

Platform dan teknologi yang berbeda menghasilkan format artefak yang berbeda. Memahami format diperlukan untuk konfigurasi pipeline CI/CD yang benar dan pemilihan sistem penyimpanan.

Artefak Android

APK (Android Package Kit) — format paket instalasi tradisional. AAB (Android App Bundle) — format modern untuk publikasi di Google Play, yang hanya berisi sumber daya yang diperlukan perangkat tertentu. AAB mengurangi ukuran aplikasi yang diinstal rata-rata 15-20% dibandingkan dengan APK universal.

Artefak iOS

IPA (iOS App Store Package) — arsip dengan kode dan sumber daya untuk perangkat iOS. XCArchive — artefak perantara yang dibuat oleh Xcode, dari mana IPA final diekspor. dSYM — file debug yang diperlukan untuk simbolisasi log crash.

Artefak proyek server dan library

JAR (Java ARchive) — untuk library Java/Kotlin. AAR (Android ARchive) — untuk library Android dengan sumber daya. Image Docker — artefak kontainer untuk mikroservis. Setiap jenis memiliki registry dan aturan manajemen versi sendiri.

Artefak dalam pipeline CI/CD

Artefak — penghubung antara tahap pipeline. Setiap tahap mengonsumsi artefak dari tahap sebelumnya dan menghasilkan yang baru. Memahami aliran ini sangat penting untuk konfigurasi CI/CD yang efektif.

Aliran artefak dalam pipeline

Aliran tipikal meliputi: commit → server build mengompilasi kode dan membuat artefak yang tidak dioptimalkan → artefak tes digunakan untuk menjalankan tes → jika berhasil, artefak rilis dibuat → ditandatangani dan dipublikasikan di registry artefak → dari registry, artefak diambil untuk penerapan ke staging dan produksi. Setiap transisi antar tahap disertai dengan verifikasi integritas dan kesesuaian.

Artefak antara dan akhir

Pipeline dapat membuat beberapa artefak di tahap yang berbeda. Artefak Debug berisi informasi debug, tidak dioptimalkan — dibuat cepat untuk pengujian, artefak rilis — final, dengan optimasi dan obfuskasi. Sistem CI harus dapat membedakannya dan menerapkan kebijakan penyimpanan yang sesuai untuk setiap jenis.

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 vs Artifact

Penting untuk membedakan cache dependensi dan artefak build. Cache (Gradle cache, CocoaPods cache) mempercepat build berulang, tetapi tidak dimaksudkan untuk penerapan. Artefak — produk akhir siap didistribusikan. Untuk cache, atur TTL beberapa hari, untuk artefak — minggu atau bulan.

Penyimpanan artefak

Artefak tidak boleh disimpan di server build — untuk itu ada sistem khusus. Repository Manager menyediakan penyimpanan terpusat, pengindeksan, kontrol akses, dan integrasi dengan alat CI/CD.

Registry artefak populer

JFrog Artifactory — manajer universal yang mendukung Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — alternatif open-source dengan dukungan format utama. GitHub Packages — registry bawaan di GitHub, nyaman untuk tim yang sudah menggunakan GitHub. GitLab Container Registry — untuk image Docker.

Kriteria pemilihan registry

Faktor utama: format yang didukung, model lisensi (open-source/enterprise), integrasi dengan CI/CD yang ada, kemampuan replikasi antar region, adanya kebijakan pembersihan otomatis versi lama, dan laporan kepatuhan.

// Pipeline Jenkins — publikasi APK ke 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)

Versioning dan penamaan

Strategi versioning artefak yang tepat sangat penting untuk reproduksibilitas build dan pelacakan perubahan. Tanpa versioning, tidak mungkin menentukan versi kode mana yang menyebabkan masalah di produksi.

Semantic Versioning (SemVer)

Standar MAJOR.MINOR.PATCH: MAJOR berubah pada perubahan API yang tidak kompatibel, MINOR — saat menambahkan fungsionalitas yang kompatibel mundur, PATCH — pada perbaikan yang kompatibel mundur. Untuk CI/CD, metadata build ditambahkan ke versi: 2.4.1+build.20260703.1. Ini memungkinkan penentuan yang tepat commit mana yang menghasilkan artefak tertentu dan kapan dibuatnya.

Traceability — hubungan dengan Git

Setiap artefak harus berisi metadata tentang asal-usulnya: commit SHA, nomor build CI, nama cabang, tanggal build. Informasi ini dicatat dalam manifes artefak dan memungkinkan rekonstruksi konteks pembuatannya kapan saja. Tanpa traceability, bekerja dengan artefak menjadi tebak-tebakan versi, yang tidak dapat diterima untuk sistem produksi dengan persyaratan audit.

Penamaan artefak

Konvensi penamaan: {project}-{module}-{version}.{ext}. Contoh: `messaging-sdk-2.4.1.aar` atau `app-release-2.4.1.apk`. Server build dapat secara otomatis menghasilkan versi berdasarkan tag Git atau nomor build CI.

• Gunakan tag Git sebagai sumber versi — ini menghubungkan artefak dengan status kode tertentu
• Tambahkan commit SHA ke metadata untuk identifikasi yang tepat saat debugging
• Konfigurasikan kebijakan retensi — simpan N versi terakhir, arsipkan sisanya

Snapshot vs Release

Di registry artefak Maven/Gradle, dibedakan antara versi release (tetap, tidak dapat diubah) dan versi snapshot (pengembangan saat ini, dapat ditimpa). Dalam pipeline CI/CD, artefak snapshot nyaman untuk pengembangan, tetapi di produksi hanya versi release yang boleh digunakan.

Keamanan artefak

Artefak — elemen kunci rantai pasokan perangkat lunak (software supply chain). Kompromi artefak dapat menyebabkan kode berbahaya masuk ke produksi. Keamanan artefak mencakup beberapa tingkat perlindungan.

Penandatanganan artefak

File APK ditandatangani dengan jarsigner atau apksigner; IPA — dengan sertifikat Apple; image Docker — dengan Content Trust (Notary) dari Docker. Tanda tangan menjamin integritas dan mengonfirmasi penulis artefak. Pipeline CI/CD harus mencakup verifikasi tanda tangan semua dependensi pihak ketiga.

Pemindaian kerentanan

Sebelum publikasi, artefak diperiksa oleh pemindai otomatis: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Mereka menganalisis dependensi yang disertakan, versi library yang digunakan, dan kerentanan CVE yang diketahui. Jika kerentanan kritis terdeteksi, rilis segera diblokir sampai diperbaiki oleh pengembang.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — kerangka kerja keamanan yang mendefinisikan tingkat kepercayaan dari SLSA 1 (dasar) hingga SLSA 4 (maksimum). Server build harus menghasilkan provenance attestation — bukti yang ditandatangani secara kriptografis tentang bagaimana dan dari kode mana artefak dibuat.