การวางแผนการใช้งาน Power BI: พัฒนาเนื้อหาและจัดการการเปลี่ยนแปลง

โน้ต

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

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

• ทีม Center of Excellence (COE) และ BI: ทีมที่มีหน้าที่ดูแล Power BI ในองค์กร ทีมเหล่านี้ประกอบด้วยผู้มีอํานาจตัดสินใจที่ตัดสินใจวิธีการจัดการวงจรชีวิตของเนื้อหา Power BI ทีมเหล่านี้ยังรวมถึงบทบาทเช่น ผู้จัดการวางจําหน่าย ที่จัดการวงจรชีวิตของการเผยแพร่เนื้อหา หรือวิศวกรที่สร้างและจัดการคอมโพเนนต์ที่จําเป็นในการใช้และสนับสนุนการจัดการวงจรชีวิตอย่างมีประสิทธิภาพ
• ผู้สร้างเนื้อหาและเจ้าของเนื้อหา: ผู้ใช้ที่สร้างเนื้อหา ซึ่งพวกเขาต้องการเผยแพร่ไปยังพอร์ทัล Fabric เพื่อแชร์กับผู้อื่น บุคคลเหล่านี้มีหน้าที่รับผิดชอบในการจัดการวงจรชีวิตของเนื้อหา Power BI ที่พวกเขาสร้าง

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

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

รูปภาพต่อไปนี้แสดงวงจรชีวิตของเนื้อหา Power BI การเน้นขั้นตอนที่สองซึ่งคุณพัฒนาเนื้อหาและจัดการการเปลี่ยนแปลง

แผนภาพ

โน้ต

สําหรับภาพรวมของการจัดการวงจรชีวิตเนื้อหา ดูบทความแรก ในชุดนี้

ปลาย

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

• การจัดการวงจรชีวิตใน Microsoft Fabric คืออะไร: บทความนี้ให้คําแนะนําทางเทคนิคและบทช่วยสอน ไปยังการรวม Fabric Git และไปป์ไลน์การปรับใช้
• แนวทางปฏิบัติที่ดีที่สุดสําหรับการจัดการวงจรชีวิต: บทความนี้มีเคล็ดลับการปฏิบัติและคําแนะนําสําหรับการใช้คุณลักษณะการจัดการวงจรชีวิตของ Fabric และ Power BI เพื่อพัฒนาเนื้อหาและจัดการการเปลี่ยนแปลง
• การรวม OneDrive และ SharePoint ของ Power BI Desktop: บทความนี้ประกอบด้วยภาพรวมของตัวเลือกในการใช้และจัดเก็บไฟล์ที่บันทึกไว้ใน OneDrive for Work และ School หรือ SharePoint เมื่อคุณดําเนินการควบคุมเวอร์ชันด้วยไฟล์ .pbix
• เริ่มต้นใช้งาน Git ในที่เก็บ Azure: ชุดบทความนี้ประกอบด้วยเคล็ดลับการปฏิบัติ บทช่วยสอน และคําแนะนําสําหรับการดําเนินการควบคุมแหล่งข้อมูลโดยใช้ที่เก็บ Git ใน Azure Repos

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

ประโยชน์อื่น ๆ ของการควบคุมเวอร์ชันรวมถึงความสามารถในการ:

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

ปลาย

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

ขั้นตอนแรกในการตั้งค่าการควบคุมเวอร์ชันคือตัดสินใจว่าคุณจะพัฒนาเนื้อหาอย่างไร

ตัดสินใจเลือกวิธีการพัฒนาเนื้อหา

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

ปลาย

เมื่อพัฒนาแบบจําลองความหมายและรายงานโดยใช้ Power BI Desktop เราขอแนะนําให้คุณใช้ไฟล์ .pbip แทนไฟล์ .pbix เมื่อพัฒนาแบบจําลองความหมายโดยใช้เครื่องมือ XMLA เราขอแนะนําให้คุณใช้รูปแบบ Tabular Model Definition Language (TMDL) แทนที่จะเป็นไฟล์ .bim

รูปแบบ .pbip และ TMDL รองรับการติดตามและการผสานการเปลี่ยนแปลงระดับวัตถุได้ง่ายขึ้น ซึ่งหมายความว่าคุณสามารถดูและจัดการการเปลี่ยนแปลงไปยังแต่ละออบเจ็กต์ได้ เช่น หน่วยวัดหรือตาราง DAX

Power BI Desktop

คุณสามารถใช้ Power BI Desktop เพื่อสร้างแบบจําลองเชิงความหมายหรือรายงาน ซึ่งคุณสามารถบันทึกเป็นไฟล์ .pbix หรือ .pbip ได้ ยังมีไฟล์เนื้อหาแบบกําหนดเองเพิ่มเติมที่คุณอาจใช้เมื่อคุณใช้ Power BI Desktop เมื่อใช้ Power BI Desktop เพื่อสร้างเนื้อหา การตัดสินใจที่สําคัญที่คุณควรทํามีได้แก่:

• รูปแบบไฟล์ใดที่จะใช้: คุณสามารถบันทึกเนื้อหาเป็นไฟล์ .pbix หรือ .pbip ได้ ตัวอย่างเช่น การรวม Git จําเป็นต้องให้คุณใช้ไฟล์ .pbip ผู้สร้างแบบบริการตนเองอาจพบไฟล์ .pbix ที่ง่ายขึ้นในการจัดการและบํารุงรักษาใน Teams, SharePoint หรือ OneDrive
• วิธีการจัดการเนื้อหาแบบกําหนดเอง: คุณสามารถเพิ่มธีม วิชวลแบบกําหนดเอง หรือรูปภาพไปยังไฟล์ Power BI Desktop ซึ่งอาจต้องมีข้อควรพิจารณาที่แตกต่างกันสําหรับการจัดการวงจรชีวิต ตัวอย่างเช่น เมื่อผู้สร้างเนื้อหาสร้างวิชวลแบบกําหนดเองพวกเขาควรบันทึกและจัดการข้อกําหนดของวิชวลในไฟล์แยกต่างหาก
• วิธีการจัดการคุณลักษณะตัวอย่าง: คุณสามารถเลือกใช้คุณลักษณะหรือการตั้งค่าตัวอย่างใน Power BI Desktop ซึ่งจะเปลี่ยนแปลงเนื้อหาและวิธีที่คุณจะใช้ ตัวอย่างเช่น คุณอาจดําเนินการขั้นตอนเพิ่มเติมเพื่อตรวจสอบเนื้อหาที่ใช้คุณลักษณะตัวอย่าง

การเขียนเว็บ

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

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

ปลาย

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

ความระมัดระวัง

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

เครื่องมืออื่น ๆ

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

• Visual Studio หรือ Visual Studio Code: สภาพแวดล้อมการพัฒนาแบบรวมสําหรับนักพัฒนาเพื่อสร้างและจัดการแบบจําลองความหมายหรือสมุดบันทึก Fabric ด้วยทั้ง Visual Studio และ Visual Studio Codeนักพัฒนายังสามารถดําเนินการจัดการการควบคุมแหล่งที่มา (SCM) โดยการยอมรับและส่งการเปลี่ยนแปลงภายในเครื่องไปยังที่เก็บระยะไกล
• ตัวแก้ไขตาราง: เครื่องมือของบุคคลที่สามเพื่อพัฒนาและจัดการแบบจําลองความหมาย
• Excel: เครื่องมือไคลเอ็นต์สําหรับตาราง Pivot และตารางที่เชื่อมต่อสดที่ทํางานกับแบบจําลองความหมาย
• ตัวสร้างรายงาน Power BI : แอปพลิเคชันบนเดสก์ท็อปสําหรับการสร้างรายงานแบบแบ่งหน้า (.rdl)

เมื่อสร้างเนื้อหาโดยใช้เครื่องมืออื่น การตัดสินใจที่สําคัญบางอย่างที่คุณควรทําประกอบด้วย:

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

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

ตัดสินใจว่าคุณจะตั้งค่าและใช้พื้นที่ทํางานอย่างไร

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

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

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

สําคัญ

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

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

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

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

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

โน้ต

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

• การเผยแพร่จาก Power BI Desktop
• ปรับใช้เนื้อหาจากพื้นที่ทํางานอื่นโดยใช้ไปป์ไลน์การปรับใช้ Fabric
• การซิงค์เนื้อหาจากที่เก็บ Git ระยะไกลโดยใช้การรวม Git
• ปรับใช้เนื้อหาทางโปรแกรมโดยใช้ Fabric REST APIs, Power BI REST API หรือจุดสิ้นสุด XMLA

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีเหล่านี้ในการปรับใช้เนื้อหา โปรดดู ลําดับขั้นที่ 4: ปรับใช้เนื้อหา ภายหลังในชุดนี้

ทดสอบและผลิตพื้นที่ทํางาน

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

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

แผนภาพแสดงกระบวนการและคอมโพเนนต์ต่อไปนี้เพื่อแยกพื้นที่ทํางานในวิธีนี้

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

โน้ต

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

การพัฒนา การทดสอบ และพื้นที่ทํางานการผลิต

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

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

แผนภาพแสดงกระบวนการและคอมโพเนนต์ต่อไปนี้เพื่อแยกพื้นที่ทํางานในวิธีนี้

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

โน้ต

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

พื้นที่ทํางานส่วนตัวที่มีการรวม Git

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

โน้ต

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

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

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

โน้ต

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

แผนภาพแสดงกระบวนการและคอมโพเนนต์ต่อไปนี้เพื่อแยกพื้นที่ทํางานในวิธีนี้

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

การสนับสนุนแหล่งข้อมูลสําหรับพื้นที่ทํางาน

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

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

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

ตัดสินใจว่าคุณจะใช้การควบคุมเวอร์ชันอย่างไร

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

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

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

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

ตัวควบคุมเวอร์ชันโดยใช้ SharePoint หรือ OneDrive สําหรับที่ทํางานและโรงเรียน

SharePoint มีตัวควบคุมเวอร์ชันที่มีอยู่ภายในสําหรับไฟล์ ผู้สร้างเนื้อหาสามารถพัฒนาแบบจําลองเชิงความหมายหรือรายงานภายในเครื่องได้ และการเปลี่ยนแปลงของพวกเขาจะถูกซิงโครไนซ์กับ SharePoint หรือ OneDrive for Work และ School document library

ปลาย

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

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

แผนภาพอธิบายถึงกระบวนการและคอมโพเนนต์ต่อไปนี้

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

สําคัญ

คุณสามารถดําเนินการควบคุมเวอร์ชันได้เฉพาะโดยใช้ SharePoint หรือไฟล์ OneDrive for Power BI Desktop ที่ประกอบด้วยแบบจําลองหรือรายงานเชิงความหมายเท่านั้น คุณไม่สามารถดําเนินการควบคุมเวอร์ชันได้อย่างง่ายดายโดยใช้ SharePoint หรือ OneDrive สําหรับรายการประเภทอื่น ๆ ของ Power BI เช่น กระแสข้อมูล หรือสําหรับประเภทรายการ Fabric เช่น สมุดบันทึก สําหรับชนิดรายการอื่นๆ เหล่านี้ คุณควรดําเนินการควบคุมเวอร์ชันโดยใช้ที่เก็บ Git ระยะไกล เช่น Azure Repos

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

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

พิจารณาใช้ SharePoint หรือ OneDrive เพื่อติดตามและจัดการการเปลี่ยนแปลงในสถานการณ์ต่อไปนี้:

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

โน้ต

OneDrive และ SharePoint สนับสนุนเนื้อหาที่มีการใช้ป้ายชื่อระดับความลับ ยกเว้นสําหรับสถานการณ์ที่จํากัด บางอย่าง ในทางตรงกันข้าม การรวม Fabric Git ไม่รองรับป้ายชื่อระดับความลับ

หลีกเลี่ยงการใช้ SharePoint หรือ OneDrive เพื่อติดตามและจัดการการเปลี่ยนแปลงในสถานการณ์ต่อไปนี้:

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

ส่วนต่อไปนี้อธิบายข้อควรพิจารณาเพิ่มเติมเพื่อใช้การควบคุมเวอร์ชันอย่างมีประสิทธิภาพโดยใช้ SharePoint หรือ OneDrive กับ Power BI

การรวม Microsoft Teams

คุณอาจใช้ไลบรารีเอกสารจาก Microsoft Teams หากผู้สร้างเนื้อหาใช้เพื่อการทํางานร่วมกัน ไลบรารีเอกสารคือไซต์ SharePoint และการใช้ไลบรารีเอกสาร (แทนที่จะเป็นไซต์ SharePoint หรือโฟลเดอร์ OneDrive แยกต่างหาก) ช่วยรับประกันการรวมศูนย์กลางของเนื้อหา ไฟล์ และการทํางานร่วมกัน

ไฟล์เช็คอินและเช็คเอาท์

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

ประวัติเวอร์ชัน

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

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

ตัวควบคุมแหล่งข้อมูลโดยใช้ที่เก็บ Git ระยะไกล

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

โน้ต

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

ไดอะแกรมต่อไปนี้แสดงภาพรวมระดับสูงของวิธีการที่คุณดําเนินการควบคุมแหล่งข้อมูลโดย

แผนภาพอธิบายถึงกระบวนการและคอมโพเนนต์ต่อไปนี้

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

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

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

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

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

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

ปลาย

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

คำเตือน

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

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

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

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

โน้ต

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

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

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

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

สําคัญ

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

ใช้สาขา

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

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

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

ปลาย

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

การเปลี่ยนแปลงชุดงานในยอมรับ

ในขณะที่พัฒนาเนื้อหา ผู้สร้างควรเปลี่ยนลําดับขั้นเป็นชุดงาน (หรือกลุ่ม) เป็นประจํา การเปลี่ยนแปลงเหล่านี้ควรจัดการกับรายการงานเฉพาะสําหรับโซลูชัน (เช่น คุณลักษณะหรือปัญหา) เมื่อพร้อมแล้ว ผู้สร้างเนื้อหาจะยอมรับการเปลี่ยนแปลงที่มีลําดับขั้นเหล่านี้

การทําชุดงานจะเปลี่ยนแปลงด้วยวิธีนี้มีประโยชน์หลายอย่าง

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

เมื่อคุณกําหนดระยะและยอมรับการเปลี่ยนแปลงเนื้อหา Power BI ให้พิจารณาปัจจัยต่อไปนี้

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

ปลาย

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

สร้างคําขอดึงข้อมูลเพื่อผสานการเปลี่ยนแปลง

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

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

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

ปลาย

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

รายการตรวจสอบ - เมื่อวางแผนตําแหน่งที่คุณจะจัดเก็บไฟล์ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

• เลือกเครื่องมือการพัฒนาของคุณ: ตรวจสอบให้แน่ใจว่าวิธีของคุณในการพัฒนาเนื้อหาสอดคล้องกับวิธีที่คุณจะทํางานร่วมกับผู้สร้างเนื้อหาคนอื่น ๆ และใช้การควบคุมเวอร์ชัน
• เลือกระหว่างรูปแบบ .pbip และ .pbix สําหรับแบบจําลองและรายงาน: โดยทั่วไปแล้ว รูปแบบ .pbip จะเป็นประโยชน์มากกว่าสําหรับตัวควบคุมแหล่งข้อมูล แต่ผู้ใช้แบบบริการตนเองสามารถค้นหาไฟล์.pbix ที่ใช้งานง่ายขึ้น
• แยกแบบจําลองความหมายและการพัฒนารายงาน : การควบคุมเวอร์ชันมีประสิทธิภาพมากที่สุดเมื่อคุณจัดการการเปลี่ยนแปลงสําหรับรายการประเภทต่าง ๆ แยกต่างหาก การแยกแบบจําลองและการพัฒนารายงาน ถือว่าเป็นแนวทางปฏิบัติที่ดี
• ตัดสินใจจํานวนพื้นที่ทํางานที่คุณต้องการ: การใช้สภาพแวดล้อมที่แยกต่างหากเป็นสิ่งสําคัญสําหรับความสําเร็จของการจัดการวงจรชีวิตเนื้อหา ตรวจสอบให้แน่ใจว่าคุณได้ชี้แจงจํานวนพื้นที่ทํางานที่คุณต้องการ และดําเนินการวางแผนระดับพื้นที่ทํางาน ที่เหมาะสม
• ตัดสินใจว่าคุณจะใช้ควบคุมเวอร์ชันอย่างไร : ตัดสินใจระหว่างวิธีการที่ง่ายขึ้นโดยใช้ SharePoint หรือ OneDrive for Business หรือโดยใช้ Azure DevOps เพื่ออํานวยความสะดวกในการควบคุมแหล่งข้อมูล
• ตั้งค่าที่เก็บระยะไกลของคุณ: สร้างพื้นที่ที่มีโครงสร้างในโฟลเดอร์ OneDrive หรือ Git Repo ที่คุณจัดเก็บเนื้อหาเพื่อติดตามและจัดการการเปลี่ยนแปลง
• ถ้าคุณกําลังใช้ตัวควบคุมแหล่งข้อมูล ให้ตั้งค่าไฟล์ .gitignore และ .gitattributes: ตรวจสอบให้แน่ใจว่าคุณตั้งค่าที่เก็บของคุณเพื่อให้คุณติดตามเฉพาะการเปลี่ยนแปลงที่มีความหมายเท่านั้น
• ถ้าคุณกําลังใช้ตัวควบคุมแหล่งข้อมูล ให้กําหนดกลยุทธ์การแยกสาขาและการรวม: ตรวจสอบให้แน่ใจว่าคุณกําหนดกระบวนการที่ชัดเจนสําหรับวิธีที่คุณตั้งค่าและใช้การควบคุมแหล่งข้อมูลเพื่อสนับสนุนการพัฒนาที่ดีที่สุด หลีกเลี่ยงการทําให้กระบวนการของคุณซับซ้อนมากเกินไป แต่ให้พยายามเสริมวิธีการทํางานในทีมพัฒนาของคุณให้เป็นส่วนเสริม

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

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