Belajar GitLab CI/CD - Directed Acyclic Graph (DAG) Pipelines dengan needs

#Pendahuluan

Di episode 8 kita mempercepat pipeline lewat caching. Sekarang bayangkan masalah lain: pipeline kalian punya lima job di stage build dan tiga job di stage test. Job test pertama hanya butuh satu job build, tapi ia harus menunggu seluruh job build selesai — termasuk job build yang sama sekali tidak relevan. Semakin besar tim, semakin banyak job yang tidak saling bergantung, dan semakin lama waktu terbuang di balik aturan stage yang kaku.

Ini adalah keluhan paling umum di pipeline besar: "pipenya lambat padahal job-nya cepat". Episode ini membahas solusinya — Directed Acyclic Graph (DAG) pipelines dengan keyword needs: . Kalian akan belajar mengapa pipeline stage tradisional lambat, bagaimana DAG memecahkan kebuntuan itu, dan kapan harus menggunakannya dengan bijak.

#Pembahasan Utama

#Masalah Pipeline Stage yang Linear

Pipeline default GitLab mengikuti aturan ketat: semua job di stage N harus selesai sebelum job di stage N+1 dimulai. Bayangkan restoran yang hanya menyajikan menu set — semua hidangan harus selesai dimasak dulu sebelum satu pun dikirim ke meja. Padahal kenyataannya, tamu yang memesan hanya sup tidak perlu menunggu steak panggang selesai.

stages:
  - build
  - test
  - deploy
 
build_a:
  stage: build
  script:
    - echo "build module A"
    - sleep 20
 
build_b:
  stage: build
  script:
    - echo "build module B"
    - sleep 20
 
test_a:
  stage: test
  script:
    - echo "test module A"

Di pipeline ini, test_a hanya bergantung pada build_a, tapi ia dipaksa menunggu build_b selesai — 20 detik terbuang sia-sia. Sekarang kalikan dengan puluhan job, dan kalian paham mengapa pipeline besar terasa seperti menunggu antrean yang tidak perlu.

#Konsep Directed Acyclic Graph (DAG)

DAG membalik paradigma tersebut: sebuah job boleh berjalan begitu semua dependensinya selesai, tanpa menunggu stage lain rampung. Kata "acyclic" menegaskan aturannya: tidak boleh ada dependency yang membentuk lingkaran (A menunggu B dan B menunggu A). Hasilnya adalah graph berarah yang masing-masing job hanya menunggu apa yang benar-benar dibutuhkannya.

Kembali ke analogi restoran: alih-alih menyajikan menu set, DAG mengirim tiap hidangan begitu hidangan itu siap — tamu yang memesan sup tidak pernah menunggu steak. GitLab menerapkan konsep ini lewat keyword needs: sejak GitLab 12.2, dan hasilnya bisa memangkas durasi pipeline hingga 50 persen atau lebih.

#Sintaks Dasar needs:

stages:
  - build
  - test
  - deploy
 
build_a:
  stage: build
  script:
    - echo "build module A"
    - sleep 20
 
build_b:
  stage: build
  script:
    - echo "build module B"
    - sleep 20
 
test_a:
  stage: test
  needs:
    - build_a
  script:
    - echo "test module A"

Dengan needs: [build_a], job test_a mulai berjalan segera setelah build_a selesai — tidak peduli apakah build_b masih berjalan. Dua bentuk sintaks yang bisa dipakai:

• Daftar singkat: needs: [build_a, build_b] — array nama job.
• Daftar rinci: needs: - job: build_a artifacts: true — memungkinkan pengaturan tambahan per dependency.

#needs + Artifacts: true/false

Ingat di episode 7 kita membahas transfer artifacts antar stage. Dengan needs, transfer itu menjadi eksplisit dan terkendali. Dalam bentuk rinci, kalian bisa memilih apakah sebuah dependency ikut membawa artifacts-nya:

deploy_backend:
  stage: deploy
  needs:
    - job: build_backend
      artifacts: true
    - job: test_report
      artifacts: false
  script:
    - ls backend-binary/
    - deploy.sh

artifacts: true mengunduh artifacts dari build_backend — persis perilaku transfer antar stage biasa. artifacts: false menandakan job test_report hanya dibutuhkan sebagai penanda selesai, tanpa membawa artifacts-nya. Pola ini menuntaskan dua masalah sekaligus: job berjalan lebih cepat (tidak menunggu semua stage) dan hanya mengunduh artifacts yang relevan (hemat bandwidth dan storage).

#Perbandingan Waktu: Linear vs DAG

# LINEAIR: test_a menunggu build_b selesai (40 detik + overhead)
build_a (20s) + build_b (20s) -> test_a (5s) = ~45 detik
 
# DAG: test_a mulai begitu build_a selesai
build_a (20s) -> test_a (5s)   = ~25 detik (build_b jalan paralel)
 
# Hemat: 45 -> 25 detik, penghematan ~45%

Dengan 4 job yang saling bergantung, penghematannya sudah terasa. Pada pipeline enterprise dengan puluhan job — unit test per modul, linter, SAST, build image per service — needs mengubah waktu total dari penjumlahan semua stage menjadi panjang jalur dependensi terlama. Itulah alasan utama banyak tim melaporkan pemangkasan durasi hingga setengahnya.

#Kapan Menggunakan needs dengan Bijak

DAG bukan pengganti total untuk stage. Ada kalanya menunggu seluruh stage justru diinginkan:

• Gate deployment: deploy ke produksi sebaiknya menunggu semua test selesai, bukan hanya sebagian. Tetap pakai stage biasa (tanpa needs) di sini.
• Laporan agregat: job yang merangkum hasil semua job lain (misalnya membuat laporan akhir) memang harus menunggu semuanya — tidak perlu needs.
• Job paralel independen: unit test per modul yang tidak saling bergantung adalah kandidat sempurna untuk needs — apalagi dikombinasikan dengan parallel yang akan kita bahas di episode 10.

#Penutup

Pada episode 9 ini kalian telah memahami DAG pipelines:

• Pipeline stage linear memaksa job menunggu seluruh stage sebelumnya, meski tidak saling bergantung — ini sumber pemborosan waktu terbesar di pipeline besar.
• DAG dengan needs: mengeksekusi job begitu dependensinya selesai, mengabaikan batasan stage.
• needs: [job_a, job_b] menyebutkan dependency secara eksplisit; bentuk rinci memungkinkan kontrol artifacts: true/false per dependency.
• Penghematan hingga 50 persen atau lebih pada pipeline dengan banyak job yang tidak saling bergantung.

Intinya: needs membuat pipeline berjalan secepat jalur dependensi terpanjangnya, bukan secepat penjumlahan semua job. Setelah pipeline kalian mengalir seperti DAG, satu langkah berikutnya yang paling berdampak adalah menggandakan jumlah job uji secara otomatis. Di episode 10 kita akan membahas matrix jobs & parallel execution — menguji aplikasi di banyak kombinasi versi bahasa dan database sekaligus, serta memecah suite test besar ke banyak runner paralel. Sampai jumpa di episode 10!