Belajar GitLab CI/CD - Modularisasi Pipeline dengan include & Child Pipelines

#Pendahuluan

Di episode 10 sebelumnya kita membahas bagaimana parallel: matrix dan parallel: 5 memecah pekerjaan menjadi banyak runner paralel sehingga durasi pipeline bisa dipangkas drastis. Sekarang bayangkan dua tahun kemudian: repository mulai dipegang banyak tim, dan file .gitlab-ci.yml di root repository sudah membengkak menjadi ribuan baris dengan job yang saling menyalin konfigurasi. Setiap tim meng-copy-paste blok yang sama, dan satu perubahan kecil pada konfigurasi build berarti mengedit sekaligus memikirkan dampaknya ke puluhan job di seluruh repository.

Situasi ini persis seperti sebuah buku catatan raksasa yang dipakai bersama-sama oleh seluruh kelas: setiap kali satu siswa ingin menulis, siswa lain harus menunggu, dan semua orang harus membaca halaman yang sama hanya untuk menemukan bagian miliknya. Di dunia nyata, tim DevOps tidak bekerja seperti itu. Mereka memecah file besar menjadi modul, menyimpan konfigurasi umum di tempat terpusat, dan mengorkestrasi pipeline kecil-kecil yang bertanggung jawab atas domain masing-masing.

Episode ini membahas dua alat utama GitLab untuk memecahkan masalah tersebut: keyword include untuk reusability kode, dan teknik parent-child pipelines serta multi-project pipelines untuk memecah pipeline besar menjadi sub-pipeline yang independen. Inilah fondasi arsitektur pipeline enterprise yang akan terus kita pakai di episode-episode berikutnya.

#Pembahasan Utama

#Kenapa File `.gitlab-ci.yml` Monolitik Menjadi Masalah

Sebelum membahas solusinya, mari pahami dulu akar masalahnya. File pipeline monolitik tidak hanya terasa "panjang" — ia menimbulkan empat masalah konkret di tim nyata:

Konflik merge request. Dua tim yang mengedit file yang sama hampir pasti bentrok di git merge, dan resolver konflik pipeline adalah salah satu pekerjaan paling tidak menyenangkan.
Tidak ada reuse lintas proyek. Konfigurasi build Docker atau deploy yang sama ditulis ulang di setiap repository, dan ketika pola berubah, semua repository harus diubah satu per satu.
Perubahan berdampak luas. Satu edit kecil di bagian atas file bisa secara tidak sengaja mengubah perilaku puluhan job di bawahnya.
Sulit dibaca dan diaudit. Reviewer dan anggota baru harus memahami seluruh pipeline hanya untuk menyetujui satu perubahan kecil.

Solusi GitLab untuk masalah-masalah ini adalah keyword include, yang memungkinkan pipeline dibangun dari banyak file YAML — mirip cara bahasa pemrograman modern memecah kode menjadi modul dan fungsi.

#`include: local`: Modul dalam Repository yang Sama

include: local mengimpor file YAML dari repository yang sedang diproses. Ini pola paling dasar untuk memecah .gitlab-ci.yml besar menjadi file-file per domain.

.gitlab-ci.yml utama

include:
  - local: /ci/build.yml
  - local: /ci/test.yml
  - local: /ci/deploy.yml
 
stages: [build, test, deploy]

ci/build.yml — modul build

build-backend:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build

Path local selalu dimulai dengan / (relatif ke root repository) atau relatif terhadap file yang meng-include-nya. File yang di-include bisa berisi definisi job, stage, variabel, atau apa pun yang sah di .gitlab-ci.yml.

Tip

Gunakan folder .gitlab/ci/ atau ci/ untuk menyimpan modul-modul ini. Konvensi yang konsisten membuat tim langsung tahu di mana mencari konfigurasi job tertentu tanpa harus membaca isi file utama.

#`include: project`: Reuse Konfigurasi Lintas Repository

Masalah local adalah ia hanya bekerja di dalam satu repository. Padahal konfigurasi linting, build, atau deploy biasanya identik di banyak proyek. include: project mengimpor file YAML dari repository GitLab lain — dalam organisasi yang sama atau bahkan dari project publik.

Import template internal dari repo lain

include:
  - project: "my-org/ci-templates"
    ref: v2.4.0
    file: /templates/build.yml
  - project: "my-org/ci-templates"
    ref: v2.4.0
    file: /templates/test.yml

Perhatikan pasangan ref dan file: ref memilih branch, tag, atau commit dari project sumber. Mengikat include ke tag (v2.4.0) alih-alih branch main adalah praktik terbaik — beginilah template internal perusahaan dapat di-versioning dengan semantic versioning, sama seperti library software.

#`include: template`: Template Resmi GitLab

include: template mengimpor template CI resmi yang dikelola tim GitLab. Template ini mencakup pekerjaan keamanan, SAST, dependency scanning, dan berbagai bahasa pemrograman.

Mengaktifkan template resmi GitLab

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml

Template adalah cara tercepat mengadopsi fitur GitLab tanpa menulis apapun. Kita akan membedah template keamanan ini secara mendalam di episode 12.

#`include: remote`: Import dari URL HTTP/S

include: remote mengambil file YAML dari URL eksternal. Ini berguna untuk berbagi konfigurasi lintas organisasi, misalnya template publik yang dikelola komunitas.

Import dari URL eksternal

include:
  - remote: "https://example.com/team/pipeline-base.yml"

Warning

Include remote adalah pintu masuk yang berbahaya jika tidak hati-hati. Kalian mengeksekusi konfigurasi dari URL yang tidak kalian kontrol. Pastikan URL dikelola organisasi kalian, atau setidaknya pin ke commit hash tertentu, dan jangan pernah meng-include URL yang bisa diubah siapa pun. Untuk penggunaan internal, project + ref jauh lebih aman dan bisa diaudit.

#`extends`: Warisan Konfigurasi Tanpa Salin-Tempel

Selain include, GitLab menyediakan keyword extends untuk mewarisi konfigurasi dari job lain dalam file yang sama. Ini menggantikan YAML anchors yang sudah deprecated di versi modern.

Base job diwarisi oleh job lain

.base-job:
  image: node:20-alpine
  variables:
    NODE_ENV: production
  before_script:
    - npm ci
 
build-app:
  extends: .base-job
  stage: build
  script:
    - npm run build

Perhatikan bahwa job yang dimulai dengan titik (.base-job) tidak dijalankan oleh GitLab — ia hanya dijadikan cetakan. extends melakukan merge konfigurasi: nilai yang tidak ditimpa diwarisi, sedangkan nilai yang ditulis di job turunan akan menimpa milik parent. Ini adalah cara paling idiomatis untuk menghindari copy-paste.

#Parent-Child Pipelines: Orkestrasi dalam Satu Repository

Ketika repository membengkak menjadi monorepo — misalnya berisi folder frontend, backend, dan docs — satu pipeline raksasa membuat semua tim terikat pada konfigurasi bersama. Parent-child pipelines memecahnya: pipeline induk (parent) memicu sub-pipeline (child) yang masing-masing memiliki file YAML dan lifecycle sendiri.

Parent pipeline memicu child pipeline

stages: [pre, build, deploy]
 
build-children:
  stage: pre
  trigger:
    include:
      - local: /frontend/child-ci.yml
      - local: /backend/child-ci.yml
    strategy: depend

Keyword trigger membuat job bertindak sebagai pemantik pipeline lain, bukan mengeksekusi script. Dengan strategy: depend, parent pipeline menunggu child pipeline selesai sebelum melanjutkan ke stage berikutnya — cocok ketika build monorepo harus selesai sebelum deploy. Setiap child pipeline berjalan di bawah naungan pipeline induknya dan bisa menggunakan predefined variables seperti CI_PROJECT_DIR untuk folder masing-masing.

#Multi-Project Pipelines: Menghubungkan Pipeline Lintas Repository

Berkebalikan dengan child pipeline (masih di repository yang sama), multi-project pipeline memicu pipeline di repository terpisah. Ini adalah tulang punggung pola downstream pipeline: repository A (misalnya shared library) selesai build, lalu memicu test di repository B (aplikasi yang mengonsumsi library tersebut).

Memicu pipeline di project lain

trigger-deploy:
  stage: deploy
  trigger:
    project: my-org/api-gateway
    branch: main
    strategy: depend

Untuk memicu pipeline di project lain, GitLab menggunakan CI_JOB_TOKEN dari project pemantik — artinya project target harus memberi izin akses melalui fitur Pipeline trigger pada project settings. Hasil pipeline downstream dapat dipantau langsung dari pipeline upstream di UI GitLab.

#Kapan Memakai Yang Mana

Tujuan	Alat	Contoh
Memecah `.gitlab-ci.yml` besar dalam satu repo	`include: local`	`/ci/test.yml`
Share template antar repo dalam organisasi	`include: project`	repo `ci-templates` + tag `v2.4.0`
Mengaktifkan fitur resmi GitLab	`include: template`	`Jobs/SAST.gitlab-ci.yml`
Import konfigurasi dari luar organisasi	`include: remote`	URL publik tim
Mewarisi konfigurasi antar job	`extends`	job `.base-job`
Monorepo dengan banyak tim	Parent-child pipelines	`trigger: include:`
Memicu pipeline di repo lain	Multi-project pipelines	`trigger: project:`

Important

Kombinasi include dan extends adalah pola inti arsitektur CI/CD modern di GitLab: gunakan include untuk menyusun pipeline dari banyak file, dan extends untuk menurunkan konfigurasi di dalam file tersebut. Keduanya menggantikan YAML anchors dan only/except yang deprecated.

#Penutup

Pada episode ini kita telah membahas cara memecah pipeline monolitik: keempat bentuk include — local, project, template, dan remote — beserta contoh masing-masing; keyword extends untuk mewarisi konfigurasi antar job; parent-child pipelines dengan trigger: include yang cocok untuk monorepo; serta multi-project pipelines dengan trigger: project untuk menghubungkan pipeline lintas repository.

Inti dari episode ini: pipeline bukanlah satu file raksasa, melainkan orkestrasi modul-modul kecil yang independen. Dengan modularisasi, tim bisa bergerak cepat, template bisa di-versioning, dan setiap bagian pipeline bertanggung jawab atas domainnya sendiri.

Di episode 12 selanjutnya kita masuk ke FASE 5: DevSecOps Native GitLab — mengaktifkan SAST, Secret Detection, Dependency Scanning, dan Container Scanning hanya dengan beberapa baris include: template, lalu membaca hasilnya dari Security Center. Sampai jumpa!