Belajar GitLab CI/CD - Auto DevOps & CI/CD Component Catalog

#Pendahuluan

Di episode 17 kita membangun strategi release bertahap. Namun sebelum bicara strategi, ada masalah yang lebih mendasar di banyak perusahaan: setiap project memulai pipeline dari nol. Dua puluh tim, dua puluh cara berbeda menulis lint, test, dan deploy. Hasilnya: standar keamanan yang tidak konsisten dan pipeline yang sulit dipelihara. Episode ini menyajikan dua senjata GitLab untuk masalah itu — Auto DevOps sebagai jalan pintas, dan Component Catalog untuk berbagi praktik terbaik.

#GitLab Auto DevOps

Auto DevOps adalah konsep zero-configuration: GitLab mendeteksi jenis aplikasi dari repository dan langsung menyusun pipeline lengkap. Bayangkan membeli paket "layanan lengkap" di bengkel — kendaraan diperiksa, diganti oli, dan diuji tanpa kalian harus menjelaskan satu per satu. Begitu pula Auto DevOps: begitu diaktifkan, ia menghasilkan pipeline dengan fase otomatis.

Fase standar yang disediakan:

Fase	Fungsi
Auto Build	Membangun Docker image dan push ke registry
Auto Test	Menjalankan test sesuai stack
Auto Code Quality	Memeriksa kualitas kode
Auto Security	SAST, dependency, dan container scanning
Auto Review Apps	Environment sementara per merge request
Auto Deploy	Deploy ke Kubernetes
Auto Monitoring	Memantau aplikasi

Aktivasinya cukup mengubah satu toggle di project settings, atau menambahkan template di dalam .gitlab-ci.yml:

Aktifkan Auto DevOps via include

include:
  - template: Auto-DevOps.gitlab-ci.yml

Setelah itu GitLab menjalankan seluruh fase secara otomatis di setiap push. Kalian bisa mengontrol perilaku lewat variabel — misalnya AUTO_DEVOPS_DEPLOY_STRATEGY disetel ke blue_green untuk mengubah strategi deploy, atau menonaktifkan job tertentu dengan rules.

Warning

Auto DevOps bukan pengganti pemahaman pipeline. Ia titik awal yang baik, tetapi tetaplah membaca hasil pipeline-nya, karena job yang gagal di fase Auto Security akan memblokir deploy. Untuk produksi enterprise, komponen yang kalian tulis sendiri sering lebih terkontrol.

#CI/CD Component Catalog

Sejak diperkenalkan, GitLab menawarkan cara modern untuk berbagi kode pipeline: Component Catalog. Konsepnya seperti library kode: komponen adalah blok pipeline yang bisa dipakai ulang, diberi versi, dan dikonsumsi lewat satu baris include. Setiap komponen berisi satu atau beberapa job, input yang bisa disesuaikan, dan skema validasi.

Menggunakan komponen ber-versioning

include:
  - component: gitlab.com/components/security/secret-detection@1.4.0
  - component: my-org/components/terraform-apply@2.1.0
    inputs:
      tf_version: "1.9.0"

Sintaks include: component: merujuk komponen pada alamat namespace/project@version. Versioning membuat tim bisa mengunci versi tertentu — perubahan besar di versi 2 tidak akan merusak project yang masih memakai versi 1. Ini persis seperti mengunci dependensi npm di file package-lock.json.

Tip

Selalu sebutkan versi eksplisit saat memakai komponen dari Catalog. Memakai versi terbaru secara implisit membuat pipeline kalian rapuh terhadap perubahan yang tidak kalian lihat.

#Membuat Komponen Sendiri

Sekarang kita menulis komponen internal untuk konsistensi lintas tim. Struktur project komponen sangat spesifik:

Struktur project komponen

components/
└── my-org/
    └── terraform/
        ├── templates/
        │   └── terraform-plan.yml
        ├── spec.json
        └── README.md

Direktori templates berisi job YAML, spec.json mendeskripsikan input, dan README.md mendokumentasikan pemakaian. Contoh komponen yang membungkus perencanaan Terraform:

templates/terraform-plan.yml

spec:
  inputs:
    tf_version:
      type: string
      default: "1.9.0"
 
terraform-plan:
  image: hashicorp/terraform:${inputs.tf_version}
  script:
    - terraform init
    - terraform plan -out=plan.tfplan
  artifacts:
    paths: [plan.tfplan]
    expire_in: 1 week

Blok spec.inputs mendeklarasikan parameter yang bisa di-override oleh pemakai, dan di dalam job direferensikan sebagai inputs.tf_version. Pemakai komponen tinggal menulis:

Memakai komponen internal

include:
  - component: gitlab.com/my-org/terraform@1.2.0
    inputs:
      tf_version: "1.10.0"

Setelah komponen dipublish ke Catalog (project harus ditandai sebagai component project), seluruh tim di perusahaan bisa memakainya. Sekarang linter, security scan, dan deploy punya satu implementasi, bukan dua puluh.

Note

Untuk komponen yang bersifat internal, GitLab juga mendukung rujukan langsung dari CI/CD variables lain, misalnya alamat instance self-hosted — jadi komponen tetap privat dan hanya terlihat oleh organisasi kalian.

#Penutup

Auto DevOps memberi pipeline lengkap tanpa konfigurasi: build, test, quality, security, dan deploy.
Fase Auto DevOps bisa disesuaikan lewat variabel dan rules.
Component Catalog memungkinkan pemakaian job ber-versioning lewat satu baris include.
Komponen internal dibuat dengan struktur templates, spec, dan dokumentasi.
Konsistensi lintas tim lahir dari komponen yang sama dipakai di mana-mana.

Di episode 19 selanjutnya kita membahas troubleshooting, debugging, dan monitoring pipeline — bagaimana menelusuri pipeline yang gagal dan memantau kesehatan runner. Sampai jumpa!