Gitflow'dan Trunk-Based'e geçerken feature flag mimarisini nasıl konumlandırırım?
Soru
20 kişilik bir ekibiz. Gitflow'da `feature`/`develop`/`release`/`master` dalları üzerinden ilerliyoruz ama merge'ler uzun sürüyor (conflict) ve release süreleri haftaları buluyor. Continuous Delivery kültürüne geçmek için Trunk-Based'e geçmeyi planlıyoruz. Kodun küçük parçalar halinde doğrudan ana dala gittiği bu modelde, bitmemiş özelliklerin canlıda aktif olmasını engellemek için feature flag mimarisini nasıl konumlandırırım?
Cevap
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.
Kısa cevap
Mesele şu: kodu sık merge etmek istiyorsunuz ama yarım işin canlıya kaçmasını da istemiyorsunuz. Bu çelişkinin köprüsü flag’ler. Dal, merge ve PR disiplininin üretimdeki karşılığını Git rehberinde topluca ele almıştım; buradaki geçiş o disiplinin üstüne kurulur.
Neden
-
Uzun ömürlü dallar problemin kendisi.
feature/develop/releasedalları zamanla ana daldan uzaklaşır; conflict ve haftalara yayılan release tam buradan doğar. -
Flag, deploy’u release’den ayırır. Kodu istediğiniz an deploy edersiniz (deploy), özelliği hazır olunca açarsınız (release). Bu ayrım size flag bazında canary/kademeli açılım da kazandırır — aynı sürümü %5 kullanıcıya açıp izleyebilirsiniz.
-
Temizlenmeyen flag’ler yeni bir borç yaratır. Ölü flag’ler kendileri birer teknik borca dönüşür ve kod tabanını çorbaya çevirir; yani flag’i kalıcı bir yapı olarak görmek, çözdüğü problemin yerine bir yenisini koyar.
Ne yapmalı
-
Uzun ömürlü dalları kaldırın, değişikliği sürekli main’e alın. Trunk-Based’de değişiklikleri küçük parçalar halinde sürekli main’e alırsınız; dal ömrü kısaldıkça conflict de release süresi de kendiliğinden düşer.
-
Bitmemiş işi flag arkasında “karanlıkta” tutun. Tamamlanmamış özelliği prod’da kapalı bir flag’in arkasına koyun, kodu yine de günlük main’e merge edin. Özellik bitip test edilince flag’i açarsınız. Böylece kod canlıda olur ama kullanıcıya görünmez.
-
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 temizleyin.
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.
İlgili Yazılar
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.