GitOps & mavi-yeşil / sıfır kesinti dağıtım

Belirti

Amaç: Şema ve uygulama değişikliklerini kesintisiz dağıt; expand-contract (genişlet-daralt) migration, mavi-yeşil ortam, feature flag ve otomatik rollback ile sıfır kesintiye yaklaş.

1. GitOps: Git tek doğru kaynak olsun

Hem altyapı hem şema migration'ları hem uygulama sürümü Git'te tanımlı olsun; dağıtım, depoya yapılan merge ile tetiklensin (GitOps). Bir uzlaştırıcı (Argo CD/Flux veya CI/CD) istenen durumu gerçek ortama uygular. Böylece her değişiklik denetlenebilir, tekrarlanabilir ve gerektiğinde bir önceki commit'e geri alınabilir.

PostgreSQL

# repo/
#   migrations/  (Vxxx__*.sql)
#   k8s/         (Deployment, Service)
#   flags/       (feature flag config)

2. Şemayı geriye uyumlu değiştir (expand-contract)

Sıfır kesinti için şemayı tek adımda kırıcı biçimde değiştirme; iki aşamaya böl. EXPAND: yeni yapıyı (yeni kolon/tablo) ekle, eski ve yeni kod aynı anda çalışabilsin (kolon nullable, varsayılanlı, çift yazma). Uygulama yeni yapıya geçtikten SONRA CONTRACT: artık kullanılmayan eski kolonu/tabloyu ayrı bir migration'da kaldır. Böylece dağıtım sırasında eski ve yeni uygulama sürümü yan yana sorunsuz çalışır.

PostgreSQL

-- EXPAND (V5): geriye uyumlu ekleme
ALTER TABLE musteri ADD COLUMN eposta text;

-- kod her iki kolona da yazar/okur bir süre

-- CONTRACT (V9): eski kolonu kaldır
ALTER TABLE musteri DROP COLUMN mail_eski;

3. Riskli davranışı feature flag arkasına al

Yeni kod yolunu (yeni kolonu okuma gibi) bir feature flag ile koşullu çalıştır; şema hazır olunca flag'i aç, sorun olursa deploy'a dokunmadan kapat. Flag, kod dağıtımını (deploy) ile özelliğin devreye girmesini (release) ayırır. Böylece expand aşaması yayınlanır ama davranış değişikliği kontrollü açılır ve hızlı geri alınabilir.

PostgreSQL

-- uygulama katmanı (sözde kod)
-- if flag('yeni_eposta_alani'):
--     SELECT eposta FROM musteri ...
-- else:
--     SELECT mail_eski FROM musteri ...

4. Mavi-yeşil ortamı kur

İki eş ortam tut: 'mavi' (canlı) ve 'yeşil' (yeni sürüm). Yeni uygulama sürümünü yeşile dağıt ve gerçek trafik almadan doğrula; hazır olunca yönlendiriciyi/trafiği yeşile çevir. Kritik nokta: veritabanı genelde PAYLAŞILIR, bu yüzden şema her iki sürümle de uyumlu olmalı (expand-contract bunu sağlar). Geçiş anında bağlantı hedefi değişse de şema uyumu sayesinde kesinti olmaz.

PostgreSQL

# trafik yeşile (yeni sürüm) çevrilir
# DB paylaşımlı: şema hem mavi hem yeşil ile uyumlu olmalı

5. İzleme ile dağıtımı doğrula (canary/gözlem)

Trafiği tam çevirmeden önce hata oranı, gecikme, veritabanı hata/lock sayısı ve replikasyon gecikmesi gibi metrikleri izle; istersen trafiğin küçük bir yüzdesini (canary) yeşile verip gözlemle. Sağlık göstergeleri iyiyse trafiği kademeli artır, kötüyse ilerleme. İzleme, otomatik rollback kararının girdisidir.

PostgreSQL

-- canlı sağlık sorguları
SELECT count(*) FROM pg_stat_activity WHERE wait_event_type='Lock';
SELECT * FROM pg_stat_replication;

6. Otomatik rollback'i hazırla

Metrikler eşiği aşarsa dağıtım otomatik geri alınmalı: mavi-yeşilde trafiği hızla maviye (eski sürüm) döndür. Uygulama rollback'i anlıktır çünkü mavi hâlâ ayakta. Şema tarafında ise geri alma çoğu zaman GEREKMEZ: expand-contract sayesinde yeni şema eski kodla da uyumludur, dolayısıyla yalnızca uygulamayı geri almak yeter. Bu yüzden şema değişimini uygulama dağıtımından bağımsız ve daima geriye uyumlu tut.

PostgreSQL

# trafik anında maviye döner (uygulama rollback)
# şema geri alınmaz: expand-contract eski kodla uyumlu
# gerçekten gerekirse: düzeltici yeni migration yaz