Trunk-Based Development — nedir, ilkeleri ve tek bir dalda çalışma

Trunk-Based Development Nedir?

Trunk-Based Development (TBD), tüm geliştiricilerin değişikliklerini günde birkaç kez tek bir ana dala (trunk, main veya master) entegre ettiği bir sürüm yönetimi metodolojisidir. Uzun ömürlü özellik dallarına sahip Git Flow'un aksine, TBD dal ömrünü birkaç saate, nadiren 1–2 güne indirir. Ana hedef, büyük bir özelliğin haftalarca geliştirmeden sonra trunk'a birleştirildiği “birleştirme cehennemi”nden (merge hell) kaçınmaktır.

Google Cloud DevOps, 2024'e göre, Trunk-Based Development yüksek performanslı DevOps ekiplerinin temel uygulamalarından biridir. State of DevOps Report (Puppet, 2023), TBD kullanan ekiplerin arızalardan %30 daha hızlı kurtulduğunu ve üretimde kritik kusurlarla %50 daha az karşılaştığını gösterdi. TBD, Continuous Deployment için zorunludur.

Trunk-Based Development, geliştiricilerin inceleme olmadan doğrudan trunk'a commit yaptığı anlamına gelmez. TBD'de, MR oluşturma ve hızlı kod incelemesinden (birkaç saat içinde) sonra trunk'a birleştirilen kısa ömürlü özellik dalları kullanılır. İnceleme bir günden fazla sürerse, özelliğin daha küçük parçalara bölünmesi gerekir.

State of DevOps Report: TBD Hakkında Veriler

Yıllık State of DevOps Report (Puppet/DORA), yüksek performanslı ekiplerin uygulamalarını takip eder. 2015'ten bu yana TBD, yüksek dağıtım sıklığı (deploy frequency) ve düşük kurtarma süresi (MTTR) ile ilişkili ilk 3 uygulama arasında yer almaktadır. TBD uygulayan ekipler, kodu 2–3 kat daha sık dağıtır ve arızalardan %30 daha hızlı kurtulur (DORA, 2023).

Feature Toggles: Dallar Olmadan Tamamlanmamış Kod Yönetimi

Feature Toggles (özellik bayrakları, feature flags), kodu değiştirmeden işlevselliği etkinleştirme ve devre dışı bırakma mekanizmasıdır. TBD'de, feature toggles özellik dallarının yerini alır: geliştirici tamamlanmamış kodu trunk'a gönderir ancak koşullu bir bayrağın arkasında gizler. Özellik göstermeye hazır olduğunda, bayrak yeniden dağıtım olmadan yapılandırmada değiştirilir.

Martin Fowler, 2024'e göre, feature toggles dört türe ayrılır: release toggles (özellik görünürlüğü yönetimi), experiment toggles (A/B testi), ops toggles (operasyonel parametre yönetimi) ve permission toggles (role dayalı erişim). Mobil projelerde, release toggles özellikle kullanışlıdır: yeni işlevsellik yayın tarihine kadar gizlenir, ancak kod zaten trunk'tadır ve CI/CD'den geçer.

// Android'de Kotlin ile Feature Toggle
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Kodda kullanım
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

Trunk-Based Development'ta CI/CD: Zorunlu Uygulamalar

Continuous Integration (CI), TBD'nin en önemli bileşenidir. Trunk'a (veya MR'dan önce geçici bir dala) her push, tam bir pipeline'ı tetikler: derleme, birim testler, entegrasyon testleri, lint'ler, statik analiz, kod kapsamı kontrolü. En az bir aşama başarısız olursa, yazar bir sonraki commit'ten önce kodu düzeltir. “Kırık trunk — durdurulmuş geliştirme” TBD'nin ana kuralıdır.

Jez Humble, Continuous Delivery, 2024'e göre, Trunk-Based Development, 10–15 dakikada tamamlanan bir CI pipeline'ı gerektirir. Derleme daha uzun sürerse, geliştiriciler daha az sıklıkta commit yapar ve bu da TBD'nin anlamını bozar. Mobil projelerde, Android ve iOS derlemeleri 20–30 dakika sürebilir ve bu da TBD'yi daha az kullanışlı hale getirir. Bu durumlarda, ekipler anında CI ile Short-Lived Feature Branches (1 günlük dallar) kullanır.

# TBD (Android) için GitHub Actions
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Kısa Ömürlü Dallar: TBD'de Çalışma Kuralları

Kısa ömürlü dallar (short-lived branches), saf TBD (doğrudan trunk'a commit) ile Git Flow arasında bir uzlaşmadır. Bir dal en fazla 1–2 gün yaşar, 1–3 commit'lik değişiklikler içerir ve incelemeden (en fazla 4 saat bekleme) sonra trunk'a birleştirilir. Bir özellik daha fazla zaman gerektiriyorsa, her biri kendi kısa ömürlü dalına sahip alt görevlere bölünür.

TBD Documentation, 2024'e göre, kısa ömürlü dal kuralları: dal taze bir trunk'tan (1 saatten eski olmayan) oluşturulur, merge/rebase ile trunk ile senkronize edilmez (4 saatten fazla geçmişse yeni bir dal oluşturulur), MR/PR ilk commit'ten hemen sonra oluşturulur (iş tamamlanmamış olsa bile — Draft olarak).

Pre-tested Commits: Garantili Commit'ler

Trunk-Based Development için, pre-tested commits tekniği önemlidir: geliştirici commit yapmadan önce kendi dalında CI pipeline'ını çalıştırır ve yalnızca yeşil durumdan sonra commit trunk'a ulaşır. GitLab'de bu, “Merge when pipeline succeeds” seçeneğiyle Merge Request pipeline'ları aracılığıyla uygulanır. GitHub'da — Required status checks ile branch protection rules aracılığıyla. Bu, trunk'ın asla bozuk kod içermemesini sağlar.

• 1–2 gün — short-lived branch'in maksimum ömrü
• 1–3 commit — optimal değişiklik boyutu
• 4 saat — kod incelemesi için maksimum bekleme süresi
• MR oluşturun ilk commit'ten hemen sonra, Draft durumunda bile

Branch by Abstraction: Dallanmadan Kod Değiştirme

Branch by Abstraction, uzun ömürlü bir özellik dalı oluşturmadan sistemin bir parçasını değiştirmeye veya önemli ölçüde değiştirmeye olanak tanıyan bir tekniktir. Git'te dallanma yerine, geliştirici hem eski hem de yeni uygulamanın altında çalıştığı bir soyutlama (arayüz) oluşturur. Kademeli olarak, tüm tüketiciler yeni uygulamaya geçirilir ve ardından eski uygulama kaldırılır.

Branch by Abstraction, 2024'e göre, Branch by Abstraction aşamaları: 1) değiştirilecek bileşen için bir soyutlama oluşturun, 2) soyutlama altında yeni sürümü uygulayın, 3) tüketicileri yapılandırma yoluyla yeni uygulamaya geçirin, 4) eski uygulamayı kaldırın. Tüm adımlar, her biri CI/CD'yi bozmayan küçük parçalar halinde trunk'a commit edilir.

TBD vs Git Flow: Yaklaşımların Karşılaştırması

Trunk-Based Development ve Git Flow, dal yönetimine iki zıt yaklaşımdır. Git Flow uzun ömürlü dallar ve katı bir hiyerarşi kullanırken, TBD tek bir dal ve kısa entegrasyon döngüleri kullanır. Aralarındaki seçim, ekip büyüklüğüne, yayın sıklığına ve CI/CD otomasyon seviyesine bağlıdır.

Trunk-Based Development Uygularken Tipik Hatalar

TBD hataları çoğunlukla yetersiz CI/CD veya zayıf commit disiplini ile ilgilidir. İlk hata, CI olmadan TBD uygulamaktır ve ilk başarısız commit'te çöker. Trunk 15 dakika içinde düzeltilemezse, ekip sürece olan güvenini kaybeder ve uzun dallara geri döner. İkinci hata, “sadece bu özellik için” uzun ömürlü dallara izin vermektir ve bu da tüm konsepti yok eder.

Paul Hammant, 2023'e göre, üçüncü hata zayıf kod modülerliğidir. Trunk-Based Development, kodun bağımsız modüllere bölünmesini gerektirir. Bir sınıftaki değişiklik diğer üç modülü bozarsa, geliştiriciler küçük parçalar halinde commit yapamazlar. Dördüncü hata, feature toggles'ı görmezden gelmektir: bayrak olmadan tamamlanmamış kod göndermeye çalışmak, tüm ekip için trunk'ı bozar.

Mobil Geliştirmede Trunk-Based Development

Trunk-Based Development mobil projelerde, uzun derleme süreleri (Android ve iOS için 20–30 dakika) ve katı kalite gereksinimleri nedeniyle özelliklere sahiptir. Google ve Spotify, mobil geliştirmede TBD kullanır ve birleştirmeden önce zorunlu CI ile kısa ömürlü dallar uygular. Feature toggles, Firebase Remote Config veya LaunchDarkly aracılığıyla yönetilir.

LaunchDarkly Docs, 2024'e göre, mobil geliştirmede TBD bir avantaj sağlar: özellikler, yayın tarihinden önce trunk'ta kodun geri kalanıyla birlikte test edilir ve entegrasyon sorunları riskini azaltır. CI pipeline'ı 15 dakikadan fazla sürerse, her push'ta otomatik CI ile 1 günlük kısa ömürlü dallar idealdir. Apple App Store ve Google Play için TBD, feature toggles aracılığıyla aşamalı dağıtım yapılandırması gerektirir.

Hizmet Olarak Feature Flags: LaunchDarkly ve Firebase

TBD'de feature toggles yönetimi için platformlar kullanılır: LaunchDarkly (kurumsal, tam özellikli), Firebase Remote Config (küçük projeler için ücretsiz), Split.io (açık kaynak). Bunlar sağlar: kullanıcı yüzdesine göre hedefli özellik etkinleştirme, A/B testi, kullanım izleme ve hatalarda otomatik devre dışı bırakma. Mobil projelerde, Firebase Remote Config, Firebase ile entegrasyonu ve 1000 kullanıcıya kadar ücretsiz eşiği nedeniyle en popüler seçimdir.