GitLab — dasar-dasar, fitur dan CI/CD

Apa itu GitLab?

GitLab — adalah platform DevOps lengkap dengan open source di bawah lisensi MIT. Tidak seperti GitHub yang menggabungkan berbagai layanan melalui integrasi, GitLab menyediakan alat tunggal untuk seluruh siklus hidup pengembangan: dari manajemen kode dan code review hingga CI/CD, pemantauan, keamanan, dan deployment. Platform ini tidak memerlukan layanan pihak ketiga untuk sebagian besar tugas DevOps.

Sejarah GitLab dimulai pada tahun 2011 sebagai proyek internal pengembang Ukraina. Versi publik pertama dirilis pada September 2011, dan pada tahun 2015 GitLab menjadi proyek pertama di GitLab.com, meluncurkan hosting cloud. Pada tahun 2017, GitLab melakukan proses migrasi yang menyakitkan namun mendidik — pemindahan seluruh infrastruktur dari Azure ke Google Cloud, yang disiarkan langsung dan didokumentasikan dalam serangkaian tulisan.

Arsitektur GitLab terdiri dari tiga komponen utama: GitLab Rails (aplikasi web di Ruby on Rails), GitLab Shell (pemrosesan operasi Git melalui SSH) dan Gitaly (server gRPC untuk akses data Git). CI/CD disediakan melalui GitLab Runner — aplikasi terpisah yang diinstal di server build dan menjalankan job di lingkungan terisolasi (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipeline dan runner

GitLab CI/CD — adalah sistem integrasi dan pengiriman berkelanjutan bawaan yang merupakan keunggulan utama platform. Tidak seperti GitHub Actions, GitLab CI/CD telah dimasukkan ke dalam arsitektur sejak awal dan tidak memerlukan konfigurasi terpisah: setiap proyek secara otomatis mendapatkan CI/CD setelah menambahkan file .gitlab-ci.yml ke root repositori.

Pipeline (pipeline) terdiri dari tahapan (stages) yang dijalankan secara berurutan atau paralel: build → test → deploy. Setiap tahap berisi satu atau beberapa job yang dijalankan pada runner. Jika satu job dalam tahap berakhir dengan kesalahan, seluruh tahap ditandai sebagai failed, dan tahap berikutnya tidak dijalankan secara default. Di bawah ini adalah contoh pipeline untuk proyek mobile:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner mendukung beberapa executor (pelaksana): Docker (direkomendasikan), Kubernetes, SSH, VirtualBox dan Parallels. Opsi paling populer adalah executor Docker, yang menjalankan setiap job dalam kontainer terpisah. Runner dapat didaftarkan sebagai spesifik untuk satu proyek atau bersama (shared) untuk seluruh grup. GitLab.com menyediakan runner bersama gratis dengan batas 2000 menit per bulan.

Fitur CI/CD Lanjutan

GitLab CI/CD mendukung penjalanan manual (when: manual), penjalanan tertunda (when: delayed), eksekusi paralel (parallel: 5), matriks (matrix), pipeline dinamis (child pipelines) dan pipeline bertingkat (parent-child). Ini memungkinkan pembangunan skenario kompleks: misalnya, menghasilkan pipeline secara dinamis untuk setiap modul dalam monorepositori atau menjalankan build paralel untuk arsitektur Android yang berbeda (arm64, x86_64).

GitLab vs GitHub: perbedaan utama

GitLab dan GitHub — dua pesaing utama di pasar platform Git, namun filosofi dan arsitektur mereka pada dasarnya berbeda. GitHub berfokus pada komunitas terbuka, ekosistem integrasi, dan fitur sosial (fork, bintang). GitLab berfokus pada siklus DevOps yang komprehensif dan menyediakan semua alat siap pakai: dari perencanaan hingga pemantauan.

Perbedaan arsitektur utama: GitLab — adalah aplikasi monolitik tunggal yang diinstal pengembang secara keseluruhan. Semua fitur (CI/CD, Container Registry, Security Scanning, Pages) sudah terpasang dan berfungsi segera setelah instalasi. GitHub — adalah platform dengan API, di mana sebagian besar fitur diimplementasikan melalui integrasi dengan layanan pihak ketiga: Travis CI, CircleCI, Jenkins, SonarQube. Tabel di bawah membandingkan karakteristik utama:

Pilihan antara GitLab dan GitHub tergantung pada kebutuhan tim. Jika prioritasnya adalah deployment cepat dengan konfigurasi nol dan komunitas terbuka — pilih GitHub. Jika diperlukan kontrol penuh atas infrastruktur, hosting sendiri, dan keamanan bawaan — GitLab lebih disukai. Menurut survei Stack Overflow (2024), 90% pengembang menggunakan GitHub, 33% — GitLab (seringkali kedua platform secara bersamaan).

Self-Managed GitLab: instalasi di server sendiri

Self-Managed GitLab (sebelumnya On-Premises) memungkinkan instalasi platform di server sendiri dan mendapatkan kontrol penuh atas data, infrastruktur, dan ketersediaan. Ini sangat penting bagi organisasi dengan persyaratan kepatuhan: sektor keuangan, lembaga pemerintah, organisasi medis, di mana data tidak dapat disimpan di server pihak ketiga.

Instalasi GitLab didukung di Ubuntu, Debian, CentOS dan melalui Docker. Paket Omnibus resmi mencakup semua komponen: server web (NGINX), basis data (PostgreSQL), cache (Redis), pemroses Git (Gitaly) dan proses latar belakang. Persyaratan minimum: 4 GB RAM dan 2 CPU untuk tim hingga 100 orang. Untuk instalasi besar dengan beban tinggi, disarankan pemisahan komponen ke server terpisah.

# Menginstal GitLab CE di Ubuntu melalui Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Menginstal paket
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Melihat status
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab tidak memiliki batasan menit CI/CD — semua runner milik organisasi, dan kekuatan mereka hanya dibatasi oleh perangkat keras sendiri. Juga tersedia Geo-replikasi untuk wilayah, log audit, pemblokiran IP, dan integrasi dengan penyedia LDAP/SAML korporat. GitLab merilis pembaruan setiap bulan (tanggal 22) dengan fitur baru dan perbaikan keamanan.

Alat keamanan bawaan GitLab

Keamanan di GitLab terpasang di tingkat platform dan mencakup beberapa pemindai yang bekerja di setiap tahap pipeline. SAST (Static Application Security Testing) menganalisis kode sumber untuk kerentanan tanpa menjalankan aplikasi, mendukung lebih dari 15 bahasa, termasuk Java, Kotlin, Swift, Python dan JavaScript. DAST (Dynamic Application Security Testing) menguji aplikasi web yang berjalan untuk kerentanan dari dalam.

Alat tambahan: Container Scanning memeriksa gambar Docker untuk kerentanan di lapisan dasar; Dependency Scanning menganalisis dependensi proyek dan memperingatkan tentang CVE yang dikenal; Secret Detection menemukan kunci API, kata sandi, dan token yang tidak sengaja di-commit; Fuzz Testing melakukan pengujian otomatis dengan data yang salah untuk menemukan bug yang tidak jelas. Semua hasil pemindaian ditampilkan dalam satu Security Dashboard.

GitLab juga menyediakan Compliance — alat untuk memenuhi persyaratan peraturan. Compliance Dashboard menunjukkan status kepatuhan semua proyek, Audit Events mencatat setiap tindakan administrator dan pengembang, dan Compliance Frameworks memungkinkan penerapan paksa kebijakan konfigurasi untuk grup proyek tertentu. Ini menjadikan GitLab pilihan populer di lingkungan korporat dengan persyaratan keamanan yang ketat.

Container Registry dan Dependency Proxy

GitLab Container Registry — adalah registri Docker bawaan yang terintegrasi dengan CI/CD. Setelah membangun gambar Docker di pipeline, gambar tersebut dapat segera dipublikasikan di Registry menggunakan variabel lingkungan CI_REGISTRY dan CI_REGISTRY_USER. Registry mendukung caching pull-through, penandaan, kebijakan pembersihan, dan pemindaian kerentanan langsung di registri.

Dependency Proxy — mekanisme caching kontainer dan gambar dari registri eksternal (Docker Hub, Quay, GCR). Ketika pipeline meminta gambar ubuntu:latest, GitLab pertama-tama memeriksa cache-nya sendiri — jika gambar sudah dimuat, tidak diunduh lagi. Ini mengurangi beban pada registri eksternal, mempercepat pipeline, dan melindungi dari batas kecepatan Docker Hub.

Untuk pengembang mobile, GitLab menyediakan GitLab Pages untuk hosting dokumentasi dan laporan pengujian. Setelah menjalankan tes, artefak (laporan HTML, tangkapan layar, log) dapat dipublikasikan sebagai Pages dan mendapatkan tautan untuk dikirim ke tim QA. Ini lebih nyaman daripada mengunggah laporan ke penyimpanan cloud, karena semuanya ditempatkan dalam proyek GitLab yang sama.

GitLab API dan Webhook

GitLab API (REST dan GraphQL) menyediakan akses ke semua sumber daya platform: proyek, pengguna, pipeline, Merge Request, registri. API digunakan untuk otomatisasi: membuat proyek dari template, menunjuk reviewer, mendapatkan status pipeline. Webhook memungkinkan pengiriman notifikasi HTTP ke sistem eksternal pada peristiwa: push, merge, pembuatan Issue. Webhook terintegrasi dengan Mattermost, Slack, Telegram dan sistem pemantauan internal.

GitLab Pages untuk Dokumentasi Mobile

GitLab Pages secara otomatis mempublikasikan situs web statis dari repositori. Untuk proyek mobile, Pages berguna untuk menempatkan dokumentasi API, laporan cakupan tes, dan hasil analisis lint. Publikasi terjadi secara otomatis setelah pipeline berhasil — cukup tentukan langkah deploy dengan publikasi ke Pages di .gitlab-ci.yml. Hasilnya tersedia di https://namespace.gitlab.io/nama-proyek.