Gitflow'dan Trunk-Based'e geçerken feature flag mimarisini nasıl konumlandırırım?

Kısa cevap: Gitflow’da merge’lerin acı vermesi ve release’lerin haftalar sürmesi tam olarak uzun ömürlü dalların sürüklenmesinden kaynaklanıyor. Trunk-Based bunu küçük değişiklikleri sürekli main’e alarak çözer; ama “main’deki bitmemiş özellik kullanıcıya ulaşamasın” şartını feature flag’ler sağlar.

Mesele şu: kodu sık merge etmek istiyorsun ama yarım işin canlıya kaçmasını da istemiyorsun. Bu çelişkinin köprüsü flag’ler.

1. Uzun ömürlü dallar problemin kendisi — onları kaldır. feature/develop/release dalları zamanla ana daldan uzaklaşır; conflict ve haftalara yayılan release tam buradan doğar. Trunk-Based’de değişiklikleri küçük parçalar halinde sürekli main’e alırsın.
2. Bitmemiş işi flag arkasında “karanlıkta” tut. Tamamlanmamış özelliği prod’da kapalı bir flag’in arkasına koy, kodu yine de günlük main’e merge et. Özellik bitip test edilince flag’i açarsın. Böylece kod canlıda olur ama kullanıcıya görünmez.
3. Flag, deploy’u release’den ayırır. Kodu istediğin an deploy edersin (deploy), özelliği hazır olunca açarsın (release). Bu ayrım sana flag bazında canary/kademeli açılım da kazandırır — aynı sürümü %5 kullanıcıya açıp izleyebilirsin.
4. Disiplin şart: kısa ömürlü dallar, güçlü CI, flag hijyeni. Dallar bir-iki gün yaşasın, her merge’de CI sağlam çalışsın. En kritiği flag hijyeni: ölü flag’leri temizle, yoksa kendileri birer teknik borca dönüşür ve kod tabanını çorbaya çevirir.

Sonuç: 20 kişilik, Continuous Delivery hedefleyen bir ekip için doğru model Trunk-Based + feature flag’ler. Ben olsam dalları kısa tutar, her şeyi flag arkasında merge eder ve flag’leri geçici kabul edip biter bitmez temizlerdim. Trunk-Based’e tam olarak ne zaman ve hangi ön koşullarla geçtiğimi sade.dev’de ayrıntısıyla anlattım.