# Trunk Based Development Nedir? SRE İçin Pratik Rehber

URL: https://upstreamapi.com/tr/journal/trunk-based-development-nedir
Type: blog
Locale: tr
Published: 2026-10-10
Updated: 2026-10-10

---

> Trunk based development pratikte neyi gerektirir: günlük birleştirmeler, feature flag'ler, hızlı CI, gözlemlenebilirlik ve modelin yanlış seçim olduğu durumlar.

Saat sabahın 3'ü ve release dalı birleşmiyor. Üç hafta önce açılmış kırk commit, main ile aynı dosyalara dokunuyor. Bu sahne, trunk based development'ın neden var olduğunu anlatıyor. Peki trunk based development nedir? Herkes küçük değişiklikleri tek bir paylaşılan dala, yani trunk veya main'e günde en az bir kez birleştirir ve o dalı her zaman yayınlanabilir durumda tutar.

Bu rehber, Git'i zaten bilen platform mühendisleri için yazıldı. Modelin neyi gerektirdiğini, neyi koruduğunu ve nerede sessizce bozulduğunu anlatıyor.

## Operasyonel olarak trunk based development nedir?

Tanımı kısıtlarına indirgeyin. Tüm geliştiriciler tek bir dala entegre olur. Diğer her dal saatler boyunca yaşar, haftalar değil. Trunk her commit'te derlenir ve testlerden geçer, böylece istendiği anda yayınlanabilir.

[DORA'nın yetenek sayfası](https://dora.dev/capabilities/trunk-based-development/) bunu somut sayılarla tanımlar: depoda en fazla üç aktif dal, trunk'a günde en az bir birleştirme, kod dondurması olmaması ve birkaç dakikada tamamlanan bir build ve test döngüsü. Bu sayılar modelin özüdür. Trunk based development bir dallanma tarzı tercihi değil, bir geri bildirim döngüsü bütçesidir.

![Gece karanlık bir masa, üzerinde terminal açık bir dizüstü bilgisayar ve yanan bir telefon bildirimi](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/6d43db-i1.webp)

Küçük ekipler bazen doğrudan trunk'a commit atar. Daha büyük ekipler review ve build kontrolleri için kısa ömürlü dallar ve pull request'ler kullanır, ama işi entegrasyondan alıkoymak için asla. [trunkbaseddevelopment.com referansı](https://trunkbaseddevelopment.com/) her iki modu da anlatır ve Google'ı örnek gösterir. Google, bir monorepo içinde yaklaşık 35.000 geliştiriciyi tek bir trunk üzerinde çalıştırıyor.

## Uzun ömürlü dallar öngörülebilir bir takvimde neden çöker

Özellik dalı bir borçtur. Faizi merge conflict'tir ve sen uzaktayken main'e her commit indiğinde bu faiz birikir. Dal ne kadar uzun yaşarsa diff o kadar büyür, diff büyüdükçe de kimse onu dikkatle okumaz.

Bunun change failure rate üzerindeki etkisi şöyle: 2.000 satırlık bir birleştirme bir göz gezdirilip onaylanır. 60 satırlık bir birleştirme ise gerçekten okunur. Review yapanlar tembel değildir, dikkatlerini kısıtlı bir kaynak gibi dağıtırlar. Review kalitesini ölçeklenebilir tutan tek mekanizma küçük partilerdir.

İkinci maliyet sürüme kadar görünmez kalır. CI'dan geçen iki dal, bir araya geldiklerinde birbirlerini bozabilir. Bunu entegrasyon anında öğrenirsiniz, yani en kötü anda, üzerinde bir de teslim tarihiyle.

## Trunk'a güvenmeden önce neye ihtiyacınız var

Destekleyici pratikler olmadan trunk'a geçmek, takımların bir çeyrek içinde yeniden özellik dallarına dönmesinin yoludur. Önce dört şeyin var olması gerekir.

- 
Yaklaşık on dakikanın altında çalışan bir build ve test süreci. CI 40 dakika sürüyorsa geliştiriciler değişiklikleri biriktirir ve biriktirme modeli bozar.

- 
Gerçek nedenlerle başarısız olan testler. Kararsız (flaky) bir test takımı tekrar çalıştırıp yine de birleştirmeye iter.

- 
Hızlı ve dürüst bir review süreci. DORA, ağır ve asenkron code review'u yaygın bir engel olarak listeler, çünkü geliştiricileri işi biriktirmeye iter.

- 
Yarım işi güvenle yayınlamanın bir yolu. Bu bir sonraki bölümün konusu.

Bu eksikler giderilmeden trunk, kırılmaların yakalandığı yer olmak yerine birikip durduğu yer olur.

## Yarım kalan işi yayınlamadan nasıl birleştirirsiniz?

Her şüphecinin sorduğu soru budur ve cevabı sıkıcıdır: deploy ile release'i ayırırsınız. Kod karanlık şekilde production'a ulaşır. Kimin göreceğine bir flag karar verir.

`// checkout.ts
import { flags } from "./flags";

export async function renderCheckout(user: User) {
  if (await flags.isEnabled("new-payment-flow", { userId: user.id })) {
    return renderNewPaymentFlow(user); // trunk'a birleşti, varsayılan olarak kapalı
  }
  return renderLegacyCheckout(user);
}`Yeni akış ilk günden trunk'a birleşir, ama flag kapalıdır. Önce dahili kullanıcılar için açarsınız, sonra yüzde 1, sonra yüzde 10, ve her adımda bir SLO kapısı bulunur. Hata oranı bütçeyi aşarsa flag kapanır ve değişiklik bir deploy olmadan fiilen geri alınmış olur. Barındırılan flag servislerini değerlendiren ekipler çoğu zaman LaunchDarkly ile başlar, ama bu desen herhangi bir sağlayıcı ya da kendi yapılandırma deponuzla da çalışır.

İkinci teknik, büyük refactor'lar için branch by abstraction'dır. Bir arayüz tanıtırsınız, çağıranları bu arayüzden geçirirsiniz, yeni implementasyonu arayüzün arkasında kurarsınız ve hazır olduğunuzda değiştirirsiniz. Uzun ömürlü dal yok, büyük patlamalı birleştirme yok.

![Bazıları açık, bazıları kapalı bir sıra duvar anahtarı, feature flag'lere benzer](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/81ea3c-i3.webp)

## Dürüst maliyet: flag'ler yarılanma ömrü olan borçtur

Konferans sahnelerinde kimse bundan bahsetmek istemez. Eklediğiniz her flag, birinin kaldırması gereken bir production koşuludur. 80 mühendislik ekibinin yüzlerce eski flag taşıdığını gördük. Her biri, kimsenin tam olarak test edemediği bir kod dalıdır.

Flag'leri sözleşme gereği kısa ömürlü sayın. Her birine oluşturulduğu anda bir sahip ve bir son kullanma tarihi verin. Süresi geçmiş flag'ler için uyarı kurun. Ölü kod yolunu, flag'i kaldıran pull request'in içinde silin.

Kombinatoryal risk de gerçek. On bağımsız boolean flag, 1.024 olası yapılandırma demektir. Hepsini asla test etmeyeceksiniz. Flag etkileşimlerini az tutun ve release flag'lerini kill switch gibi uzun ömürlü operasyonel anahtarlardan ayrı tutun.

## Trunk'ın üzerinde yayın stratejileri

Trunk'tan yayın kesmenin iki yaygın yolu vardır ve hiçbiri uzun ömürlü bir dal gerektirmez.

- 
Doğrudan trunk'tan yayınlayın. Her yeşil commit bir adaydır. Hatalar, eski bir dalı yamalayarak değil, yeni bir commit ile ileriye doğru düzeltilir. Bu, güçlü otomatik testleri ve hızlı deploy'ları olan ekiplere uyar.

- 
Yayın dalını tam zamanında kesin. Bilinen iyi bir trunk commit'inden dal açarsınız, sertleştirir, yayınlar ve dalı silersiniz. Düzeltmeler önce trunk'a girer ve sonra geri cherry-pick edilir. Bu, yavaş yayın kapıları olan ya da regülasyon gereği onay gerektiren ekiplere uyar.

Hangisini seçeceğiniz tespit süresinize bağlıdır. Kötü bir deploy'u beş dakika içinde fark edip iki dakikada geri alabiliyorsanız ileriye düzeltin. Ortalama tespit süreniz bir saatse, bir yayın dalı size durmak için bir zemin sağlar.

![Yan raylardan gelip tek bir ana hatta birleşen kısa tren yolları](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/67c259-i2.webp)

## Gözlemlenebilirlik anlaşmanın diğer yarısıdır

Trunk based development deploy sıklığınızı artırır, bu da bir şeyin ters gidebileceği anların sayısını artırır. Model, bir birleştirmenin ardından regresyonu dakikalar içinde görebiliyorsanız işe yarar. Bu da belirli bir release'e bağlı hata oranlarını, gecikme yüzdelik değerlerini ve doygunluğu gerektirir. Pazartesi günü birisinin baktığı bir dashboard yeterli değildir.

Hızlı bir test: bir birleştirmeden sonra, beş sekme açmadan "bu değişiklik p99'u ya da hata oranını oynattı mı?" sorusunu yanıtlayabiliyor musunuz? Yanıtlayamıyorsanız, günde on kez birleştirmeye hazır değilsiniz.

Birleştirmenin ilk on dakikası kritik bir pencere. Bu süre içinde deploy'u izleyen kişi hangi metriğe bakacağını önceden bilmelidir. Bilmiyorsa her birleştirme bir keşif gezisine dönüşür, ekip bir sonraki değişikliği göndermek yerine ekranın başında bekler ve modelin hızı tükenir. Bu yüzden izlenecek metrikler, deploy'un hemen ardından açılacak dashboard ile birlikte önceden tanımlanmalı ve her değişiklik için aynı yerde durmalıdır.

Hangi stack'i kullanırsanız kullanın gereksinim aynıdır. Grafiklerinizde deploy işaretleri, SLO burn-rate uyarıları ve yorgun bir insanın sabah 3'te düşünmeden çalıştırabileceği bir geri alma yolu.

## Trunk based development, GitFlow ve GitHub Flow karşılaştırması

Üçü sık sık karıştırılır, o yüzden birbirinden tek bir özellikle ayırın: iş paylaşılan daldan ne kadar süre uzak kalıyor?

- 
GitFlow bir develop dalı, özellik dalları, release dalları ve hotfix dalları tutar. İş haftalarca izole kalabilir. Sürümlü ve planlanmış yayınlar için tasarlanmıştı ve günde on kez deploy etmeye çalıştığınızda bu ortaya çıkar.

- 
GitHub Flow trunk'a yakındır. Kısa ömürlü dallar, pull request'ler, main'e birleştirme, deploy. Referans sitesinin çizdiği fark çoğunlukla yayınların nereden çıktığıyla ilgilidir.

- 
Trunk based development, üçü arasında dal ömrü konusunda en katı olanıdır ve tek bir küçük değişiklikle yayınlanamayan her şey için feature flag'leri ya da branch by abstraction'ı varsayar.

Takımınız zaten iki günden kısa yaşayan dallarla GitHub Flow yapıyorsa, sandığınızdan daha yakınsınız demektir. Aradaki fark genellikle araç değil, flag disiplini ve review gecikmesidir.

## Hangi DORA metrikleri önce hareket eder?

Başlamadan önce bunları ölçün, yoksa sonradan hislerle tartışırsınız. Deploy sıklığı ve değişiklik için lead time önce tepki verir, çünkü küçük partiler pipeline'dan daha hızlı geçer. Change failure rate ve restore süresi ardından gelir ve bunlar yalnızca dallanmaya değil, gözlemlenebilirliğinize ve geri alma yolunuza bağlıdır.

Sayıları bireyler için bir karne haline getirmeyin. Sistemi tarif ederler. Lead time yükseldiğinde insanlara bakmadan önce review kuyruğuna ve CI süresine bakın.

Ölçümde bir tuzak var: lead time'ı kodlamanın başladığı andan değil, ilk commit ile production'daki ilk başarılı deploy arasındaki süreden hesaplayın. Aksi halde yalnızca geliştirme süresini ölçmüş olursunuz ve trunk'a geçişin etkisi görünmez kalır. Ortalamaya da tek başına güvenmeyin. Tek bir haftalık dal, ortalamayı sessizce şişirir. Medyanı ve 90. yüzdeliği birlikte izleyin, böylece hem tipik akışı hem de en uzun bekleyen değişiklikleri görürsünüz.

## Trunk based development ne zaman yanlış karardır?

Birkaç durumda bunu atlayın ya da ertelemeniz gerekir. Hangisinde olduğunuzu dürüstçe kabul edin.

- 
Test paketiniz bir saat sürüyor ve paralelleştiremiyorsunuz. Biriktirme yaparsınız ve biriktirme modeli bozar.

- 
Müşterilere sürümlü artifact'lar teslim ediyorsunuz ve müşteriler yıllarca eski sürümlerde kalıyor. Bakım dallarına ihtiyacınız var. Bu meşrudur ve yine de trunk'a her gün entegre olabilirsiniz.

- 
Bir flag sisteminiz yok ve bir tane kurma isteğiniz de yok. Yarım kalmış iş yayınlara sızar.

- 
Takımınız build'e güvenmiyor. Önce testleri düzeltin. Trunk bunu düzeltmez.

Trunk based development hiçbir şeyin garantisi de değildir. DORA'nın bulgusu 2016 ve 2017 verilerinden gelen bir korelasyondur: bu pratikleri izleyen ekipler daha iyi teslimat ve operasyonel performans gösteriyor. Dallarınızın adını değiştirmenin pipeline'ınızı düzelttiğini söylemez.

## Büyük patlamalı göç olmadan nasıl başlanır?

Bir politika ilan etmeyin. Önce ölçün, sonra küçültün.

- 
Mevcut dal ömrünüzü ve medyan pull request boyutunu kaydedin. Bunlar başlangıç değerleriniz olur.

- 
Bir sınır koyun, örneğin iki günden eski dal olmasın, ve bunu bir dashboard'da görünür yapın.

- 
CI'ın en yavaş kısmını düzeltin. Build 30 dakika sürüyorsa henüz başka hiçbir şey önemli değildir.

- 
Gerçek bir özellik için tek bir flag tanıtın. Karanlık şekilde yayınlayın. Bir sprint içinde kaldırın.

- 
Kod dondurmalarını en son kaldırın, geri alma yolunuz gerçekten denendikten sonra.

Bir ay sonra yeniden bakın. İlk hareket eden sayılar genellikle pull request boyutu ve birleştirme süresidir. Change failure rate daha uzun sürer ve bazen iyileşmeden önce kötüleşir, çünkü kırılmaları artık daha erken görmeye başlarsınız.

## Son post-mortem'iniz dal modeliniz hakkında ne söylerdi?

Post-mortem ne diyecek? Yayına almadan önce sorulacak yararlı soru budur. Son olayınız incelenemeyen bir birleştirmeye, üç hafta ayrışmış bir dala ya da kırk değişikliği paketleyen bir yayına dayandıysa, borcun nerede vadesinin geldiğini zaten biliyorsunuz.

Son üç kesintinize bakın. Kaçında büyük, geç bir entegrasyon vardı? Bu sayı sizin iş gerekçenizdir.

## FAQ

### Trunk based development tek cümlede nedir?

Geliştiricilerin küçük değişiklikleri en az günde bir kez tek bir paylaşılan dala birleştirdiği, diğer dalların birkaç saatlik ömre sahip olduğu ve trunk'ın her zaman yayınlanabilir tutulduğu bir kaynak kodu yönetimi pratiğidir.

### Trunk based development, GitFlow'dan nasıl farklıdır?

GitFlow işi günlerce ya da haftalarca feature, develop ve release dallarında izole eder. Trunk based development ise sürekli entegrasyon yapar ve tamamlanmamış işi dallar yerine feature flag'lerin ya da soyutlamaların arkasında gizler.

### Trunk based development için feature flag gerekir mi?

Her değişiklik için değil, ama tamamlanmamış işi güvenle birleştirmenin bir yolu gerekir. Feature flag ve branch by abstraction bunun iki standart tekniğidir. Flag'ler ayrıca kademeli yayın ve hızlı kapatma anahtarı sağlar.

### Trunk based development'ta bir dal ne kadar yaşamalı?

DORA, dalların genellikle birkaç saatten fazla yaşamadığını, trunk'a birleştirmelerin günde en az bir kez yapıldığını ve depoda üç veya daha az aktif dal bulunduğunu söyler.

### Trunk based development büyük ekipler için de işe yarar mı?

Evet. Daha büyük ekipler review ve build kontrolleri için kısa ömürlü dallar, bunun yanında flag'ler ve soyutlamalar kullanır. Referans site, bir monorepo içinde tek trunk üzerinde yaklaşık 35.000 geliştirici çalıştıran Google'ı örnek gösterir.

### Trunk based development ne zaman benimsenmemeli?

CI her birleştirmede çalışamayacak kadar yavaşsa, tamamlanmamış işi gizleyecek bir mekanizmanız yoksa ya da ekip test paketine güvenmiyorsa. Önce bunları düzeltin.