Trunk-based development: ana dala sık ve küçük birleştirme

Trunk-based development nedir?

Trunk-based development, tüm geliştiricilerin tek bir ortak dala (trunk, Git'te çoğunlukla ana dal) sık sık ve küçük parçalar halinde katkı yaptığı bir kaynak kod yönetimi yaklaşımıdır. Uzun süre ayrı yaşayan özellik dalları yerine, çalışmalar ya doğrudan ana dala işlenir ya da ana daldan ayrılıp çok kısa sürede geri birleştirilen dallarda yapılır.

Temel fikir şudur: Kod ne kadar uzun süre ana daldan ayrı kalırsa, sonradan birleştirmek o kadar zorlaşır. Birleştirmeyi sık yaparak çakışmalar küçük ve çözülebilir kalır; ana dal da her an çalışır durumda tutulur.

Nasıl çalışır?

Günlük akış genellikle şöyledir. Geliştirici ana dalın güncel halinden başlar, küçük bir değişiklik yapar, yerelde testleri çalıştırır ve değişikliği aynı gün içinde ana dala birleştirir. Kısa ömürlü dal kullanılıyorsa bu dal çok kısa süre yaşar ve kod incelemesinden hızlıca geçer.

Ekip büyüdükçe birleştirme sırasında otomatik doğrulama önem kazanır: her birleştirmede sürekli entegrasyon hattı derleme ve testleri çalıştırır. Ana dal kırılırsa öncelik yeni özellikten çok onu düzeltmektir. Bu disiplin olmadan yöntem, düzensiz bir ortak çalışma alanına dönüşür.

Bitmemiş işi nasıl saklarsınız? Özellik bayrakları

Yaygın bir itiraz şudur: Bir özellik günlerce sürüyorsa ve her gün ana dala giriyorsa, yarım kalmış kod kullanıcıya görünmez mi? Çözüm özellik bayraklarıdır (feature flags). Yeni kod ana dalda bulunur ama bir bayrakla kapalı tutulur; özellik tamamlanıp test edilince bayrak açılır.

Bayraklar aynı zamanda kademeli açılışa izin verir. Özellik önce ekip içinde, sonra sınırlı bir kullanıcı grubunda açılabilir. Sorun çıkarsa kodu geri almak yerine bayrak kapatılır. Bayraklar iş bitince temizlenmezse kodda karmaşıklık biriktirdiği için, her bayrağın bir sahibi ve kaldırılma planı olmalıdır.

Gitflow ve uzun ömürlü dallarla farkı

Gitflow gibi modellerde geliştirme, yayın ve düzeltme için ayrı uzun ömürlü dallar bulunur ve özellikler kendi dallarında haftalarca yaşayabilir. Bu model yayın döngüsü seyrek olan ürünlerde işe yarar, ancak birleştirme anında büyük çakışmalar ve entegrasyon sürprizleri üretebilir.

Trunk-based developmentta ise tek bir kaynak gerçeği vardır. Yayın dalı gerekiyorsa bile ana daldan kısa süreliğine kesilir ve kalıcı bir paralel geliştirme hattı olmaz. Bu fark, sürekli entegrasyon ve sürekli teslimat uygulayan ekipler için yöntemi doğal bir tercih haline getirir.

Ne zaman uygundur, nelere dikkat edilmeli?

Yöntem, sık yayın yapan ve otomatik test kapsamı yeterli olan ekiplerde daha iyi sonuç verir. Test güvencesi zayıfsa ana dalı sık güncellemek korkutucu hale gelir ve ekipler yöntemi bırakır. Bu nedenle yöntemi benimsemeden önce testlerin ve derleme hattının güvenilir olması gerekir.

Dikkat edilecek diğer noktalar: değişiklikleri küçük tutmak, kod incelemesini hızlı yapmak, ana dalı kırık bırakmamak ve bitmemiş işi bayraklarla ayırmaktır. Açık kaynak projeler gibi dışarıdan katkı alan yapılarda ya da çok seyrek yayın yapan ürünlerde başka dallanma modelleri de makul olabilir; tek doğru yoktur.

Git ve dallanma stratejilerini derinlemesine çalışmak isteyen geliştiriciler için Mindset'te 'Git İleri Seviye: Branching, Rebase ve Monorepo' programında 'Dallanma Stratejileri ve Birleştirme' modülü, 'DevOps Temelleri' ve 'SAFe DevOps Practitioner' programlarında ise sürekli entegrasyon ve teslimat başlıkları yer alır.