19. Workflow Git: Branching Strategy

Untuk menjaga stabilitas basis kode dan mendukung kolaborasi tim FE yang efisien, Bit Group Asia menerapkan strategi percabangan (branching strategy) yang terstruktur. Kita menggunakan variasi dari Git Flow yang disederhanakan, di mana setiap kontribusi kode wajib melalui serangkaian tahapan validasi sebelum dirilis ke lingkungan produksi.

A. Hierarki Branch & Pemetaan Lingkungan (Environment Mapping)

Dalam siklus pengembangan aplikasi (Software Development Life Cycle - SDLC), pemisahan peran antar branch penting dilakukan untuk menjaga agar perubahan kode yang belum teruji tidak memengaruhi pengguna akhir secara langsung. Oleh karena itu, setiap branch utama memiliki pemetaan ke lingkungan hosting (environment) masing-masing.

Berikut adalah pembagian dan pemetaan hierarki branch utama yang digunakan dalam repositori proyek:

1. Branch main (Produksi)

• Pemetaan Lingkungan: Lingkungan Produksi (Production/Live Environment).
• Deskripsi: Branch ini merupakan branch utama yang menyimpan kode sumber aplikasi versi stabil terbaru yang sedang aktif digunakan di server produksi.
• Ketentuan Akses:
  • Protected Branch: Akses dorong langsung (git push) diblokir sepenuhnya untuk seluruh tim pengembang.
  • Prosedur Update: Kode ke branch main hanya dapat dimasukkan melalui Pull Request (PR) resmi dari branch staging (untuk rilis terjadwal) atau dari branch hotfix/* (untuk perbaikan darurat).
  • Tag Versi: Setiap kali penggabungan (merge) ke main berhasil dilakukan, DevOps atau Tech Lead wajib membuat penanda versi (Git Tag) berbasis semantic versioning (misal: v1.2.0).

2. Branch staging (UAT & Pre-Production)

• Pemetaan Lingkungan: Lingkungan Staging / UAT (User Acceptance Testing Environment).
• Deskripsi: Berfungsi sebagai replika dari lingkungan produksi. Branch ini digunakan untuk proses verifikasi akhir (release candidate) oleh tim penjamin mutu (Quality Assurance), Product Manager, dan klien sebelum kode dirilis secara global.
• Ketentuan Akses:
  • Protected Branch: Tim pengembang tidak diperbolehkan melakukan push langsung ke branch ini.
  • Prosedur Update: Perubahan dimasukkan melalui PR dari branch development ketika siklus iterasi fitur baru selesai dan siap diuji secara formal.

3. Branch development (Integrasi & Dev Testing)

• Pemetaan Lingkungan: Lingkungan Development / Sandbox (Development Environment).
• Deskripsi: Pusat integrasi harian bagi seluruh pengembang. Semua fitur baru dan perbaikan bug yang telah selesai dikerjakan di lokal mesin akan digabungkan ke sini terlebih dahulu untuk melihat keselarasan kode secara terintegrasi.
• Ketentuan Akses:
  • Protected Branch: Meskipun merupakan branch kerja harian, push langsung ke branch development tetap dibatasi untuk meminimalkan konflik kode yang tidak terpantau.
  • Prosedur Update: Menggabungkan kode dari branch kerja developer (feature/* atau bugfix/*) melalui proses Pull Request yang disertai peninjauan kode (code review).

4. Branch Kerja Developer (Temporary/Supporting Branches)

Merupakan branch temporer yang dibuat mandiri oleh developer untuk mengerjakan tugas spesifik dan akan dihapus setelah dimerge ke branch utama.

• feature/*: Dibuat dari branch development untuk pembuatan fitur baru. Target penggabungan kembali ke development.
• bugfix/*: Dibuat dari branch development (atau staging jika diperlukan) untuk memperbaiki masalah/bug non-kritis yang ditemukan selama pengujian QA. Target penggabungan kembali ke development.
• hotfix/*: Dibuat langsung dari branch main untuk menangani insiden crash atau bug kritis di server produksi. Target penggabungan kembali ke main dan development.
• refactor/*: Dibuat dari development untuk keperluan restrukturisasi kode tanpa merubah fungsionalitas bisnis.

B. Perbedaan Lingkungan: Development vs Staging vs Production

Setiap lingkungan (environment) memiliki peran, konfigurasi data, stabilitas, dan target audiens yang berbeda. Pemahaman mendalam mengenai perbedaan ketiga lingkungan ini sangat penting agar tidak terjadi kebocoran data sensitif, kerusakan sistem di produksi, atau hambatan pada proses pengujian QA.

Berikut adalah rincian perbedaan ketiga lingkungan tersebut:

1. Lingkungan Development (Dev / QA)

Lingkungan ini merupakan tahap pengujian pertama setelah kode selesai ditulis di mesin lokal developer.

• Karakteristik:
  • Konfigurasi API dan servis menggunakan akun Sandbox atau Mocking (misalnya: payment gateway sandbox dengan saldo buatan).
  • Toleransi terhadap kegagalan/error cukup tinggi karena tujuannya adalah mendeteksi kesalahan sedini mungkin.
  • Sering mengalami pembangunan ulang (build/deploy) otomatis setiap kali ada PR yang dimerge ke branch development.
• Aksi Developer: Menggabungkan fitur baru, menguji fungsionalitas unit, dan membiarkan QA menguji integrasi awal.

2. Lingkungan Staging (UAT / Pre-Production)

Lingkungan staging adalah replika dari lingkungan produksi. Prinsip utama di staging adalah memastikan aplikasi berjalan dengan baik sebelum rilis ke produksi.

• Karakteristik:
  • Performa server, arsitektur, dan konfigurasi dibuat semirip mungkin dengan produksi untuk mendeteksi masalah skalabilitas atau konfigurasi server.
  • Pengujian di lingkungan ini mencakup Regression Testing, Performance Testing, Security Penetration Testing, dan persetujuan dari Klien / Product Manager melalui proses UAT.
  • Data yang digunakan adalah data tiruan yang menyerupai perilaku data asli, bukan data produksi riil (karena alasan kepatuhan privasi/GDPR/data privacy).
• Aksi Developer: Memastikan build produksi sukses berjalan, memeriksa konsistensi visual di environment hosting staging, dan mendampingi QA/Client saat proses UAT.

3. Lingkungan Production (Prod / Live)

Ini adalah lingkungan aktif tempat aplikasi diakses langsung oleh pengguna akhir. Fokus utama di lingkungan produksi adalah menjaga ketersediaan layanan (uptime) dan integritas data.

• Karakteristik:
  • Keamanan maksimal. Akses ke server produksi dan database produksi sangat dibatasi (hanya DevOps/SRE tertentu yang memiliki akses).
  • Skalabilitas tinggi dengan load balancer, CDN, caching agresif, dan monitoring real-time (menggunakan Sentry, Datadog, atau Prometheus).
  • Setiap perilisan ke produksi wajib direncanakan matang-matang (misalnya saat low-traffic hours) dan memiliki rencana pemulihan darurat jika terjadi kegagalan (rollback plan).
• Aksi Developer: Melakukan rilis melalui tag versi resmi, memantau error log pasca-rilis di Sentry, dan segera bertindak jika alarm hotfix menyala.

C. Standar Penamaan Branch (Branch Naming Conventions)

Semua branch baru wajib menggunakan format penamaan lowercase dan kata pemisah menggunakan tanda hubung (kebab-case). Penulisan nama branch harus mencantumkan ID Tiket Jira/Task (jika ada) diikuti deskripsi singkat yang relevan.

Aturan Format:

[tipe-branch]/[id-tiket]-[deskripsi-singkat]

Jenis Prefiks yang Diizinkan:

• feature/: Untuk pengembangan fitur baru atau implementasi User Story.
  • Contoh: feature/BIT-102-user-login, feature/cart-page
• bugfix/: Untuk perbaikan kutu/masalah yang ditemukan di lingkungan development atau staging.
  • Contoh: bugfix/BIT-405-fix-dropdown-crash, bugfix/navbar-overlap
• hotfix/: Untuk perbaikan krusial dan mendesak langsung di lingkungan produksi (main).
  • Contoh: hotfix/BIT-911-fix-payment-gateway-leak
• refactor/: Untuk perubahan struktur kode tanpa mengubah fungsionalitas fitur (seperti restrukturisasi folder atau pembersihan kode).
  • Contoh: refactor/api-helper-cleanup
• docs/: Untuk pembaruan berkas dokumentasi saja.
  • Contoh: docs/update-readme
• chore/: Untuk pembaruan konfigurasi proyek, dependensi package (package.json), atau konfigurasi build pipeline.
  • Contoh: chore/upgrade-next-version

D. Alur Kerja Promosi Kode (Visualized Promotion Flow)

Berikut adalah visualisasi bagaimana perubahan kode mengalir dari komputer lokal developer hingga sampai ke server produksi:

 [Local Work]       [QA & Integration]       [UAT & Sandbox]       [Production Release]
  feature/*   ───►     development     ───►     staging      ───►        main
  bugfix/*                  │                       │                     │
   (Pull Request)           │ (Auto/Manual PR)      │ (Release PR)        │
                            ▼                       ▼                     ▼
                       [Dev Server]           [Staging Server]     [Production Server]

E. Panduan Langkah Demi Langkah bagi Developer (Step-by-Step Developer Guide)

Ikuti alur kerja berikut setiap kali Anda mendapatkan tugas baru untuk menjamin integrasi kode berjalan mulus tanpa konflik besar.

Langkah 1: Memperbarui Branch development Lokal

Sebelum mulai membuat branch baru, pastikan branch development di komputer lokal Anda sudah sinkron dengan server repositori pusat (origin).

git checkout development
git pull origin development

Langkah 2: Membuat Branch Baru

Buat branch baru dari development dengan format penamaan standar.

git checkout -b feature/BIT-123-implement-checkout

Langkah 3: Implementasikan Kode & Lakukan Commit

Terapkan perubahan Anda, jalankan validasi linter lokal, dan buat commit dengan mengikuti panduan Conventional Commits (lihat bagian 20).

git add .
git commit -m "feat(checkout): implement item selection and summary card"

Langkah 4: Sinkronisasi Terhadap Perubahan Terkini (Rebase/Merge)

Secara berkala, atau sesaat sebelum Anda membuat Pull Request, tarik perubahan terbaru dari development untuk menyelesaikan potensi konflik sejak dini di mesin lokal Anda.

# Tarik perubahan terbaru pada development di background
git fetch origin development

# Lakukan rebase agar riwayat komit Anda tetap linier
git rebase origin/development

[!TIP] Jika terjadi konflik saat rebase, selesaikan secara manual pada berkas yang bermasalah, lalu jalankan git add <berkas> dan lanjutkan dengan git rebase --continue.

Langkah 5: Dorong Branch ke Remote & Buka Pull Request

Setelah dipastikan lokal build aman, dorong branch Anda ke origin dan buka Pull Request di platform Git (GitHub/GitLab) ke target branch development.

git push -u origin HEAD

Langkah 6: Proses Tinjauan Kode (Code Review Checklist)

• Isi deskripsi PR dengan detail mengenai perubahan apa saja yang dilakukan, tangkapan layar (jika ada perubahan visual UI), dan cara mengujinya.
• Pastikan pipeline CI/CD (linting, testing, sonar build) sukses dijalankan (status hijau/pass).
• Tugaskan (Assign) rekan setim (minimal 1 peer reviewer) untuk meninjau kode Anda.
• Setelah disetujui, gunakan metode Squash and Merge untuk menggabungkan kode ke branch development demi menjaga riwayat commit tetap bersih dan mudah dibaca.

F. Strategi Perbaikan Darurat (Hotfix Flow)

Jika terjadi critical bug di lingkungan produksi (main) yang harus segera diselesaikan saat itu juga:

1. Buat branch hotfix langsung dari branch main:

   git checkout main
   git pull origin main
   git checkout -b hotfix/fix-checkout-crash
   

2. Lakukan perbaikan kode, uji secara menyeluruh, lalu commit.
3. Buat dua Pull Request terpisah:
   • PR 1: hotfix/fix-checkout-crash ➔ main (untuk rilis patch cepat ke produksi).
   • PR 2: hotfix/fix-checkout-crash ➔ development (agar perbaikan tersebut tidak hilang saat rilis fitur berikutnya).
4. Setelah disetujui dan dimerge ke main, lakukan tag versi baru (misalnya v1.2.1).

G. Aturan Penting Repositori (Git Safeguards - Do's & Don'ts)

• ❌ JANGAN PERNAH melakukan force push (git push -f atau git push --force) ke branch bersama seperti development, staging, atau main.
• ❌ JANGAN PERNAH mengabaikan kegagalan uji build pada pipeline CI/CD demi mempercepat merge.
• ❌ JANGAN memasukkan berkas sensitif (file .env, credentials, secret keys) ke dalam commit. Selalu verifikasi .gitignore.
• ✅ SELALU hapus branch lokal Anda setelah PR berhasil dimerge ke repositori utama untuk menghemat ruang disk dan merapikan branch lokal.

  git branch -d feature/BIT-123-implement-checkout
  

• ✅ SELALU buat Pull Request berukuran kecil dan terarah. PR dengan perubahan di bawah 250 baris kode jauh lebih mudah ditinjau dan dideteksi kesalahannya daripada PR raksasa berisi ribuan baris kode.