Veritabanı Deployment Sonrası Doğrulama: Çoğu Ekibin Atladığı Adım
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
Deployment tamamlandı. Script çalıştı, hata vermedi. Herkes bir sonraki işe geçti.
Ama doğrulama yapıldı mı?
Hata Vermemek Yeterli Değil
Bir deployment başarılı sayılmak için iki koşulu sağlamalı: teknik olarak hatasız çalışmak ve iş mantığı açısından doğru sonuç üretmek.
Script hata vermeden çalışabilir ama yanlış veriyi güncelleyebilir, yanlış sonuç döndürebilir ya da beklenmedik bir yan etki yaratabilir.
Bunu anlamanın tek yolu doğrulama.
Doğrulama Neleri Kapsamalı?
Veri bütünlüğü kontrolü
Deployment sonrası kritik tablolardaki kayıt sayıları beklenen değerlerde mi? Yabancı anahtar kısıtlamaları sağlanıyor mu? Null olmaması gereken alanlar boş değil mi?
sql
-- Deployment sonrası kontrol sorgusu örneği
SELECT
'Musteriler' AS Tablo,
COUNT(*) AS KayitSayisi,
SUM(CASE WHEN Email IS NULL THEN 1 ELSE 0 END) AS NullEmail
FROM Musteriler
UNION ALL
SELECT
'Siparisler',
COUNT(*),
SUM(CASE WHEN MusteriID IS NULL THEN 1 ELSE 0 END)
FROM Siparisler
Performans kontrolü
Deployment sonrası kritik sorgular hâlâ makul sürede çalışıyor mu? Yeni bir index eklendi ama başka bir sorgu yavaşladı mı?
Uygulama kontrolü
Deployment'tan etkilenen uygulama ekranları test edildi mi? API endpoint'leri beklenen yanıtları döndürüyor mu?
Zamanlanmış iş kontrolü
Deployment'tan etkilenen SQL job'ları çalıştı mı, çalışacak mı?
Doğrulama Kaydı
Doğrulama sadece yapılmamalı, kayıt altına da alınmalı. Kim doğruladı, ne kontrol etti, sonuç ne oldu.
Bu kayıt üç işe yarıyor: bir sorun çıkarsa neyin kontrol edilip edilmediği belli oluyor, denetimde deployment sürecinin eksiksiz işlendiği kanıtlanıyor ve ekip içi disiplin oluşuyor.
Ne Zaman Rollback Kararı Verilmeli?
Doğrulama sırasında şu durumlardan biri varsa rollback gündemine gelmeli:
Kritik bir sorgu yavaşladıysa, veri tutarsızlığı tespit edildiyse, uygulama hata vermeye başladıysa ya da beklenen kayıt sayıları tutmuyorsa.
Rollback kararını vermek zordur. Ama önceden belirlenmiş kriterler bu kararı kolaylaştırır. "Şu durum varsa rollback yapıyoruz" şeklinde önceden yazılmış bir kural, kriz anındaki tartışmayı ortadan kaldırır.
Sonuç
Deployment doğrulama bir ekstra adım değil, deployment sürecinin ayrılmaz parçası. Atlandığında risk görünmez, yaşandığında ise geç kalınmış olur.
Detaylı bilgi için: sqlchangeguard.com