Belajar DevOps Engineer - Version Control & Git Workflow

#Pendahuluan

Setelah di episode 3 kita mengotomasi dengan skrip, pertanyaannya: di mana skrip, kode, dan konfigurasi itu tinggal? Jawabannya di episode ini: repository Git. Git adalah "sumber kebenaran" (single source of truth) untuk seluruh siklus hidup DevOps — mulai dari kode aplikasi, pipeline, hingga definisi infrastruktur.

Mengapa Git begitu sentral? Karena semua praktik yang akan kalian pelajari ke depan — CI (episode 5), CD (episode 6), bahkan GitOps (episode 14) — berpijak pada satu ide: segala sesuatu yang bernilai harus masuk ke Git. Jika tidak ada di Git, ia tidak bisa diaudit, direview, diuji, atau di-rollback.

#Konsep Dasar yang Wajib Dikuasai

Bukan sekadar perintah, tapi mental model dari empat objek berikut:

1. Commit — snapshot seluruh repository pada satu titik waktu. Commit membawa pesan yang menjelaskan mengapa perubahan dibuat.
2. Branch — garis pengembangan paralel. Sebuah branch adalah pekerjaan yang belum selesai dan ingin diuji secara terpisah.
3. Merge / Rebase — menyatukan kembali garis pengembangan. Merge mencatat "percabangan terjadi", rebase menulis ulang riwayat agar linear.
4. Pull Request (PR) — mekanisme review sebelum pekerjaan digabungkan ke branch utama.

Alur harian yang paling umum:

git checkout -b feat/fix-login
# ... edit kode ...
git add .
git commit -m "feat: perbaiki validasi form login"
git push -u origin feat/fix-login

#Strategi Branching: GitFlow vs Trunk-Based

Cara mengorganisasi branch menentukan seberapa cepat dan aman rilis kalian. Dua kubu utama:

#GitFlow

GitFlow punya banyak branch permanen: main, develop, plus branch sementara feature/*, release/*, dan hotfix/*.

Keunggulan: terstruktur dan cocok untuk model rilis berkala (misal rilis bulanan). Kekurangan: rumit, banyak merge, dan lead time panjang — bertentangan dengan target DORA "deploy beberapa kali sehari".

#Trunk-Based Development

Trunk-based memakai satu branch utama (main atau trunk). Semua developer bekerja langsung di trunk atau branch fitur yang sangat pendek (umumnya kurang dari sehari), lalu langsung di-merge. Proteksi rilis dijaga oleh feature flag dan pengujian otomatis, bukan oleh banyak branch.

Keunggulan: lead time pendek, integrasi terus-menerus, minim konflik merge — inilah pola yang dianut tim DORA elite. Kekurangan: menuntut disiplin CI yang kuat dan feature flag yang matang.

#Code Review: Mutu di Gerbang Pull Request

Code review bukan formalitas. Ia adalah quality gate pertama sebelum kode masuk ke main. Prinsipnya:

• PR sekecil mungkin — PR kecil lebih cepat direview dan lebih jarang mengandung bug tersembunyi.
• Reviewer fokus pada desain, bukan nitpicking gaya — perbaikan gaya bisa diotomasi dengan linter di CI.
• Setiap PR wajib lolos pipeline CI — manusia tidak boleh membuang waktu mengecek hal yang bisa dicek mesin.
• Gunakan protected branch di main agar PR tidak bisa di-merge tanpa review dan tanpa CI hijau.

#Menuju GitOps Mindset

Di episode 14 kalian akan mendalami GitOps, tetapi mental modelnya kita tanam sejak sekarang: jika seluruh infrastruktur dan konfigurasi dideklarasikan sebagai file dalam Git, dan ada proses yang terus menyinkronkan state Git dengan state produksi, maka recovery dan audit menjadi semudah membalikkan commit.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: registry.example.com/myapp:1.2.3

Perhatikan image: registry.example.com/myapp:1.2.3 — versi ada di Git, bukan di kepala manusia. Siapa pun yang mengubahnya, kapan pun, di branch apa pun, semuanya tercatat.

#Praktik: Workflow Kolaboratif

Latihan singkat yang meniru kerja tim nyata:

git clone git@github.com:team/myapp.git
git checkout -b feat/add-healthcheck
# edit kode, jalankan test lokal
git add src/
git commit -m "feat: tambahkan healthcheck endpoint"
git push -u origin feat/add-healthcheck
# buat Pull Request via web/gh
gh pr create --title "feat: tambahkan healthcheck" --fill

Setelah PR direview dan pipeline hijau, baru di-merge. Dari sana, CI/CD mengambil alih — dan itulah jembatan ke episode 5.

#Pitfall Umum

• Commit besar dan jarang — pecah menjadi kecil dan sering; lebih mudah direview dan di-rollback.
• Menulis pesan commit ambigu ("fix bug", "update file") — gunakan Conventional Commits, pola yang juga dipakai repo ini.
• Me-review PR sendiri — selalu minta pair review; dua pasang mata menangkap lebih banyak.
• Merge langsung ke main tanpa PR — matikan akses ini di pengaturan protected branch.

#Penutup

Inti yang harus dibawa pulang:

• Git adalah sumber kebenaran untuk kode, pipeline, dan infrastruktur.
• Pahami perbedaan GitFlow vs Trunk-based; untuk rilis cepat, trunk-based menang.
• Code review + CI hijau adalah gerbang kualitas di setiap PR.
• Mental model GitOps: semua state dideklarasikan dalam Git dan disinkronkan otomatis.

Di episode 5 selanjutnya kita membahas Continuous Integration (CI) — otomasi yang memastikan setiap perubahan kode dibangun, diuji, dan di-lint sebelum sampai ke main. Di sinilah skrip dari episode 3 dan Git dari episode 4 bertemu menjadi satu sistem.