Trunk Based Development Nedir: Tek Ana Dalda Geliştirme

Trunk based development nedir? Tüm geliştiricilerin tek bir paylaşılan dala -- genellikle main -- günde en az bir kez kod gönderdiği bir geliştirme modelidir. Uzun ömürlü feature branch yok. Haftalarca bekleten hotfix-v2-backup-final yok. Kısa dallar saatler içinde açılır, hızla birleştirilir ve silinir. Kod tabanı sürekli yayına hazır kalır. Google, 35.000 geliştiricisiyle bu şekilde çalışıyor. Nasıl işlediği, ne zaman uygun olduğu ve ne zaman olmadığı aşağıda.

"rapor_v2_FINAL_bunu_kullan.xlsx" Sorunu -- Ama Kod İçin

Paylaşılan bir klasörü açıp rapor_v1.xlsx, rapor_v2_FINAL.xlsx ve rapor_BU_KULLAN_greg_duzeltmeleri.xlsx dosyalarını yan yana gördüyseniz trunk based development'ın çözmeye çalıştığı acıyı zaten biliyorsunuzdur.

Ekipler uzun ömürlü feature branch kullandığında kod tabanında tam olarak aynı şey oluyor. Biri birinci haftada bir feature başlatıyor. Ekibin geri kalanı göndermeye devam ediyor. Üçüncü haftada o dal, main'in onlarca commit gerisinde kalıyor. Birleştirmek hafta sonu projesi haline geliyor; kimse sahiplenmek istemiyor. Çakışmalar birikiyor. Kodu yazan geliştirici neden yarısını yazdığını unutmuş bile. İşte bu "birleşim cehennemi."

En yaygın öğretilen alternatif olan Gitflow, buna biçimsel yapıyla çözüm bulmaya çalışıyor: feature, release ve hotfix için ayrı dallar, her birinin belirlenmiş bir ömrü var. Yapı kağıt üzerinde temiz görünüyor. Pratikte dallar paylaşılan diskteki elektronik tablo sürümleri gibi birikiyor ve entegrasyon günü entegrasyon haftasına dönüşüyor.

Trunk based development tam tersini savunuyor: entegrasyon borcunu biriktirmeyi bırak. Bugün main'e commit at.

Herkes Her Gün Main'e Commit Atıyor. Modelin Tamamı Bu.

Temel kural basit: tüm geliştiriciler değişikliklerini en az 24 saatte bir paylaşılan trunk'a gönderiyor. "Henüz bitirmedim" istisnası yok -- elindekini commit ediyorsun ve elindekinin build'i bozmadığından emin oluyorsun.

Bu, güvenli kılan mekanizmaları anlayana kadar ürkütücü geliyor:

• Kısa ömürlü dallar: Hâlâ dal kullanabilirsiniz, ancak dallar haftalar değil saatler içinde yaşıyor. İki günden uzun süren bir dal, incelemesi gereken bir uyarı işareti.

• Her commit'te otomatik test: CI pipeline test suite'i anında çalıştırıyor. Bir şey bozulursa dakikalar içinde anlıyorsunuz, sprint sonunda değil.

• Feature flag: Yarım kalan feature'lar hazır olana kadar bir toggle'ın arkasında gizli kalıyor. Kullanıcılar tamamlanmamış çalışmayı hiç görmüyor, üretim kodunda olsa bile.

Sonuç, her an yayına hazır bir kod tabanı. "Feature branch'i birleştirip bir hafta QA çalıştırdıktan sonra yayına hazır" değil; şu an gerekse yayına alınabilecek. Bu temel vaattir.

Peki bu pratikte nasıl görünüyor? Sabah standupında bir geliştirici şunu söylüyor: "Dün ödeme akışının veri katmanını tamamladım, test geçti, main'e merge ettim. Bugün UI bileşenlerini başlatıyorum, feature flag arkasında, akşama kadar main'e geliyor." Bu cümle trunk based development'ın özüdür. Bitmemiş bir özellik değil; bitmemiş ama güvenle paketlenmiş ve paylaşılmış iş.

Kısa Ömürlü Dallar: Haftalarca Değil, Saatlerle Ölç

Trunk based development'ta dallar yasaklı değil. Uzun dallar yasaklı.

Sabah 9'da açtığınız, sabahı çalışarak geçirdiğiniz, öğleden sonra kod incelemesi yaptırdığınız ve akşam 5'ten önce main'e birleştirdiğiniz dal tam doğru türde. Takım arkadaşlarına çalışmayı trunk'a gelmeden önce inceleme fırsatı veriyor. Tek okumada anlaşılacak kadar küçük. Varsa çakışmalar dakikalar içinde çözülüyor.

Bir geliştiricinin üç haftayı tam bir kimlik doğrulama sistemini yalnız başına geliştirerek geçirdiği dal ise sorun. Sonunda birleştirme zamanı geldiğinde ekip, feature geliştirmeye harcadığından daha fazla zamanı çakışma çözmeye harcıyor.

Çoğu trunk-based takımın kullandığı pratik eşik: bir dal iki gün içinde birleştirilmediyse bir şeylerin değişmesi gerekiyor. Ya feature çok büyük ve daha küçük parçalara bölünmesi gerekiyor, ya da kısmi çalışmanın güvenle trunk'a gelmesi için bir feature flag lazım.

Çalışmayı daha küçük parçalara bölmek, trunk based development'ın asıl geliştirdiği temel disiplin. "Tüm dashboard'u yap" yerine "veri katmanını ekle," ardından "ilk grafiği ekle," ardından "filtreleri bağla." Her parça trunk'a birleşiyor, test ediliyor ve bağımsız olarak gönderiliyor. Tam feature birkaç commit üzerinden aşamalı olarak ortaya çıkıyor.

Bu daha yavaş gibi görünüyor. Pratikte daha hızlı, çünkü sorunları bağlam hâlâ tazeyken ve kapsam hâlâ küçükken buluyorsunuz.

Küçük parçaların bir başka faydası: kod incelemesi çok daha verimli. 50 satırlık bir değişikliği inceleyen bir geliştirici gerçek geri bildirim verebiliyor. 800 satırlık bir PR'ı inceleyen birisi çoğunlukla yüzeysel geçiyor, çünkü tüm bağlamı aynı anda kafasında tutmak mümkün değil. Küçük, sık birleştirmeler doğal olarak daha iyi kod kalitesine yol açıyor.

Feature Flag: Yarım İşi Hiçbir Şeyi Bozmadan Nasıl Gönderirsiniz

Feature flag'ler (özellik bayrakları da deniyor), bir feature tek kısa ömürlü dalda tamamlanamadığında trunk based development'ı pratikte mümkün kılan mekanizma.

Fikir basit: yeni işlevselliği yalnızca belirli bir flag açıkken etkinleşen bir koşula sarın.

if (featureFlags.yeniRaporlamaDashboard) {
  yeniDashboardGoster();
} else {
  eskiDashboardGoster();
}

Yeni kod canlıya alınıyor. Siz toggle'ı açana kadar kullanıcılar için çalışmıyor. Bu şu anlama geliyor:

• Geliştiriciler devam eden çalışmayı kimseyi etkilemeden trunk'a commit edebiliyor

• QA, flag'i belirli bir kullanıcı veya ortam için etkinleştirerek canlı ortamda feature'ı test edebiliyor

• Bir sürüm, dağıtım olayı değil yapılandırma değişikliği oluyor

• Bir şey bozulursa rollback veya hotfix dalı olmadan flag'i kapatıyorsunuz

Feature flag altyapısı başlangıçta kontrol edilen basit bir ortam değişkeninden özel feature flag platformlarına kadar uzanıyor. Yeni başlayan bir ekip için bir yapılandırma dosyası veya ortam başına değişken yeterli. Önemli olan araç karmaşıklığı değil, kapasite.

Flag'lerin ek bir avantajı var: A/B testini çok basit hale getiriyor. Yeni özelliği kullanıcıların yalnızca %10'una açıp davranışını ölçebilirsiniz. Sorun görürseniz flag'i kapatırsınız, sıfır dağıtım olayı. Sorun yoksa kademelı olarak tüm kullanıcılara açarsınız. Bu, geleneksel sürüm yönetimiyle çok daha zahmetli bir süreç olurdu.

Trunk Based Development Her Durumda Doğru Seçim Değil

Açıkça söylemek gerekiyor: trunk based development evrensel olarak daha iyi değil. Belirli bağlamlara uyuyor.

Atlayın eğer:

CI/CD pipeline'ınız hazır değilse. Her commit'te otomatik test olmadan trunk based development bir branching stratejisi değil, hızla biriken bozuk bir kod tabanı. Test altyapısı önce yerinde olmalı, branching modeli ancak ondan sonra işe yarayabilir.

Ekip yapısı gereği sık commit atamıyorsa. Asenkron çalışan dağıtık ekipler, farklı saat dilimlerinde çalışan katkıcılar veya seyrek toplu gönderimler yapan açık kaynak projeleri günlük commit temposuyla zorlanacaktır.

Zorunlu yayın pencereleri olan düzenlenmiş bir ortamdasınız. Bazı sektörler dış onay, uzun QA döngüsü ve resmi denetim izi gerektiriyor. Gitflow'un yapılandırılmış yayın dalları bu tür iş akışlarıyla daha iyi uyuşuyor.

Ekip disiplini henüz oturmamışsa. Trunk based development, main'e atılan her commit'in ya tüm testleri geçmesini ya da anında düzeltilmesini gerektiriyor. Ekibiniz bozuk build'lere tolerans gösteriyorsa, paylaşılan trunk herkesin ortak sorunu haline geliyor.

Gitflow, üç ayda bir yayın takvimi olan, ayrı ekiplerin birden fazla feature geliştirdiği veya dal düzeyinde izolasyon gerektiren uyumluluk gereksinimleri olan takımlar için makul bir tercih. Konu ilkede hangisinin kazandığı değil, dürüstçe uyumu bulmak. Yanlış bağlamda doğru aracı kullanmak, doğru bağlamda yanlış aracı kullanmaktan her zaman daha iyi sonuç verir.

GitFlow'dan TBD'ye Kriz Yaratmadan Geçiş

Ekibiniz Gitflow'daysa ve trunk based development'ı denemek istiyorsa, geçişin sert bir kesinti olması gerekmiyor.

Yeni uzun ömürlü dal açmayı bırakarak başlayın. Karardan sonra başlayan feature'lar kısa ömürlü dallar alıyor. Uzun dallarda hâlâ devam eden feature'lar eski modelde bitiyor. İki yaklaşım geçici olarak bir arada yaşıyor.

Tamamlanmamış işi trunk'a commit etmeden önce feature flag'lerin hazır olması gerekiyor. Temel düzeyde bile bir feature flag sistemi kurmak, her şeyin ön koşulu. Onsuz trunk based development, canlı ortam kullanıcılarına tamamlanmamış arayüz göndermek anlamına geliyor.

Ardından main branch üzerinde CI'ı zorunlu hale getirin: her push'ta otomatik testler çalışıyor, başarısız testler birleştirmeyi engelliyor ve geçen bir build olmadan kimse birleştiremiyor. Bu pazarlık konusu olmayan kısım.

Son olarak iki günlük kuralı açıkça tanımlayın: iki günden eski herhangi bir dal, ne yapılacağına dair bir konuşmayı hak ediyor. Feature'ı daha küçük parçalara bölün, flag ekleyin veya hazır olanı gönderin. Bunu pull request sürecinizde görünür hale getirin.

Çoğu ekibin rahatsız olduğu ayarlama şu: "kısmen tamamlanmış" olmanın, bir flag'in arkasına gizlenip mevcut testleri bozmadığı sürece commit edilebilecek geçerli bir şey olduğunu kabul etmek.

DORA Raporu Gönderim Hızı Hakkında Ne Söylüyor

DevOps Research and Assessment (DORA) raporları, yazılım geliştirmede takım pratikleri üzerine büyük ölçekli ampirik araştırmanın en yakın benzeri. 2021 DORA raporu, elite performanslı takımların düşük performanslı takımlara kıyasla trunk based development kullanma olasılığının 2,3 kat daha yüksek olduğunu buldu.

DORA çerçevesindeki elite performanslılar günde birden fazla kez dağıtım yapıyor; commit'ten üretime geçiş süresi haftalar yerine saatlerle ölçülüyor. Trunk based development bu sonuçlarla tutarlı biçimde ilişkili çıkıyor.

Önemli uyarı: korelasyon nedensellik değil. Yüksek performanslı takımlar trunk based development'ı benimsiyor çünkü temel disiplinine zaten yatırım yapmışlar -- otomatik test, sağlam CI/CD altyapısı, küçük ve odaklı değişiklikler yazan geliştiriciler. Bu temeller önce geliyor. Trunk based development, o bağlama uyan branching modeli; o bağlamı yaratan şey değil.

Biscuit bunu hızlıca anlıyor: iyi bir retriever bir anda üç topu birden taşımaya çalışmaz. Bir commit, bir inceleme, bir birleştirme. Good boy.

TBD'ye Geçmeye Değer mi?

Ekibiniz her sprint'te birleşim çakışmalarına anlamlı zaman harcıyorsa, "feature branch hazır değil" diye sürümleri geciktiriyorsa veya neden açıldığını kimsenin hatırlamadığı dallar varsa -- trunk based development ciddi bir değerlendirmeyi hak ediyor.

Günlük commit temposu zorlu. Feature flag altyapısı kurulum gerektiriyor. Kültürel dönüşüm birkaç hafta sürüyor. Ancak sonuç -- her zaman yayına hazır bir kod tabanı, dosyalar yerine satırlarla ölçülen birleşim çakışmaları ve kriz yerine rutin olan sürümler -- ekibin çalışma biçiminde anlamlı bir iyileşme.

Küçük başlayın: bir ekip, bir sprint, her push'ta çalışan CI, hazır feature flag'ler. Dört haftada ne değiştiğini görün.

En önemli ölçüt birleşim çakışmalarına harcanan zamandır. Sprint retrospektifinde şunu sorun: "Bu sprintte birleşim çakışmalarını çözmek için kaç saat harcadık?" O sayıyı bir sonraki sprint için de takip edin. TBD işe yarıyorsa sayı düşüyor olmalı. İşe yaramıyorsa -- CI yeterince hızlı değil, feature'lar hâlâ çok büyük, feature flag kullanımı yetersiz -- o alanda derine inin. Mekanizma sorunu varsa önce onu çözün, modeli suçlamadan önce.