Fabric depo geliştirme için Git entegrasyonu

Şunlar için geçerlidir: ✅ Microsoft Fabric'te Ambar

Bu makale, Fabric'nin yerleşik Git entegrasyonuyla Fabric Data Warehouse geliştirme ve dağıtmanın avantajlarını açıklıyor.

Important

Bu özellik önizleme aşamasındadır.

Fabric'te Git entegrasyonu kullanılarak, ekipler modern kaynak kontrol uygulamalarını depo geliştirmeye uygulayabilir. Geliştiriciler, dallardaki değişiklikleri izole edebilir, commitler aracılığıyla şema evrimini takip edebilir, pull requestler aracılığıyla iş birliği yapabilir ve güncellemeleri Git depoları ile Fabric çalışma alanları arasında senkronize edebilir.

Tipik senaryolar şunlardır:

  • Şube ve çalışma alanlarında şema değişiklikleri güvenli şekilde geliştirmek
  • Git'te depo nesnelerinin sürüm düzenlemesi
  • Birden fazla dal ve çalışma alanında iş birliği
  • Şubeler arasında doğrulanmış değişiklikleri teşvik etmek
  • İş alanı öğelerini (depo ve diğerleri) Git gerçeklik kaynağı ile uyumlu tutmak

Depo geliştirme yaşam döngüleri boyunca tutarlılık, izlenebilirlik ve güvenilirliği korumak için bu iş akışlarını anlamanız gerekir.

Fabric Warehouse Git entegrasyon geliştirme yaşam döngüsünün diyagramı.

Bir Fabric Data Warehouse çalışma alanını Git'e bağladığınızda, depo tanımlarını bir veritabanı projesi olarak commit etmiş olursunuz. Bu proje, depo şemasının kaynak kontrolünde yetkili temsili haline gelir ve devam eden geliştirme faaliyetlerinin temelini oluşturur. Kaynak kontrol gezgininde şema bireysel .sql dosyalar olarak görünür.

Bir depo şemasının ekran görüntüsü kaynak kontrol gezicisi.

Fabric Git Entegrasyonu ve Fabric Data Warehouse kullanarak şunları yapabilirsiniz:

Karşılaştırma

Bu senkronizasyon sürecinde, Fabric değişiklikleri uygulamak için DacFx tabanlı artan şema dağıtımı kullanır. Bu yaklaşım, depo tanımının tamamını güncellemek yerine yalnızca ilgili şema farklılıklarını depoya uygular.

Artan çıkarma, kaynak kontrolündeki gereksiz değişimi azaltmaya, dallar arasında daha temiz şema farklılıklarını korumaya ve verimli dallanma ile birleştirme iş akışlarını desteklemeye yardımcı olur. Çıkarma süreci şema farkında olduğu için, çalışma alanı durumu ile Git takip edilen tanımlar arasında güvenilir karşılaştırma ve doğrulama da mümkün kılar.

Depo şemalarının çıkarılma ve depolanma şeklinin standartlaştırılması, geliştirme ortamları arasında tutarlılığı artırır. Şema tanımları dallar arasında sabit kalır, farklılıklar kasıtlı geliştirme değişikliklerini daha doğru yansıtır ve kaynak kontrolü dağıtım, iş birliği ve yaşam döngüsü yönetimi için güvenilir bir temel haline gelir.

Dosyanın XMLA.json kendisi Git entegrasyon iş akışları sırasında dışlanıyor. Fabric, bu dosyayı commitlerden ve güncellemelerden çıkarır, böylece varsayılan semantik model meta veri istemeden Git'te saklanmaz. Git'ten bir çalışma alanı senkronize edilirken, XMLA.json bu da şubanı değiştirme veya Git'ten güncellemeler sırasında çatışmaları, istemeden üzerine yazmaları ve gürültüyü önlemeye yardımcı olur.

Kaynak denetimindeki sınırlamalar

İzinler gibi SQL güvenlik özellikleri ayrı bir dışa aktarma ve göç yaklaşımı gerektirir.

  • Depolar ile SQL analitik uç noktaları arasındaki çapraz eş bağımlılıkları şu anda geliştirme iş akışlarında desteklenmemektedir. Sonuç olarak, bu maddeler arasında koordineli değişikliklere dayanan senaryolar güvenilir şekilde çalışmayabilir.

  • Depo düzeyindeki seçici commitler şu anda desteklenmemektedir. Değişiklikler, daha ince detaylı nesne seviyeleri yerine depo öğesi seviyesinde yapılır.

  • SQL analytics uç noktaları için sürüm kontrol desteği şu anda mevcut değil. Bu sınırlama, çözümler hem depoları hem de SQL analitik uç noktalarını kapsadığında uçtan uca yaşam döngüsü yönetimini kısıtlayabilir.

Git tümleştirmesindeki sınırlamalar

  • İki veya daha fazla depo öğesi birbirine referans verdiğinde, döngüsel bir bağımlılık oluştururlar. Sistem, bu dairesel referansı branch-out veya Git-to-workspace senkronizasyon işlemleri sırasında algılar ve bu işlemlerin başarısız olmasına neden olur. Öğeler arasında döngüsel bağımlılıklardan kaçının.
  • Şu anda ambar için çıkış hedefi belirlenmiş bir Dataflow Gen2 oluşturmayın. Adlı DataflowsStagingWarehouse yeni bir öğe depoda görünür ve Git'ten işlemeyi ve güncelleştirmeyi engeller.
  • SQL analiz uç noktası ile ambar arasındaki öğe bağımlılıkları, öğe sıralaması ve eşitleme boşlukları, geliştirme ve sürekli tümleştirme sırasında "yeni veya mevcut bir çalışma alanına dallanma" ve "farklı bir dala geçiş" iş akışlarını etkiler.
  • Bir nesne aynı depodaki başka bir nesneye üç bölümlü adlandırma () kullanarak referans verirse (database.schema.object), Git'ten commit veya güncelleme başarısız olabilir. Daha fazla bilgi ve bir çözüm için, Deponun kendi nesnelerine üç bölümlü isim kullanarak referanslar bölümünü inceleyebilirsiniz.
  • Tanımlanmış bir sütunu IDENTITY değiştirirseniz, Git'ten commit veya güncelleme yapmak, tablo IDENTITY_INSERT için etkinleştirilene kadar başarısız olabilir.
  • Depoda eski .sqlproj bir SDK sürümünü sabitleyen bir dosya varsaMicrosoft.Build.Sql, Git'ten commit veya güncelleme başarısız olabilir çünkü eski SDK yeni depo sözdizimi (IDENTITYörneğin sütunlar ve CLUSTER BY). Daha fazla bilgi ve bir çözüm için Git deposunda Out-of-date .sqlproj sayfasına bakınız.
  • Bir nesne, her sütunu alias olarak nitelendirmeden başka bir depoda iki veya daha fazla tabloya referans verirse, Git'ten commit veya güncelleme başarısız olabilir. Daha fazla bilgi ve geçici çözüm için, başka bir depodaki iki veya daha fazla tabloya referans veren nesnelerdeki niteliksiz sütunlara bakınız.
  • Eğer scriptleriniz başka bir deponun aynı şemasında iki veya daha fazla farklı nesneye referans veriyorsa ve şema adını tutarsız büyük harflerle yazıyorsa, Git'ten commit veya güncelleme başarısız olabilir. Daha fazla bilgi ve geçici bir çözüm için, şema adlarının tutarsız büyük harflerle yazılması sayfasına bakınız.
  • Aday listesinde ayrıcatıcı :: bulunan belirsiz sütun hataları, Git'ten commit yaparken veya güncelleme yaparken ortaya çıkabilir, gerçek bir belirsizlik olmasa bile. Daha fazla bilgi ve geçici çözümler için, Tekrarlanan aday nesnelerle belirsiz sütun hataları sayfasına bakınız.

Desteklenmeyen senaryolar

Aşağıdaki CI/CD iş akışları, farklı çalışma alanlarındaki depolarda farklı sıralama kuralları kullanıldığında resmi olarak desteklenmez. Bu işlemler hata olmadan başarılı olsa da meta veri hatalarına neden olabilir.

Bu senaryoların tamamında harmanlama uyuşmazlığı oluşursa, veri kümesi (TMSL) harmanlamasını ambar harmanlaması ile eşleşecek şekilde güncelleştirmek için Fabric araç kutusundaki Python betiğini scripts/dw-collation-error-update-tmsl/pbi_interactive.py kullanın GitHub deposunu kullanın.

Scenario Description Risk
Dağıtım boru hatları Hedef ambarın kaynaktan farklı bir harmanlamayla oluşturulduğu işlem hattı aşamaları (örneğin, Geliştirme → Test → Prod) aracılığıyla ambar içeriğini yükseltme desteklenmez. Dağıtım başarılı olabilir, ancak veri kümesi harmanlaması hedef ambar harmanlaması ile eşleşecek şekilde güncelleştirilmez.
Yeni veya mevcut bir çalışma alanına uzantı oluşturma Mevcut bir çalışma alanından, ambarın farklı sıralama özelliğine sahip olduğu yeni veya mevcut bir çalışma alanına dal oluşturmak için Git entegrasyonu kullanılması desteklenmez. Ambar içeriği eşitleniyor, ancak düzenleme meta verileri uzlaştırılmadı.
Çalışma alanında dalları değiştirme Git bağlantılı çalışma alanında farklı bir harmanlama ambarıyla ilişkilendirilmiş bir dala geçiş desteklenmez. Senkronize edilen içerik, geçerli ambarla eşleşmeyen harmanlama varsayımlarını taşıyabilir.
Çalışma alanları arasındaki değişiklikleri dallar aracılığıyla birleştirme Git dallarının, ambarların farklı harmanlamalara sahip olduğu çalışma alanları arasında birleştirilmesi desteklenmez. Birleştirme Git düzeyinde başarılı olabilir, ancak sonuçta elde edilen veri kümesi harmanlaması hedef ambarın harmanlamasını yansıtmaz.

Sonraki adım

Depo geliştirme ve dağıtım için Git Entegrasyonunu kullanın

İlgili içerik

  • Last updated on