Artifact sa pag-develop ng app: ano ito, mga uri at paano pamahalaan

Ano ang Artifact sa pag-develop

Artifact (build artifact) — ay resulta ng pag-compile ng source code, handa para sa deployment o paggamit bilang dependency. Ang proseso ng build ay nagko-convert ng mga source file (Java, Kotlin, Swift, C++, at iba pa) sa binary package na maaaring patakbuhin sa target na device o server.

Ang konsepto ng artifact ay lumalampas sa executable file. Halimbawa, JAR library — ay isang artifact na ginagamit bilang dependency sa ibang proyekto. Docker image — artifact na naglalaman ng app at environment nito. Kahit ang report ng test coverage ay maituturing na artifact sa konteksto ng CI/CD.

Ang modernong pag-develop sa malalaking kumpanya ay kinabibilangan ng pamamahala sa daan-daang libong artifact. Google DORA ay nag-uugnay ng kapanahunan ng pamamahala ng artifact sa pangkalahatang epektibidad ng DevOps — ang mga team na gumagamit ng artifact registry ay mas mabilis mag-release at mas madalang makaranas ng problema sa deployment.

Lifecycle ng artifact

Ang bawat artifact ay dumadaan sa ilang yugto: paglikha (build, compilation), validation (testing, security check), pag-imbak (artifact registry), pamamahagi (pag-publish para i-download), at pag-archive o pagtanggal (kapag luma na ang bersyon).

Mga uri ng artifact sa mobile development

Ang iba't ibang platform at teknolohiya ay gumagawa ng iba't ibang format ng artifact. Pag-unawa sa mga format ay kinakailangan para sa tamang configuration ng CI/CD pipeline at pagpili ng storage system.

Android artifact

APK (Android Package Kit) — tradisyonal na format ng installation package. AAB (Android App Bundle) — modernong format para sa pag-publish sa Google Play, na naglalaman lamang ng mga resource na kailangan ng partikular na device. Binabawasan ng AAB ang laki ng naka-install na app ng average na 15-20% kumpara sa universal APK.

iOS artifact

IPA (iOS App Store Package) — archive na may code at resources para sa iOS device. XCArchive — intermediate artifact na ginawa ng Xcode, kung saan ine-export ang final IPA. dSYM — debug file na kailangan para sa simbolisasyon ng crash logs.

Mga artifact ng server at library projects

JAR (Java ARchive) — para sa Java/Kotlin library. AAR (Android ARchive) — para sa Android library na may resources. Docker image — container artifact para sa microservices. Ang bawat uri ay may sariling registry at rules para sa version management.

Mga artifact sa CI/CD pipeline

Ang mga artifact — ang nag-uugnay sa pagitan ng mga yugto ng pipeline. Bawat yugto ay kumokonsumo ng artifact ng nauna at gumagawa ng bago. Ang pag-unawa sa daloy na ito ay kritikal para sa configuration ng epektibong CI/CD.

Daloy ng mga artifact sa pipeline

Karaniwang daloy ay kinabibilangan ng: commit → build server ay nag-compile ng code at gumagawa ng hindi-optimized na artifact → test artifact ay ginagamit para sa pagpapatakbo ng tests → kapag successful, ginagawa ang release artifact → ito ay si-sign at ipo-publish sa artifact registry → mula sa registry, kukunin ang artifact para i-deploy sa staging at production. Bawat transition sa pagitan ng yugto ay may kasamang verification ng integridad at pagsunod sa mga kinakailangan.

Mga intermediate at final artifact

Ang pipeline ay maaaring gumawa ng maraming artifact sa iba't ibang yugto. Debug artifact ay naglalaman ng debug information, hindi-optimized — mabilis na binuo para sa testing, release artifact — final, na may optimization at obfuscation. Ang CI system ay dapat na makilala ang mga ito at mag-apply ng angkop na storage policy para sa bawat uri.

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

Mahalagang pag-iba-ibahin ang dependency cache at build artifact. Cache (Gradle cache, CocoaPods cache) ay nagpapabilis ng paulit-ulit na build, ngunit hindi para sa deployment. Artifact — final product na handa para sa pamamahagi. Para sa cache, mag-set ng TTL ng ilang araw, para sa artifact — linggo o buwan.

Mga imbakan ng artifact

Ang mga artifact ay hindi dapat i-imbak sa build server — para dito may mga specialized system. Repository Manager ay nagbibigay ng sentralisadong imbakan, pag-index, kontrol sa access, at integrasyon sa CI/CD tools.

Sikat na artifact registry

JFrog Artifactory — universal manager na sumusuporta sa Maven, Gradle, Docker, NuGet, npm, APT, YUM. Sonatype Nexus — open-source na alternatibo na may suporta para sa mga pangunahing format. GitHub Packages — built-in registry sa GitHub, maginhawa para sa mga team na gumagamit na ng GitHub. GitLab Container Registry — para sa Docker image.

Criteria sa pagpili ng registry

Mga pangunahing factor: mga format na sinusuportahan, modelo ng lisensya (open-source/enterprise), integrasyon sa kasalukuyang CI/CD, kakayahang mag-replicate sa pagitan ng mga rehiyon, pagkakaroon ng auto-cleanup policy para sa lumang bersyon, at compliance report.

// Jenkins pipeline — pag-publish ng APK sa 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)

Pag-version at pagpapangalan

Ang tamang strategy sa pag-version ng artifact ay kritikal para sa reproducibility ng build at pagsubaybay sa mga pagbabago. Kung walang pag-version, hindi matutukoy kung aling bersyon ng code ang nagdulot ng problema sa production.

Semantic Versioning (SemVer)

Standard MAJOR.MINOR.PATCH: Nagbabago ang MAJOR sa mga hindi compatible na API changes, MINOR — sa pagdagdag ng backward-compatible functionality, PATCH — sa backward-compatible fixes. Para sa CI/CD, idinadagdag ang build metadata sa version: 2.4.1+build.20260703.1. Ito ay nagbibigay-daan sa tumpak na pagtukoy kung aling commit ang gumawa ng partikular na artifact at kung kailan ito ginawa.

Traceability — kaugnayan sa Git

Ang bawat artifact ay dapat maglaman ng metadata tungkol sa pinagmulan nito: commit SHA, CI build number, branch name, build date. Ang impormasyong ito ay naitala sa manifest ng artifact at nagbibigay-daan sa pag-reconstruct ng konteksto ng paggawa nito anumang oras. Kung walang traceability, ang pagtatrabaho sa artifact ay nagiging hulaan ng bersyon, na hindi katanggap-tanggap para sa production system na may audit requirements.

Pagpapangalan ng artifact

Convention ng pangalan: {project}-{module}-{version}.{ext}. Halimbawa: `messaging-sdk-2.4.1.aar` o `app-release-2.4.1.apk`. Ang build server ay maaaring awtomatikong gumawa ng version batay sa Git tag o CI build number.

• Gamitin ang Git tag bilang source ng version — ito ay nag-uugnay ng artifact sa partikular na state ng code
• Idagdag ang commit SHA sa metadata para sa tumpak na identification sa debugging stage
• Mag-configure ng retention policy — itago ang huling N version, i-archive ang natitira

Snapshot vs Release

Sa Maven/Gradle artifact registry, pinag-iiba ang release version (fixed, hindi nababago) at snapshot version (kasalukuyang development, maaaring ma-overwrite). Sa CI/CD pipelines, ang snapshot artifact ay maginhawa para sa development, ngunit sa production ay release version lang ang dapat gamitin.

Seguridad ng mga artifact

Ang mga artifact — pangunahing elemento ng software supply chain. Ang kompromiso ng artifact ay maaaring humantong sa pagpasok ng malisyosong code sa production. Ang seguridad ng artifact ay may kasamang ilang antas ng proteksyon.

Pag-sign ng artifact

Ang APK file ay sini-sign gamit ang jarsigner o apksigner; IPA — gamit ang Apple certificate; Docker image — gamit ang Content Trust (Notary) mula sa Docker. Ang pag-sign ay ginagarantiyahan ang integridad at kinukumpirma ang may-akda ng artifact. Ang CI/CD pipeline ay dapat may kasamang verification ng mga signatura ng lahat ng third-party na dependency.

Pag-scan ng mga kahinaan

Bago i-publish, ang artifact ay sinusuri ng automatic scanners: Snyk, Trivy, Sonatype Nexus IQ, GitHub Dependabot. Sila ay nag-a-analyze ng mga kasamang dependency, bersyon ng ginamit na library, at kilalang CVE vulnerabilities. Kapag may nakitang kritikal na kahinaan, ang release ay agad na bina-block hanggang sa maayos ito ng mga developer.

Supply chain levels

SLSA (Supply chain Levels for Software Artifacts) — security framework na nagtatakda ng mga antas ng tiwala mula SLSA 1 (basic) hanggang SLSA 4 (maximum). Ang build server ay dapat gumawa ng provenance attestation — cryptographically signed na patunay kung paano at mula sa anong code ginawa ang artifact.