สถานการณ์การใช้งาน Power BI: การเผยแพร่เนื้อหาระดับองค์กร

หมายเหตุ

บทความนี้เป็นส่วนหนึ่งของ ชุดการวางแผน การใช้งาน Power BI ของบทความ ชุดข้อมูลนี้เน้นไปที่ประสบการณ์การใช้งาน Power BI ภายใน Microsoft Fabric เป็นหลัก สําหรับบทนําสู่ชุดข้อมูล โปรดดู ที่ การวางแผนการใช้งาน Power BI

เมื่อผู้สร้างเนื้อหาทํางานร่วมกันเพื่อส่งมอบโซลูชันการวิเคราะห์ที่มีความสําคัญต่อองค์กร พวกเขาต้องตรวจสอบให้แน่ใจว่ามีการส่งเนื้อหาไปยังผู้บริโภคอย่างทันท่ีี่และเชื่อถือได้ ทีมทางเทคนิคจัดการกับการทดสอบนี้โดยใช้กระบวนการที่เรียกว่า DevOps DevOps ช่วยให้ทีมสามารถทําให้กระบวนการเป็นอัตโนมัติและปรับขนาดโดยการใช้แนวทางปฏิบัติที่ปรับปรุงและเร่งการส่งมอบ

หมายเหตุ

ทีมข้อมูลที่จัดการกับความท้าทายเดียวกันอาจยังฝึก DataOps DataOps สร้างขึ้นตามหลักการ DevOps แต่ DataOps รวมแนวทางปฏิบัติเพิ่มเติมที่เฉพาะเจาะจงกับการจัดการข้อมูล เช่น การประกันคุณภาพข้อมูลและการกํากับดูแล เราอ้างอิงถึง DevOps ในบทความนี้ แต่โปรดทราบว่าหลักการพื้นฐานสามารถนําไปใช้กับ DataOps ได้เช่นกัน

ผู้สร้างเนื้อหาและผู้บริโภคได้รับประโยชน์จากข้อดีหลายประการเมื่อใช้แนวทางปฏิบัติ DevOps เพื่อเผยแพร่เนื้อหา Power BI ประเด็นต่อไปนี้เป็นภาพรวมระดับสูงของวิธีการทํางานของกระบวนการนี้

1. พัฒนาเนื้อหาและบันทึกงานไปยังที่เก็บระยะไกล: ผู้สร้างเนื้อหาพัฒนาโซลูชันของพวกเขาบนเครื่องของตนเอง พวกเขาบันทึกและบันทึกงาน ไปยังที่เก็บ ระยะไกลอย่างสม่ําเสมอในระหว่างการพัฒนา ที่เก็บระยะไกลประกอบด้วยโซลูชันเวอร์ชันล่าสุดและสามารถเข้าถึงทีมพัฒนาทั้งหมดได้
2. ทํางานร่วมกันและจัดการการเปลี่ยนแปลงเนื้อหาโดยใช้การควบคุมเวอร์ชัน: ผู้สร้างเนื้อหาคนอื่น ๆ สามารถทําการแก้ไขโซลูชันได้โดยการสร้างสาขา สาขาเป็นสําเนาของที่เก็บระยะไกล เมื่อการแก้ไขเหล่านี้พร้อมและอนุมัติแล้ว สาขาจะถูกผสานเข้ากับโซลูชันเวอร์ชันล่าสุด มีการติดตามการแก้ไขทั้งหมดของโซลูชัน กระบวนการนี้เรียกว่า ตัวควบคุม เวอร์ชัน (หรือ ตัวควบคุมแหล่งข้อมูล)
3. ปรับใช้และเลื่อนระดับเนื้อหาโดยใช้ไปป์ไลน์: ในสถานการณ์การใช้งานการเผยแพร่เนื้อหาแบบบริการตนเอง เนื้อหาจะได้รับการเลื่อนระดับ (หรือปรับใช้) ผ่านการพัฒนา ทดสอบ และพื้นที่ทํางานการผลิตโดยใช้ไปป์ไลน์การปรับใช้ Power BI ไปป์ไลน์การปรับใช้ Power BI สามารถเลื่อนระดับเนื้อหาไปยังพื้นที่ทํางาน Power BI Premium ด้วยตนเองโดยใช้ส่วนติดต่อผู้ใช้หรือใช้ API REST ในทางตรงกันข้าม การเผยแพร่เนื้อหาระดับองค์กร (จุดมุ่งเน้นของสถานการณ์การใช้งานนี้) โปรโมตเนื้อหาโดยใช้ Azure Pipelines Azure Pipelines เป็นบริการ Azure DevOps ที่ทําให้การทดสอบ การจัดการ และการปรับใช้เนื้อหาเป็นแบบอัตโนมัติโดยใช้ชุดของขั้นตอนการเขียนโปรแกรมแบบกําหนดเอง ในสถานการณ์การใช้งานการเผยแพร่เนื้อหาองค์กร ไปป์ไลน์เหล่านี้ยังสามารถเรียกว่า ไปป์ไลน์การรวมและการปรับใช้ อย่างต่อเนื่อง (หรือ CI/CD) ไปป์ไลน์เหล่านี้มักจะรวมการเปลี่ยนแปลงและทําให้การเผยแพร่เนื้อหามีประสิทธิภาพขึ้นโดยอัตโนมัติ

สำคัญ

ในบางครั้งที่บทความนี้อ้างอิงถึง Power BI Premium หรือการสมัครใช้งานความจุ (P SKU) โปรดทราบว่าในขณะนี้ Microsoft กําลังรวมตัวเลือกการซื้อและหยุดใช้งาน Power BI Premium ต่อความจุ SKU ลูกค้าใหม่และลูกค้าที่มีอยู่ควรพิจารณาซื้อการสมัครใช้งานความจุ Fabric (F SKU) แทน

สําหรับข้อมูลเพิ่มเติม โปรดดู ที่ การอัปเดตที่สําคัญเกี่ยวกับการให้สิทธิ์การใช้งาน Power BI Premium และ คําถามที่ถามบ่อยของ Power BI Premium

DevOps สนับสนุนวิธีการที่เป็นระบบและการจัดการเนื้อหาและการเผยแพร่ ช่วยให้ผู้สร้างเนื้อหาสามารถทํางานร่วมกันบนโซลูชัน และช่วยให้มั่นใจในการส่งเนื้อหาไปยังผู้บริโภคได้อย่างรวดเร็วและเชื่อถือได้ เมื่อคุณปฏิบัติตามแนวทางปฏิบัติของ DevOps คุณจะได้รับประโยชน์จากเวิร์กโฟลว์ที่คล่องตัว น้อยลง ข้อผิดพลาดน้อยลง และประสบการณ์ที่ดีขึ้นสําหรับผู้สร้างเนื้อหาและผู้บริโภคเนื้อหา

คุณตั้งค่าและจัดการแนวทางปฏิบัติ DevOps สําหรับโซลูชัน Power BI ของคุณโดยใช้ Azure DevOps ในสถานการณ์ขององค์กร คุณสามารถเผยแพร่เนื้อหาโดยอัตโนมัติด้วย Azure DevOps และ Power BI REST API ในสามวิธีที่แตกต่างกัน

• Power BI REST API กับไปป์ไลน์การปรับใช้ Power BI: คุณสามารถนําเข้าเนื้อหาไปยังพื้นที่ทํางานการพัฒนาและใช้ไปป์ไลน์การปรับใช้เพื่อ ปรับใช้ เนื้อหาผ่านการทดสอบและพื้นที่ทํางานการผลิต คุณยังคงควบคุมการปรับใช้จาก Azure DevOps และใช้ Power BI REST API เพื่อจัดการไปป์ไลน์การปรับใช้แทนรายการเนื้อหาแต่ละรายการ นอกจากนี้ คุณใช้ตําแหน่งข้อมูล XMLA เพื่อปรับใช้เมตาดาต้าของแบบจําลองข้อมูลแทนไฟล์ Power BI Desktop (.pbix) ด้วย Azure DevOps เมตาดาต้านี้ช่วยให้คุณสามารถติดตามการเปลี่ยนแปลงระดับออบเจ็กต์โดยใช้การควบคุมเวอร์ชัน ในขณะที่วิธีที่แข็งแกร่งและง่ายต่อการบํารุงรักษามากขึ้น วิธีนี้ยังต้องใช้สิทธิ์การใช้งานระดับพรีเมียมและการเขียนสคริปต์ปานกลางเพื่อตั้งค่าการนําเข้าเนื้อหาและการปรับใช้กับ Power BI REST API ใช้วิธีการนี้เมื่อคุณต้องการลดความซับซ้อนของการจัดการวงจรชีวิตเนื้อหาด้วยไปป์ไลน์การปรับใช้และคุณมีสิทธิการใช้งานแบบ Premium ตําแหน่งข้อมูล XMLA และไปป์ไลน์การปรับใช้ Power BI เป็นคุณลักษณะแบบพรีเมียม
• Power BI REST API: คุณยังสามารถ นําเข้า เนื้อหาเพื่อพัฒนา ทดสอบ และผลิตพื้นที่ทํางานโดยใช้ Azure DevOps และเฉพาะ Power BI REST API วิธีนี้ไม่จําเป็นต้องมีสิทธิ์การใช้งานระดับพรีเมียม แต่จะเกี่ยวข้องกับความพยายามในการเขียนสคริปต์และการตั้งค่าสูงเนื่องจากการปรับใช้ได้รับการจัดการภายนอก Power BI ใช้วิธีนี้เมื่อคุณต้องการปรับใช้เนื้อหา Power BI จากศูนย์จาก Azure DevOps หรือเมื่อคุณไม่มีสิทธิการใช้งาน Premium สําหรับการเปรียบเทียบภาพระหว่างสองวิธีแรก ดูไปป์ไลน์เผยแพร่จะเข้าถึงไดอะแกรมโฟลว์
• เครื่องมืออัตโนมัติของ Power BI กับไปป์ไลน์การปรับใช้ Power BI: คุณสามารถใช้ส่วนขยาย Azure DevOps เครื่องมืออัตโนมัติของ Power BI เพื่อจัดการไปป์ไลน์การปรับใช้แทน Power BI REST API วิธีการนี้เป็นทางเลือกแรก ซึ่งใช้ Power BI REST API กับไปป์ไลน์การปรับใช้ Power BI ส่วนขยายเครื่องมืออัตโนมัติของ Power BI เป็นเครื่องมือโอเพนซอร์ส (Open Source) ซึ่งช่วยให้คุณจัดการและเผยแพร่เนื้อหาจาก Azure DevOps โดยไม่จําเป็นต้องเขียนสคริปต์ PowerShell ใช้วิธีนี้เมื่อคุณต้องการจัดการไปป์ไลน์การปรับใช้งานจาก Azure DevOps ด้วยความพยายามในการเขียนสคริปต์น้อยที่สุดและคุณมีความจุแบบพรีเมียม

บทความนี้มุ่งเน้นไปที่ตัวเลือกแรก ซึ่งใช้ Power BI REST API กับไปป์ไลน์การปรับใช้ Power BI ซึ่งอธิบายวิธีการที่คุณสามารถใช้ Azure DevOps เพื่อตั้งค่าแนวทางปฏิบัติสําหรับ DevOps นอกจากนี้ยังอธิบายวิธีการที่คุณสามารถใช้ ที่เก็บ Azure สําหรับที่เก็บระยะไกลของคุณ และทําให้การทดสอบเนื้อหา การรวม และการส่งมอบเป็น ไปป์ไลน์ Azure โดยอัตโนมัติ Azure DevOps ไม่ใช่วิธีเดียวที่จะตั้งค่าการเผยแพร่เนื้อหาระดับองค์กร แต่การรวมอย่างง่ายกับ Power BI ทําให้เป็นตัวเลือกที่ดี

หมายเหตุ

สถานการณ์การใช้งานนี้เป็นหนึ่งในสถานการณ์การจัดการเนื้อหาและการปรับใช้ เพื่อความคล่องตัว หัวข้อบางแง่มุมที่อธิบายไว้ในหัวข้อการทํางานร่วมกันของ เนื้อหาและสถานการณ์ การจัดส่งนั้นไม่ครอบคลุมในบทความนี้ สําหรับความครอบคลุมที่สมบูรณ์ ให้อ่านบทความเหล่านั้นก่อน

เคล็ดลับ

Microsoft Fabric มีตัวเลือกอื่น ๆ สําหรับการเผยแพร่เนื้อหาระดับองค์กรโดยใช้ การรวม Fabric Git การรวม Git ช่วยให้คุณเชื่อมโยงพื้นที่ทํางาน Fabric ไปยังสาขาในที่เก็บข้อมูลระยะไกลของ Azure Repos ของคุณ เนื้อหาที่บันทึกไปยังสาขานั้นจะซิงโครไนซ์กับพื้นที่ทํางานโดยอัตโนมัติราวกับว่าเนื้อหานั้นถูกเผยแพร่ไปยังพื้นที่ทํางาน ในทางกลับกัน ผู้สร้างเนื้อหาสามารถยอมรับและส่งการเปลี่ยนแปลงจากพื้นที่ทํางาน Fabric ไปยังที่เก็บระยะไกลได้

การรวม Git สามารถเพิ่มประสิทธิภาพการทํางานร่วมกันและการเผยแพร่เนื้อหา แต่จําเป็นต้องมีการวางแผนเพิ่มเติมสําหรับวิธีที่คุณจะใช้พื้นที่ทํางาน Fabric และกลยุทธ์การโยงหัวข้อของคุณคืออะไร สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการตั้งค่าและใช้การรวม Fabric Git ดู เริ่มต้นใช้งานการรวม Git หรือ บทช่วยสอน: การจัดการวงจรชีวิตสิ้นสุด

ไดอะแกรมสถานการณ์จําลอง

ไดอะแกรมต่อไปนี้แสดงภาพรวมระดับสูงของการดําเนินการของผู้ใช้ทั่วไปส่วนใหญ่และคอมโพเนนต์ Power BI ที่สนับสนุนการเผยแพร่เนื้อหาระดับองค์กร มุ่งเน้นไปที่การใช้ Azure DevOps เพื่อจัดการและเผยแพร่เนื้อหาด้วยการกําหนดโปรแกรมผ่านการพัฒนา การทดสอบ และพื้นที่ทํางานการผลิตในบริการของ Power BI

เคล็ดลับ

เราขอแนะนําให้คุณ ดาวน์โหลดไดอะแกรม สถานการณ์ถ้าคุณต้องการฝังลงในงานนําเสนอ เอกสารหรือบล็อกโพสต์ของคุณ หรือพิมพ์ออกมาเป็นโปสเตอร์บนผนัง เนื่องจากเป็นภาพกราฟิกเวกเตอร์ที่ปรับขนาดได้ (SVG) คุณสามารถปรับขนาดขึ้นหรือลงได้โดยไม่สูญเสียคุณภาพ

ไดอะแกรมสถานการณ์แสดงการดําเนินการ กระบวนการ และคุณลักษณะของผู้ใช้ต่อไปนี้

สินค้า	คำอธิบาย:
	ผู้สร้างเนื้อหาพัฒนาแบบจําลองข้อมูลโดยใช้ Power BI Desktop หรือ Tabular Editor และพวกเขาพัฒนารายงานโดยใช้ Power BI Desktop ผู้สร้างเนื้อหาจะบันทึกงานของพวกเขาไปยังที่เก็บภายในเครื่องในระหว่างการพัฒนา
	ผู้สร้างเนื้อหาสามารถลอกแบบที่เก็บระยะไกลเพื่อรับสําเนาเนื้อหานั้นภายในเครื่องได้
	แหล่งข้อมูลบางแหล่งอาจจําเป็นต้องใช้เกตเวย์ข้อมูลภายในองค์กรหรือเกตเวย์ VNet สําหรับการรีเฟรชข้อมูล เช่นเดียวกับที่อยู่ภายในเครือข่ายส่วนตัว
	ผู้สร้างเนื้อหาจะยอมรับและส่งการเปลี่ยนแปลงไปยังที่เก็บระยะไกลในระหว่างการพัฒนาโดยใช้ไคลเอ็นต์ Git เช่น Visual Studio Code ในแผนภาพ ที่เก็บระยะไกลคือ Azure Repos
	ผู้สร้างเนื้อหาอื่น ๆ ใช้ Azure Repos เพื่อติดตามการเปลี่ยนแปลงด้วยการควบคุมเวอร์ชัน พวกเขาทํางานร่วมกันโดยยอมรับการเปลี่ยนแปลงในสาขาที่แยกต่างหาก
	การเปลี่ยนแปลงเนื้อหาในที่เก็บข้อมูลระยะไกลทริกเกอร์ไปป์ไลน์ Azure ไป ป์ไลน์ การตรวจสอบเป็นไปป์ไลน์แรกที่ทริกเกอร์ ไปป์ไลน์การตรวจสอบจะดําเนินการทดสอบอัตโนมัติเพื่อตรวจสอบเนื้อหาก่อนที่จะเผยแพร่
	เนื้อหาที่ผ่านไปป์ไลน์การตรวจสอบความถูกต้องจะทริกเกอร์ไปป์ไลน์การสร้างที่ตามมา ไปป์ไลน์รุ่นเตรียมเนื้อหาสําหรับการเผยแพร่ไปยังบริการของ Power BI กระบวนการจนถึงจุดนี้มักเรียกว่า การผสานรวม แบบต่อเนื่อง (CI)
	มีการเผยแพร่และปรับใช้เนื้อหาโดยใช้ ไปป์ไลน์การเผยแพร่ ไปป์ไลน์การเผยแพร่ใช้ Power BI REST API หรือจุดสิ้นสุด XMLA ของพื้นที่ทํางานเพื่อนําเข้าเนื้อหาไปยังบริการของ Power BI ทางโปรแกรม การปรับใช้โดยใช้ไปป์ไลน์เผยแพร่โดยทั่วไปจะเรียกว่า การปรับใช้ อย่างต่อเนื่อง (CD)
	ตัวจัดการการวางจําหน่ายจะควบคุมการปรับใช้เพื่อทดสอบและผลิตพื้นที่ทํางานโดยใช้การอนุมัติการเผยแพร่ของ Azure Pipelines ในการเผยแพร่เนื้อหาระดับองค์กร โดยทั่วไปผู้จัดการเผยแพร่จะวางแผนและพิกัดการเผยแพร่เนื้อหาเพื่อทดสอบและใช้งานจริง พวกเขาประสานงานและสื่อสารกับผู้สร้างเนื้อหา ผู้เกี่ยวข้อง และผู้ใช้
	ไปป์ไลน์การเผยแพร่เนื้อหาไปยังพื้นที่ทํางานการพัฒนา หรือเลื่อนระดับเนื้อหาจากการพัฒนาไปยังพื้นที่ทํางานทดสอบหรือทดสอบไปยังพื้นที่ทํางานการผลิต
	ผู้สร้างเนื้อหาที่ทํางานในพื้นที่ทํางานที่มี โหมดสิทธิ์การใช้งาน Fabric สามารถใช้การรวม Git ได้ ด้วยการรวม Git ผู้สร้างเนื้อหาสามารถทํางานในพื้นที่ทํางานส่วนตัวในระหว่างการพัฒนา ผู้สร้างเนื้อหาซิงค์สาขาระยะไกล (โดยทั่วไปจะเป็นสาขาคุณลักษณะเฉพาะหรือสาขาบั๊ก) จาก Azure Repos ไปยังพื้นที่ทํางานส่วนตัวของพวกเขา การเปลี่ยนแปลงเนื้อหาจะถูกซิงโครไนซ์ระหว่างสาขาระยะไกลใน Azure Repos และพื้นที่ทํางาน ในสถานการณ์นี้ ผู้สร้างเนื้อหาไม่จําเป็นต้องใช้ Azure Pipelines เพื่อเผยแพร่เนื้อหา ผู้สร้างเนื้อหายังสามารถยอมรับและส่งการเปลี่ยนแปลงจากพื้นที่ทํางานหลังจากการเผยแพร่อย่างสม่ําเสมอ เมื่อพร้อมแล้ว ผู้สร้างเนื้อหาสามารถทําคําขอดึงข้อมูล (PR) เพื่อผสานการเปลี่ยนแปลงของพวกเขาไปยังสาขาหลักได้
	เมื่อใช้การรวม Git พื้นที่ทํางานการพัฒนาจะซิงค์กับสาขาหลักเพื่อรับเนื้อหาเวอร์ชันล่าสุด เนื้อหานี้รวมถึงการเปลี่ยนแปลงทั้งหมดจากคําขอดึงข้อมูลที่ผู้จัดการเผยแพร่ตรวจทาน อนุมัติ และผสาน
	พื้นที่ทํางานถูกตั้งค่าเป็นความจุ Fabric, ความจุพรีเมียม, Premium ต่อผู้ใช้ หรือโหมดสิทธิ์การใช้งานแบบฝังตัว เพื่ออนุญาตให้ใช้ไปป์ไลน์การปรับใช้ Power BI และตําแหน่งข้อมูลการอ่าน/เขียน XMLA
	ผู้ดูแลระบบไปป์ไลน์การปรับใช้ตั้งค่าไปป์ไลน์การปรับใช้ Power BI ที่มีสามขั้นตอน: การพัฒนา การทดสอบ และการผลิต แต่ละลําดับขั้นจะจัดแนวเป็นพื้นที่ทํางานแยกต่างหากในบริการของ Power BI มีการตั้งค่าและการเข้าถึงการปรับใช้สําหรับไปป์ไลน์การปรับใช้
	พื้นที่ทํางานการพัฒนาประกอบด้วยเนื้อหาเวอร์ชันล่าสุด รวมถึงการเปลี่ยนแปลงที่ได้รับอนุมัติและผสานทั้งหมด เมื่อได้รับอนุมัติ ไปป์ไลน์เผยแพร่จะปรับใช้เนื้อหาจากการพัฒนาไปยังพื้นที่ทํางานทดสอบ
	ผู้ตรวจสอบภายในพื้นที่ทํางานทดสอบทําการทดสอบและรับประกันคุณภาพเนื้อหา เมื่อได้รับอนุมัติ ไปป์ไลน์เผยแพร่จะปรับใช้เนื้อหาจากการทดสอบไปยังพื้นที่ทํางานการผลิต เมื่อใช้การรวม Git กับไปป์ไลน์การปรับใช้ พื้นที่ทํางานการทดสอบจะไม่ซิงค์กับสาขาใด ๆ
	หลังจากไปป์ไลน์การปรับใช้เสร็จสิ้น ผู้สร้างเนื้อหาจะทํากิจกรรมหลังการปรับใช้ด้วยตนเอง กิจกรรมสามารถรวมถึงการตั้งค่าการรีเฟรชข้อมูลตามกําหนดการหรือการอัปเดตแอป Power BI สําหรับพื้นที่ทํางานการผลิต เมื่อใช้การรวม Git กับไปป์ไลน์การปรับใช้ พื้นที่ทํางานการผลิตจะไม่ซิงค์กับสาขาใด ๆ
	ผู้ชมเนื้อหาเข้าถึงเนื้อหาโดยใช้พื้นที่ทํางานการผลิตหรือแอป Power BI

เคล็ดลับ

เราขอแนะนําให้คุณตรวจทาน สถานการณ์การใช้งานการ เผยแพร่เนื้อหาแบบบริการตนเองและ การจัดการ แบบจําลองข้อมูลขั้นสูง สถานการณ์การใช้งานการเผยแพร่เนื้อหาระดับองค์กรจะสร้างตามแนวคิดที่สถานการณ์เหล่านี้แนะนํา

ประเด็นสําคัญ

ต่อไปนี้คือประเด็นสําคัญบางประการที่ต้องเน้นเกี่ยวกับสถานการณ์การเผยแพร่เนื้อหาระดับองค์กร

การควบคุมเวอร์ชัน

การติดตามการเปลี่ยนแปลงในระหว่างวงจรชีวิตเนื้อหาเป็นสิ่งสําคัญเพื่อให้มั่นใจว่าการจัดส่งเนื้อหาไปยังผู้บริโภคมีเสถียรภาพและสอดคล้องกัน ในสถานการณ์การใช้งานนี้ ผู้สร้างและเจ้าของเนื้อหาจะจัดการการเปลี่ยนแปลงเนื้อหาในที่เก็บระยะไกลโดยใช้ การควบคุมเวอร์ชัน การควบคุมเวอร์ชันคือแนวทางปฏิบัติในการจัดการการเปลี่ยนแปลงไฟล์หรือโค้ดในที่เก็บส่วนกลาง แนวทางปฏิบัตินี้ช่วยให้การทํางานร่วมกันและการจัดการประวัติเวอร์ชันมีประสิทธิภาพยิ่งขึ้น การควบคุมเวอร์ชันมีข้อดีสําหรับผู้สร้างเนื้อหา รวมถึงความสามารถในการย้อนกลับหรือผสานการเปลี่ยนแปลง

โดยทั่วไปผู้สร้างเนื้อหาจะพัฒนาแบบจําลองข้อมูลในตัวแก้ไขตารางเพื่อสนับสนุนการควบคุมเวอร์ชันที่ดีขึ้น แตกต่างจากแบบจําลองข้อมูลที่คุณพัฒนาใน Power BI Desktop แบบจําลองข้อมูลที่พัฒนาขึ้นในตัว แก้ไข ตารางจะถูกบันทึกในรูปแบบเมตาดาต้าที่มนุษย์สามารถอ่านได้ รูปแบบนี้จะเปิดใช้งานการควบคุมเวอร์ชันระดับออบเจ็กต์ของแบบจําลองข้อมูล คุณควรใช้การควบคุมเวอร์ชันระดับออบเจ็กต์เมื่อทํางานร่วมกับหลายคนในแบบจําลองข้อมูลเดียวกัน สําหรับข้อมูลเพิ่มเติม โปรดดู สถานการณ์การใช้งานการจัดการ แบบจําลองข้อมูลขั้นสูง ไม่สามารถดูการเปลี่ยนแปลงที่คุณทําในไฟล์ Power BI Desktop (.pbix) เช่น ข้อกําหนดของรายงานหรือแบบจําลองข้อมูล ตัวอย่างเช่น คุณไม่สามารถติดตามการเปลี่ยนแปลงไปยังหน้ารายงาน เช่น วิชวลที่ใช้ ตําแหน่งของวิชวล และการแมปเขตข้อมูลหรือการจัดรูปแบบ

ผู้สร้างเนื้อหาจะจัดเก็บไฟล์เมตาดาต้าและไฟล์ .pbix ในที่เก็บระยะไกลส่วนกลาง เช่น ที่เก็บ Azure ไฟล์เหล่านี้ได้รับการรวบรวมโดย เจ้าของทางเทคนิค ในขณะที่ผู้สร้างเนื้อหาพัฒนาโซลูชัน เจ้าของทางเทคนิคมีหน้าที่จัดการโซลูชัน และตรวจสอบการเปลี่ยนแปลง และผสานเข้ากับโซลูชันเดียว Azure Repos มีตัวเลือกที่ซับซ้อนสําหรับการติดตามและจัดการการเปลี่ยนแปลง วิธีการนี้แตกต่างจากวิธีการที่อธิบายไว้ใน สถานการณ์การใช้งานการ เผยแพร่เนื้อหาแบบบริการตนเอง ซึ่งผู้สร้างใช้ที่เก็บข้อมูล OneDrive พร้อมการติดตามเวอร์ชัน การรักษาที่เก็บข้อมูลที่รวบรวมอย่างดีและจัดทําเป็นเอกสารเป็นสิ่งจําเป็นเนื่องจากเป็นรากฐานของเนื้อหาและการทํางานร่วมกันทั้งหมด

ต่อไปนี้คือข้อควรพิจารณาหลักบางประการเพื่อช่วยให้คุณตั้งค่าที่เก็บระยะไกลสําหรับการควบคุมเวอร์ชัน

• ขอบเขต: กําหนดขอบเขตของที่เก็บอย่างชัดเจน ตามหลักแล้ว ขอบเขตของที่เก็บจะเหมือนกับขอบเขตของพื้นที่ทํางานและแอปปลายทางที่คุณใช้ในการส่งเนื้อหาไปยังผู้บริโภค
• การเข้าถึง: คุณควรตั้งค่าการเข้าถึงที่เก็บข้อมูลโดยใช้แบบจําลองสิทธิ์ที่คล้ายกันตามที่คุณได้ตั้งค่าสําหรับสิทธิ์ไปป์ไลน์การปรับใช้และบทบาทพื้นที่ทํางานของคุณ ผู้สร้างเนื้อหาจําเป็นต้องเข้าถึงที่เก็บ
• เอกสาร: เพิ่มไฟล์ข้อความไปยังที่เก็บเพื่อจัดทําเอกสารวัตถุประสงค์ ความเป็นเจ้าของ การเข้าถึง และกระบวนการที่กําหนดไว้ ตัวอย่างเช่น เอกสารสามารถอธิบายว่าควรดําเนินการเปลี่ยนแปลงอย่างไรและยืนยันการเปลี่ยนแปลงอย่างไร
• เครื่องมือ: เพื่อบันทึกและส่งการเปลี่ยนแปลงไปยังที่เก็บระยะไกล ผู้สร้างเนื้อหาต้องมีไคลเอ็นต์ Git เช่น Visual Studio หรือ Visual Studio Code Git เป็นระบบควบคุมเวอร์ชันแบบกระจายที่ติดตามการเปลี่ยนแปลงในไฟล์ของคุณ หากต้องการเรียนรู้พื้นฐานของ Git โปรดดู Git คืออะไร

หมายเหตุ

พิจารณาใช้ Git Large File Storage (LFS) ถ้าคุณวางแผนที่จะยอมรับไฟล์ Power BI Desktop (.pbix) Git LFS มีตัวเลือกขั้นสูงสําหรับการจัดการไฟล์ที่ไม่สามารถมองเห็นการเปลี่ยนแปลงได้ (ไฟล์ที่ไม่สามารถแยกแยกันได้ ) เช่น ไฟล์ .pbix ตัวอย่างเช่น คุณสามารถใช้ การ ล็อกไฟล์เพื่อป้องกันการเปลี่ยนแปลงที่เกิดขึ้นพร้อมกันกับรายงาน Power BI ในระหว่างการพัฒนาได้ อย่างไรก็ตาม Git LFS มีไคลเอ็นต์และการกําหนดค่าของตัวเอง

การทํางานร่วมกันกับ Azure DevOps

เมื่อโซลูชันเพิ่มขอบเขตและความซับซ้อน อาจจําเป็นสําหรับผู้สร้างและเจ้าของเนื้อหาหลายคนให้ทํางานร่วมกัน ผู้สร้างและเจ้าของเนื้อหาสื่อสารและทํางานร่วมกันในฮับที่เป็นศูนย์กลางที่ได้รับการจัดการโดยใช้ Azure DevOps

หากต้องการทํางานร่วมกันและสื่อสารใน Azure DevOps คุณต้องใช้บริการสนับสนุน

• บอร์ด Azure: เจ้าของเนื้อหาใช้บอร์ดเพื่อติดตาม รายการงาน รายการงานแต่ละอย่างจะถูกกําหนดให้กับนักพัฒนารายเดียวในทีม และพวกเขาอธิบายถึงปัญหา ข้อบกพร่อง หรือคุณลักษณะในโซลูชัน และผู้มีส่วนได้เสียที่เกี่ยวข้อง
• Azure Wiki: ผู้สร้างเนื้อหาแชร์ข้อมูลกับทีมของพวกเขาเพื่อทําความเข้าใจและมีส่วนร่วมในโซลูชัน
• Azure Repos: ผู้สร้างเนื้อหาจะติดตามการเปลี่ยนแปลงในที่เก็บระยะไกลและผสานลงในโซลูชันเดียว
• Azure Pipelines: เจ้าของไปป์ไลน์ตั้งค่าตรรกะทางโปรแกรมเพื่อปรับใช้โซลูชันโดยอัตโนมัติหรือตามต้องการ

ไดอะแกรมโฟลว์การทํางานร่วมกัน

แผนภาพต่อไปนี้แสดงภาพรวมระดับสูงของตัวอย่างหนึ่งที่แสดงให้เห็นว่า Azure DevOps ช่วยให้ทํางานร่วมกันในสถานการณ์การใช้งานของการเผยแพร่เนื้อหาระดับองค์กรได้อย่างไร จุดมุ่งเน้นของแผนภาพนี้คือการใช้ Azure DevOps เพื่อสร้างกระบวนการเผยแพร่เนื้อหาที่มีโครงสร้างและเป็นเอกสาร

ไดอะแกรมแสดงการดําเนินการ กระบวนการ และคุณลักษณะของผู้ใช้ต่อไปนี้

สินค้า	คำอธิบาย:
	ผู้สร้างเนื้อหาสร้างสาขาใหม่ที่ถ่ายทอดสดสั้นโดยการลอกแบบสาขาหลักซึ่งประกอบด้วยเนื้อหาเวอร์ชันล่าสุด สาขาใหม่มักจะเรียกว่า สาขาคุณลักษณะ เนื่องจากใช้เพื่อพัฒนาคุณลักษณะเฉพาะหรือแก้ไขปัญหาเฉพาะ
	ผู้สร้างเนื้อหาจะบันทึกการเปลี่ยนแปลงไปยังที่เก็บภายในเครื่องในระหว่างการพัฒนา
	ผู้สร้างเนื้อหาเชื่อมโยงการเปลี่ยนแปลงของพวกเขากับรายการงานที่ได้รับการจัดการใน Azure Boards รายการงานจะอธิบายการพัฒนา การปรับปรุง หรือการแก้ไขข้อบกพร่องที่เฉพาะเจาะจงตามขอบเขตของสาขา
	ผู้สร้างเนื้อหาจะยอมรับการเปลี่ยนแปลงของตนเองเป็นประจํา เมื่อพร้อมแล้ว ผู้สร้างเนื้อหาจะเผยแพร่สาขาของตนไปยังที่เก็บระยะไกล
	เมื่อต้องทดสอบการเปลี่ยนแปลงของพวกเขา ผู้สร้างเนื้อหาจะใช้โซลูชันของตนกับพื้นที่ทํางานแยกต่างหากสําหรับการพัฒนาของพวกเขา (ไม่แสดงในแผนภาพนี้) ผู้สร้างเนื้อหายังสามารถซิงค์สาขาคุณลักษณะไปยังพื้นที่ทํางานโดยใช้การรวม Fabric Git
	ผู้สร้างเนื้อหาและเจ้าของเนื้อหาทําเอกสารเกี่ยวกับโซลูชันและกระบวนการใน Azure Wiki ซึ่งพร้อมใช้งานสําหรับทีมพัฒนาทั้งหมด
	เมื่อพร้อมแล้ว ผู้สร้างเนื้อหาจะเปิดคําขอดึงข้อมูลเพื่อผสานสาขาคุณลักษณะลงในสาขาหลัก
	เจ้าของทางเทคนิคมีหน้าที่รับผิดชอบในการตรวจสอบคําขอดึงข้อมูลและผสานการเปลี่ยนแปลง เมื่อพวกเขาอนุมัติคําขอดึงข้อมูล พวกเขาจะรวมสาขาคุณลักษณะลงในสาขาหลัก
	การผสานที่สําเร็จจะทริกเกอร์การปรับใช้โซลูชันไปยังพื้นที่ทํางานการพัฒนาโดยใช้ Azure Pipeline (ไม่แสดงในแผนภาพนี้) เมื่อใช้การรวม Fabric Git สาขาหลักจะซิงค์กับพื้นที่ทํางานการพัฒนา
	ผู้จัดการเผยแพร่ทําการตรวจทานขั้นสุดท้ายและอนุมัติโซลูชัน การอนุมัติการเผยแพร่นี้จะป้องกันไม่ให้มีการเผยแพร่โซลูชันก่อนที่จะพร้อม ในการเผยแพร่เนื้อหาระดับองค์กร โดยทั่วไปแล้ว ผู้จัดการฝ่ายเผยแพร่จะวางแผนและประสานงานการเผยแพร่เนื้อหาเพื่อทดสอบและผลิตพื้นที่ทํางาน พวกเขาประสานงานและสื่อสารกับผู้สร้างเนื้อหา ผู้เกี่ยวข้อง และผู้ใช้
	เมื่อผู้จัดการเผยแพร่อนุมัติการเผยแพร่ Azure Pipelines จะจัดเตรียมโซลูชันสําหรับการปรับใช้โดยอัตโนมัติ อีกวิธีหนึ่งคือ Azure Pipeline ยังสามารถทริกเกอร์ไปป์ไลน์การปรับใช้เพื่อเลื่อนระดับเนื้อหาระหว่างพื้นที่ทํางาน
	ผู้ใช้ทดสอบและตรวจสอบเนื้อหาในพื้นที่ทํางานทดสอบ เมื่อใช้การรวม Git กับ Azure Pipelines สําหรับการปรับใช้ พื้นที่ทํางานการทดสอบจะไม่ซิงค์กับทุกสาขา
	หลังจากที่ผู้ใช้ยอมรับและตรวจสอบการเปลี่ยนแปลงแล้ว ผู้จัดการฝ่ายเผยแพร่จะทําการตรวจสอบและอนุมัติโซลูชันขั้นสุดท้ายเพื่อปรับใช้กับพื้นที่ทํางานการผลิต
	ผู้ใช้ดูเนื้อหาที่เผยแพร่ไปยังพื้นที่ทํางานการผลิต เมื่อใช้การรวม Git กับ Azure Pipelines สําหรับการปรับใช้ พื้นที่ทํางานการผลิตจะไม่ซิงค์กับทุกสาขา

เพื่ออธิบายให้ละเอียด ผู้สร้างเนื้อหาสามารถทํางานร่วมกันได้โดยใช้ กลยุทธ์การแบ่งสาขา กลยุทธ์การแยกสาขาคือวิธีการที่ผู้สร้างเนื้อหาสร้าง ใช้ และผสานสาขาเพื่อให้สร้างและจัดการการเปลี่ยนแปลงเนื้อหาได้อย่างมีประสิทธิภาพ ผู้สร้างเนื้อหาแต่ละคนทํางานแยกจากกันในที่เก็บภายในเครื่องของพวกเขา เมื่อพร้อมแล้ว พวกเขาจะรวมการเปลี่ยนแปลงของพวกเขาเป็นโซลูชันเดียวในที่เก็บระยะไกล ผู้สร้างเนื้อหาควรกําหนดขอบเขตงานของตนไปยังสาขาโดยการเชื่อมโยงไปยังรายการงานสําหรับการพัฒนา การปรับปรุง หรือการแก้ไขข้อบกพร่องที่เฉพาะเจาะจง ผู้สร้างเนื้อหาแต่ละคนจะสร้างสาขาของตนเองในที่เก็บข้อมูลระยะไกลสําหรับขอบเขตงานของพวกเขา การทํางานเสร็จสิ้นบนโซลูชันภายในเครื่องของพวกเขาได้รับการบันทึกและส่งไปยังเวอร์ชันของสาขาในที่เก็บระยะไกลด้วย ข้อความยืนยัน ข้อความที่ยอมรับจะอธิบายการเปลี่ยนแปลงที่ทําในที่ยอมรับ

ในการผสานการเปลี่ยนแปลง ผู้สร้างเนื้อหาจะ เปิดคําขอดึงข้อมูล คําขอดึงข้อมูลคือการส่งการตรวจสอบแบบเพียร์ที่สามารถนําไปสู่การผสานงานที่ทําเป็นโซลูชันเดียว การผสานอาจส่งผลให้เกิดข้อขัดแย้งซึ่งต้องได้รับการแก้ไขก่อนการผสานสาขา การตรวจสอบคําขอดึงข้อมูลเป็นสิ่งสําคัญเพื่อให้แน่ใจว่าผู้สร้างปฏิบัติตามมาตรฐานและแนวทางปฏิบัติขององค์กรสําหรับการพัฒนา คุณภาพ และการปฏิบัติตามข้อกําหนด

คําแนะนําการทํางานร่วมกัน

เราขอแนะนําให้คุณกําหนดกระบวนการที่มีโครงสร้างสําหรับวิธีที่ผู้สร้างเนื้อหาควรทํางานร่วมกัน ตรวจสอบให้แน่ใจว่าคุณกําหนด:

• วิธีการทํางานกําหนดขอบเขตและวิธีสร้าง ตั้งชื่อ และใช้สาขา
• วิธีการที่ผู้เขียนจัดกลุ่มเปลี่ยนแปลงและอธิบายการเปลี่ยนแปลงเหล่านั้นด้วยข้อความที่ยอมรับ
• ใครรับผิดชอบในการตรวจสอบและอนุมัติคําขอดึงข้อมูล
• วิธีการแก้ไขข้อขัดแย้งการผสาน
• การเปลี่ยนแปลงในสาขาต่างๆ จะรวมกันเป็นสาขาเดียวอย่างไร
• วิธีทดสอบเนื้อหาและผู้ที่ดําเนินการทดสอบก่อนปรับใช้เนื้อหา
• วิธีการและเวลาที่มีการปรับใช้การเปลี่ยนแปลงในพื้นที่ทํางานการพัฒนาการทดสอบและการผลิต
• ควรย้อนกลับการเปลี่ยนแปลงหรือเวอร์ชันของโซลูชันที่ปรับใช้อย่างไรและเมื่อใด

สำคัญ

ค่าที่กําหนดโดย DevOps เป็นสัดส่วนโดยตรงกับการยึดมั่นในกระบวนการที่กําหนดการใช้งาน

การทํางานร่วมกันที่ประสบความสําเร็จขึ้นอยู่กับกระบวนการที่กําหนดไว้อย่างดี สิ่งสําคัญคือต้องอธิบายและจัดทําเอกสารเวิร์กโฟลว์การพัฒนาแบบครบวงจรอย่างชัดเจน ตรวจสอบให้แน่ใจว่ากลยุทธ์และกระบวนการที่เลือกสอดคล้องกับแนวทางปฏิบัติที่มีอยู่ในทีมของคุณ และหากไม่เป็นเช่นนั้น คุณจะจัดการการเปลี่ยนแปลงได้อย่างไร นอกจากนี้ ตรวจสอบให้แน่ใจว่ากระบวนการมีความชัดเจนและสื่อสารกับสมาชิกในทีมและผู้เกี่ยวข้องทั้งหมด ตรวจสอบให้แน่ใจว่าสมาชิกทีมและผู้มีส่วนได้เสียที่ยังใหม่กับกระบวนการได้รับการฝึกฝนเกี่ยวกับวิธีการนํามาใช้และพวกเขาชื่นชมกับค่าของการนํา DevOps ที่ประสบความสําเร็จมาใช้

Power BI REST API

คุณพัฒนาตรรกะทางโปรแกรมเพื่อนําเข้าและปรับใช้เนื้อหาจาก Azure DevOps โดยใช้ Power BI REST API คุณนําเข้าไฟล์ Power BI (.pbix) ไปยังพื้นที่ทํางานโดยใช้ การดําเนินการนําเข้า คุณใช้การดําเนินการไปป์ไลน์เพื่อปรับใช้เนื้อหาบางส่วนหรือเนื้อหาทั้งหมดเพื่อทดสอบหรือพื้นที่ทํางานการผลิตโดยใช้ไปป์ไลน์การปรับใช้ Power BI ตรรกะทางโปรแกรมจะถูกกําหนดไว้ในไปป์ไลน์ Azure

เราขอแนะนําให้คุณใช้ โครงร่างสําคัญ ของบริการเพื่อเรียกใช้ Power BI REST API ในไปป์ไลน์ของคุณ โครงร่างสําคัญของบริการมีไว้สําหรับกิจกรรมอัตโนมัติอัตโนมัติและไม่ได้ใช้ข้อมูลประจําตัวผู้ใช้ อย่างไรก็ตาม บางรายการและกิจกรรม บางอย่างไม่ได้รับการสนับสนุนโดย Power BI REST API หรือเมื่อใช้โครงร่างสําคัญของบริการ เช่น กระแสข้อมูล

เมื่อคุณใช้บริการหลัก ตรวจสอบให้แน่ใจว่าได้จัดการสิทธิ์อย่างระมัดระวัง เป้าหมายของคุณควรที่จะปฏิบัติตามหลักการของ สิทธิ์พิเศษน้อยที่สุด คุณควรตั้งค่าสิทธิ์ที่เพียงพอสําหรับโครงร่างสําคัญของบริการโดยไม่จัดเตรียมสิทธิ์มากเกินไป ใช้ Azure Key Vault หรือบริการอื่นที่จัดเก็บข้อมูลลับและข้อมูลประจําตัวของโครงร่างสําคัญของบริการได้อย่างปลอดภัย

ข้อควรระวัง

ถ้าคุณมีแบบจําลองข้อมูลที่ถูกบันทึกเป็นรูปแบบเมตาดาต้าที่มนุษย์สามารถอ่านได้ จะไม่สามารถเผยแพร่โดยใช้ Power BI REST API ได้ แต่คุณต้องเผยแพร่โดยใช้ตําแหน่งข้อมูล XMLA คุณสามารถเผยแพร่ไฟล์เมตาดาต้าได้โดยใช้เครื่องมือของบุคคลที่สาม เช่น อินเทอร์เฟซบรรทัดคําสั่งสําหรับตัวแก้ไขตาราง (CLI) คุณยังสามารถเผยแพร่ไฟล์เมตาดาต้าด้วยการเขียนโปรแกรมโดยใช้การพัฒนา .NET แบบกําหนดเองของคุณเอง การพัฒนาโซลูชันแบบกําหนดเองต้องใช้ความพยายามมากขึ้น เนื่องจากคุณต้องใช้ส่วนขยาย Microsoft Tabular Object Model (TOM) ของไลบรารีวัตถุ Analysis Management (AMO)

Azure Pipelines

Azure Pipelines ทําให้การทดสอบ การจัดการ และการปรับใช้เนื้อหาเป็นไปโดยอัตโนมัติทางโปรแกรม เมื่อมีการเรียกใช้ไปป์ไลน์ ขั้นตอนในไปป์ไลน์จะดําเนินการโดยอัตโนมัติ เจ้าของไปป์ไลน์สามารถกําหนดทริกเกอร์ ขั้นตอน และฟังก์ชันการทํางานเพื่อตอบสนองความต้องการในการปรับใช้ ดังนั้น จํานวนและชนิดของไปป์ไลน์จะแตกต่างกันไปขึ้นอยู่กับข้อกําหนดของโซลูชัน ตัวอย่างเช่น Azure Pipeline สามารถเรียกใช้การทดสอบอัตโนมัติหรือปรับเปลี่ยนพารามิเตอร์แบบจําลองข้อมูลก่อนการปรับใช้

ไปป์ไลน์ Azure มีสามประเภทที่คุณสามารถตั้งค่าเพื่อทดสอบ จัดการ และปรับใช้โซลูชัน Power BI ของคุณ:

• การตรวจสอบความถูกต้องของไปป์ไลน์
• สร้างไปป์ไลน์
• เผยแพร่ไปป์ไลน์

หมายเหตุ

ไม่จําเป็นต้องมีทั้งสามไปป์ไลน์เหล่านี้ในโซลูชันการเผยแพร่ของคุณ ขึ้นอยู่กับเวิร์กโฟลว์และความต้องการของคุณ คุณอาจตั้งค่าตัวแปรอย่างน้อยหนึ่งรายการของไปป์ไลน์ที่อธิบายไว้ในบทความนี้เพื่อทําให้การเผยแพร่เนื้อหาเป็นแบบอัตโนมัติ ความสามารถในการกําหนดค่าไปป์ไลน์นี้เป็นข้อดีของไปป์ไลน์ Azure ผ่านไปป์ไลน์การปรับใช้ Power BI ที่มีอยู่ภายใน ตัวอย่างเช่น คุณไม่จําเป็นต้องมีไปป์ไลน์การตรวจสอบความถูกต้อง คุณสามารถใช้ได้เฉพาะไปป์ไลน์สร้างและเผยแพร่เท่านั้น

การตรวจสอบความถูกต้องของไปป์ไลน์

ไปป์ไลน์การตรวจสอบความถูกต้องทําการตรวจสอบคุณภาพพื้นฐานของแบบจําลองข้อมูลก่อนที่จะเผยแพร่ไปยังพื้นที่ทํางานการพัฒนา โดยทั่วไปการเปลี่ยนแปลงในสาขาของที่เก็บระยะไกลจะทริกเกอร์ไปป์ไลน์เพื่อตรวจสอบการเปลี่ยนแปลงเหล่านั้นด้วยการทดสอบอัตโนมัติ

ตัวอย่างของการทดสอบอัตโนมัติรวมถึงการสแกนแบบจําลองข้อมูลสําหรับการละเมิดกฎแนวทางปฏิบัติที่ดีที่สุดโดยใช้ Best Practice Analyzer (BPA) หรือโดยการเรียกใช้คิวรี DAX กับแบบจําลองความหมายที่เผยแพร่ จากนั้นผลลัพธ์ของการทดสอบเหล่านี้จะถูกเก็บไว้ในที่เก็บระยะไกลสําหรับเอกสารและวัตถุประสงค์การตรวจสอบ ไม่ควรเผยแพร่แบบจําลองข้อมูลที่ล้มเหลวในการตรวจสอบความถูกต้อง แต่ไปป์ไลน์ควรแจ้งผู้สร้างเนื้อหาเกี่ยวกับปัญหา

สร้างไปป์ไลน์

สร้างไปป์ไลน์เตรียมแบบจําลองข้อมูลสําหรับการเผยแพร่ไปยังบริการของ Power BI ไปป์ไลน์เหล่านี้รวมเมตาดาต้าแบบจําลองอนุกรมไว้ในไฟล์เดียวที่เผยแพร่ในภายหลังโดยไปป์ไลน์การเผยแพร่ (อธิบายไว้ในไดอะแกรมไปป์ไลน์การเผยแพร่) ไปป์ไลน์รุ่นยังสามารถทําการเปลี่ยนแปลงอื่น ๆ ในเมตาดาต้า เช่น การปรับเปลี่ยนค่าพารามิเตอร์ ไปป์ไลน์รุ่นสร้างอาร์ทิแฟกต์การปรับใช้ที่ประกอบด้วยเมตาดาต้าแบบจําลองข้อมูล (สําหรับแบบจําลองข้อมูล) และไฟล์ Power BI Desktop (.pbix) ที่พร้อมสําหรับการเผยแพร่ไปยังบริการของ Power BI

เผยแพร่ไปป์ไลน์

เผยแพร่ไปป์ไลน์เผยแพร่หรือปรับใช้เนื้อหา โดยทั่วไปโซลูชันการเผยแพร่จะประกอบด้วยไปป์ไลน์การเผยแพร่หลายรายการ โดยขึ้นอยู่กับสภาพแวดล้อมเป้าหมาย

• ไปป์ไลน์การพัฒนา: ไปป์ไลน์แรกนี้จะถูกทริกเกอร์โดยอัตโนมัติ ซึ่งจะเผยแพร่เนื้อหาไปยังพื้นที่ทํางานการพัฒนาหลังจากไปป์ไลน์การสร้างและการตรวจสอบความถูกต้องประสบความสําเร็จ
• ทดสอบและเผยแพร่การผลิตไปป์ไลน์: ไปป์ไลน์เหล่านี้จะไม่ถูกทริกเกอร์โดยอัตโนมัติ แต่จะถูกทริกเกอร์ตามคําขอหรือเมื่อได้รับอนุมัติ ทดสอบและเผยแพร่การผลิตไปป์ไลน์ปรับใช้เนื้อหาไปยังการทดสอบหรือพื้นที่ทํางานการผลิตตามลําดับหลังจาก อนุมัติการเผยแพร่ การอนุมัติ การเผยแพร่ทําให้แน่ใจว่าเนื้อหาไม่ได้ถูกปรับใช้ไปยังขั้นตอนการทดสอบหรือการผลิตโดยอัตโนมัติก่อนที่จะพร้อม การอนุมัติเหล่านี้มีให้โดยผู้จัดการวางจําหน่ายซึ่งมีหน้าที่วางแผนและประสานงานการเผยแพร่เนื้อหาเพื่อทดสอบและผลิตสภาพแวดล้อม

มีสองวิธีที่แตกต่างกันในการเผยแพร่เนื้อหาด้วยไปป์ไลน์ทดสอบและเผยแพร่ ไม่ว่าจะเลื่อนระดับเนื้อหาโดยใช้ไปป์ไลน์การปรับใช้ Power BI หรือเผยแพร่เนื้อหาไปยังบริการของ Power BI จาก Azure DevOps

ไดอะแกรมต่อไปนี้แสดงวิธีการแรก ในแนวทางนี้ ให้เผยแพร่ไปป์ไลน์หรือปรับใช้เนื้อหาเพื่อทดสอบและผลิตพื้นที่ทํางานโดยใช้ไปป์ไลน์การปรับใช้ Power BI เนื้อหาได้รับการเลื่อนระดับผ่านพื้นที่ทํางานการพัฒนา การทดสอบ และการผลิตใน Power BI แม้ว่าวิธีการนี้จะมีประสิทธิภาพและง่ายต่อการบํารุงรักษามากกว่า แต่ต้องใช้สิทธิการใช้งานระดับพรีเมียม

ไดอะแกรมแสดงการดําเนินการ กระบวนการ และคุณลักษณะของผู้ใช้ต่อไปนี้ของวิธีการแรก

สินค้า	คำอธิบาย:
	ในวิธีแรก ไปป์ไลน์การเผยแพร่เนื้อหาโดยใช้ตําแหน่งข้อมูล XMLA และ Power BI REST API กับไปป์ไลน์การปรับใช้ Power BI เนื้อหาได้รับการเผยแพร่และเลื่อนระดับผ่านพื้นที่ทํางานการพัฒนา การทดสอบ และการผลิต ไปป์ไลน์การปรับใช้ Power BI และตําแหน่งข้อมูลการอ่าน/เขียน XMLA เป็น คุณลักษณะพรีเมียม
	การผสานสาขาที่สําเร็จหรือการเสร็จสิ้นของไปป์ไลน์อัพสตรีมจะทริกเกอร์ไปป์ไลน์การสร้าง จากนั้น ไปป์ไลน์สร้างจะเตรียมเนื้อหาสําหรับการเผยแพร่และทริกเกอร์ไปป์ไลน์รุ่นการพัฒนา
	ไปป์ไลน์การเผยแพร่การพัฒนาจะเผยแพร่เนื้อหาไปยังพื้นที่ทํางานการพัฒนาโดยใช้ตําแหน่งข้อมูล XMLA (สําหรับเมตาดาต้าแบบจําลองข้อมูล) หรือ Power BI REST API (สําหรับไฟล์ Power BI Desktop ซึ่งสามารถประกอบด้วยแบบจําลองข้อมูลและรายงาน) ไปป์ไลน์การพัฒนาใช้อินเทอร์เฟซบรรทัดคําสั่ง (CLI) ตัวแก้ไขตาราง (CLI) เพื่อปรับใช้เมตาดาต้าแบบจําลองข้อมูลโดยใช้ตําแหน่งข้อมูล XMLA
	การอนุมัติการเผยแพร่หรือทริกเกอร์ตามความต้องการจะเปิดใช้งานไปป์ไลน์ทดสอบการเผยแพร่
	ไปป์ไลน์การเผยแพร่การทดสอบจะปรับใช้เนื้อหาโดยใช้การดําเนินการปรับใช้ Power BI REST API ซึ่งเรียกใช้ไปป์ไลน์การปรับใช้ Power BI
	ไปป์ไลน์การปรับใช้ Power BI เลื่อนระดับเนื้อหาจากพื้นที่ทํางานการพัฒนาไปยังพื้นที่ทํางานทดสอบ หลังจากการปรับใช้ ไปป์ไลน์เผยแพร่จะดําเนินการกิจกรรมหลังการปรับใช้โดยใช้ Power BI REST API (ไม่แสดงในแผนภาพ)
	การอนุมัติการเผยแพร่หรือทริกเกอร์ตามความต้องการจะเปิดใช้งานไปป์ไลน์เผยแพร่การผลิต
	ไปป์ไลน์เผยแพร่การผลิตจะปรับใช้เนื้อหาโดยใช้การดําเนินการปรับใช้ Power BI REST API ซึ่งเรียกใช้ไปป์ไลน์การปรับใช้ Power BI
	ไปป์ไลน์การปรับใช้ Power BI เลื่อนระดับเนื้อหาจากพื้นที่ทํางานทดสอบไปยังพื้นที่ทํางานการผลิต หลังจากการปรับใช้ ไปป์ไลน์เผยแพร่จะดําเนินการกิจกรรมหลังการปรับใช้โดยใช้ Power BI REST API (ไม่แสดงในแผนภาพ)

แผนภาพต่อไปนี้แสดงวิธีการที่สอง วิธีการนี้ไม่ได้ใช้ไปป์ไลน์การปรับใช้ แต่จะใช้ไปป์ไลน์การเผยแพร่เพื่อเผยแพร่เนื้อหาเพื่อทดสอบและผลิตพื้นที่ทํางานจาก Azure DevOps โดยเฉพาะอย่างยิ่ง วิธีที่สองนี้ไม่จําเป็นต้องมีการให้สิทธิ์การใช้งาน Premium เมื่อคุณเผยแพร่เฉพาะไฟล์ Power BI Desktop ด้วย Power BI REST API ซึ่งเกี่ยวข้องกับความพยายามในการตั้งค่าและความซับซ้อนมากขึ้นเนื่องจากคุณต้องจัดการการปรับใช้ภายนอก Power BI ทีมพัฒนาที่ใช้ DevOps อยู่แล้วสําหรับโซลูชันข้อมูลภายนอก Power BI อาจคุ้นเคยกับวิธีนี้มากขึ้น ทีมพัฒนาที่ใช้วิธีนี้สามารถรวมการปรับใช้โซลูชันข้อมูลใน Azure DevOps

แผนภาพแสดงการดําเนินการ กระบวนการ และคุณลักษณะของผู้ใช้ต่อไปนี้ในแนวทางที่สอง

สินค้า	คำอธิบาย:
	ในวิธีที่สอง ไปป์ไลน์การเผยแพร่เนื้อหาโดยใช้ตําแหน่งข้อมูล XMLA และ Power BI REST API เท่านั้น เนื้อหาถูกเผยแพร่ไปยังพื้นที่ทํางานการพัฒนา การทดสอบ และการผลิต
	การผสานสาขาที่สําเร็จหรือการเสร็จสิ้นของไปป์ไลน์อัพสตรีมจะทริกเกอร์ไปป์ไลน์การสร้าง จากนั้น ไปป์ไลน์สร้างจะเตรียมเนื้อหาสําหรับการเผยแพร่และทริกเกอร์ไปป์ไลน์รุ่นการพัฒนา
	ไปป์ไลน์การเผยแพร่การพัฒนาจะเผยแพร่เนื้อหาไปยังพื้นที่ทํางานการพัฒนาโดยใช้ตําแหน่งข้อมูล XMLA (สําหรับเมตาดาต้าแบบจําลองข้อมูล) หรือ Power BI REST API (สําหรับไฟล์ Power BI Desktop ซึ่งสามารถประกอบด้วยแบบจําลองข้อมูลและรายงาน) ไปป์ไลน์การพัฒนาใช้อินเทอร์เฟซบรรทัดคําสั่ง (CLI) ตัวแก้ไขตาราง (CLI) เพื่อปรับใช้เมตาดาต้าแบบจําลองข้อมูลโดยใช้ตําแหน่งข้อมูล XMLA
	การอนุมัติการเผยแพร่หรือทริกเกอร์ตามความต้องการจะเปิดใช้งานไปป์ไลน์ทดสอบการเผยแพร่
	ไปป์ไลน์การเผยแพร่การพัฒนาจะเผยแพร่เนื้อหาไปยังพื้นที่ทํางานทดสอบโดยใช้ตําแหน่งข้อมูล XMLA (สําหรับเมตาดาต้าแบบจําลองข้อมูล) หรือ Power BI REST API (สําหรับไฟล์ Power BI Desktop ซึ่งสามารถมีแบบจําลองข้อมูลและรายงาน) ไปป์ไลน์การพัฒนาใช้อินเทอร์เฟซบรรทัดคําสั่ง (CLI) ตัวแก้ไขตาราง (CLI) เพื่อปรับใช้เมตาดาต้าแบบจําลองข้อมูลโดยใช้ตําแหน่งข้อมูล XMLA หลังจากการปรับใช้ ไปป์ไลน์เผยแพร่จะดําเนินการกิจกรรมหลังการปรับใช้โดยใช้ Power BI REST API (ไม่แสดงในแผนภาพ)
	การอนุมัติการเผยแพร่หรือทริกเกอร์ตามความต้องการจะเปิดใช้งานไปป์ไลน์เผยแพร่การผลิต
	ไปป์ไลน์การเผยแพร่การพัฒนาจะเผยแพร่เนื้อหาไปยังพื้นที่ทํางานการผลิตโดยใช้ตําแหน่งข้อมูล XMLA (สําหรับเมตาดาต้าของแบบจําลองข้อมูล) หรือ Power BI REST API (สําหรับไฟล์ Power BI Desktop ซึ่งสามารถมีแบบจําลองข้อมูลและรายงาน) ไปป์ไลน์การพัฒนาใช้อินเทอร์เฟซบรรทัดคําสั่ง (CLI) ตัวแก้ไขตาราง (CLI) เพื่อปรับใช้เมตาดาต้าแบบจําลองข้อมูลโดยใช้ตําแหน่งข้อมูล XMLA หลังจากการปรับใช้ ไปป์ไลน์เผยแพร่จะดําเนินการกิจกรรมหลังการปรับใช้โดยใช้ Power BI REST API (ไม่แสดงในแผนภาพ)

ไปป์ไลน์การเผยแพร่ควรจัดการ กิจกรรมหลังการปรับใช้ กิจกรรมเหล่านี้อาจรวมถึงการตั้งค่าข้อมูลประจําตัวของแบบจําลองความหมายหรือการอัปเดตแอป Power BI สําหรับการทดสอบและพื้นที่ทํางานการผลิต เราขอแนะนําให้คุณ ตั้งค่าการแจ้งเตือน เพื่อแจ้งบุคคลที่เกี่ยวข้องเกี่ยวกับกิจกรรมการปรับใช้

เคล็ดลับ

การใช้ที่เก็บสําหรับการควบคุมเวอร์ชันช่วยให้ผู้สร้างเนื้อหาสามารถสร้างกระบวนการย้อนกลับได้ กระบวนการย้อนกลับสามารถย้อนกลับการปรับใช้ล่าสุดโดยการคืนค่าเวอร์ชันก่อนหน้า พิจารณาการสร้างชุดที่แยกต่างหากของไปป์ไลน์ Azure ที่คุณสามารถทริกเกอร์เพื่อย้อนกลับการเปลี่ยนแปลงการผลิต คิดอย่างรอบคอบเกี่ยวกับกระบวนการและการอนุมัติที่จําเป็นในการเริ่มต้นการย้อนกลับ ตรวจสอบให้แน่ใจว่ากระบวนการเหล่านี้ได้รับการจัดทําเป็นเอกสาร

ไปป์ไลน์การปรับใช้ Power BI

ไปป์ไลน์การปรับใช้ Power BI ประกอบด้วยสามขั้นตอน: การพัฒนา การทดสอบ และการผลิต คุณกําหนดพื้นที่ทํางาน Power BI เดียวไปยังแต่ละขั้นตอนในไปป์ไลน์การปรับใช้ เมื่อมีการปรับใช้เกิดขึ้น ไปป์ไลน์การปรับใช้จะเลื่อนระดับรายการ Power BI จากพื้นที่ทํางานหนึ่งไปยังอีกพื้นที่ทํางานหนึ่ง

ไปป์ไลน์การเผยแพร่ Azure ใช้ Power BI REST API เพื่อ ปรับใช้เนื้อหาโดยใช้ไปป์ไลน์การปรับใช้ Power BI การเข้าถึงทั้งพื้นที่ทํางานและไปป์ไลน์ การปรับใช้เป็นสิ่งจําเป็นสําหรับผู้ใช้ที่ดําเนินการปรับใช้ เราขอแนะนําให้คุณ วางแผนการเข้าถึง ไปป์ไลน์การปรับใช้เพื่อให้ผู้ใช้ไปป์ไลน์สามารถดูประวัติการปรับใช้และเปรียบเทียบเนื้อหาได้

เคล็ดลับ

เมื่อคุณ แยกพื้นที่ทํางานข้อมูลจากพื้นที่ทํางานการรายงาน ให้พิจารณาใช้ Azure Pipelines เพื่อเรียงลําดับเนื้อหาที่เผยแพร่ด้วยไปป์ไลน์การปรับใช้ Power BI หลายรายการ มีการปรับใช้แบบจําลองแสดงความหมายก่อน แล้วจึงรีเฟรช สุดท้าย มีการปรับใช้รายงาน วิธีนี้ช่วยให้คุณปรับใช้ได้ง่ายขึ้น

สิทธิการใช้งานแบบพรีเมียม

ไปป์ไลน์การปรับใช้ Power BI และตําแหน่งข้อมูลการอ่าน/เขียน XMLA เป็น คุณลักษณะพรีเมียม คุณลักษณะเหล่านี้พร้อมใช้งานกับความจุ Power BI Premium และ Power BI Premium Per User (PPU)

PPU เป็นวิธีที่ประหยัดค่าใช้จ่ายในการจัดการการเผยแพร่เนื้อหาระดับองค์กรสําหรับพื้นที่ทํางานการพัฒนาและทดสอบซึ่งโดยทั่วไปจะมีผู้ใช้จํานวนน้อย วิธีนี้มีประโยชน์เพิ่มเติมจากการแยกปริมาณงานการพัฒนาและทดสอบจากปริมาณงานการผลิต

หมายเหตุ

คุณยังคงสามารถตั้งค่าการเผยแพร่เนื้อหาระดับองค์กรโดยไม่มีสิทธิ์การใช้งานระดับ Premium ตามที่อธิบายไว้โดยวิธีที่สองในส่วนของ ไปป์ไลน์ การเผยแพร่ ในวิธีที่สอง คุณใช้ Azure Pipelines เพื่อจัดการการปรับใช้ไฟล์ Power BI Desktop เพื่อพัฒนา ทดสอบ และผลิตพื้นที่ทํางาน อย่างไรก็ตาม คุณไม่สามารถปรับใช้เมตาดาต้าแบบจําลองโดยใช้ตําแหน่งข้อมูล XMLA ได้เนื่องจากไม่สามารถเผยแพร่แบบจําลองความหมายรูปแบบเมตาดาต้าด้วย Power BI REST API นอกจากนี้ยังไม่สามารถเลื่อนระดับเนื้อหาผ่านสภาพแวดล้อมที่มีไปป์ไลน์การปรับใช้โดยไม่มีสิทธิการใช้งานแบบพรีเมียม

การตั้งค่าเกตเวย์

โดยทั่วไปแล้ว จําเป็นต้องใช้เกตเวย์ข้อมูลเมื่อเข้าถึงแหล่งข้อมูลที่อยู่ภายในเครือข่ายส่วนตัวหรือเครือข่ายเสมือน วัตถุประสงค์สองประการของเกตเวย์คือการ รีเฟรชข้อมูลที่นําเข้า และดูรายงานที่สอบถามการเชื่อมต่อสดหรือ แบบจําลองความหมาย DirectQuery (ไม่ได้อธิบายไว้ในแผนภาพสถานการณ์)

เมื่อทํางานกับหลายสภาพแวดล้อม เป็นเรื่องปกติที่จะตั้งค่าการเชื่อมต่อการพัฒนา การทดสอบ และการผลิตไปยังระบบแหล่งข้อมูลที่แตกต่างกัน ในกรณีนี้ ให้ใช้ กฎแหล่งข้อมูลและกฎ พารามิเตอร์เพื่อจัดการค่าที่แตกต่างกันระหว่างสภาพแวดล้อม คุณสามารถใช้ Azure Pipelines เพื่อจัดการเกตเวย์โดยใช้ การดําเนินการ เกตเวย์ของ Power BI REST API

หมายเหตุ

เกตเวย์ข้อมูลส่วนกลางในโหมดมาตรฐานขอแนะนําอย่างยิ่งผ่านเกตเวย์ในโหมดส่วนบุคคล ในโหมดมาตรฐาน เกตเวย์ข้อมูลสนับสนุนการเชื่อมต่อแบบสดและการดําเนินการ DirectQuery (นอกเหนือจากการดําเนินการรีเฟรชข้อมูลที่กําหนดไว้)

ระบบ oversight

เหตุการณ์บันทึกบันทึกกิจกรรมที่เกิดขึ้นในบริการของ Power BI ผู้ดูแลระบบ Power BI สามารถใช้บันทึกกิจกรรมเพื่อตรวจสอบกิจกรรมการปรับใช้

คุณสามารถใช้เมตาดาต้า Power BI ที่สแกน API เพื่อสร้างสินค้าคงคลังของผู้เช่าได้ ผลลัพธ์ API จะเป็นประโยชน์ในการตรวจสอบว่ามีการปรับใช้รายการใดในแต่ละพื้นที่ทํางาน เพื่อตรวจสอบสายข้อมูล และเพื่อตรวจสอบการตั้งค่าความปลอดภัย

นอกจากนี้ยังมีบันทึกการตรวจสอบภายใน Azure DevOps ซึ่งอยู่นอกบริการของ Power BI ผู้ดูแลระบบ Azure DevOps สามารถใช้บันทึกการตรวจสอบเพื่อตรวจสอบกิจกรรมในที่เก็บและไปป์ไลน์ระยะไกล

เนื้อหาที่เกี่ยวข้อง

สําหรับสถานการณ์อื่น ๆ ที่มีประโยชน์เพื่อช่วยคุณในการตัดสินใจการใช้งาน Power BI โปรดดู บทความ สถานการณ์ การใช้งาน Power BI