Belajar GitLab CI/CD - Sejarah, Konsep & Arsitektur Utama

#Pendahuluan

Di episode 0 kalian sudah menyiapkan tiga fondasi skill — Git & GitLab workflow, YAML, dan bash — plus environment lengkap dengan glab dan VS Code. Sekarang saatnya berhenti mengetik sejenak dan memahami mengapa kita semua ada di sini. Sebelum menulis .gitlab-ci.yml pertama, kalian harus paham betul bagaimana arsitektur GitLab dirancang, bagaimana komponen-komponennya bekerja sama, dan mengapa GitLab CI menjadi pilihan utama di perusahaan enterprise.

Percaya atau tidak, kesalahan terbesar yang dilakukan pemula adalah langsung menulis YAML pipeline tanpa memahami arsitekturnya — akibatnya pipeline jadi kumpulan perintah copy-paste yang sulit dirawat dan sulit di-debug. Episode ini membangun fondasi konseptual tersebut.

#Pembahasan Utama

#Mengapa GitLab CI/CD Populer di Skala Enterprise

GitLab dimulai pada tahun 2011 sebagai tool Git hosting open source, dan pada tahun 2016 merilis CI/CD terintegrasi pertama yang berjalan langsung di dalam platform. Bedanya dengan tool lain: GitLab adalah single application all-in-one — bukan kumpulan tool yang disambung-sambung dengan webhook. Dalam satu platform kalian mendapatkan:

• Source Code Management (SCM): repository Git, branch protection, dan code review.
• Issue Tracking: issues, epics, milestones, hingga board perencanaan.
• CI/CD: pipeline otomatis untuk build, test, dan deploy.
• Container Registry: registry Docker bawaan untuk image yang kalian build.
• Security Dashboard: SAST, dependency scanning, secret detection, dan container scanning dalam satu tampilan.

Analoginya seperti restoran: di tool tradisional kalian harus menyewa pemasok terpisah untuk bahan, koki, dan kasir. Di GitLab semuanya ada di satu dapur — bahan masuk dari commit, masakan diuji pipeline, dan disajikan lewat deployment, semuanya dalam satu aplikasi. Inilah alasan utama tim enterprise memilih GitLab: satu alur kerja, satu sumber kebenaran, satu tim yang mengelolanya.

#Arsitektur Utama GitLab CI/CD

Ada tiga komponen inti yang harus kalian pahami selamanya:

• GitLab Server / SaaS — "otaknya". Komponen ini menyimpan metadata project, menyediakan UI dan REST API, serta memicu pipeline setiap kali ada event (push, MR, tag). Di GitLab.com, server dikelola penuh oleh GitLab; di self-hosted, server dijalankan di infrastruktur kalian.
• GitLab Runner — "pekerjanya". Agent eksekusi yang ringan dan terpisah dari server. Runner mendengar perintah dari GitLab Server, mengambil job dari antrean, mengeksekusinya, lalu melaporkan hasil kembali. Bisa dijalankan di mesin lokal, VM, Docker, atau Kubernetes.
• .gitlab-ci.yml — file deklaratif di root repository yang mendeskripsikan seluruh pipeline. File ini adalah "resep masakan": jika ada di repository, GitLab otomatis membacanya dan mengeksekusinya setiap kali ada event.

Saat sebuah commit di-push, alur yang terjadi adalah:

Developer push commit ke GitLab
        |
        v
GitLab Server mendeteksi .gitlab-ci.yml
        |
        v
Server membuat pipeline dan memasukkan job ke queue
        |
        v
Runner mengambil job, checkout kode, eksekusi script
        |
        v
Runner kirim log dan status kembali ke GitLab Server
        |
        v
Status tampil di UI, merge request, dan notifikasi

#Hierarki Pipeline Execution: Stages, Jobs, Scripts

Di dalam .gitlab-ci.yml, pipeline dieksekusi berdasarkan hierarki tiga tingkat:

• Stages — urutan fase eksekusi. Contoh klasik: build → test → deploy. Semua job di stage yang sama berjalan paralel; stage berikutnya baru mulai setelah seluruh job di stage sebelumnya sukses.
• Jobs — unit kerja spesifik di dalam sebuah stage. Satu job memegang satu tanggung jawab, misalnya job unit_test dan job lint yang sama-sama berada di stage test.
• Scripts — daftar perintah CLI yang dieksekusi di dalam job. Jika satu perintah mengembalikan exit code bukan nol, job dianggap gagal.

stages:
  - build
  - test
  - deploy
 
unit_test:
  stage: test
  script:
    - npm test

Bisa kalian lihat polanya: stages mendefinisikan urutan, unit_test adalah sebuah job yang ditaruh di stage test, dan npm test adalah script yang dijalankan. Gambaran mental sederhananya: pipeline adalah bangunan, stages adalah lantainya, jobs adalah ruangan di tiap lantai, dan scripts adalah pekerjaan yang dilakukan di dalam ruangan tersebut.

#Perbandingan GitLab CI vs GitHub Actions vs Jenkins

Agar posisi GitLab jelas, mari bandingkan dengan dua pesaing utamanya:

Tidak ada pilihan yang salah mutlak — Jenkins tetap jago untuk kontrol penuh, GitHub Actions unggul bagi tim di ekosistem GitHub. GitLab CI dipilih ketika kalian ingin satu aplikasi menangani seluruh alur pengembangan, dari repository hingga security dashboard, tanpa biaya integrasi antar tool.

#Penutup

Pada episode 1 ini kalian telah membangun fondasi konseptual yang penting:

• Mengapa GitLab populer di enterprise: single application all-in-one yang mencakup SCM, issue tracking, CI/CD, container registry, dan security dashboard.
• Arsitektur inti: GitLab Server sebagai orkestrator, GitLab Runner sebagai eksekutor, dan .gitlab-ci.yml sebagai definisi deklaratif pipeline.
• Hierarki eksekusi: stages (fase), jobs (unit kerja), dan scripts (perintah CLI) yang tersusun dari besar ke kecil.
• Perbandingan tools: keunggulan dan posisi GitLab CI di tengah GitHub Actions dan Jenkins.

Sekarang kalian tahu bagaimana arsitekturnya, saatnya memahami bagaimana menulisnya. Di episode 2 kita akan membuat .gitlab-ci.yml pertama dengan syntax dasar: keyword global, definisi stages, struktur job, inline dan multi-line script, serta allow_failure untuk menangani error. Sampai jumpa di episode 2!