VS Code ile SQL Şema Yönetimi Artık Akıcı: Yayın Penceresi ve Şablonlarla Tanışın
Veritabanı Geliştirme Sürecinde Gerçekten Ne Değişti?
Açık konuşacağım: SQL şemasına dokunmak hâlâ birçoğumuz için stres kaynağı. Lafı uzatmaya gerek yok, aynı döngü yıllardır devam ediyor — kodunu açarsın, VS Code’da takılırsın, sonra “Dur şu SSMS’e geçeyim”, belki Azure Portal’a zıplarsın ya da Fabric’in editöründe bulursun kendini. Bu sırada sürekli kopyala-yapıştır, komutları dışa aktar, elin titreyerek “Yanlış yere deploy mu edeceğim?” paniği… Konsantrasyon anında yerle yeksan oluyor.
2019’u hatırlıyorum; büyük bir e-ticaret devinin veri ambarındaydım. Şema değişikliği deyince aklıma ilk gelen şey masa başındaki üç farklı araç arasında mekik dokuyup bir publish işi tamamlamak öldü. Hele bir de Cuma akşamları kimseye tavsiye etmem! Migration yanlış gitti mi kimin üzerine kalacak diye herkes huzursuzdu.
Neyse ki Microsoft’un SQL Database Projects eklentisindeki son yeniliklerle bu hengame kökten değişmiş gibi görünüyor. Yayın penceresi (Publish Dialog). O meşhur hazır öğe (item template) şablonları sayesinde işler hem daha kontrollü hem de tempo bozulmadan ilerliyor. Kafayı karıştırmasın; sadece Azure SQL değil bildiğimiz klasik SQL Server veya Fabric ortamlarında da gayet güzel çalışıyorlar.
Geçmişten Gelen Zorluklar
- Araçlar Arası Geçiş: VS Code, SSMS, Azure Portal arasında sürekli geçiş sürecin ritmini bozar.
- Kopyala-Yapıştır Hataları: Farkına varmadan staging’e değil, production’a yanlış kod göndermek an meselesi.
- Geri Dönüş Zorluğu: Hatalı deployment sonrası geri almak için çoğu zaman elinde güvenilir script bile olmaz.
Günümüzde Neden Farklı?
Vallahi, Yayın penceresinin getirdiği önizleme, şablonların sağladığı standartlaşma ve version kontrolüne dahil yapı sayesinde artık koddan veriye kadar uçtan uca bir akış kurmak mümkün.
Şöyle ki, Bu noktada, kendi tecrübeme göre; büyük bir lojistik firmasında 2023 başında schema migration işinde doğrudan VS Code’dan çıkmadan birkaç dakika içinde tüm süreci bitirebildik. Önceki yıllarda işe aynı iş saatlerce sürerdi!
Yayın Penceresi (Publish Dialog): Ne Deploy Ediyorsun? Artık Sürpriz Yok!
Tüm Kontrol Sende mi? Evet Ama Bir Dakika…
Birkaç hafta önce Logosoft’taki bankacılık projesinde schema güncellemesi yapmam gerektiğinde dedim ki: “Şu yeni publish ekranını deneyeyim!” Sağ tıklıyorsun projeye, Publish diyorsun — hop interaktif pencere karşında: Bu konuyla ilgili Azure OpenAI ve GPT-4o: FedRAMP High ile ABD Devletinde Yepyeni Bir Yapay Zekâ Çağı yazımıza da göz atmanızı tavsiye ederim.
- Bağlantı Seçimi: Connection string’le cebelleşmek tarihe gömülüyor, sunucu adını ezberlemek desen kim uğraşır… Mevcut kaynaklar sıralanıyor ve dilediğini seçiyorsun.
- Script Önizleme: Bence can alıcı kısmı bu! Publish etmeden önce T-SQL’de neyin koşulacağı ayan beyan görünüyor. Production’a deploy atmadan önce masadaki bardak bile rahatlıyor çünkü “Tablo siler mıyım?” stresi bitiyor.
- Ayarlar: Tabiî obje drop mu edilecek yoksa ekleme mi olacak? Bunlar tek tuşla halloluyor – hiç detay kaçmıyor.
Pratik Yayın Senaryosu: Gerçekten Kolay mı?
Şahsen, Geçtiğimiz aylarda, müşterinin isteğiyle birden fazla view değişikliği gerektiren, kritik bir güncelleme işim olmuştu. Publish Dialog’u açıp ön izlemeyi çalıştırdığımda, eski alışkanlıkla “herhalde bir şey eksik çıkacak” diye endişelendim. Scriptin baştan sona doğru olduğunu görmek şaşırtıcı derecede rahatlattı.
Bir işte en ufak tereddütün varsa yayınlayacağın script’i mutlaka Publish ekranında didikle – hatta mümkünse yan masadaki arkadaşa göster; sonra “Ben görmedim” deme hakkın olmuyor!
Küçük Bir Eksiklik Var mı?
İtiraf edeyim, Dürüst olmak gerekirse, Evet her şey tozpembe değil açıkçası… Büyük ölçekli pipeline senaryolarında bazı ileri seviye ayarlara ulaşmak için hâlâ dolambaçlı yollar var ya da logging dediğin biraz elle tutulur olsun istiyorsun — henüz tam istediğim noktada değil yanı! Buna rağmen günlük işleri düzene sokma konusunda işe performansı beklentimin üstünde çıktı diyebilirim.
.sql dosyası almak ve arka cebine backup olarak koymak ilaç gibi geliyor! Kaybolursa geri dönmek çocuk oyuncağı.
İleri Düzey Yayınlarda Dikkat Edilecekler
- Transaction Kullanımı: Kompleks migrationlarda publish öncesi transaction kapsamı test edilmeli.
- Script Backup: Otomatik alınan script dosyası ekstra bir güvenlik katmanı sunuyor.
- Yayın Notları: Her yayından sonra küçük bir log tutmak, ileride neyin ne zaman değiştiğini takip etmeyi kolaylaştırır.
VS Code + SQL Database Projects güncellemeleriyle şema değişikliklerinde “araçlar arası mekik”, “yanlış yere deploy” ve “geri dönüş zorluğu” azalıyor. Yayın penceresi önizleme ve şablonlar sayesinde süreç daha kontrollü ve akıcı hâle geliyor.
| Özellik | VS Code ile (Yayın penceresi + şablonlar) | Eski akış (SSMS/Azure Portal/Fabric) |
|---|---|---|
| Araç geçişi | Tek ekosistem içinde ilerleme | Sık sık VS Code ↔ SSMS ↔ Portal geçişi |
| Deploy kontrolü | Publish öncesi T-SQL/etki önizlemesi | Önceden net görmeden kopyala-yapıştır riski |
| Standartlaşma | İtem template şablonlarıyla tutarlı yapı | Her ekip/kişi farklı yöntemle ilerleyebiliyor |
| Hatalardan sonra geri dönüş | Akış daha izlenebilir ve güvenli ilerler | Hatalı deploy sonrası geri alma için script eksikliği |
Not: Özellikle “tablo silme/drop” gibi kritik değişikliklerde önizleme stresi ciddi ölçüde azaltır.
Ekip Standartlarında Kod Başlangıcı İçin Öğelerin Şablonları
Kopyala-Yapıştır Devri Bitiyor Mu?
Doğrusu, Dürüst olayım burası bana bayağı iyi geldi. Yıllarca ekip içinde birbirimize “Abi geçen yıldan view var mıydı?”, “Şu tablonun örneği yok mu?” diye dolaşıp durduk. Şimdi item template ile tablo/fonksiyon/procedure eklerken birkaç tıkta kendi standart iskeletini elde ediyorsun; takımınızda isimlendirme şekliniz varsa ya da ekstra audit alanlarını önceden tanımladıysanız onlar bile hazır şekilde geliyor—eller serbest resmen! Bu konuyla ilgili .NET 10 ile Yapay Zekâya Sıfırdan Giriş: Generative AI for Beginners v2 Neler Getiriyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Fiziksel Sistem Tasarımında Yeni Dönem: Azure MSWB ile Geleceğe Bakış yazımıza bakabilirsiniz.
Şablon Kullanımının Avantajları
- Zamandan Tasarruf: Ekipte yeni başlayanların günlerce döngüye girmesine gerek kalmıyor.
- Standartlaşma: Kod kalitesi ve isimlendirme tutarlılığı sağlanıyor.
- Hataların Azalması: Kopyala-yapıştır kökenli syntax ve mantık hataları büyük oranda azalıyor.
Gerçek Dünya Örneği
Sözgelimi geçtiğimiz ay Anadolu Yakası’nda orta büyüklükte lojistik firmasının yeni başlayan juniorlarına tabloları böyle ekletmeye başladığımızda haftalarca yapılan adaptasyon hatalarını resmen ortadan kaldırdılar. Kısa sürede gerçek katkıya başladılar — ciddi anlamda zaman kazandık. Bakın, daha fazla bilgi için Copilot Coding Agent ile 10 Ay: Kodun Kalbinde Yapay Zekâ Gerçekten İşe Yarıyor mu? yazımıza bakabilirsiniz.
- Add Item > Template tıklıyorsun;
- Birkaç parametreyi girip onay veriyorsun;
- Dört dörtlük biçimli.sql dosyan önüne düşüyor.
Copilot ile Şablonların Kombinasyonu
Dikkat ettiğim başka mesele işe Copilot’un burada çok işe yaradığını görmek öldü; function template açınca prompt olarak mesela “audit loglu hesap tablosu oluştur” dediğimde ortaya makul çözümler çıkardı (arada field isimlerini çok İngilizceleştiriyor. Olsun). Neticede klasik copy-paste’den fersah fersah hızlısınız Copilot+template kombinasyonunda!
Neden Uğraşıyoruz? Geliştirici Akışı Bozulmasın Diye!
Koddan Veriye Tek Yerde Kalmak Lüks Değil Mecburiyet Öldü
Düşünün şimdi — uygulama geliştirmede kodunu yazıp commitlersin, PR açarsın CI/CD’den release’e itersin… Editörden burnunu çıkarmazsın.
Ama iş database tarafına gelince eski usül hâlâ devam:
- .sql dosyasını editörde yaz →
- dışarı at siteye upload et →
- sürüm kontrolü hak getire →
- (kim neyi değiştirdi belli değil!) →
Artık bütün şema dosyalarını Git üstünden izleyip,
Pull Request’lerle birlikte takım halinde gözden geçirip,
VS Code içinden yayına basabiliyoruz.
Net şekilde bütünleşik çalışma düzeni oluştu.
CI/CD Entegrasyonu ile Gelişmiş Akış
2022 sonunda bir kamu kurumunda yaptığımız projede CI/CD pipeline’a SQL şema yayınını eklemenin ekibe ne kadar hız kattığını bizzat yaşadık. Kodla veri değişiklikleri eş zamanlı ilerleyince hatalar dip yaptı, PR’lar üzerinde toplu inceleme yapmak işe başka bir güven katmanı sağladı.
Versiyon Kontrolünün Getirdiği Rahatlık
Her.sql dosyası git ile takip edildiği için, “Kim neyi silmiş?”, “Bu tabloya neden ek alan gelmiş?” gibi klasik tartışmalar da hafifledi (ben de ilk duyduğumda şaşırmıştım). Geçmişe dönüp yapılan migration’ları rahatça takip etmek mümkün öldü.
Peki Ya Zorluklar? Her Gülün Dikeni Var…
Yayın Sürecinde Karşılaşılan Sorunlar
Açık söyleyeyim; teknoloji her derde deva değil malumunuz… Büyük migration senaryolarında benim elim hâlâ titriyor doğrusu — canlıya downtime’sız deploy yapılacaksa risk almak istemezsin kolay kolay! Preview ekranından bakıyorsun evet ama environment bağımlılıkları veya karışık transaction operasyonlarında dikkat etmek şart.
Geçen sene sigorta sektöründeki test ortamında küçük gördüğümüz constraint değişiklikleri production’da sistemi resmen frenlediğini tecrübe ettik (hayatta unutamam!). O yüzden bence incremental review + manuel test ikilisi vazgeçilmez.
İleri Düzey Gereksinimler ve Alternatifler
Bazen işe complex use-case’lerde eski usül SSDT’ye yanaştığım öldü – demek ki mükemmel çözüm henüz icat edilmemiş.
Ama normal kullanıcı profilinde
süreklilik,
görsel publish süreçleri,
otomatik standardizasyon
– say say bitmez nimet!
Mentor Tavsiyesi: Güvenlik ve Geri Dönüş
Yayın süreçlerinde backup almadan, staging’de test etmeden ve minimum iki gözle kontrol etmeden production’a bir şey göndermemek en akıllıca yol. 2020’de bir yaz kampında, bir trainee tablonun constraint’ını yanlış kaldırdı; şansımıza staging’di ve anında rollback yaptık – ancak production olsa, tam bir felaket olurdu!
Püf Noktaları ve Pratik Tavsiyeler
- Editörden kafanı kaldırmamaya çalış! Aracı değiştirmenin yarattığı mental kaos azalınca hakikaten daha verimli hissediyorsun—kişisel tavsiye 😊
- Skript preview’una ikinci göz olmadan basma derim—gerçekten iki kişi bakarsa fark edilmeyen detayı yakalarsınız.
- Eğer hep benzer tip objeleri yaratıyorsan custom item template dizisi hazırla—ufak çaplı şirket içi şablon havuzu kurabilirsin.
- Ciddi boyutta schema update gerektiren işlerde doğrudan production’a gitme; staging’de pilot deployment’la testi ihmal etme 😉
- Daha fazla kod kalite önerisi istersen şu yazıya göz gezdir:
VS Code’da SQL Kod Analizi Artık Daha Kolay – Kural Ayarlarını Ellemeden Yapmayı Dene 🙂
Sıkça Sorulan Sorular
VS Code’da SQL Database Projects uzantısını yüklemek zor mu?
Hiç zor değil! Extension paneline “SQL Database Projects” yazınca tek tıkla ekleyebiliyorsun. Otomatik kurulumdan sonra açılır menüler ve Publish ekranı elinin altında oluyor. Microsoft’un kendi dökümanı da adım adım anlatıyor zaten.
Yayın penceresindeki script önizlemesi canlı bir veritabanında riskli olabilir mi?
Önizleme sadece simüle edilen T-SQL scriptini gösteriyor; yayına basmadan hiçbir şey değişmiyor. Yalnız, karmaşık migration’larda preview’u dikkatlice incelemek ve staging’de test etmek şart. Aksi hâlde production’da sürprizle karşılaşabilirsin (ben de ilk duyduğumda şaşırmıştım)
Şablonları ekibimiz için özelleştirebilir mıyız?
Evet, kendi template dizilerini ekleyebiliyorsun. .sql şablonlarını şirkete özel hâle getirip ekip havuzunda saklayabilir, istediğin kadar özelleştirme yapabilirsin. Çoğu şirket içi best practice’i şablona gömmek harika oluyor!
CI/CD pipeline ile otomatik publish nasıl çalışıyor?
Şahsen, Git’teki değişiklikleri tetikleyip Azure Pipelines ya da Github Actions gibi araçlarla otomatik publish workflow’u kurgulanabiliyor. Böylece kod-review’dan sonra doğrudan staging veya production’a script deployment mümkün.
Klasik SSDT ile arasındaki en büyük fark nedir?
Bak şimdi, VS Code eklentisi çok hafif ve hızlı; direkt kodun içine entegre çalışıyor. SSDT işe Visual Studio içindeki klasik devasa projeler için hâlâ tercih ediliyor (inanın bana). VS Code ile modern, küçük ekipler çok daha hızlı ilerleyebiliyor.
Kaynaklar ve İleri Okuma
SQL Database Projects uzantısı — Microsoft Docs (buna dikkat edin)
Publish a database project — Microsoft Docs
Doğrusu, SQL Database Projects Extension for Visual Studio Code — Azure Blog (ki bu çoğu kişinin gözünden kaçıyor)
Azure Data Studio GitHub Repository
Daha fazla içerik ve güncel pratikler için blogun ana sayfasını ziyaret edebilirsin.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder