RELEASE STRATEJİLERİ

"Release yaptık" cümlesi çoğu ekipte "kodu prod'a deploy ettik" anlamına gelir. Oysa release ile deploy aynı şey değildir — pek çok mühendis bunu yanlış biliyor. Deploy bir binary'nin sunucuya taşınmasıdır; release ise o değişikliğin son kullanıcıya ne zaman, kime ve nasıl açılacağıdır. Bu ikisini ayırmadığınız sürece her küçük değişiklik gece yarısı bakım penceresi, geri alınamayan hata ve panikli rollback denemesine dönüşür. Release stratejileri tam burada devreye girer: kodun çıkışı ile özelliğin açılışını birbirinden ayırmanın disiplinidir.

Release ve Deploy Neden Aynı Şey Değildir?

Deploy operasyonel bir olaydır: artifact üretilir, ortama yerleşir, süreç ayağa kalkar. Release ise ürün kararıdır: hangi kullanıcı, hangi yüzdeyle, hangi bölgede yeni davranışı görsün? Modern CI/CD pratiğinde deploy günde onlarca kez yapılabilirken release bambaşka bir kadansta — bazen saatler, bazen haftalar sonra — gerçekleşir. Bu ayrım olmadan "her commit prod'a gitsin" söylemi felaket reçetesidir.

Aynı kod tabanında dört bağımsız katman çalışır: Konuya ilişkin kapsamlı referansı ek bir başvuru kaynağı olarak değerlendirilebilir.

• Deploy katmanı: Kodun ortama taşınması, sağlık kontrolleri, blue-green veya rolling güncelleme.
• Release katmanı: Özelliğin kullanıcıya açılma kararı — feature flag, segmentasyon, yüzdeli açılış.
• Rollback katmanı: Hatalı davranışın geri alınması — kod geri çekme değil, çoğu zaman flag kapatma.
• İletişim katmanı: Kullanıcıya, destek ekibine, paydaşa neyin değiştiğinin haberi.

Feature Flag: Release'i Kodun Hayatından Ayırmak

Feature flag, kodu prod'a göndermenize ama özelliği kapalı tutmanıza izin verir. Bir if-else kadar basit görünür, ancak doğru kurulduğunda release yönetiminin omurgasına dönüşür. Bayraklar farklı amaçlarla yaşar: kısa ömürlü "release flag" yeni kodun açılışı içindir, "experiment flag" A/B testleri için, "ops flag" ise üretim sırasında hızlı kapama anahtarı olarak durur.

Bayrak çoğaldıkça teknik borca dönüşme riski vardır. Bu yüzden her flag'in sahibi, son kullanma tarihi ve temizlik planı olmalıdır. CI/CD süreçlerinizi sıfırdan kurguluyorsanız CI/CD ve DevOps eğitimi içeriklerinden yararlanabilirsiniz.

Dark Launch: Kullanıcı Görmeden Üretimde Test

Dark launch, yeni kodu prod trafiğinde çalıştırırken sonucunu kullanıcıya göstermeme tekniğidir. Yeni arama algoritmasını eskisinin yanında sessizce çalıştırır, sadece eskinin cevabını döner; arka planda yeninin latency'sini, hata oranını ve sonuç farkını ölçersiniz. Böylece "yük altında ne olur" sorusunu kullanıcıya hiç dokunmadan cevaplarsınız.

Dark launch tipik olarak şu durumlarda hayat kurtarır:

1. Veritabanı sorgu motorunun yeniden yazıldığı büyük refactor'larda.
2. Üçüncü parti bir servisten kendi servisinize geçişte (strangler pattern).
3. Performans karakteristiği belirsiz yeni cache veya indexleme katmanlarında.
4. Yeni bir öneri/skorlama modelinin gerçek trafikle doğrulanmasında.

Canary ve Yüzdeli Açılış

Canary release, yeni sürümü önce küçük bir kullanıcı diliminin görmesidir — %1, sonra %5, sonra %25. Bu sırada hata oranı, p95 latency, business metrikler izlenir. Beklenenden sapma varsa açılış durur veya geri alınır. Canary'nin gücü teknikten çok disiplindendir: "metrik X şu eşiği aşarsa otomatik durdur" kuralı önceden yazılmadıysa, canary sadece yavaş bir full release'e dönüşür.

Canary ile blue-green sık karıştırılır. Blue-green iki ortam arasında ani trafik anahtarıdır; canary kademeli yüzde artışıdır. Blue-green hızlı rollback için iyidir, canary risk azaltma için. İkisi birlikte de kullanılabilir.

Rollback: Geri Alma Değil, Hızlı Kapama

Klasik rollback "önceki sürüme dön" demektir; ama bu çoğu zaman pahalı, bazen imkânsızdır — özellikle veritabanı şeması ileri sarmışsa. Olgun bir release stratejisinde rollback genellikle kodu geri çekmek değil, ilgili feature flag'i kapatmaktır. Saniyeler içinde gerçekleşir, deploy gerektirmez ve geri alınmış kod hâlâ üretimde olduğu için yeniden açmak da bir tık uzaklıktadır.

Etkili bir rollback planı için şunlar netleşmiş olmalı:

• Hangi metrik eşiği aşıldığında geri alma tetiklenir?
• Geri alma kararını kim, hangi onaylarla verebilir?
• Veritabanı migration'ları geri alınabilir mi, yoksa forward-fix mi gerekir?
• Geri alma sonrası kullanıcıya ve destek ekibine ne iletilir?

İletişim: Unutulan Dördüncü Katman

Teknik açıdan kusursuz bir release, kimsenin haberi olmadığında yine de başarısız sayılabilir. Yeni bir özellik açıldığında destek ekibi soruları bilmiyorsa, satış ekibi yeni yeteneği konuşamıyorsa, kullanıcılar arayüzdeki değişikliğe hazırlıksız yakalanıyorsa release "deploy başarılı" göstergesine rağmen değer üretmez. Release notları, in-app duyurular, changelog ve internal sync'ler bu katmanın araçlarıdır.

Hangi Stratejiyi Ne Zaman Seçmeli?

Tek bir doğru strateji yoktur; risk profiline göre kombinlenir. Düşük riskli iç araç değişiklikleri doğrudan rolling deploy ile gidebilir. Kullanıcıya dokunan UI değişikliği feature flag arkasında yüzdeli açılırken, performansı belirsiz altyapı değişikliği önce dark launch ile doğrulanır. Ödeme veya kimlik doğrulama gibi kritik yollarda canary + otomatik rollback + iletişim planı bir arada çalışır. Strateji seçimi "en yeni teknik hangisi" sorusu değil, "yanlış giderse kim, ne kadar sürede etkilenir" sorusunun cevabıdır.

Release stratejilerini öğrenmek tek tek tekniklerin adını ezberlemek değildir. Asıl kazanım, deploy ile release'i ayrı düşünebilmek; her değişiklik için "bu kod prod'a ne zaman gider", "kullanıcı ne zaman görür", "ters giderse ne yaparız" ve "kime ne söyleriz" sorularını ayrı ayrı cevaplayabilmektir. DevOps süreçlerinizi olgunlaştırmak için CI/CD pipeline ve sürekli teslimat eğitim içeriklerini inceleyebilirsiniz. Disiplinli kurulmuş bir release pratiği, gece yarısı acil çağrılarını saat üçten saat üçe almayan, sakin bir mühendislik kültürünün temelidir.