CI/CD’de Bir Kör Nokta: Veri Tabanı

Veri tabanları birçok kurum için BT uygulamalarının merkezindedir. DevOps, GitOps veya diğer varyasyonlar ekseriyetle yazılım geliştirme ve sürüm kontrollerine odaklanmaktadır. Peki ya merkezimizdeki veri tabanları ne durumda?

Veri tabanları öncül yani verinin menbağını barındırmaktadır. Dolayısıyla Devops döngüsünde derlenen ve belli bir vazife atfedilen uygulama kodlarından farklı bir yerde ikamet ederler. Yani test veri tabanları test edilen kodlar gibi üretim ortamına derç edilemez. Çünkü bu gerçek kullanıcı veya uygulama verilerinin test verileri ile değiştirilmesi demektir ki sektör henüz böyle bir heyecan için yeterli ferasete sahip değil. Söz konusu veri tabanı olunca işler biraz tersten işliyor ve biz bu sefer kodda olan test -> üretim ortamı yönünü, üretim ortamı -> test şeklinde eviriyoruz. Yani canlı ortam verilerini korele edip en yakın gerçeklikte test ortamı verilerini elde ediyoruz. Bu durum DevOps otomasyonundan veri tabanın ilk kopuşu olarak ortaya çıkıyor. Tabi canlı ortam verilerine erişimin güvenlik riskleri ve regülasyonel uyum konuları da cabası. 

Devops’un gezegeninde test ortamından üretim ortamına doğru giden erdemli yolda kaynak kodların kontrolü ve gözden geçirilmesi otomatize edilmiştir. Bir kodun yaşam döngüsünde bu işlemler çok fazla efor ve vakit kaybı içermez. Ancak bu gezegende veri tabanları ciddi bir handikaptır. DBA’lar genellikle manuel olarak değişiklikleri gözden geçirir ve bu çok ciddi bir vakit kaybı demektir. Bazen süreci hızlandırmak bazen de eforu düşürmek adına DevOps takımları DBA’ların manuel gözden geçirme ve kontrol adımlarını atlamaktadır. Her geçen gün işlerin daha da otomatize edildiği ve hızlandırıldığı DevOps gezegeninde bu durum belki anlayışla karşılanabilir. Ancak doğrulanmamış bu değişiklikler veri tabanı için çok ciddi bir bütünlük ve süreklilik riski içermektedir. Bu durum da DevOps otomasyonlarından veri tabanının bir diğer kopuşudur.

Bir uygulamanın yaşam döngüsüne bakalım. Proje bir sürüm kontrol sisteminde tanımlanır ve ekiplere branch’ler dağıtılır. Geliştirmeler tamamlanır ve kaynak kontrol sistemine sürüm bilgisi ile yüklenir. Kaynak kodlar projeye eklenir, proje derlenir, sürüm yayımlanır ve testlere başlanır. Birim testleri, sürüm testleri ve kullanıcı kabul testleri derken uygulama RC (Release Cadidate) olarak neşrolur. Şimdi geçelim dağıtıma. Sürecin en acılı aşaması olan dağıtımda, dumanı üstünde uygulama canlı ortamda hayata gözlerini açar. Beklenmedik bir hata ile karşılaşma olasılığımız yüksek mi? Geliştiricilerin bir takım küçük hatalar yaptığı söylenir hep. Koca Taborlin her sandığı açarmış derler. (Burada Kral Katili Güncesi’ne atıfta bulunulmuştur) Ramston çeliği kadar sağlam ama bir o kadar da kırılgan bir uygulamamız düşen ilk cephe oluyor. Internal Server Error… Görünen o ki, yeni uygulama veya yeni sürüm yüklendikten sonra veri tabanında bir takım küçük sorunlarımız var.

Çakışan sorgular, boş prosedürler, locklar, cache tabloları, konfigürasyon kaynaklı performans düşüşü olası veri tabanı sorunları. Bir film şeridi gibi geçiyor insanın gözü önünde tablolar, şemalar, view’lar, prosedüler, fonksiyonlar, DDL’ler, DML’ler….

Şimdi neler olduğunu bir düşünelim. Kaynak kodlarımız da her değişiklik kayıt altına alınıyor. Her branch güncellemesinin her satırın her kod niteliğindeki parçacığın iz kaydı var. Master’a giden erdemli yolda her ayak izi mevcut. Bir önceki sürüme dönülür ve konu kapanır. Her şeyi unutur hiç bişey yaşanmamış sayarız.  Kutsal Git’e bir mühlet daha minnettar oluruz. Peki her şey eskisi gibi olacak mı? Ya veri tabanı, tablolar, şemalar, prosedürler, güncellenenler, silinenler, yeniler, eskiler ve Taselyalılar.

İşte bu noktada herşeyin merkezindeki veri tabanına odaklanmak gerekiyor. Demokles’in kılıcı uygulama veya kodun üzündeyken peki ya veri tabanı değişikleri. Veri tabanında fütursuzca çalıştırılan script’ler? Devops dünyasın da zerre miskal kodun bir izi bir sürümü bir süreci varken veri tabanı ne yazık ki Devops gezegenin dışında kalmıştır. Büyük küçük her kurum bir CI/CD raconu benimsemiş olsa da veri tabanı bu süreçte kör nokta olmuştur.

Maalesef veri tabanları gerçek ortam testleri, sürüm kontrolleri, iz kayıtları, gözden geçirme veya bir önceki sürüme dönme gibi günümüz Devops gezegeninin nimetlerinin çoğundan mahrum bir şekilde hayatını idame etmektedir. Veri tabanı sürüm kontrolü, dağıtıma çıkan sürüm ile veri tabanı değişikliklerinin hizalanması ve iz kayıtlarının oluşturulması artık veri tabanları için çok kritik mevzulardır.

Dolayısıyla kurumlarımız için çok kritik bir öneme haiz olan veri tabanları sürekli güncelenen ve hızlanan Devops gezegeninde kendine bir yer tutmalıdır. Bu noktada Veri Tabanı Devops yaklaşımı ortaya çıkıyor. Bu yaklaşıma göre bazı kurumlar DBA’leri Devops’un içine alırken bazı kurumlar veri tabanlarını Devops’un içine dahil etmektedir. Her iki yaklaşım da veri tabanı için Devops’u ihtiyaçları konusunda hemfikirdir. Bunlar;

 

• • Veri Tabanı sürüm kontrolü

• • Veri Tabanı değişiklikleri ile uygulama dağıtımlarının hizalanması

• • Veri Tabanı sürümlerinin ve değişikliklerinin iz kayıtlarının tutulması

• • Canlı ortam testleri (Dry Run)

• • Önceki sürümlere dönebilme

• • Daha efektif gözden geçirme ve politikalar

• • Güvenlik 

Platform Mühendisliğinin konuşulduğu günümüzde artık veri tabanlarının kör nokta olarak kalması zor görünüyor. Bu anlamda kurumların Veri Tabanı Devops için kendi yaklaşımlarına uygun bir araç benimseyip bu kritik sistemleri CI/CD’nin karanlık dehlizlerinden çıkarması zaruret olacaktır.

RDBMS, noSQL tartışmalarının gölgesinde PARC tapınaklarında kendi kendini yöneten ML tabanlı DBMS’ler konuşuluyormuş. Sahi bu teknoloji hiç mi yorulmaz?