Jenkins pipeline'ı her pull request'e kendi kullan-at Postgres branch'ini veriyor

Her PR için bir veritabanı branch'i

Bir geliştirici, her pull request'in kendi kullan-at Postgres veritabanını aldığı çalıştırılabilir bir CI kurulumunu yayınladı: PR açıldığında oluşturulan, gerçek satırlarla test edilen ve build bittiğinde silinen, production'ın anlık copy-on-write branch'i. Harish Shenoy'nun dev.to'daki yazısına göre pipeline, Databricks Lakebase üzerinde çalışıyor; Lakebase, depolamayı compute'dan ayıran ve branch'i birinci sınıf bir nesne haline getiren yönetilen bir Postgres servisi — production verisini taşıyan tam bir klon, saniyeler içinde hazır, kullanan olmadığında compute'u sıfıra ölçekleyen bir endpoint'le.

Hedeflediği sorun

Kurulum, tanıdık bir soruna saldırıyor: bütün ekibin eşzamanlı olarak, izolasyon olmadan kullandığı tek bir paylaşımlı dev veya staging Postgres. Shenoy, yarım kalmış migration'ların ve gelişigüzel denemelerin hafta sonuna doğru paylaşımlı instance'ı kullanılamaz hale getirdiğini, CI'dan geçen migration'ların ise sadece boş bir şemaya karşı çalıştığını anlatıyor. Asıl derin kusur olarak bunu gösteriyor: migration SQL'ini sıfır satırlı tablolarla çalıştırmak, aynı ifadenin production hacminde nasıl davranacağı konusunda hiçbir şey kanıtlamaz — makaledeki örnek, production'da orders tablosunu dokuz dakika kilitleyen bir ADD COLUMN.

Pipeline nasıl çalışıyor

Jenkinsfile'ın birbirinden ayırdığı iki yol var.

Bir pull request açıldığında Jenkins, doğrudan production'dan PR'un adını taşıyan bir branch oluşturuyor (örnekte ci-pr-42). Klon copy-on-write olduğu için branch anında var oluyor ve production verisini taşıyor. PR'un migration'ı bu branch'e uygulanıyor, test paketi ortaya çıkan satırlara karşı çalışıyor ve her zaman çalışan bir temizlik adımı branch'i sonrasında siliyor; böylece hiçbir şey arkada kalmıyor ve depolamayı tüketmeye devam etmiyor.

Kod main'e merge edildiğinde pipeline, branch ve test aşamalarını atlıyor ve DBA ekibine kısıtlı bir onay kapısında duruyor. Bir insan onayladıktan sonra ancak promote aşaması migration'ı production'a uyguluyor. Gözden geçiren kişi SQL'i soyut olarak değerlendirmiyor — production verisinin kopyasına karşı CI'ı çoktan atlatmış migration artefaktının aynısına imza atıyor.

Bilinçli bir tercihle Jenkinsfile yalnızca beş shell script'ini (create, migrate, test, promote, teardown) orkestre ediyor; böylece aynı komutlar hem dizüstü bilgisayarda hem CI'da çalışıyor. Mantık shell'de yaşadığı için yazar, aynı akışın GitHub Actions, GitLab CI, Azure DevOps, CircleCI veya script çalıştırabilen herhangi bir orkestratör altında da işlediğini belirtiyor.

Argümanı taşıyan assertion

Demo proje, az sayıda tohumlanmış müşterisi olan bir orders servisi. Örnek bir migration, NOT NULL ve default değerli bir fulfillment_status kolonu ve bir index ekliyor. Kritik test, mevcut siparişlerin gerçekten default değerle doldurulup doldurulmadığını kontrol ediyor. Default'suz naif bir NOT NULL kolon ekleme boş bir test şemasında geçer ama production'ı bozar; veri taşıyan bir branch'te ise aynı migration, yola çıkmadan önce testi güvenli biçimde düşürür. Python bağımlılığı kuramayan kilitli CI agent'ları için depoda saf SQL assertion dosyası bulunuyor ve rollback'li versiyonlanmış changelog'lar için isteğe bağlı bir Liquibase yolu da var.

Maliyet, alternatifler ve erişim

Makaledeki karşılaştırma, Aurora'nın fast clone'unu en yakın alternatif olarak konumlandırıyor; Oracle RMAN restore'ları ve SQL Server restore'ları ise yavaş — Oracle'ın durumunda saatler — ve çalışır halde tutulması pahalı olarak tasvir ediliyor. Lakebase'in iddia edilen avantajları: anlık copy-on-write branching, lisans maliyeti olmayan kullanım bazlı fiyatlandırma ve boşta duran ortamlar için sıfır compute maliyeti. Geliştiricilerin production kopyaları açmasına izin verme güvenlik sorusunda Shenoy, branch'lerin production'ın kendisine erişim değil izole klonlar olduğunu ve kimlik doğrulamanın Jenkins credential store'daki statik bir veritabanı şifresi yerine bir service principal'dan gelen kısa ömürlü OAuth token'larıyla yapıldığını vurguluyor.

Çalışır hale getirmek

Her şey herkese açık. Depo (GitHub'da harishshenoy552/lakebase-cicd), beş aşamanın tamamından geçen gerçek bir Jenkins çalışmasının ekran görüntülerini içeriyor; yazar, Lakebase autoscaling katmanında bulunan bir Databricks workspace'e ve Databricks CLI, psql, jq ve Python'a sahipseniz akışın tamamının — bootstrap, branch, migrate, test, promote, teardown — yaklaşık üç dakikada denenebileceğini söylüyor. Yazıya dokuz dakikalık bir video anlatım da eşlik ediyor.

Neden önemli

Kod branching'i son on yılda anlık ve fiilen ücretsiz hale geldi; veritabanı branching'i aynı muameleyi görmedi, bu yüzden ekipler açığı ritüellerle kapattı — kimsenin güvenmediği bir staging veritabanı, bir DBA ticket kuyruğu, gergin bir Cuma deploy'u. Bu pipeline o ritülleri test edilebilir bir şeyle değiştiriyor: migration'lar herkes onaylamadan önce gerçek veriyle çalışıyor, geliştiriciler paylaşımlı bir instance'ın arkasında sıraya girmeyi bırakıyor ve DBA'lar etkisini tahmin etmek yerine çoktan çalıştırılmış bir migration'ı gözden geçiriyor. Handikap, yaklaşımın sizi tek bir satıcının yönetilen Postgres'ine bağlıyor olması. Ama insanlı bir promote kapısıyla PR başına veritabanı izolasyonu için çalışan bir örüntü olarak, bu somut ve çalıştırılabilir bir referans uygulama, bir öneri değil.