Gerçekten Ürün Çıkaran Ekipler İçin Dallanma Stratejisi
- Trunk-based geliştirme en az günlük dağıtım yapan ekiplere uyar; bu sıklığın altında karşılıksız sürtünme yaratır.
- GitHub flow çoğu ürün ekibi için doğru varsayılandır: kısa ömürlü dallar, tek ana dal ve birleştirmede dağıtım.
- GitFlow mobil, masaüstü ve gömülü sistemler gibi paketlenmiş ikili dosyalar dağıtan ekipler içindir.
- Sürüm dalları (release branches) risk park alanıdır. Zorunlu olduğunda kullanın ve en hızlı şekilde kapatın.
Dallanma stratejisi tartışmaları, her iki uçtaki acıyı bizzat yaşamamış kişiler tarafından soyut düzlemde yürütülür. Müşteri projelerinde her türlü git geçmişini devraldık: otuz mühendisin saat başı doğrudan ana dala yazdığı trunk depoları, altı paralel sürüm dalı olan GitFlow kurulumları ve sessizce aylarca yaşayan çatallara dönüşmüş GitHub flow dalları. Hiçbiri prensipte yanlış değildir; ancak hepsi kendi teslimat ritmine uymayan bir ekip için yanlıştır.
Doğru soru hangi modelin en iyisi olduğu değil, ekibinizin hangi sıklıkta ürün çıkardığı ve bir canlı ortam vakasının maliyetinin ne olduğudur.
Stratejiyi Belirleyen Dört Metrik
Bir mühendislik ekibine dallanma değişikliği önermeden önce DORA araştırmalarından gelen dört temel metriği ölçeriz: dağıtım sıklığı, ortanca PR ömrü, değişiklik hata oranı ve ortalama kurtarma süresi (MTTR). Ölçümlerin işaret ettiği karar tablosu oldukça nettir:
- Günde birkaç kez dağıtım ve 4 saatin altında PR ömrü: Özellik bayraklarıyla desteklenen Trunk-based geliştirme.
- Günlük ila haftalık dağıtım ve 1 ila 5 gün PR ömrü: GitHub flow.
- Haftalık ila aylık dağıtım ve 5 ila 14 gün PR ömrü: Ana daldan kesilen kısa süreli sürüm dalları.
- Aylıktan seyrek dağıtım ve 14 günü aşan PR ömrü: Yalnızca paketlenmiş ikili dosya (mobil, firmware) dağıtılıyorsa GitFlow.
En büyük sürtünme bu eşleşmeler bozulduğunda yaşanır. Haftada bir canlıya çıkan bir ekibe trunk-based disiplini dayatmak temizlenmeyen özellik bayrağı çöplüğü yaratırken, günde beş kez dağıtım yapan ekibi GitFlow’a zorlamak her hafta saatler süren gereksiz birleştirme mesaisine yol açar.
Trunk-Based ve GitHub Flow Ne Zaman Çalışır?
Trunk-based geliştirme, ön koşulları sağlandığında en yüksek çıktı üreten modeldir. Ana dala giren her commit dağıtılabilir olmalı, tamamlanmamış işler özellik bayrakları arkasına gizlenmeli, kod incelemesi dört saatin altında tamamlanmalı ve dağıtım hattı 15 dakikadan kısa sürmelidir. Bu dört şarttan biri eksikse yarım kalmış işler canlıya sızar.
Üç ila otuz mühendisten oluşan ve günlük veya haftalık dağıtım yapan çoğu SaaS ekibi için doğru varsayılan GitHub flow’dur. Eğer özellik dalları sürekli bir haftayı geçiyorsa veya birleştirme çakışmaları ekibin ritmini bozuyorsa, sorun dallanma modelinde değil işlerin çok büyük kapsamlı parçalar halinde tanımlanmasındadır.
GitFlow’dan Çıkış ve Gerçekten Önemli Olanlar
Sahada en sık yaptığımız dönüşüm, üç yıl önce üç ayda bir sürüm çıkarırken kurulan GitFlow yapısını, artık her gün dağıtım yapan ekiplerden kaldırmaktır. Mekanik geçiş bir gün sürer: develop dalı main içine katlanır, uzun ömürlü sürüm dalları kapatılır ve sıcak yamalar dal şekli olmaktan çıkarılıp normal sürece dahil edilir. Dal isimlendirme kuralları veya squash-rebase tartışmaları mimari değil boya rengidir; sayılara göre modeli seçin ve ritminiz değiştiğinde modeli güncelleyin.
Sıkça sorulan sorular
Trunk-based geliştirme her zaman en modern ve doğru seçim midir?
Hayır. Trunk-based yaklaşımı ya olgun bir özellik bayrağı (feature flag) sistemi ya da yalnızca tamamlanmış küçük parçaları birleştirme disiplini gerektirir. Bu ön koşulları atlayan ekipler yarım kalmış özellikleri yanlışlıkla canlıya alır ve sorunun modelde olduğunu düşünür.
Bir özellik dalı (feature branch) ne kadar süre açık kalmalıdır?
Ürün ekipleri için beş iş gününün altında, trunk-based çalışanlar için bir günün altında kalmalıdır. İki haftayı aşan dallar, dalın kendi değerinden daha pahalıya mal olan birleştirme borcu biriktirir.
Özellik bayrakları kullanıyorsak sürüm dallarına ihtiyacımız var mı?
Neredeyse hiçbir zaman. Özellik bayrakları dağıtımı sürümden ayırarak sürüm dallarının varlık nedenini ortadan kaldırır. Sürüm dallarını yalnızca mobil mağaza paketleri veya denetim için dondurulmuş dal şartı olan regüle ortamlarda tutun.