Belajar DevOps Engineer - Artifact & Environment Management

#Pendahuluan

Di episode 5 CI menghasilkan artifact, dan di episode 6 artifact itu diteruskan ke environment. Namun ada satu pertanyaan yang belum dijawab tuntas: apa yang terjadi pada artifact di tengah perjalanan? Jika artifact dibangun ulang di setiap environment, atau diubah di tengah jalan, maka yang diuji di staging bukan lagi yang dirilis ke produksi.

Artifact management menjawabnya dengan satu prinsip: build once, run anywhere. Artifact dibangun sekali, ditandai dengan versi yang immutable, lalu dipromosikan antar-environment — bukan dibangun ulang. Di episode ini kalian memahami container registry, versioning, dan pola promotion yang benar dalam pipeline release.

#Artifact Immutable: Fondasi Rilis yang Aman

Artifact adalah hasil build yang siap dijalankan: image container, binary, package, atau bundle. Sifat yang wajib dijaga:

• Immutable — isi artifact tidak pernah berubah setelah dipublish.
• Identifiable — setiap artifact bisa diidentifikasi secara unik (versi + digest).
• Traceable — dari commit mana ia berasal, siapa yang membangun, kapan.

Jika artifact bersifat mutable (misal tag latest yang ditimpa), kalian kehilangan segalanya: rollback tidak bisa menunjuk ke versi lama, audit tidak bisa membuktikan apa yang berjalan, dan perbedaan staging vs produksi menjadi misteri.

#Container Registry dan Versioning

Registry (episode 7) adalah tempat artifact hidup. Kunci penggunaannya ada di tag dan digest:

ghcr.io/username/myapp:1.2.0        # tag versi (semver)
ghcr.io/username/myapp@sha256:a1b2... # digest — immutable, tidak bisa ditimpa

Aturan versioning yang harus dipegang:

• SemVer — MAJOR.MINOR.PATCH; breaking change menaikkan MAJOR.
• Satu build, satu versi — tag dibuat sekali; jika build gagal, versi di-skip, bukan dipakai ulang.
• Digest sebagai kebenaran akhir — ketika audit butuh kepastian mutlak, gunakan digest, bukan tag.
• Jangan pernah menimpa tag — myapp:1.2.0 yang sudah dipakai tidak boleh di-push ulang dengan isi berbeda.

docker tag myapp:1.2.0 ghcr.io/username/myapp:1.2.0
docker push ghcr.io/username/myapp:1.2.0
docker inspect ghcr.io/username/myapp:1.2.0 --format '{{index .RepoDigests 0}}'
# ghcr.io/username/myapp@sha256:a1b2c3... (digest unik, tidak berubah)

#Environment dan Artifact Promotion

Rantai environment dari episode 6 menjadi jelas artinya di sini: setiap environment mengonsumsi artifact yang sama persis — yang berbeda hanya konfigurasi dan data.

Promotion bukan "menyalin artifact", melainkan mengubah environment mana yang memakai artifact itu — seringnya dengan meng-update referensi di manifest Git (GitOps, episode 14). Artifact tetap satu; yang berubah adalah penunjuknya.

#Praktik: Pipeline Release dengan Artifact Promotion

Pipeline release yang benar memisahkan build (sekali) dari promotion (berulang). Contoh dengan GitHub Actions menggunakan reusable workflow:

name: Release
on:
  push:
    tags: ["v*"]
 
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build dan push sekali
        uses: docker/build-push-action@v6
        with:
          push: true
          tags: |
            ghcr.io/username/myapp:${{ github.ref_name }}
            ghcr.io/username/myapp:sha-${{ github.sha }}
      - name: Generate SBOM
        run: syft scan ghcr.io/username/myapp:${{ github.ref_name }} -o spdx-json > sbom.json
 
  promote-staging:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Update tag di manifest staging
        run: |
          git clone https://github.com/username/deploy-manifests.git
          sed -i "s|tag: .*|tag: ${{ github.ref_name }}|" deploy-manifests/staging/values.yaml
          git -C deploy-manifests commit -am "promote ${{ github.ref_name }} ke staging"
          git -C deploy-manifests push
 
  promote-prod:
    needs: promote-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: Update tag di manifest produksi
        run: |
          git clone https://github.com/username/deploy-manifests.git
          sed -i "s|tag: .*|tag: ${{ github.ref_name }}|" deploy-manifests/prod/values.yaml
          git -C deploy-manifests commit -am "promote ${{ github.ref_name }} ke produksi"
          git -C deploy-manifests push

#Kebijakan Environment: Immutable vs Reusable

Dua filosofi pengelolaan environment:

• Immutable environments — setiap rilis membuat environment baru (blue-green dari episode 6). Konsisten dan aman, tapi lebih mahal.
• Reusable environments — dev/staging/prod yang sama diperbarui terus-menerus. Hemat, tapi rawan drift antar-rilis.

Kebanyakan tim memakai kombinasi: environment dev/staging reusable, sementara produksi memakai pola blue-green atau canary dengan environment yang dapat diganti cepat.

#Pitfall Umum

• Tag latest untuk produksi — menimpa kebenaran dan membuat rollback tidak mungkin diarahkan dengan pasti.
• Build ulang di tiap environment — perbedaan kecil (versi dependency, flag build) menciptakan bug "hanya di produksi".
• Promotion tanpa SBOM/scan — artifact harus ter-scan sebelum menuju produksi (episode 18).
• Environment tanpa pemisahan secret — prod memakai config dev adalah bencana yang menunggu terjadi.
• Tanpa audit trail — kalian harus bisa menjawab "versi apa yang berjalan di produksi sejak jam berapa?" kapan pun diminta.

#Penutup

Inti yang harus dibawa pulang:

• Artifact harus immutable, identifiable, traceable — build sekali, run di mana pun.
• SemVer + digest membuat setiap rilis dapat diidentifikasi dan di-rollback dengan pasti.
• Promotion = mengubah referensi environment ke artifact yang sama, bukan menyalin artifact.
• Pipeline release memisahkan build dari promotion, dengan gate di setiap environment.

Di episode 18 selanjutnya kita masuk DevSecOps & Shift-Left Security — menggeser keamanan ke awal pipeline: SAST/DAST, dependency scanning, supply-chain (SLSA/SBOM), dan policy-as-code dengan OPA. Artifact yang kalian promosikan di episode ini kini harus melewati gerbang keamanan otomatis.