31 Ekim 2026, Cumartesi

Snorkel AI kodu Kubernetes üzerine kurulu bir CI pipeline’ıyla yayınlıyor: her açık pull request ve bazı ad-hoc commit’ler kendi geçici Kubernetes namespace’ini (‘PR namespace’) alıyor; geliştirici branch’ini orada deploy edip birleştirmeden önce tüm test paketini çalıştırıyor. Testler en çok gerçek veriyle işe yarıyor. Production veritabanları Amazon Aurora PostgreSQL ve her PR namespace’ine ayrı bir kopya vermek zor kısımdı: bir kopyayı geri yüklemek ortamlar başına yaklaşık 20 dakika sürüyordu; geliştiriciler gün boyu PR açarken ve merge queue her koşu için taze bir ortam isterken bu çok yavaş. Alternatifler (paylaşımlı staging veritabanı, kısaltılmış fixture ya da sentetik veri) gerçek veriyle test etmenin çözmeye çalıştığı sorunları geri getiriyor: testlerin birbirini bozması, eski şemalar ve yalnızca gerçek veri şekillerinde çıkan bug’lar.

Lakebase branching. Lakebase, Databricks’in sunucusuz Postgres veritabanı; depolama ve hesaplama ayrı ve veritabanını Git branch’i gibi dallandırmayı destekliyor: herhangi bir zaman noktasından yeni, yalıtılmış, yazılabilir bir branch oluşturabilirsin. Branch’ler copy-on-write: oluşturmak bir metadata işlemi, veri kopyalanmıyor; yeni branch ana dalla aynı depolama sayfalarını paylaşıyor ve yalnızca değiştirdiği sayfalar yeni depolama olarak yazılıyor. Pratikte iki özellik deseni mümkün kılıyor: copy-on-write branching ve branch expiration (TTL).

Akış dört adım. (1) Ana dalda production’ın taze bir kopyasını tut: Lakebase standart Postgres olduğundan AWS DMS için hedef olabiliyor, özel araç gerekmiyor; Snorkel bir DMS görevini production Aurora’ya yöneltip Lakebase projesinin main branch’ine kopyalıyor. (2) PR açıldığında CI pipeline’ı Lakebase API’sini çağırıp main’den bir branch oluşturuyor, bir sona erme zamanı koyuyor ve bağlantı bilgilerini PR namespace’ine veriyor. (3) PR namespace’indeki uygulama branch’ine standart Postgres olarak bağlanıyor; testler migration çalıştırabilir, veri yazabilir ve şemayı değiştirebilir, production’ı, main’i ya da diğer PR’ları etkilemeden. (4) PR kapanınca ya da test geçince branch siliniyor; temizleme adımı çalışmazsa TTL son çare olarak branch’i kendisi düşürüyor.

İki güvenlik gereksinimi. *Private connectivity:* production verisi Aurora’dan Lakebase’e ve Lakebase’den CI kümesine halka açık internet yerine özel ağ üzerinden akıyor. *Identity:* Snorkel’in iki tür veritabanı kullanıcısı var, PR ortamında hata ayıklamak için etkileşimli bağlanan geliştiriciler ve hiçbir insan olmadan çalışan CI pipeline’ları. Okta SSO tarayıcı tabanlı etkileşimli girişe göre kurulu olduğundan tasarım kullanıcı türüne göre ikiye bölünmüş.