Veritabanlarını Özel Kar Taneleri Gibi Ele Almayı Bırakın: Azure DevOps + SQL Projeleri Doğru Yapıldığında

Emiliano Montesdeoca — Wed, 15 Jul 2026 00:00:00 +0000

Birçok ekip DevOps yaptığını iddia ediyor, sonra veritabanı değişikliklerini birinin dizüstü bilgisayarından manuel olarak dağıtıyor. Bu çelişki, tam olarak bu Azure SQL rehberliğinin düzelttiği şey. SQL projeleri artı Azure DevOps boru hatları, veritabanı teslimatını gerçek üretim iş akışları için yeterince deterministik, denetlenebilir ve güvenli hale getiriyor.

Orijinal kaynak: https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/

Yaklaşımın en güçlü kısmı YAML söz dizimi değil, disiplin sırası: önce derle, sonra yayınla ve en az ayrıcalık ile şifresiz kimlikle dağıtım yolunu güvenli hale getir. dotnet ile bir .sqlproj derlemek, hedef platform uyumluluğunu erken doğrular ve ortamlar arasında yükseltilebilecek bir DACPAC yapısı üretir.

Görüşüm basit: şemanız CI’de derlenmiyorsa, veritabanı kalite süreciniz büyük ölçüde umuttan ibarettir. SSMS veya VS Code’da yerel başarı bir yayın garantisi değildir.

Dağıtım tasarımı da tazeleyici derecede pragmatik. Entra kimliklerine bağlı hizmet bağlantıları kullanın, şema ve veri karşılaştırması için kapsamlı veritabanı rolleri verin ve çalıştırıcı IP’leri için garantili temizlikle geçici güvenlik duvarı açılışını otomatikleştirin. Bu, ekiplerin bir ihlal incelemesi her şeyi yeniden gözden geçirmeye zorlayana kadar atladığı türden operasyonel hijyen.

Hemen uygulanacak pratik öneriler:

Derleme ve dağıtım boru hatlarını ayırın. Derleme, dal değişikliklerinde çalışmalı ve hızlıca başarısız olmalı. Dağıtım ortam bazlı ve politika kapılı olmalı. Hedef bağlantı dizelerini ve altyapı meta verilerini güvenli boru hattı değişkenlerinde saklayın ve rol atamaları için yönetişim incelemelerini düzenli olarak döndürün. Ayrıca, sürpriz davranış değişikliklerinden kaçınmak için CI’de SqlPackage sürümlerini açık ve sabit tutun.

Erken aşırı yetki vermeyin. Her boru hattı asıl kullanıcısına “sadece çalışsın diye” db_owner vermek yerine, db_ddladmin, db_datareader ve db_datawriter ile başlamak daha iyi bir temeldir. Yalnızca somut bir dağıtım gereksinimi bunun gerekli olduğunu kanıtladığında yükseltin.

Bir diğer güçlü çıkarım taşınabilirlik. SQL projeleri .NET SDK araç zinciri üzerinde çalıştığından, bu desen yalnızca Azure DevOps’a özgü değil. Aynı temel ilkeler GitHub Actions veya diğer orkestratörlere de aktarılıyor, bu da bu rehberliği platforma kilitli değil stratejik yapıyor.

Kuruluşunuz hâlâ şema teslimatını uygulama CI/CD’sinin dışında özel bir süreç olarak ele alıyorsa, bu sizin göç planınız. Kahramanca platform mühendisliğine ihtiyacınız yok. Tutarlılığa, kimlik öncelikli güvenliğe ve veritabanı değişikliklerini rastgele ayrıcalık yollarıyla göndermeyi bırakma isteğine ihtiyacınız var.

Bunu yapan ekipler daha az geri alma olayıyla daha hızlı gönderim yapacak. Ertelemeyi seçen ekipler ise manuel veri düzlemi dağıtımlarının gizli vergisini ödemeye devam edecek.

CI/CD | The .NET Blog

Veritabanlarını Özel Kar Taneleri Gibi Ele Almayı Bırakın: Azure DevOps + SQL Projeleri Doğru Yapıldığında