Haftalık yayınlar için Trunk tabanlı geliştirme vs GitFlow

Yanlış dallanma modeliyle haftalık yayınlar nasıl karışır

Haftalık yayın basit görünür — ta ki bir hafta kaçırana kadar. Perşembe günü yapı "neredeyse hazırdır", QA geç bir Cuma'da sorun bulur ve Pazartesi temiz bir başlangıç yerine temizlik günü olur.

Büyük etken dallanma modelinizdir. O, değişikliklerin ne zaman buluştuğunu, entegrasyonun nerede yapıldığını ve bir şey bozulduğunda ne kadar hızlı toparlanabileceğinizi belirler. Entegrasyon haftanın sonuna itiliyorsa, bunun bedelini birleştirme çatışmaları, sürpriz hatalar ve sallantılı test ortamlarıyla ödersiniz.

İş akışı size karşı çalıştığında genellikle şöyle hissedersiniz:

• Birleşmeler, bu birleşmelere neden olan özellik işinden daha uzun sürer.
• QA, dallar sürüklendiği için yanlış değişiklik karışımını test eder.
• Sürümler rutin olmaktan çıkar, pazarlığa dönüşür.
• Hotfix'ler panik yaratır çünkü kimse başka nelerin yayına gideceğinden emin değildir.
• İnsanlar QA'ya güvenmeyi bırakır ve istisnalar ister.

Dallanma aynı zamanda QA kararlılığını şekillendirir. QA yarı-entegre kod yolları arasında gidip geliyorsa hedef sürekli hareket eder. Güçlü test uzmanları bile, sistem her birkaç saatte bir değiştiğinde veya geç bir birleşme dün test ettiklerini sessizce değiştirdiğinde net cevap veremez.

İşte bu yüzden ekipler haftalık yayın ritmine geçerken trunk tabanlı geliştirme ile GitFlow'u karşılaştırır. Doğru soru hangisinin popüler olduğu değil; hangisinin birleşme ağrısını azalttığı, sürümleri öngörülebilir kıldığı, hotfix'leri güvenli ve hızlı yaptığı ve QA'yı anlamlı tuttuğudur.

Küçük-orta ölçekli bir ekip, tek bir paylaşılan repo, her push'ta CI çalışıyor varsayın. Belki bir web uygulaması ve API yayınlıyorsunuz. Veya ekibin bir kısmı AppMaster gibi bir platformda görsel olarak inşa ederken yine de üretilen kod ve dağıtımları diğer ürün ekipleri gibi yönetiyor olabilir.

Mevcut süreciniz büyük, haftanın sonundaki birleşmeler üretiyorsa, haftalık ritminiz kaymaya devam eder. Eğer küçük, sık entegrasyonu teşvik ediyorsa haftalık sürümler sıkıcı (iyi anlamda) olmaya başlar.

Trunk tabanlı geliştirme ve GitFlow basitçe

Her iki yaklaşım da işin "devam ediyor" halinden "yayına" sorunsuz geçmesi için dal kullanım kurallarıdır. Gerçek fark kaç uzun ömürlü dal tuttuğunuz ve işin başkalarının koduyla buluşmadan önce ne kadar süre ayrı kaldığıdır.

• Trunk tabanlı, neredeyse her şeyi maine yakın tutar.
• GitFlow, devam eden iş ve sürüm stabilizasyonu için ayrı hatlar tutar.

Trunk tabanlı geliştirme (basit anlatım)

Trunk tabanlı geliştirme, maini (trunk) merkez olarak ele alır. İnsanlar kısa ömürlü dallarda (saatler ila bir-iki gün) çalışır, sık geri merge eder ve maini yayınlanabilir durumda tutarlar.

Bir şey hazır değilse, ya onu küçülterek hızlıca bitirirsiniz, ya da feature flag'in arkasına saklayarak görünür olmadan güvenle yayınlarsınız.

GitFlow (basit anlatım)

GitFlow genellikle feature çalışmalarının önce düştüğü uzun ömürlü bir develop dalı ve developdan çıkan feature dalları kullanır. Sürüm zamanına yaklaşıldığında release/* dalı kesilir, test ve stabilizasyon burada yapılır. Prod kırıldığında genellikle mainden bir hotfix/* dalı kesilir ve geri merge edilir.

Bu model ayrımı optimize eder: devam eden işler developde sürerken release dalı test edilip düzeltilir.

Çoğu acı da yaygın yanlış anlamalardan gelir:

• Trunk tabanlıyı "dal yok" zannetmek (hala dal kullanır, ama kısa ömürlüdür).
• GitFlow kullanıp gerçek bir release dalı hiç yaratmamak, böylece develop kararsız bir staging alanına dönüşür.
• Feature dallarının haftalarca yaşamasına izin vermek; bu her modeli birleşme sorununa çevirir.
• "yayınlanabilir"i "her şey bitmiş" ile karıştırmak yerine "deploy için güvenli" demek.

Birleştirme sürtüşmesi: gerçekte ne sebep olur

Birleştirme çatışmaları genellikle iki kaynaktan gelir: dalların çok uzun süre yaşaması ve birden çok kişinin aynı alanları koordinasyonsuz değiştirmesi.

Trunk tabanlı ile GitFlow arasındaki en büyük pratik fark, işin diğer işlerle buluşmadan önce ne kadar süre ayrı kaldığıdır.

Trunk tabanlı geliştirmede değişiklikler ana hattı sık sık vurur. Pull request'ler daha küçük, diff'ler daha küçük olur ve çatışmalar bağlam taze iken erken görünür. Çatışmalar hâlâ olur ama genelde birkaç satırı uzlaştırmak kolaydır, iki haftalık sürüklenmeyi çözmekten daha basittir. Takas disiplin gerektirir: build'leri yeşil tutun, değişiklikleri artımlı yapın ve maini ürün gibi davranın.

GitFlow'da feature çalışması uzun süre diğer geliştiricileri günlük olarak etkilemeden bekleyebilir. Maliyet daha sonra, daha büyük birleşme olayları olarak kendini gösterir: feature→develop, develop→release/*, release/*→main. Her birleşme daha büyük bir değişim buluşmasıdır, bu yüzden çatışmalar daha olası ve çözmesi daha zordur. Haftalık gönderimler için bu büyük birleşmeler genelde ekibin test yapmak istediği zamana gelir.

Kod inceleme yükü de kayar. Trunk tabanlı genelde daha fazla inceleme demektir, ama her biri anlaması daha çabuktur. GitFlow ise genelde daha az ama daha ağır incelemeler ve release birleşmeleri sırasında ekstra gözden geçirme süresi getirir.

Her iki modelde de birleştirme sürtüşmesini azaltmak için:

• PR'ları küçük ve odaklı tutun (tek bir hedef).
• Riskli alanlar için sahipliği kabul edin (migrasyonlar, paylaşılan konfigürasyon, çekirdek UI).
• Yukarı akışı günlük çekin ki sürüklenmeyesiniz.
• Bir dosya sürekli "ateşliyse", paralel yarışmak yerine eşli çalışın.

Çatışmalar sürekli hissediliyorsa genelde entegrasyonu çok geç yaptığınızın işaretidir; Git problem değildir.

Haftalık ritim için sürüm öngörülebilirliği

Öngörülebilirlik üç şey demektir: sürümün ne zaman çıkacağını, içinde ne olduğunu ve ship etmeden önce hangi kontrollerin geçmesi gerektiğini bilmek. Ekipler genelde haftalık yayınları kaçırırlar çünkü kapsam kararlarını son dakika düzeltmeleriyle karıştırırlar.

Trunk tabanlı geliştirmede, main yeşil kaldığı sürece haftalık sürümler öngörülebilir kalır. Küçük değişiklikleri sıkça merge eder ve kapsamı feature flag'lerle kontrol edersiniz; bu, bir özellik bitmemiş olsa bile haftalık treni hareket ettirir. Kod yerde durur ama kullanıcıya açık davranış kapalı kalır.

Kalite kapıları genelde daha basittir çünkü doğrulama için tek bir yer vardır:

• Otomatik testler mainde geçmeli.
• QA, saat başı ne gelirse onu değil, kararlı bir candidate build'i test eder.
• Rollout ve rollback adımları yazılıdır.
• Net bir release kesme zamanı vardır (commit'ler gelmeye devam etse bile).

GitFlow'da öngörülebilirlik release dalının bir freeze bölgesi gibi davranmasından gelir. Bir kesinti seçer, release/* kesersiniz ve sadece gönderim için gereken değişikliklere izin verirsiniz. Bu sınır yardımcıdır ama koordinasyon ekler çünkü düzeltmeler genelde birden fazla yere (release ve develop) uygulanmak zorundadır.

Tamamlanmamış işler farklı şekilde ele alınır:

• Trunk tabanlı: güvenli parçaları merge edin, geri kalanını flag'lerin arkasında tutun.
• GitFlow: tamamlanmamış işi developde tutun ve release dalına dahil etmeyin.

Örnek: ödeme akışındaki iyileştirmeler Çarşamba yarım kaldıysa, trunk tabanlı model güvenli refactor'ları merge eder ve yeni UI'yı gizler. GitFlow genelde bunu developde tutar, yayın bunu olmadan yapar ve bir sonraki haftalık sürümde tamamlar.

Hotfix akışı: prod'a en hızlı ve güvenli yol

Hotfix normal iş değildir. Hız, düşük risk ve değişikliğin ekibin çalıştığı yere geri geldiği bir yol gerekir ki aynı hatayı iki kere düzeltmeyesiniz.

Başlangıç sorusu: şu anda prod'ta tam olarak hangi kod çalışıyor? Buna saniyeler içinde cevap veremiyorsanız hotfix'ler tahmine dönüşür.

Trunk tabanlı hotfix'ler

Trunk tabanlı hotfix'ler daha basit gelebilir çünkü main bilgi kaynağı olarak kabul edilir.

Yaygın akış:

• Prod commit'inden kısa ömürlü bir dal oluşturun (çoğunlukla main).
• En küçük mümkün düzeltmeyi yapın (mümkünse bir test ekleyin).
• Hızla maine merge edin.
• mainden deploy edin ve release tag'i atın.

Ekip sıkça maine entegre ettiği için hotfix doğal olarak bir sonraki haftalık sürümün parçası olur. Ana risk, maini yayınlanamaz hale getirerek "main yayınlanabilir" kuralını bozmak; feature flag'ler yardımcı olur ama varsayılan kapalı olduklarından ve hotfix'i doğrularken alakasız özellikleri etkinleştirmediğinizden emin olun.

GitFlow ile hotfix'ler

GitFlow'da hotfix genellikle mainden başlar ve düzeltmeyi kaybetmemek için develope de merge edilmelidir.

Güvenli akış:

• Prod tag'inden hotfix/* dalı oluşturun.
• Düzeltin ve yayınlayın (hotfix dalından veya maine merge ettikten sonra).
• Hotfix'i maine ve ayrıca develope merge edin.
• Eğer bir release/* dalı varsa, ona da merge edin.

En yaygın başarısızlık bu merge'lerden birini unutmaktır. Bir hafta sonra hata "geri döner" çünkü develop yamayı hiç almadı.

Basit bir kural çoğunu önler: hotfix, tekrar yayınlayacak tüm uzun ömürlü dallara merge edilmeden tamamlanmış sayılmaz.

QA ortamlarını kararlı tutma (ekibi engellemeden)

Haftalık yayınlar, "QA"nın "şu anda dağıtılan her şey" olduğu zaman bozulur. Ortamlarınıza isim verin ve her birine bir görev atayın: dev hızlı geri bildirim için, QA ekip testi için, staging sürüm kontrolleri için, prod müşteriler için. Bir ortamın amacını bir cümlede açıklayamıyorsanız insanlar onu yanlış kullanır.

Hareketli hedefleri önleyen kurallar

Kararlı QA, dallanma modelinden çok ne deploy ettiğinizle ilgilidir.

Trunk tabanlı çalışmada, QA'ya rastgele commit'ler dağıtmayın. Aynı kontrolleri geçen sabit bir candidate (tag'lenmiş build, build numarası veya kısa ömürlü release-candidate dalı) deploy edin. QA, geliştirme mainde devam ederken bile test edilecek sabit bir şeye sahip olur.

GitFlow'da QA genelde release dalını takip eder. Tuzak, QA başladıktan sonra release dalının değişmeye devam etmesine izin vermektir. QA başladığında release dalını bir sözleşme gibi değerlendirin: sadece onaylı düzeltmelere ve net bir süreçle izin verin.

Her iki yaklaşımı da öngörülebilir kılan küçük kurallar seti:

• QA'ya sadece geçen build'leri dağıtın.
• Deploy edilen versiyonu pinleyin (tag, build numarası veya release dalı head'i) ve bunu duyurun.
• QA değişikliklerini hata düzeltmeleriyle sınırlayın, yeni özelliklerle değil.
• Test verilerini zamanlanmış olarak sıfırlayın ve neyin silindiğini belgeleyin.
• Konfigürasyonu kod olarak tutun (değişkenler ve şablonlar) ki ortam sürüklenmesi azalır.

Ekip AppMaster kullanıyorsa aynı ilke geçerlidir: QA için belirli bir build'i yeniden oluşturup deploy edin, rastgele sürekli değişen düzenlemeler değil.

Birden fazla ekip aynı QA'yı paylaşıyorsa

Tek bir paylaşılan QA ortamı, iki ekip farklı versiyonlara ihtiyaç duyduğunda darboğaz olur. Ayrı QA ortamlarını karşılayamıyorsanız hafif bir rezervasyon kuralı ekleyin: bir ekip belirli bir zaman penceresi için QA'ya sahip olsun, diğerleri dev veya staging'i kullansın. Feature flag'ler de yardımcı olur; tamamlanmamış işler deploy edilebilir ama testçilere görünmez.

Örnek: Ekip A haftalık release candidate'ı doğruluyor, QA build 1842'ye pinli kalır. Ekip B fix'leri merge etmeye devam edebilir ama bu değişiklikler bir sonraki candidate için bekler; QA testini ortasında değiştirmez.

Adım adım: ekibinizin her hafta takip edebileceği bir iş akışı seçin

"Haftalık yayın" sizin için ne demek olduğunu yazın. Bir yayın günü ve saati seçin, kabul edilebilir risk seviyesini belirleyin (ör. "bilinen P1 hatası yok"), ekip büyüklüğü ve saat dilimlerini not edin. Bu, dal tartışmalarının öncelik tartışmasına dönüşmesini engeller.

Bir temel model seçin ve bir ay boyunca ona bağlı kalın. İlk günden karıştırmayın. Karışım genelde yeni kurallar ekler ama sürprizleri azaltmaz.

Uyarlanabilir basit bir haftalık iş akışı:

• Dal ömürlerini kısa tutun (saatler ila 1–2 gün) ve en az günlük merge edin.
• Güvenlik rayları ekleyin: hızlı CI, kısa zorunlu inceleme ve gerçek kırılmaları yakalayan küçük bir otomatik test seti.
• Kapsamı nasıl kontrol edeceğinize karar verin: feature flag'ler, haftanın sonunda kısa ömürlü release dalı veya tam sürüm commit'i için tag'lar.
• Hotfix adımlarını tanımlayın: kim tetikleyebilir, hangi kontroller gerekli ve düzeltme ana hatta nasıl geri gelir.
• QA'yı sabit tutun: QA'nın neyi takip ettiğini (release dalı veya pinlenmiş candidate) belirleyin ve test ortasında değiştirmeyin.

Minimum iş akışını bir sayfaya yazın. Yeni bir ekip üyesi bununla toplantı olmadan takip edebilmeli. Bu, ekibin bir kısmı görsel olarak (ör. AppMaster) çalışıp bir kısmı kodla çalışıyorsa daha da önemlidir; çünkü el değişimleri kurallar yalnızca birinin kafasında yaşarsa başarısız olur.

Örnek: her iki modelde gerçekçi bir haftalık sürüm

6 kişilik bir ürün ekibini düşünün; her Cuma yayın yapıyorlar. İki QA tester tek bir staging ortamını paylaşıyor, staging kararsızsa test durur.

GitFlow ile yoğun bir hafta

Pazartesi: üç geliştirici feature'ları bitirip develope PR açar. QA, developden üretilen staging'i test etmeye başlar.

Çarşamba: ekip Friday için release/1.8 keser. Yeni işler develope gelmeye devam eder, ama QA artık release build'ine odaklanır.

Perşembe öğleden sonra: geç bir bug çıkar. Düzeltme önce release/1.8e gider ki QA hızlıca retest etsin. Sonra birisi bu düzeltmeyi develope merge eder; işte burada hatalar sık olur.

Tipik ritim:

• Pzt-Sal: feature'lar develope merge olur, staging sıkça değişir.
• Çar: release/1.8 kes, staging release build'lerine geçer.
• Perş: release/1.8de bug fix, sonra develope merge.
• Cum: release/1.8i maine merge et, tag at ve deploy et.

Aynı hafta trunk tabanlı ile

Hafta küçük, sık merge'ler etrafında şekillenir. Feature'lar flag'lerin arkasında tutularak eksik iş merge edilebilir.

Pzt–Per: geliştiriciler küçük değişiklikleri günlük merge eder. QA sabit bir candidate build test eder.

Salı: prod'ta bir sorun çıkarsa hotfix, mainden kısa bir dal ile yapılır, gözden sonra hemen merge edilir ve prod'a çıkar. main kaynak olarak kabul edildiği için ekstra geri merge adımı yoktur.

Her iki durumda da ekip net terfi kurallarına ihtiyaç duyar:

• Staging en son pinlenmiş candidate build'i çalıştırır, her yeni commit'i değil.
• QA yeni bir candidate hazır olduğunda ister; otomatik olarak değil.
• Sadece Cuma sürümü için gerekli düzeltmeler candidate'i değiştirebilir.
• Diğer her şey flag'lerin arkasında kalır veya candidate dışında tutulur.

Çoğalan iş ve kararsız QA yaratan yaygın hatalar

Çoğu ekip yanlış modeli seçtiği için başarısız olmaz; günlük alışkanlıklar modelle uyuşmadığı için başarısız olur ve QA gürültülü, sürümler rastgele hissedilir.

Yaygın sorun dalların "hazır değil" diye günlerce açık kalmasına izin vermektir. Kod mainden sürüklenir, çatışmalar çoğalır ve QA kimsenin yeniden üretemediği karışık bir şeyi test eder.

Bir diğer hata GitFlow'u gerçek bir freeze olmadan kullanmaktır. Release dalı stabilizasyon yapmalı ama ekip hâlâ "bir tane daha" değişikliği sıkıştırır. Bu release dalını ikinci bir main hattına çevirir ve kimse QA'nın neyi onayladığını bilmez.

QA, yarım kalmış build'ler için bir döküm ortamı gibi davranıldığında da kararsızlaşır. Eğer her commit QA'ya kurallarsız giderse tester'lar hareketli hedeflerin peşinden koşar.

En çok sürtüşme yaratan hatalar:

• Geç birleşip alakasız işleri bozan uzun ömürlü feature dalları.
• Hâlâ yeni özellikleri kabul eden release dalları.
• Net bir promosyon yolu olmaması, böylece QA test ettiği build ile ship edilen build aynı değil.
• Aceleyle yapılan hotfix'ler sonra her yere merge edilmiyor.
• Sahibi, amacı ve reset planı olmayan ortamlar.

Uygulanabilir bir kural seti tutun:

• QA sadece pinlenmiş bir candidate test eder.
• Aynı artefaktı QA'dan prod'a terfi ettirin.
• Her ortamın sahibi ve reset periyodu olsun.
• Hotfix'ler aynı gün ana hatta geri akmalı.

Sürprizler olmadan haftalık yayın için hızlı kontrol listesi

Haftalık yayın, ekibiniz birkaç sıkıcı soruya güvenle "evet" diyebildiğinde çalışır. İki veya daha fazla soruya "hayır" diyorsanız geç düzeltmeler ve QA çalkantısı bekleyin.

• Bugün güvenle dağıtabileceğiniz bir dal (branch) var mı? Build etmeli, smoke test'leri geçmeli ve yarım kalmış değişikliklerden kaçınmalı.
• Pull request'ler küçük kalıp bir-iki gün içinde merge oluyor mu? Uzun yaşayan PR'lar genelde geri bildirim gecikmesi ve büyük çatışmalar demektir.
• QA sabit bir build mi test ediyor, yoksa hareketli bir hedef mi? QA spesifik bir build numarası veya release candidate doğrulamalı.
• Yayına bitmemiş işi drama olmadan sokmaktan kaçınabiliyor musunuz? Feature flag'ler, konfigürasyon toggle'ları veya net scope-cut kuralı.
• Birisi hotfix'i ve rollback'i tahmin yapmadan çalıştırıp geri alabiliyor mu? Kısa bir runbook tribal bilgiye tercih edilir.

Bir ölçülebilir hedef istiyorsanız: QA'yı bir release candidate'e pinleyin ve o candidate sadece kasıtlı düzeltmelerle değişsin.

Sonraki adımlar: gelecek hafta denemek için bir değişiklik seçin

Ekip trunk tabanlı mı GitFlow mu diye takılıyorsa her şeyi bir anda yeniden tasarlamayın. En çok zaman kaybettiren tek problemi seçin ve bir sonraki sürüm için küçük bir deney yapın.

Eğer birleşme çatışmaları en büyük acıysa, hemen dal ömrünü kısaltın. İşinizi günlük (veya her diğer gün) olarak land etmeyi hedefleyin, gerekirse feature flag kullanın.

Eğer QA kararsızlığı en büyük acıysa, QA'nın test ettiği şeyi pinlemek ve basit bir promosyon adımı tanımlamakla başlayın.

Hafif bir pilot:

• Bir repo ve bir ekip seçin.
• Dal yaş sınırı koyun (ör. 2 günden eski dal olmayacak).
• QA'yı bir build'e pinleyin ve sadece açık terfi yoluyla değiştirin.
• Üç metriği takip edin: merge çözüm süresi, QA tekrar iş saati, hotfix prod'a ulaşma süresi.
• 2–4 hafta sonra gözden geçirin ve ayarlayın.

Eğer dahili araçlar veya müşteri portalları için sürüm baskısını azaltmak istiyorsanız, AppMaster (appmaster.io) gibi no‑code platformlar görsel tasarımdan üretime hazır backend, web ve mobil uygulamalar üretebilir. Yine de yukarıdaki alışkanlıklardan faydalanır: küçük değişiklikler, pinlenmiş QA candidate'leri ve net bir promosyon yolu.