SQL Server Container ve Docker Ortamlarında Değişiklik Yönetimi
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
SQL Server artık sadece Windows sunucularında değil. Docker container'larında, Kubernetes cluster'larında çalışıyor. Bu yeni ortamlar değişiklik yönetimine yeni sorular getiriyor.
Container'da SQL Server Ne Anlama Geliyor?
Geleneksel SQL Server kurulumunda sunucu var, üzerinde SQL Server çalışıyor. Container'da ise SQL Server bir image içinde paketlenmiş, ihtiyaca göre ayağa kaldırılıyor ve sonlandırılıyor.
Bu mimari geliştirme hızını artırıyor. Ama aynı zamanda "veritabanı değişikliği" kavramını yeniden tanımlamayı gerektiriyor.
Container'da Değişiklik Yönetiminin Yeni Boyutları
Image değişikliği de bir değişiklik
Container'da çalışan SQL Server versiyonu değişti. Yeni bir image kullanılmaya başlandı. Bu bir veritabanı değişikliği mi? Evet.
Image değişiklikleri de değişiklik yönetim sürecine dahil edilmeli. Hangi image versiyonuna geçildi, neden, kim onayladı?
Ephemeral container riski
Container'lar geçici doğada çalışır. Container yeniden başladığında içindeki veriler kaybolabilir. Veritabanı verisinin kalıcı bir volume'a bağlı olduğundan emin olmak kritik.
Ama daha önemli olan: container yeniden başladığında veritabanı şeması doğru versiyonda mı ayağa kalkıyor? Migration script'leri doğru sırada çalışıyor mu?
Kimlik doğrulama farklılaşıyor
Container ortamında servis hesapları, secret yönetimi, Kubernetes secrets — kimlik doğrulama altyapısı gelenekselden farklı. Bu değişikliklerin de izlenmesi gerekiyor.
Infrastructure as Code ve Değişiklik Yönetimi
Container ortamlarında altyapı kod olarak tanımlanıyor. Dockerfile, Kubernetes manifest dosyaları, Helm chart'lar.
Bu dosyalardaki her değişiklik bir altyapı değişikliği. Git üzerinden takip ediliyor olması güzel ama yetmez. Bu değişikliklerin de onay sürecinden geçmesi ve veritabanı değişiklik süreciyle entegre olması gerekiyor.
Migration Script Yönetimi
Container ortamında veritabanı şeması değişiklikleri migration script'leriyle yönetilmeli.
Container ayağa kalktığında migration'lar otomatik çalışıyor. Peki bu migration'lar onaylı mı? Kim yazdı, kim test etti, kim onayladı?
Migration script'leri de tıpkı diğer veritabanı değişiklikleri gibi değişiklik yönetim sürecine tabi olmalı. Fark şu: deployment manuel değil otomatik. Ama onay süreci hâlâ manuel ve zorunlu.
Loglama ve İzleme
Container ortamında log yönetimi farklı. SQL Server error log'u container içinde kalır, container kapanınca gider.
Log'ların merkezi bir sisteme yönlendirilmesi zorunlu. Hem uygulama logları hem veritabanı değişiklik logları merkezi bir yerde toplanmalı ve aranabilir olmalı.
sql
-- Container'da SQL Server error log'unu kontrol et
EXEC xp_readerrorlog 0, 1, N'error';
Bu komut çalışıyor ama log'lar dışarıya aktarılmıyorsa container kapandığında kaybolur.
Sonuç
Container ve Docker SQL Server'ı daha esnek kılıyor. Ama esneklik, değişiklik yönetimini ortadan kaldırmıyor. Yeni ortamın getirdiği yeni değişiklik türlerini tanımak ve sürece dahil etmek gerekiyor.
Detaylı bilgi için: sqlchangeguard.com