Integrasi Git untuk pengembangan gudang Fabric

Berlaku untuk: ✅ Gudang di Microsoft Fabric

Artikel ini menjelaskan keuntungan mengembangkan dan menerapkan Fabric Data Warehouse dengan integrasi Git bawaan Fabric.

Important

Fitur ini sedang dalam tahap pratinjau.

Dengan menggunakan integrasi Git di Fabric, tim dapat menerapkan praktik kontrol sumber modern dalam pengembangan gudang. Pengembang dapat mengisolasi perubahan pada cabang, melacak evolusi skema melalui commit, berkolaborasi melalui pull request, dan menyinkronkan pembaruan antara repositori Git dan workspace Fabric.

Skenario umum meliputi:

  • Mengembangkan perubahan skema dengan aman di cabang dan workspace
  • Mengubah versi objek gudang di Git
  • Berkolaborasi di berbagai cabang dan workspace
  • Mempromosikan perubahan yang tervalidasi antar cabang
  • Menjaga item workspace (gudang dan lainnya) tetap selaras dengan sumber kebenaran Git

Untuk menjaga konsistensi, keterlacakan, dan keandalan sepanjang siklus hidup pengembangan gudang, Anda perlu memahami alur kerja ini.

Diagram siklus hidup pengembangan integrasi Git Fabric Warehouse.

Saat Anda menghubungkan workspace Fabric Data Warehouse ke Git, Anda melakukan commit definisi gudang sebagai proyek basis data. Proyek ini menjadi representasi otoritatif dari skema gudang dalam kontrol sumber dan berfungsi sebagai fondasi bagi aktivitas pengembangan yang berkelanjutan. Di source control explorer, skema muncul sebagai file individual .sql .

Tangkapan layar skema gudang di source control explorer.

Dengan menggunakan Fabric Git Integration dan Fabric Data Warehouse, Anda dapat:

Perbandingan

Selama proses sinkronisasi ini, Fabric menggunakan deployment skema bertahap berbasis DacFx untuk menerapkan perubahan. Pendekatan ini hanya menerapkan perbedaan skema yang relevan pada gudang, bukan memperbarui seluruh definisi gudang.

Ekstraksi bertahap membantu mengurangi churn yang tidak perlu dalam kontrol sumber, menjaga perbedaan skema yang lebih bersih di antara cabang, dan mendukung alur kerja branching dan merging yang efisien. Karena proses ekstraksi bersifat sadar skema, proses ini juga memungkinkan perbandingan dan validasi yang andal antara status workspace dan definisi yang dilacak Git.

Standarisasi cara skema gudang diekstrak dan disimpan meningkatkan konsistensi di seluruh lingkungan pengembangan. Definisi skema tetap stabil di berbagai cabang, perbedaan lebih akurat mencerminkan perubahan pengembangan yang disengaja, dan kontrol sumber menjadi dasar yang dapat diandalkan untuk penerapan, kolaborasi, dan manajemen siklus hidup.

File itu XMLA.json sendiri dikecualikan selama alur kerja integrasi Git. Fabric mengecualikan file ini dari commit dan pembaruan sehingga metadata semantik model default tidak secara tidak sengaja disimpan di Git. Saat menyinkronkan workspace dari Git, XMLA.json diabaikan, yang membantu menghindari konflik, timpahan yang tidak diinginkan, dan noise saat branch switching atau pembaruan dari Git.

Batasan dalam kontrol sumber

Fitur keamanan SQL seperti izin memerlukan pendekatan ekspor dan migrasi terpisah.

  • Ketergantungan lintas item antara gudang dan endpoint analitik SQL saat ini belum didukung dalam alur kerja pengembangan. Akibatnya, skenario yang bergantung pada perubahan terkoordinasi pada item-item ini mungkin tidak berjalan dengan andal.

  • Commit selektif di tingkat gudang saat ini belum didukung. Perubahan dilakukan pada tingkat item gudang, bukan pada tingkat objek yang lebih rinci.

  • Dukungan kontrol versi untuk endpoint analitik SQL saat ini belum tersedia. Keterbatasan ini dapat membatasi manajemen siklus hidup end-to-end ketika solusi mencakup baik warehouse maupun endpoint SQL analytics.

Batasan dalam integrasi Git

  • Ketika dua atau lebih barang gudang saling merujuk, mereka membentuk ketergantungan siklik. Sistem mendeteksi referensi melingkar ini selama operasi branch-out atau sinkronisasi Git-to-workspace, menyebabkan operasi tersebut gagal. Hindari ketergantungan siklik antar item.
  • Saat ini, jangan membuat Dataflow Gen2 dengan tujuan output ke gudang. Item baru bernama DataflowsStagingWarehouse muncul di repositori dan memblokir penerapan dan pembaruan dari Git.
  • Dependensi lintas item, pengurutan item, dan kesenjangan sinkronisasi antara titik akhir analitik SQL dan gudang berdampak pada alur kerja "bercabang ke ruang kerja baru atau yang sudah ada" dan "beralih ke cabang yang berbeda" selama pengembangan dan integrasi berkelanjutan.
  • Jika sebuah objek merujuk objek lain di gudang yang sama dengan menggunakan penamaan tiga bagian (database.schema.object), commit atau pembaruan dari Git bisa gagal. Untuk informasi lebih lanjut dan solusi sementara, lihat Referensi ke objek gudang sendiri dengan menggunakan nama tiga bagian.
  • Jika Anda mengubah kolom yang telah IDENTITY didefinisikan, commit atau pembaruan dari Git dapat gagal sampai IDENTITY_INSERT diaktifkan untuk tabel tersebut.
  • Jika repositori berisi .sqlproj file yang menyematkan versi SDK lama Microsoft.Build.Sql , commit atau pembaruan dari Git bisa gagal karena SDK lama tidak mengenali sintaks gudang baru seperti IDENTITY kolom dan CLUSTER BY. Untuk informasi lebih lanjut dan solusi sementara, lihat .sqlproj yang sudah tidak terkini di repositori Git.
  • Jika sebuah objek merujuk pada dua atau lebih tabel di gudang lain tanpa mengkualifikasi alias-kualifikasi setiap kolom, commit atau pembaruan dari Git dapat gagal. Untuk informasi lebih lanjut dan solusi sementara, lihat Kolom tidak memenuhi syarat dalam objek yang merujuk pada dua atau lebih tabel di gudang lain.
  • Jika skrip Anda merujuk pada dua atau lebih objek berbeda dalam skema yang sama dari gudang lain dan mengeja nama skema dengan huruf kapital yang tidak konsisten, commit atau pembaruan dari Git bisa gagal. Untuk informasi lebih lanjut dan solusi sementara, lihat Kapitalisasi tidak konsisten pada nama skema.
  • Kesalahan kolom ambigu yang daftar kandidatnya berisi :: pemisah dapat terjadi saat melakukan commit atau pembaruan dari Git, bahkan ketika tidak ada ambiguitas yang nyata. Untuk informasi lebih lanjut dan solusi sementara, lihat Kesalahan kolom ambigu dengan objek kandidat duplikat.

Skenario yang tidak didukung

Alur kerja CI/CD berikut ini tidak didukung secara resmi ketika gudang di ruang kerja yang berbeda memiliki kolasasi yang berbeda. Meskipun operasi ini mungkin berhasil tanpa kesalahan, operasi ini dapat mengakibatkan kesalahan metadata.

Dalam semua skenario ini, jika terjadi ketidakcocokan kolase, gunakan skrip Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py di kotak alat Fabric GitHub untuk memperbarui kolase himpunan data (TMSL) agar sesuai dengan kolase gudang.

Scenario Deskripsi Risiko
Jalur penerapan Mempromosikan konten gudang melalui tahap alur (misalnya, Dev → Test → Prod) tidak didukung jika gudang target dibuat dengan kolasi yang berbeda dari sumber. Penyebaran mungkin berhasil, tetapi pengurutan himpunan data tidak diperbarui agar sesuai dengan pengurutan gudang target.
Mencabangkan ke ruang kerja baru atau yang sudah ada Menggunakan integrasi Git untuk membuat cabang dari ruang kerja yang ada ke ruang kerja baru atau yang sudah ada, di mana gudang data memiliki pengurutan yang berbeda, tidak didukung. Konten gudang disinkronkan, tetapi metadata kolase tidak direkonsiliasi.
Mengalihkan cabang pada ruang kerja Beralih ke cabang yang terkait dengan gudang kolase yang berbeda di ruang kerja yang terhubung dengan Git tidak didukung. Konten yang disinkronkan mungkin membawa asumsi pengurutan yang tidak sesuai dengan gudang saat ini.
Menggabungkan perubahan antar ruang kerja melalui cabang Menggabungkan cabang-cabang Git di ruang kerja yang gudangnya memiliki pengurutan berbeda tidak didukung. Penggabungan mungkin berhasil di tingkat Git, tetapi kolase himpunan data yang dihasilkan tidak mencerminkan kolase gudang target.

Langkah selanjutnya

Gunakan Git Integration untuk pengembangan dan penerapan gudang

Konten terkait

  • Last updated on