Veritabanı Değişikliklerinde Test Ortamının Önemi ve Sık Yapılan Hatalar
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
"Test ettik, çalıştı" cümlesi production krizlerinin en yaygın öncülü.
Test ortamı var ama doğru kullanılmıyor. Ya production'la farkı çok fazla ya da test süreci eksik ya da test sonuçları dikkate alınmıyor.
Test Ortamının Production'dan Farkı Neden Sorun Yaratır?
Test ortamı ne kadar production'a benzerse test sonuçları o kadar güvenilir. Ama çoğu ortamda ciddi farklar var.
Veri hacmi farkı
Test ortamında 10.000 satır, production'da 50 milyon satır. Test'te 1 saniyede çalışan sorgu production'da 5 dakika sürebilir. Performans sorunları test'te görünmez.
Konfigürasyon farkı
Test sunucusu daha az RAM, daha az CPU. Yük altındaki davranış farklı.
Veri kalitesi farkı
Test ortamındaki veri production kadar çeşitli ve karmaşık değil. Edge case'ler test'te yoktur, production'da çıkar.
Bağımlı servis farkı
Test ortamında bazı dış servisler mock'lanmış ya da hiç yok. Entegrasyon sorunları test'te yakalanmaz.
En Sık Yapılan Test Hataları
"Hata vermedi" yeterli sayılıyor
Script hata vermeden çalıştı ama doğru sonuç üretiyor mu? Doğrulama yapılmadıysa bilinmiyor.
Rollback test edilmiyor
Deployment test edildi ama rollback test edilmedi. Geri almak gerektiğinde rollback script'i çalışmıyor.
Test sonuçları belgelenmiyor
Kim ne test etti, sonuç ne oldu? Kayıt yok. Bir sorun çıktığında test yapıldı mı yapılmadı mı belli değil.
Regresyon testi atlanıyor
Yeni değişiklik test edildi ama mevcut işlevler bozuldu mu kontrol edilmedi. Regresyon testi zaman alıyor diye es geçiliyor.
BEGIN-ROLLBACK ile Production Önizleme
Test ortamı yoksa ya da production ile çok farklıysa BEGIN-ROLLBACK tekniği en güvenli alternatif:
sql
BEGIN TRANSACTION
-- Değişiklik scriptini çalıştır
UPDATE Siparisler
SET Durum = 'Tamamlandi'
WHERE OlusturmaTarihi < '2024-01-01'
AND Durum = 'Beklemede';
-- Etkilenen satırları kontrol et
SELECT @@ROWCOUNT AS GuncellenenSatir;
-- Örnek sonuçları gözden geçir
SELECT TOP 10 * FROM Siparisler
WHERE OlusturmaTarihi < '2024-01-01'
AND Durum = 'Tamamlandi';
-- Sonuçlar beklenen gibiyse COMMIT, değilse ROLLBACK
ROLLBACK TRANSACTION
-- COMMIT TRANSACTION
Bu yöntem production verisini kullanarak gerçek sonucu gösterir ama onay vermeden değişikliği geri alır.
Test Sonuçlarını Kayıt Altına Almak
Her test için minimum şu bilgiler kayıt altında olmalı: kim test etti, hangi ortamda, hangi senaryolar test edildi, sonuçlar beklenen değerlerde miydi, sorun varsa ne yapıldı.
Bu kayıt hem deployment onayı için kanıt hem de sonraki sorunlarda referans.
Sonuç
Test ortamı ne kadar production'a benzerse o kadar değerli. Ve test süreci ne kadar sistematikse o kadar güvenilir. İkisini birlikte ihmal etmek production krizlerinin en büyük kaynaklarından biri.
Detaylı bilgi için: sqlchangeguard.com
