"Bu gece 02.00'de bakım çalışması yapılacaktır" duyuruları, birçok sistem için hâlâ olağan. Oysa doğru kurgulanmış bir dağıtım süreciyle yeni sürümler gün ortasında, kullanıcılar fark etmeden yayına alınabilir. Bunun için birkaç temel yöntem ve biraz disiplin yeterlidir.
Neden kesinti olur?
- Uygulama yeniden başlarken birkaç saniye istek karşılanamaz.
- Veritabanı değişiklikleri eski kodla uyumsuzdur.
- Yeni sürümde hata çıkar ve geri dönmek uzun sürer.
Dağıtım yöntemleri
Rolling (kademeli)
Uygulamanın birden çok kopyası varsa bunlar teker teker güncellenir. Bir kopya güncellenirken diğerleri trafiği karşılar. Yük dengeleyici ve sağlık kontrolleri gerektirir.
Blue-Green
İki aynı ortam vardır: mavi (şu anki canlı) ve yeşil (yeni sürüm). Yeni sürüm yeşile kurulur, test edilir ve trafik tek hamlede yeşile çevrilir. Sorun çıkarsa trafik saniyeler içinde maviye geri döner. Tek sunuculu sistemlerde bile iki ayrı port veya klasörle ve Nginx yönlendirmesiyle uygulanabilir.
Canary
Yeni sürüm önce kullanıcıların küçük bir kısmına (örneğin %5) açılır. Hata oranları ve performans izlenir; sorun yoksa oran kademeli olarak artırılır. Adını, madenlerde tehlikeyi önceden haber veren kanaryalardan alır.
| Yöntem | Altyapı ihtiyacı | Geri dönüş hızı | Risk |
|---|---|---|---|
| Rolling | Orta | Orta | Orta |
| Blue-Green | Çift ortam | Çok hızlı | Düşük |
| Canary | İleri yönlendirme ve izleme | Hızlı | En düşük |
Veritabanı değişiklikleri: Genişlet ve daralt
Kod ile veritabanı aynı anda değişemez. Bu yüzden şema değişiklikleri iki aşamada yapılır:
- Genişlet: Yeni sütun veya tablo eklenir; eski kod da yeni kod da çalışabilir.
- Yeni sürüm yayına alınır, veriler taşınır.
- Daralt: Eski sürüm tamamen kalktıktan sonra artık kullanılmayan sütunlar kaldırılır.
Bir sütunu tek seferde yeniden adlandırmak veya silmek, dağıtım sırasında çalışan eski kopyaları bozar.
Özellik bayrakları (feature flags)
Kod yayına alınır ama özellik kapalı tutulur; bir ayarla açılır. Böylece dağıtım ile yayına sunma birbirinden ayrılır. Yeni bir ödeme ekranını önce yalnızca çalışanlara açmak gibi senaryolarda çok kullanışlıdır.
Geri alma planı
Her dağıtımın "ya ters giderse?" cevabı önceden hazır olmalıdır:
- Bir önceki sürümün paketi hazırda bekliyor mu?
- Veritabanı değişikliği geri alınabilir mi?
- Geri alma kararını kim, hangi ölçütle verecek?
Bu adımlar, otomatik CI/CD hattına dahil edildiğinde güvenilir hale gelir. Dağıtım sonrasında hata oranlarını izlemek için gözlemlenebilirlik şarttır.
Sık sorulan sorular
Masaüstü uygulamalarda bu yöntemler geçerli mi?
Kısmen. Masaüstünde kademeli güncelleme ile önce küçük bir kullanıcı grubuna yeni sürüm göndermek, canary mantığının bir uygulamasıdır.
Küçük bir proje için de gerekli mi?
Tam otomasyon gerekmeyebilir; ama genişlet-daralt yaklaşımı ve hazır bir geri alma planı her projede uygulanmalıdır.
Sonuç
Sıfır kesintili dağıtım, cesur değil disiplinli olmakla ilgilidir. Küçük sürümler, uyumlu veritabanı değişiklikleri ve hazır bir geri dönüş yolu; yeni özellikleri gün içinde güvenle yayına almayı mümkün kılar.
