DriftGuard'ı Neden Geliştirdim: Schema Drift'i Üretimden Önce Yakalamak
Kimsenin Konuşmadığı Problem
Schema drift, gece 2'de production'ı kırana kadar acil hissetmeyen problemlerden biri.
Çoğu ekip şema doğrulamasını silolarda yönetir. SQL linter'lar migration sözdizimini kontrol eder. API linter'lar OpenAPI spec'lerini doğrular. Ama gerçek drift katmanlar arasında gerçekleşir: yeniden adlandırılan bir Postgres sütunu, downstream'deki CSV dışa aktarımını veya partner API tüketicisini sessizce kırabilir.
İş yerinde bu kalıbı sürekli yaşıyordum. Veritabanında bir alanı yeniden adlandırıyorduk, API katmanını güncelliyorduk, sonra haftalar sonra dahili bir raporlama aracının hâlâ eski sütun adını beklediğini keşfediyorduk. Düzeltme her zaman reaktifti — birisi bozuk veriyi fark edip şema değişikliğine kadar izlerdi.
Mevcut Araçlar Neden Yetersizdi
DriftGuard'ı geliştirmeden önce birkaç seçeneği değerlendirdim:
- SQL linter'lar (sqlfluff, squawk): Sözdizimi için iyi ama veritabanı şemanızla API kontratlarınız arasındaki ilişkiyi anlamıyorlar.
- API linter'lar (Spectral, openapi-diff): OpenAPI spec'lerine odaklanmış, veritabanı değişikliklerine kör.
- Migration araçları (Alembic, Flyway): Şema değişikliklerinin "nasıl"ını yönetir ama "downstream'de ne kırıldı" sorusunu cevaplamaz.
Hiçbiri şu soruyu cevaplayamıyordu: "Bu sütunu yeniden adlandırırsam, başka ne kırılır?"
DriftGuard Yaklaşımı
DriftGuard temelden farklı bir yaklaşım benimser. Tek bir veri katmanını kontrol etmek yerine, 7+ heterojen kaynaktan gelen şemaları tek bir karşılaştırma modeline normalize eder:
- Veritabanları: PostgreSQL, MySQL, SQLite (SQLAlchemy 2.x ile)
- API'lar: OpenAPI spec'leri (HTTP veya dosya üzerinden)
- Dosyalar: JSON Schema, CSV başlıkları, YAML yapısı (pyarrow ile)
Semantik diff motoru sadece değişiklikleri tespit etmez — onları sınıflandırır. Bir sütun yeniden adlandırma, bulanık eşleme (SequenceMatcher) tetikler ve yeniden adlandırmaları sil-ve-ekle çiftlerinden ayırt eder.
Politika Motoru
Farklı ekiplerin değişikliğe farklı toleransı vardır. DriftGuard'ın politika motoru 5 uygulama modunu destekler:
- Strict: Herhangi bir şema değişikliği pipeline'ı durdurur
- Backward-compatible: Yalnızca geriye uyumlu değişiklikler geçer
- Forward-compatible: Yalnızca ileriye uyumlu değişiklikler geçer
- Lenient: Her şeyi logla, hiçbirinde hata verme
- Default: Kaynak başına yapılandırılabilir önem derecesi
CI Entegrasyonu
DriftGuard bir CI gate olarak çalışır. Politika ihlallerinde sıfır olmayan çıkış kodları üretir, GitHub Actions ile entegre olur ve raporları birden fazla formatta çıktılar (Terminal, JSON, Markdown, HTML).
Tipik iş akışı:
- Geliştirici bir şemayı değiştirir (veritabanı migration'ı, API spec güncellemesi, CSV format değişikliği)
- CI, önceki snapshot'a karşı DriftGuard'ı çalıştırır
- DriftGuard değişiklikleri sınıflandırır ve yapılandırılmış politikaya göre değerlendirir
- Pipeline detaylı diff raporuyla geçer veya başarısız olur
Çıkarılan Dersler
Normalizasyon en zor kısım. PostgreSQL'in information_schema'sını, bir OpenAPI spec'ini ve bir CSV dosyasını aynı karşılaştırma modeline sokmak dikkatli soyutlama gerektirdi. 7 adaptörlü collector mimarisi doğru karardı — yeni kaynaklar diff motoruna dokunmadan ekleniyor.
Bulanık eşleme korkuluklar gerektirir. SequenceMatcher yeniden adlandırmaları tespit etmek için harika ama çok agresif olursa yanlış pozitifler oluşturuyor. Gerçek şema değişiklik loglarına karşı test ettikten sonra 0.6 benzerlik eşiğine karar verdim.
Politika kod değil, veri olmalı. Politika modlarını kaynak başına yapılandırılabilir yapmak (sadece global değil) önemliydi. Ekiplerin aracı fork etmeden granüler kontrol ihtiyacı var.
Sırada Ne Var
DriftGuard şu anda en yaygın şema kaynaklarını kapsıyor. Yol haritası:
- Event-driven mimariler için Avro ve Protobuf collector'ları
- Kafka Schema Registry entegrasyonu
- CI/CD entegrasyonu için SARIF ve JUnit XML raportörleri
Proje açık kaynaklı ve GitHub üzerinde mevcut. Katkılar ve geri bildirimler memnuniyetle karşılanır.