Azure DevOps Üzerinden Local Sql Server üzerine DbOps İşlemleri
Merhabalar. Son aylarda DevOps kavrami gözüme ninja kaplumbağalar gibi gelmeye başladı :) öğrenmekten ve kullanmaktan oldukça zevk aldığım ve işlerimi büyük ölçüde kolaylaştırdığım bu alanda yine öğrenip uyguladığım bir teknikten bahsetmeye çalışacağım. Konu: DbOps kavramı.
DbOps Nedir?
Kendi anladığım şekilde; veritabanı dağıtım işlemlerinde oluşan darboğazları minimize etmek ve dağıtım aşamalarını CI/CD süreçlerine dahil ederek sürecin otomotize edilmesinin ve sürdürülebilirliğinin sağlanması için uygulanan bir teknik olarak yorumluyorum.
2019 State of Database Deployments in Application Delivery report linkinde yer alan rapora göre ankete katılanların %92 si, veritabanı dağıtım işleminde darboğaz oluştuğunu ve dağıtım işlemini hızlandırmakta zorluk çektiğini belirtmiş.
Neden İhtiyaç Duydum?
Aslında yukarıda paylaştığım bilgilendirmedeki zorluğu çalıştığım şirkette biz de yaşıyoruz. Sql scriptlerini daha önceden direk Sql Managament Studio üzerinde yazıyorduk. Sql tarafında herhangi bir versiyon kontrol aracı kullanmadığımız için neyi ne zaman nasıl değiştirdik sorusunun yanıtını bilemiyorduk. Deploy işlemini dev, test ve prod db ortamları için farklı zamanlarda ayrı ayrı backup/restore yaparak tamamlamak zorunda kalıyorduk.
Bu aşamaları kolaylaştırmanın yollarını düşündük. Aklımıza Visual Studio daki Sql Server Database Project geldi. Sql scriptlerini, backend uygulamasının bulunduğu sln içinde açtığımız sqlproj projesine aktardık ve artık tüm scriptleri(tablo,sp,view vb) burada yazarak, branch içerisinde diğer backend kodları ile birlikte pushlamaya başladık. Böylece sql scriptlerinin versiyonunu ve izlenebilirliğini sağlamış olduk. Yani bir ortama(dev,test veya prod) yeni bir sürüm çıkacağımız zaman çıkılacak branchdeki kod alınıp, Visual Studio kullanarak sql projesi ilgili serverdaki ilgili db üzerine tekrar publish ederek çalışmalara devam ettik.
Hala bir şeyler eksik gibiydi. Evet sql scriptlerini sqlproj projesi üzerinde yazıyorduk, commitliyorduk vs her şey çok güzel fakat publish zamanı geldiğinde, önceki durumun yaşattığı zorluk kadar olmasa da yine de biraz uğraştırıyordu. PR geçtikten sonra ilgili ortamın branch ini pull edip, sqlproj projesini ilgili ortama ve db ye publish ediyorduk. Bu işlem manuel olarak biri tarafından ve ilgili ci pipeline ve release pipeline lar çalıştıktan sonra takip ederek yapılmak zorundaydı. Bu durumda manuelliğin oluşturduğu yanlış branch e geçerek yanlış sql scriptlerinin publish edilmesi veya unutularak edilmemesi gibi sorunlar ortaya çıkıyordu. Bu da uygulamaların hatalı çalışmasına ve izlenebilirliğinin kaybına sebep oluyordu.
Süreçleri Nasıl İyileştirdim?
Kaizen felsefesi ile yola devam ediyorum :) Uzun zamandır düşündüğüm ama zaman bulamadığımdan dolayı deneyemediğim bir yöntemi denedim ve sonuç başarılı oldu. Veritabanını CI/CD sürecine dahil ettim. Yani scriptlerin derlenip bir dacpac dosyası oluşturulmasını ve oluşturulan bu dosyayı ilgili db lokasyonuna deploy edilmesini sağladım. Böylece deploy zamanı geldiğinde yukarıdaki Neden İhtiyaç Duydum bölümünde anlattığım tüm sorunları halletmiş oldum.
Yani süreç akışları birinci resimden ikinci resime dönüşmüş oldu.
İşlem Adımları
- Deployment Pool Oluşturma
Bir önceki makalemde bu konudan bahsetmiştim. Bu makalenin çok uzamaması için o aşamaları geçiyorum. Detaylı bilgiye oradan ulaşabilirsiniz.
2. Yeni bir Build Pipeline Oluşturma
Yazdığım yaml dan kısaca bahsedersek;
Steps ten önceki bölümler:
Branch trigger ı, yaml ın çalışacağı image, değişkenler ve bir pipeline dan sonra çalışması için koyduğum bir trigger.
Steps ten sonraki bölümler:
DacPac dosyasının oluşması için Visual Studio Build taskı, oluşan dacpac dosyasını ilgili lokasyona kopyalama ve ilgili artifact in oluşturulması.
3. Build Pipeline ın Çalıştırılması
Aşağıdaki ekran görüntüsündeki gibi pipeline çalıştırılıp tamamlandıktan sonra loglarda gözüktüğü üzere dacpac dosyasının oluşturulup ilgili lokasyona kopyalandığını görebiliriz. Şu an deploy için kullanacağımız nesnemiz hazır.
4. Release Pipeline Oluşturulması ve Artifact Seçimi
5. Stage Konfigurasyonu
Daha önce oluşturulan Deployment Pool u kullanmak için bir tane Deployment Group Job ve dacpac dosyasının kullanılması için içerisine SQL Server database deploy tipinde bir task eklenir.
6. İlgili Task ın Konfigurasyonu
İster sa ister windows authentication ile işlem yapabilirsiniz. Burada önemli olan nokta; eğer windows auth. kullanılacaksa azure agent kurulumunda ayarlanan kullanıcının yetkisi olması gerekiyor. (default olarak nt authority system kullanıcısını öneriyor. Oradaki kullanıcıyı farklı yetkili bir kullanıcı yapmak gerekiyor.) Ben kendi makinemde sa ile, server da da özel bir kullanıcı ile denedim ve sorunsuz çalıştı.
7. SqlPackage(DacFramework) Kurulumu
Release pipeline ı task ı konfigure ettikten sonra kaydedip kapatıyoruz. Çalıştırmadan önce yapmamız gereken son bir işlem var: deploy yapılacak server a bu işlemin başarılı olması için(dacpac deploy) SqlPackage kurulumu yapmak gerekiyor. Kurulum dosyasını Microsoft un kendi sitesinden buradaki linki kullanarak indirip kurabilirsiniz. Kurmazsanız release pipeline tarafında hata alacaksınız.
Her Şey Hazır!
Şimdi yapmamız gereken tek şey Release Pipeline ı başlatmak ve arkamıza yaslanıp, yaşadığımız zorlukların gözümüzün önünden film şeridi gibi geçişini izlemek olacak :) Release pipeline sorunsuz tamamlandıktan sonra ilgili sunucuda sözkonusu db yi görebilirsiniz.
Bu akışı şimdilik dev ve test ortamları için çalışan build ve release pipeline larının hemen arkasından çalışacak şekilde aktif ettim. Bir süre denedikten sonra sorun olmaması durumunda prod ortamında da etkinleştirmeyi planlıyorum.
Umarım faydalı olur. Sorun yaşarsanız yorumlarda belirtebilir veya linkedin den de iletişime geçebilirsiniz. Bir sonraki yazıda görüşmek üzere, kodla kalın :)
