İçeriğe geç
Muhammet Şafak
en
Soran: Tarık Cevaplandı:

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

  1. Uzun ömürlü dallar problemin kendisi. feature/develop/release dalları zamanla ana daldan uzaklaşır; conflict ve haftalara yayılan release tam buradan doğar.

  2. 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.

  3. 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ı

  1. 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.

  2. 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.

  3. 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

Etiketler: #CI/CD#Git#Mimari
Paylaş:

Yorumlar

Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.

Diğer Sorular

Tüm sorular

Sitede Ara

Yazı, proje ve sayfalarda arama yapmak için yazmaya başlayın.

Esc ile kapat Pagefind ile güçlendirildi