แนวทางปฏิบัติที่ดีที่สุดสําหรับการจัดการวงจรชีวิตใน Fabric

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

บทความแบ่งออกเป็นสี่ส่วน:

• การเตรียม เนื้อหา - เตรียมเนื้อหาของคุณสําหรับการจัดการวงจรชีวิต

• การพัฒนา - เรียนรู้เกี่ยวกับวิธีที่ดีที่สุดในการสร้างเนื้อหาในขั้นตอนการพัฒนาไปป์ไลน์การปรับใช้

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

• การผลิต - ใช้ขั้นตอนการผลิตไปป์ไลน์การปรับใช้เพื่อทําให้เนื้อหาของคุณพร้อมใช้งาน

แนวทางปฏิบัติที่ดีที่สุดสําหรับการเตรียมเนื้อหา

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

• เผยแพร่เนื้อหาไปยังการผลิต

• เริ่มต้นใช้ไปป์ไลน์การปรับใช้สําหรับพื้นที่ทํางานเฉพาะ

แยกการพัฒนาระหว่างทีม

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

วางแผนแบบจําลองการให้สิทธิ์ของคุณ

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

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

• ใครควรมีสิทธิ์เข้าถึงโค้ดต้นฉบับในที่เก็บ Git

• การดําเนินการใดที่ผู้ใช้ที่มีสิทธิ์เข้าถึงไปป์ไลน์สามารถทําได้ในแต่ละขั้นตอน

• ใครจะเป็นผู้ตรวจสอบเนื้อหาในขั้นตอนการทดสอบ

• ผู้ตรวจสอบของขั้นตอนการทดสอบควรมีสิทธิ์เข้าถึงไปป์ไลน์หรือไม่

• ใครควรดูแลขั้นตอนการปรับใช้กับการผลิต

• คุณจะกําหนดพื้นที่ทํางานใดในไปป์ไลน์ หรือเชื่อมต่อกับ git

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

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

• คุณจะกําหนดพื้นที่ทํางานของคุณไปยังขั้นตอนใด

• คุณจําเป็นต้องทําการเปลี่ยนแปลงสิทธิ์ของพื้นที่ทํางานที่คุณมอบหมายอยู่หรือไม่

เชื่อมต่อขั้นตอนต่างๆ กับฐานข้อมูลที่แตกต่างกัน

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

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

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

แนวทางปฏิบัติที่ดีที่สุดสําหรับขั้นตอนการพัฒนาไปป์ไลน์การปรับใช้

ส่วนนี้จะให้คําแนะนําสําหรับการทํางานกับไปป์ไลน์การปรับใช้และการใช้สําหรับขั้นตอนการพัฒนาของคุณ

สํารองข้อมูลงานของคุณลงในที่เก็บ Git

ด้วยการรวม Git นักพัฒนาซอฟต์แวร์ทุกคนสามารถสนับสนุนการทํางานของพวกเขาโดยการใส่ลงใน Git เมื่อต้องการสํารองข้อมูลงานของคุณอย่างถูกต้องใน Fabric ต่อไปนี้เป็นกฎพื้นฐานบางอย่าง:

• ตรวจสอบให้แน่ใจว่า คุณมีสภาพแวดล้อมที่แยกจากกันให้ทํางานเพื่อให้ผู้อื่นไม่แทนที่งานของคุณก่อนที่จะได้รับการมอบหมาย ซึ่งหมายความว่าการทํางานในเครื่องมือเดสก์ท็อป (เช่น VS Code, Power BI Desktop หรืออื่น ๆ) หรือในพื้นที่ทํางานแยกต่างหากที่ผู้ใช้รายอื่นไม่สามารถเข้าถึงได้

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

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

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

กําลังย้อนกลับการเปลี่ยนแปลง

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

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

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

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

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

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

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

• การสร้างสาขาใหม่: สร้างสาขาใหม่จาก สาขาหลัก เพื่อให้คุณมีเนื้อหาล่าสุดของคุณ นอกจากนี้ ตรวจสอบให้แน่ใจว่าคุณเชื่อมต่อกับโฟลเดอร์ที่ถูกต้องในสาขา เพื่อให้คุณสามารถดึงเนื้อหาที่ถูกต้องลงในพื้นที่ทํางาน

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

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

ใช้เครื่องมือไคลเอ็นต์เพื่อแก้ไขงานของคุณ

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

การจัดการพื้นที่ทํางานและสาขา

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

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

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

ทําซ้ํารายการในที่เก็บ Git

วิธีการทําซ้ํารายการในที่เก็บ Git:

1. คัดลอกไดเรกทอรีรายการทั้งหมด
2. เปลี่ยน logicalId เป็นค่าเฉพาะสําหรับพื้นที่ทํางานที่เชื่อมต่อนั้น
3. เปลี่ยนชื่อที่แสดงเพื่อแยกความแตกต่างจากรายการต้นฉบับและเพื่อหลีกเลี่ยงข้อผิดพลาดของชื่อที่แสดงที่ซ้ํากัน
4. หากจําเป็น ให้อัปเดต logicalId และ/หรือชื่อที่แสดงในการขึ้นต่อกันใดๆ

แนวทางปฏิบัติที่ดีที่สุดสําหรับขั้นตอนการทดสอบของไปป์ไลน์การปรับใช้

ส่วนนี้จะให้คําแนะนําสําหรับการทํางานกับขั้นตอนการทดสอบของไปป์ไลน์การปรับใช้

จําลองสภาพแวดล้อมการผลิตของคุณ

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

ตรวจสอบให้แน่ใจว่าสามปัจจัยเหล่านี้ได้รับการแก้ไขในสภาพแวดล้อมการทดสอบของคุณ:

• ปริมาณข้อมูล

• ปริมาณการใช้งาน

• ความจุคล้ายกับในการผลิต

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

ใช้กฎการปรับใช้ด้วยแหล่งข้อมูลในชีวิตจริง

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

ตรวจสอบรายการที่เกี่ยวข้อง

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

คุณสามารถค้นหารายการที่เกี่ยวข้องได้อย่างง่ายดายโดยใช้ การวิเคราะห์ผลกระทบ

ปรับปรุงรายการข้อมูล

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

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

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

• หากต้องการดูว่ารายการนั้นจัดการกับการเปลี่ยนแปลงด้วยข้อมูลทดสอบอย่างไร ให้อัปโหลดการเปลี่ยนแปลงก่อนไปยังสภาพแวดล้อมการพัฒนาหรือการทดสอบ

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

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

• หลังจากการปรับใช้ การทดสอบหลังการปรับใช้ใน Prod เพื่อตรวจสอบว่าทุกอย่างทํางานตามที่คาดไว้หรือไม่

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

ทดสอบแอปของคุณ

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

แนวทางปฏิบัติที่ดีที่สุดสําหรับขั้นตอนการผลิตไปป์ไลน์การปรับใช้

ส่วนนี้จะให้คําแนะนําเกี่ยวกับขั้นตอนการผลิตของไปป์ไลน์การปรับใช้

จัดการว่าใครสามารถปรับใช้กับการผลิตได้

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

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

ตั้งกฎเพื่อให้แน่ใจถึงความพร้อมใช้งานขั้นตอนการผลิต

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

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

อัปเดตแอปการผลิต

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

ปรับใช้กับการผลิตโดยใช้สาขา Git

เนื่องจาก repo ทําหน้าที่เป็น 'แหล่งเก็บข้อมูลจริงเพียงหนึ่งเดียว' บางทีมอาจต้องการปรับใช้การอัปเดตลงในขั้นตอนต่าง ๆ โดยตรงจาก Git สิ่งนี้เป็นไปได้ด้วยการรวม Git ด้วยข้อควรพิจารณาสองสามข้อ:

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

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

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

การแก้ไขด่วนไปยังเนื้อหา

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

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

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

• บทช่วยสอนการจัดการวงจรชีวิตแบบครบวงจร
• เริ่มต้นใช้งานการรวม Git
• เริ่มต้นใช้งานไปป์ไลน์การปรับใช้