Skip to main content

Command Palette

Search for a command to run...

Veritabanı Değişikliklerinde Test Ortamının Önemi ve Sık Yapılan Hatalar

Published
2 min read
S

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

More from this blog

S

SQL Change Guard

81 posts