BlockOnPossibleDataLoss=True: Neden Dostunuz?
Şema değişikliklerini yayınlarken karşınıza çıkan BlockOnPossibleDataLoss ayarı, geliştiricilerin çoğu zaman “yolumdan çekil” dediği, üretim ortamına yaklaştıkça iş biriminin en güçlü savunucusuna dönüşen bir koruma katmanıdır. Bu yazıda ayarın Database Projects ve SQL Server Management Studio (SSMS) tarafındaki davranışını, hangi ortamda açık ya da kapalı tutmanın daha mantıklı olduğunu ve publish profile yaklaşımıyla nasıl esnek bir denge kurabileceğinizi ele alıyoruz.
BlockOnPossibleDataLoss nedir?
Bu ayar, hedef veritabanının mevcut şeması ile yayınlamak istediğiniz şema arasındaki farkı değerlendirir ve uygulamanın veri kaybına yol açıp açmayacağını hesaplar. Cevap “evet” ise dağıtım durdurulur. Hem Database Projects hem de SSMS tarafında varsayılan değeri True‘dur.
En bariz örnek, bir tablonun veya kolonun silinmesidir; bu tür bir değişiklik doğrudan veri kaybı demektir. Daha az fark edilen bir örnek de bir kolonun veri tipini daralttığınız durumlardır: INT‘ten TINYINT‘e geçtiğinizde sıfırın altındaki ya da 255’in üzerindeki mevcut değerleri kaybetme riski doğar. BlockOnPossibleDataLoss=True olduğunda motor bu değerlendirmeleri yapar, şema yayınlanırken verinin kazara silinmesini engeller.
SSMS’te nerede devreye girer?
Database Projects tarafında karşılaştırma, kaynağınızdaki DACPAC ile hedef veritabanından türetilen meta veri arasında yapılır. SSMS içindeki Table Designer ve Database Diagrams gibi görsel araçlarda ise benzer şema değişiklikleri “Kaydet” ya da Ctrl+S anında bloklanır. Böylece son SQL yedeğinizi telaşla aramak zorunda kalmazsınız.
Geliştirici döngüsünde yaşanan gerilim
“Inner loop” dediğimiz yerel geliştirme döngüsü hızlıdır; birkaç dakikada bir derleyip yayınlayarak fikirleri sınarsınız. Bu tempoda BlockOnPossibleDataLoss can sıkıcı bir engel gibi hissedilebilir. Sonuçta tabloyu düşürmek, kolonu silmek veya tipi daraltmak iterasyonun doğasında var ve yerel veritabanınızda üretim verisi yok. Bu yüzden geliştirme ortamındaki koruma katmanları çoğu zaman yolu tıkayan ayrıntılara dönüşür.
Publish profile ile ortama göre koruma
Database Projects, tıpkı.NET’in C# dosyalarını DLL’e derlemesi gibi SQL dosyalarını DACPAC’e derler. Bu paket, çapraz platform komut satırı aracı olan SqlPackage ile gerçek bir veritabanına yayınlanır. Olası veri kaybı değerlendirmesi ve BlockOnPossibleDataLoss ayarının uygulanması da bu aşamada gerçekleşir.
Geliştiricilerin çoğunun atladığı nokta Publish Profile. Yayın sürecinin isteğe bağlı bu bileşeni, veritabanı ve dağıtım ayarlarını tanımlayıp yeniden kullanılabilir bir profil olarak saklamanızı sağlar. Daha da önemlisi, farklı ortamlar için farklı publish profile dosyaları oluşturabilirsiniz:
- Geliştirme profilinde
BlockOnPossibleDataLoss‘u devre dışı bırakarak hız ve iterasyonu önceleyebilirsiniz. - UAT ve üretim profillerinde ise aynı ayarı açık tutarak veriyi koruma önceliğini garanti altına alabilirsiniz.
Aynı Database Project, aynı DACPAC; ama dağıtım yaptığınız ortama göre değişen koruma seviyeleri. Geliştirici hızı ile üretim verisinin güvenliği arasında seçim yapmak zorunda değilsiniz.
SSMS tarafındaki önemli fark
SSMS’te BlockOnPossibleDataLoss, “Prevent saving changes that require table re-creation” adıyla karşınıza çıkar ve varsayılan olarak açıktır. Database Projects’ten farkı şu: Bu ayar sunucu, veritabanı veya ortama göre değil, global düzeyde tanımlıdır.
Yani ayarı yerel geliştirme deneyiminizi hızlandırmak için kapattığınızda, bağlantınızı UAT ya da üretim ortamına çevirdiğinizde de aynı korumasız halde kalırsınız. Ayar sizinle birlikte ortam değiştirmez; sonuçları ise değişir.
Ne söylediğinizin farkında olun
Bu korumayı yerel döngüde devre dışı bıraktığınızda SSMS’e “geliştirme verimi umurumda değil” demiyorsunuz; “beni olası veri kaybından koruma” diyorsunuz. Aradaki fark küçük gibi görünse de sonuçları büyük. Bu yüzden SSMS ayarını kapattıysanız, bağlantı değiştirdiğinizde bu tercihi hatırlamak size düşer.
Üretime yaklaştıkça daha bilinçli olun
Buradan çıkan mesaj “her koşulda BlockOnPossibleDataLoss=True kullanın” değil. Yerel geliştirme döngüsünde kapatmak son derece anlamlı olabilir. Asıl mesele, üretime yaklaştıkça şema değişikliklerinin nasıl dağıtıldığı konusunda daha kasıtlı davranmak.
SSMS güçlü bir araç; ama UAT ve üretime doğrudan DDL veya şema değişikliği uygulamak istisna olmalı, dağıtım stratejinizin merkezinde yer almamalıdır. Database Projects ve SqlPackage, bu iş için tasarlanmış mekanizmalar sunar:
- Declarative (bildirimsel) şema yönetimi
- Tekrarlanabilir dağıtımlar
- Ortama özel publish profile dosyaları
BlockOnPossibleDataLossgibi güvenlik önlemleri
Yerelde hızlı hareket edin, UAT’ta ölçülü ilerleyin, üretimde sorgulayıcı olun. BlockOnPossibleDataLoss=True her zaman en iyi arkadaşınız gibi hissettirmese de veri gerçekten önem kazandığı anda tam olarak öyle olur. İş biriminin veritabanı dağıtımlarında sahip olabileceği en güçlü savunuculardan biridir.
Kaynaklar ve İleri Okuma
- Your best friend: BlockOnPossibleDataLoss=True — Jerry Nixon (Azure SQL Dev Corner)
- Fundamentals of Azure DevOps with SQL Projects
- SQL Server Management Studio (SSMS) Belgeleri
- Azure SQL Dev Corner
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder