หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
นําไปใช้กับ: ✅ คลังสินค้าใน Microsoft Fabric
บทความนี้อธิบายข้อดีของการพัฒนาและปรับใช้ Fabric คลังข้อมูล ที่มีการผสานรวม Git ในตัวของ Fabric
Important
คุณลักษณะนี้อยู่ในตัวอย่าง
ด้วยการใช้การผสานรวม Git ใน Fabric ทีมงานสามารถนําแนวปฏิบัติการควบคุมซอร์สโค้ดสมัยใหม่มาใช้กับการพัฒนาคลังสินค้าได้ นักพัฒนาสามารถแยกการเปลี่ยนแปลงในสาขาต่าง ๆ ติดตามวิวัฒนาการของสคีมาผ่านการคอมมิต ทํางานร่วมกันผ่านคําขอดึงข้อมูล และซิงโครไนซ์การอัปเดตระหว่างที่เก็บข้อมูล Git และพื้นที่ทํางาน Fabric
สถานการณ์ทั่วไปได้แก่:
- การพัฒนาการเปลี่ยนแปลงสคีมาอย่างปลอดภัยในสาขาและพื้นที่ทํางาน
- การกําหนดเวอร์ชันของวัตถุคลังใน Git
- การทํางานร่วมกันข้ามหลายสาขาและพื้นที่ทํางาน
- การส่งเสริมการเปลี่ยนแปลงที่ผ่านการตรวจสอบระหว่างสาขา
- การรักษารายการพื้นที่ทํางาน (warehouse และอื่น ๆ) ให้สอดคล้องกับแหล่งข้อมูล Git
เพื่อรักษาความสม่ําเสมอ การติดตามย้อนกลับ และความน่าเชื่อถือตลอดวงจรการพัฒนาคลังสินค้า คุณจําเป็นต้องเข้าใจเวิร์กโฟลว์เหล่านี้
เมื่อคุณเชื่อมต่อพื้นที่ทํางาน Fabric คลังข้อมูล กับ Git คุณจะ commit การนิยาม warehouse เป็นโปรเจกต์ฐานข้อมูล โครงการนี้จะกลายเป็นตัวแทนที่เชื่อถือได้ของโครงสร้างคลังสินค้าในระบบควบคุมซอร์สโค้ด และเป็นรากฐานสําหรับกิจกรรมการพัฒนาอย่างต่อเนื่อง ในตัวสํารวจควบคุมซอร์ส สคีมาจะปรากฏเป็นไฟล์แยก.sql
โดยใช้ Git Integration และ Fabric คลังข้อมูล Fabric คุณสามารถ:
- พัฒนา Fabric คลังข้อมูล ด้วย Git Integration
- ปรับใช้ Fabric คลังข้อมูล โดยใช้ deployment pipeline
- ปรับใช้และปรับใช้อย่างต่อเนื่องโดยใช้พอร์ทัล Fabric, Git, IDE ของคุณเองหรือสภาพแวดล้อมการพัฒนาภายในเครื่อง, Fabric deployment pipeline หรือระบบ CI/CD ภายนอกที่เชื่อมต่อแบบต่อเนื่อง/ปรับใช้ต่อเนื่อง รวมถึง pipeline ใน Azure DevOps Services หรือ GitHub
การเปรียบเทียบ
ระหว่างกระบวนการซิงโครไนซ์นี้ Fabric ใช้การปรับใช้สคีมาแบบเพิ่มทีละน้อยบน DacFx เพื่อปรับเปลี่ยน วิธีนี้ใช้เฉพาะความแตกต่างของสคีมาที่เกี่ยวข้องกับคลังสินค้าเท่านั้น แทนที่จะอัปเดตคําจํากัดความคลังสินค้าทั้งหมด
การสกัดแบบเพิ่มทีละน้อยช่วยลดการเปลี่ยนแปลงที่ไม่จําเป็นในการควบคุมซอร์สโค้ด รักษาความแตกต่างของสคีมาให้สะอาดขึ้นระหว่างสาขา และสนับสนุนกระบวนการแยกสาขาและการรวมสาขาอย่างมีประสิทธิภาพ เนื่องจากกระบวนการดึงข้อมูลมีความตระหนักถึงสคีมา จึงช่วยให้สามารถเปรียบเทียบและตรวจสอบสถานะพื้นที่ทํางานกับนิยามที่ Git ติดตามได้อย่างน่าเชื่อถือ
การมาตรฐานวิธีการดึงและจัดเก็บสคีมาคลังสินค้าช่วยปรับปรุงความสอดคล้องในสภาพแวดล้อมการพัฒนา คํานิยามสคีมายังคงเสถียรระหว่างสาขา ความแตกต่างสะท้อนการเปลี่ยนแปลงการพัฒนาโดยเจตนาได้อย่างแม่นยํามากขึ้น และการควบคุมซอร์สโค้ดกลายเป็นพื้นฐานที่เชื่อถือได้สําหรับการปรับใช้ การทํางานร่วมกัน และการจัดการวงจรชีวิต
ไฟล์เอง XMLA.json จะถูกยกเว้นในระหว่างกระบวนการทํางานการผสานรวม Git Fabric จะยกเว้นไฟล์นี้จากการคอมมิตและอัปเดต ดังนั้นเมตาดาต้าเชิงความหมายmodelเริ่มต้นจึงไม่ถูกเก็บไว้ใน Git โดยไม่ได้ตั้งใจ เมื่อซิงโครไนซ์พื้นที่ทํางานจาก Git XMLA.json จะถูกละเลย ซึ่งช่วยหลีกเลี่ยงความขัดแย้ง การเขียนทับโดยไม่ตั้งใจ และเสียงรบกวนระหว่างการสลับสาขาหรือการอัปเดตจาก Git
ข้อจํากัดในตัวควบคุมแหล่งข้อมูล
ฟีเจอร์ความปลอดภัยของ SQL เช่น สิทธิ์ ต้องการวิธีการส่งออกและย้ายแยกต่างหาก
การพึ่งพาข้ามรายการระหว่างคลังสินค้าและอุปกรณ์วิเคราะห์ SQL ยังไม่ได้รับการสนับสนุนในเวิร์กโฟลว์การพัฒนา ดังนั้น สถานการณ์ที่ต้องปรับเปลี่ยนอย่างประสานงานในรายการเหล่านี้อาจไม่ทํางานได้อย่างน่าเชื่อถือ
การ commit แบบเลือกเฉพาะในระดับคลังสินค้ายังไม่รองรับในขณะนี้ การเปลี่ยนแปลงจะถูกบันทึกในระดับสินค้าคลังสินค้า แทนที่จะทําในระดับวัตถุที่ละเอียดกว่า
ขณะนี้ยังไม่มีการสนับสนุนการควบคุมเวอร์ชันสําหรับอุปกรณ์ SQL analytics ข้อจํากัดนี้อาจจํากัดการจัดการวงจรชีวิตแบบครบวงจรเมื่อโซลูชันครอบคลุมทั้งคลังสินค้าและจุดสิ้นสุดการวิเคราะห์ SQL
ข้อจํากัดในการรวม Git
- เมื่อสินค้าในคลังสินค้าสองรายการขึ้นไปอ้างอิงกัน จะเกิดการพึ่งพาแบบวัฏจักร ระบบจะตรวจจับการอ้างอิงแบบวงกลมนี้ระหว่างการซิงค์ระหว่างการแยกสาขาหรือการซิงค์ระหว่าง Git กับ workspace ซึ่งทําให้การดําเนินการเหล่านี้ล้มเหลว หลีกเลี่ยงการพึ่งพาแบบวนซ้ําระหว่างรายการ
- ขณะนี้ อย่าสร้างกระแสข้อมูล Gen2 ที่มีปลายทางเอาต์พุตไปยังคลังสินค้า รายการใหม่ที่มีชื่อจะ
DataflowsStagingWarehouseปรากฏในที่เก็บและบล็อกการคอมมิตและการอัปเดตจาก Git - การขึ้นต่อกันข้ามรายการ การจัดลําดับรายการ และช่องว่างการซิงโครไนซ์ระหว่างปลายทางการวิเคราะห์ SQL และคลังสินค้าส่งผลกระทบต่อเวิร์กโฟลว์ "การแตกแขนงไปยังพื้นที่ทํางานใหม่หรือที่มีอยู่" และ "การสลับไปยังสาขาอื่น" ระหว่างการพัฒนาและการรวมอย่างต่อเนื่อง
- หากวัตถุอ้างอิงวัตถุอื่นในคลัง เดียวกัน โดยใช้การตั้งชื่อสามส่วน (
database.schema.object), การคอมมิตหรืออัปเดตจาก Git อาจล้มเหลว สําหรับข้อมูลเพิ่มเติมและวิธีแก้ไข ดูที่ การอ้างอิงไปยังวัตถุของคลังสินค้าโดยใช้ชื่อสามส่วน - หากคุณเปลี่ยนคอลัมน์ที่กําหนด
IDENTITYไว้ การคอมมิตหรืออัปเดตจาก Git อาจล้มเหลวจนกว่าIDENTITY_INSERTจะเปิดใช้งานสําหรับตาราง - หากคลังข้อมูลมี
.sqlprojไฟล์ที่ยึด SDK เวอร์ชันเก่าMicrosoft.Build.Sqlการคอมมิตหรืออัปเดตจาก Git อาจล้มเหลวเพราะ SDK เก่าไม่รู้จักไวยากรณ์คลังข้อมูลใหม่ เช่นIDENTITYคอลัมน์และCLUSTER BYสําหรับข้อมูลเพิ่มเติมและวิธีแก้ไข ดูที่ Out-of-date .sqlproj ในที่เก็บ Git - หากวัตถุอ้างอิงสองตารางขึ้นไปในคลังข้อมูลอื่นโดยไม่ตรวจสอบทุกคอลัมน์ การ commit หรืออัปเดตจาก Git อาจล้มเหลว สําหรับข้อมูลเพิ่มเติมและวิธีแก้ไข ดูที่ คอลัมน์ไม่ระบุคุณสมบัติในวัตถุที่อ้างอิงสองตารางขึ้นไปในคลังสินค้าอื่น
- ถ้าสคริปต์ของคุณอ้างอิงวัตถุสองชิ้นขึ้นไปในสคีมาเดียวกันของคลังสินค้าอื่น และสะกดชื่อสคีมาด้วยตัวพิมพ์ใหญ่ไม่สอดคล้องกัน การคอมมิตหรืออัปเดตจาก Git อาจล้มเหลว สําหรับข้อมูลเพิ่มเติมและวิธีแก้ไข ดูที่ การใช้ตัวพิมพ์ใหญ่ไม่สอดคล้องกันของชื่อสคีมา
- ข้อผิดพลาดในคอลัมน์ที่คลุมเครือซึ่งรายการผู้สมัครมี
::ตัวคั่นอาจเกิดขึ้นได้เมื่อทําการคอมมิตหรืออัปเดตจาก Git แม้ว่าจะไม่มีความกํากวมจริง ๆ ก็ตาม สําหรับข้อมูลเพิ่มเติมและวิธีแก้ไข ดูที่ ข้อผิดพลาดคอลัมน์ที่คลุมเครือกับวัตถุผู้สมัครซ้ํากัน
สถานการณ์ที่ไม่ได้รับการสนับสนุน
เวิร์กโฟลว์ CI/CD ต่อไปนี้ไม่ได้รับการสนับสนุนอย่างเป็นทางการเมื่อคลังสินค้าในพื้นที่ทํางานที่แตกต่างกันมีการเปรียบเทียบที่แตกต่างกัน แม้ว่าการดําเนินการเหล่านี้อาจประสบความสําเร็จโดยไม่มีข้อผิดพลาด แต่ก็อาจส่งผลให้เกิดข้อผิดพลาดของข้อมูลเมตาได้
ในสถานการณ์ทั้งหมดเหล่านี้ ถ้าเกิดการเปรียบเทียบไม่ตรงกัน ให้ใช้สคริปต์ Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py ในที่เก็บ Fabric toolbox GitHub เพื่ออัปเดตการเปรียบเทียบชุดข้อมูล (TMSL) ให้ตรงกับการเปรียบเทียบคลังสินค้า
| บทภาพยนตร์ | คำอธิบาย | ความเสี่ยง |
|---|---|---|
| ไปป์ไลน์การปรับใช้ | การโปรโมตเนื้อหาคลังสินค้าผ่านขั้นตอนไปป์ไลน์ (ตัวอย่างเช่น Dev → Test → Prod) ซึ่งคลังสินค้าเป้าหมายถูกสร้างขึ้นด้วยการเปรียบเทียบที่แตกต่างจากแหล่งที่มาไม่ได้รับการสนับสนุน | การปรับใช้อาจสําเร็จ แต่การเปรียบเทียบชุดข้อมูลไม่ได้รับการอัปเดตเพื่อให้ตรงกับการเปรียบเทียบคลังสินค้าเป้าหมาย |
| การขยายสาขาไปยังพื้นที่ทํางานใหม่หรือที่มีอยู่ | การใช้การรวม Git เพื่อแยกสาขาออกจากพื้นที่ทํางานที่มีอยู่ไปยังพื้นที่ทํางานใหม่หรือที่มีอยู่ซึ่งคลังสินค้ามีการเปรียบเทียบที่แตกต่างกันไม่ได้รับการสนับสนุน | เนื้อหาคลังสินค้าถูกซิงค์ แต่ข้อมูลเมตาการเปรียบเทียบจะไม่กระทบยอด |
| การสลับสาขาบนพื้นที่ทํางาน | ไม่รองรับการสลับไปยังสาขาที่เชื่อมโยงกับคลังสินค้าของการเปรียบเทียบที่แตกต่างกันบนพื้นที่ทํางานที่เชื่อมต่อ Git | เนื้อหาที่ซิงค์อาจนําสมมติฐานการเปรียบเทียบที่ไม่ตรงกับคลังสินค้าปัจจุบัน |
| การผสานการเปลี่ยนแปลงระหว่างพื้นที่ทํางานผ่านสาขา | ไม่รองรับการรวมสาขา Git ในพื้นที่ทํางานที่คลังสินค้ามีการเปรียบเทียบที่แตกต่างกัน | ผสานอาจประสบความสําเร็จในระดับ Git แต่การเปรียบเทียบชุดข้อมูลที่เป็นผลลัพธ์ไม่ได้สะท้อนถึงการเปรียบเทียบของคลังสินค้าเป้าหมาย |