Belajar Git Branching Strategies - Trunk-Based Development untuk Tim Besar

#Pendahuluan

Setelah di episode 14 kita memahami perbedaan long-lived vs short-lived branches — dan mengapa branch pendek lebih disukai — pada episode ini kita membahas bagaimana Trunk-Based Development (TBD) bisa di-scale untuk tim besar. TBD di episode 3 dibahas untuk tim kecil-menengah; sekarang kita lihat bagaimana enterprise mengadaptasinya.

Kunci scaling TBD: feature flags menggantikan long-lived branches, CI/CD pipeline memastikan kualitas, dan TDD memberikan confidence untuk commit ke main setiap hari.

#Feature Flags Management System

Untuk tim besar, feature flags bukan sekadar if statement — diperlukan sistem manajemen yang terpusat:

#Contoh Implementasi

import { init, variation } from 'launchdarkly-node-server-sdk'
 
const client = init(process.env.LD_SDK_KEY!)
 
async function isNewCheckoutEnabled(userId: string): Promise<boolean> {
  return await variation(client, 'new-checkout-flow', userId, false)
}

Feature flag memungkinkan kode baru di-deploy ke production tetapi tidak aktif sampai flag diaktifkan. Ini menggantikan kebutuhan long-lived feature branch.

#Branch by Abstraction

Ketika kalian perlu mengganti dependensi lama (misal library A ke library B) tanpa memecahkan kode, gunakan branch by abstraction:

1. Buat abstraksi (interface) di atas dependensi lama.
2. Implementasikan interface dengan dependensi baru.
3. Gunakan feature flag untuk switching.
4. Hapus dependensi lama setelah semua user beralih.

// Layer abstraksi
interface PaymentGateway {
  charge(amount: number): Promise<Result>
}
 
// Implementasi lama
class StripeGateway implements PaymentGateway { ... }
 
// Implementasi baru
class MidtransGateway implements PaymentGateway { ... }
 
// Switching via feature flag
const gateway = featureFlags.isEnabled('use-midtrans')
  ? new MidtransGateway()
  : new StripeGateway()

#Parallel Change (Expand & Contract)

Pattern ini memungkinkan perubahan API tanpa breaking change dalam satu commit:

1. Expand: tambahkan versi baru API alongside versi lama.
2. Migrate: pindahkan semua consumer ke versi baru.
3. Contract: hapus versi lama.

Setiap tahap bisa di-deploy secara terpisah. Tidak perlu branch panjang untuk perubahan API.

#CI/CD Pipeline untuk TBD

Pipeline TBD harus cepat dan reliable:

#Aturan Pipeline

• Setiap push ke main harus passing semua tests.
• Deploy ke staging otomatis, production manual/approval.
• Monitoring & rollback cepat via feature flag toggle.

#TDD + TBD

Test-Driven Development memastikan setiap commit ke main aman:

1. Write test → test gagal (red).
2. Write code → test passing (green).
3. Refactor → test tetap passing.

Dengan TDD, setiap commit ke main punya test yang memvalidasi. Confidence untuk commit meningkat drastis.

#Penutup

Pada episode 15 ini, kalian telah memahami TBD untuk Tim Besar:

• Feature flags management (LaunchDarkly, Unleash, Flagsmith) menggantikan long-lived branches.
• Branch by abstraction memungkinkan pergantian dependensi tanpa branch panjang.
• Parallel change (expand & contract) memungkinkan perubahan API tanpa breaking change.
• CI/CD pipeline harus cepat dan reliable: lint → test → build → staging → approval → production.
• TDD memastikan setiap commit ke main aman dan teruji.

Di episode 16 selanjutnya kita akan mempelajari GitHub/GitLab Branch Protection & Rulesets — bagaimana mengamankan branch utama dengan status checks, approval requirements, dan rulesets modern. Sampai jumpa di episode 16!