Prisma ile Veritabanı Migration Yönetimi: Doğru ve Yanlışlar

Prisma Migrate, şema değişikliklerini takip etmeyi kolaylaştırıyor, ancak ekip içinde ya da production ortamında dikkatli kullanılmadığında sorunlara yol açabiliyor.

migrate dev ile migrate deploy Farkı

prisma migrate dev, geliştirme ortamında şema değişikliklerini algılayıp yeni migration dosyaları oluşturur ve veritabanını sıfırlayabilir. prisma migrate deploy ise yalnızca var olan migration'ları production'a uygular, şema karşılaştırması ya da sıfırlama yapmaz. Production'da asla migrate dev çalıştırılmamalı.

Geriye Dönük Uyumlu Migration'lar Yazmak

Bir sütunu doğrudan silmek veya NOT NULL yapmak, o an çalışan uygulama kodu hâlâ eski şemayı beklerken hataya yol açabilir. Güvenli bir yaklaşım:

1. Yeni sütunu nullable olarak ekle, kodu güncelle
2. Verileri geriye dönük doldur (backfill)
3. Ayrı bir migration'da NOT NULL kısıtlamasını ekle

Bu üç adımı tek migration'da yapmak, deploy sırasında kesintiye yol açabiliyor.

Migration Çakışmalarını Yönetmek

Birden fazla geliştirici aynı anda farklı migration'lar oluşturduğunda, migration geçmişinde çakışma oluşabilir. Feature branch'leri sık sık ana branch ile senkronize tutmak ve migration'ları küçük tutmak, bu çakışmaları azaltıyor.

Migration'ları Geri Almayı Planlamak

Prisma migration'lar varsayılan olarak "ileri" yönde tasarlanır. Bir migration'ın geri alınması gerektiğinde, elle yazılmış bir "down" migration'a ihtiyaç duyulabilir. Kritik değişikliklerde bu senaryoyu önceden düşünmek gerekiyor.

Sonuç

Migration yönetimi, yalnızca şema değişikliklerini kaydetmekten ibaret değil; canlı sistemi kesintiye uğratmadan evrimleştirme disiplinidir. Küçük, geri alınabilir adımlar, büyük ve riskli değişikliklerden her zaman daha güvenlidir.