เลือกตัวเลือกเวิร์กโฟลว์ Fabric CI/CD ที่ดีที่สุดสําหรับคุณ
เป้าหมายของบทความนี้คือการนําเสนอนักพัฒนา Fabric ที่มีตัวเลือกที่แตกต่างกันสําหรับการสร้างกระบวนการ CI/CD ใน Fabric โดยยึดตามสถานการณ์ของลูกค้าทั่วไป บทความนี้มุ่งเน้นไปที่ การปรับใช้ อย่างต่อเนื่อง (CD) ของกระบวนการ CI/CD สําหรับการอภิปรายเกี่ยวกับ ส่วนการรวม อย่างต่อเนื่อง (CI) โปรดดู ที่ จัดการสาขาของ Git
ในขณะที่บทความนี้แสดงตัวเลือกที่แตกต่างกันหลายรายการ แต่หลายองค์กรใช้วิธีการแบบไฮบริด
ข้อกำหนดเบื้องต้น
หากต้องการเข้าถึงคุณลักษณะของไปป์ไลน์การปรับใช้คุณต้องเป็นไปตามเงื่อนไขต่อไปนี้:
กระบวนการพัฒนา
กระบวนการพัฒนาจะเหมือนกันในสถานการณ์การปรับใช้ทั้งหมด และเป็นอิสระจากวิธีการเผยแพร่การอัปเดตใหม่ไปยังการผลิต เมื่อนักพัฒนาทํางานกับตัวควบคุมแหล่งข้อมูล พวกเขาจําเป็นต้องทํางานในสภาพแวดล้อมที่แยกจากกัน ใน Fabric สภาพแวดล้อมนั้นสามารถเป็น IDE บนเครื่องภายในเครื่องของคุณ (เช่น Power BI Desktop หรือ VS Code) หรือพื้นที่ทํางานอื่นใน Fabric คุณสามารถค้นหาข้อมูลเกี่ยวกับข้อควรพิจารณาที่แตกต่างกันสําหรับกระบวนการพัฒนาใน สาขา Manage Git
กระบวนการนําออกใช้
กระบวนการเผยแพร่จะเริ่มเมื่อการอัปเดตใหม่เสร็จสมบูรณ์ และคําขอดึงข้อมูล (PR) ผสานเข้ากับสาขาที่ใช้ร่วมกันของทีม (เช่น หลัก การพัฒนา ฯลฯ) จากจุดนี้มีหลายตัวเลือกในการสร้างกระบวนการเผยแพร่ใน Fabric
ตัวเลือกที่ 1 - การปรับใช้ตาม Git
ด้วยตัวเลือกนี้ การปรับใช้ทั้งหมดมาจากที่เก็บ Git แต่ละขั้นตอนในไปป์ไลน์การเผยแพร่มีสาขาหลักเฉพาะ (ในแผนภาพ ขั้นตอนเหล่านี้คือ Dev, Test และ Prod) ซึ่งป้อนพื้นที่ทํางานที่เหมาะสมใน Fabric
เมื่อ PR ไปยัง สาขา Dev ได้รับการอนุมัติและผสานรวม:
- ไปป์ไลน์การเผยแพร่จะถูกทริกเกอร์เพื่ออัปเดตเนื้อหาของพื้นที่ทํางาน Dev กระบวนการนี้ยังสามารถรวมการสร้างไปป์ไลน์เพื่อเรียกใช้การทดสอบหน่วย แต่การอัปโหลดจริงของไฟล์จะดําเนินการโดยตรงจาก repo ลงในพื้นที่ทํางาน โดยใช้ Fabric Git API คุณอาจจําเป็นต้องเรียกใช้ Fabric API อื่น ๆ สําหรับการดําเนินการหลังการปรับใช้ที่กําหนดการกําหนดค่าเฉพาะสําหรับพื้นที่ทํางานนี้ หรือนําเข้าข้อมูล
- จากนั้น PR จะถูกสร้างขึ้นไปยังสาขาการทดสอบ ในกรณีส่วนใหญ่ PR ถูกสร้างขึ้นโดยใช้สาขาที่วางจําหน่ายที่สามารถเชอร์รี่เลือกเนื้อหาที่จะย้ายไปยังขั้นตอนถัดไป PR ควรมีกระบวนการตรวจสอบและอนุมัติเช่นเดียวกับกระบวนการอื่น ๆ ในทีมหรือองค์กรของคุณ
- จะมีการทริกเกอร์ไปป์ไลน์การสร้างและเผยแพร่รายการอื่นเพื่ออัปเดตพื้นที่ทํางานทดสอบโดยใช้กระบวนการที่คล้ายกับขั้นตอนที่อธิบายไว้ในขั้นตอนแรก
- PR ถูกสร้างขึ้นไปยัง สาขาผลิตภัณฑ์ โดยใช้กระบวนการที่คล้ายกับที่อธิบายไว้ในขั้นตอนที่ #2
- จะมีการทริกเกอร์ไปป์ไลน์การสร้างและเผยแพร่รายการอื่นเพื่ออัปเดตพื้นที่ทํางาน Prod โดยใช้กระบวนการที่คล้ายกับที่อธิบายไว้ในขั้นตอนแรก
คุณควรพิจารณาใช้ตัวเลือก #1 เมื่อใด
- เมื่อคุณต้องการใช้ Git repo ของคุณเป็นแหล่งเก็บข้อมูลจริงแหล่งเดียว และต้นกําเนิดของการปรับใช้ทั้งหมด
- เมื่อทีมของคุณติดตาม Gitflow เป็นกลยุทธ์การแบ่งสาขา รวมถึงสาขาหลักหลายสาขา
- การอัปโหลดจาก repo จะไปยังพื้นที่ทํางานโดยตรง เนื่องจากเราไม่จําเป็นต้อง สร้างสภาพแวดล้อม เพื่อเปลี่ยนแปลงไฟล์ก่อนการปรับใช้ คุณสามารถเปลี่ยนได้โดยการเรียก API หรือเรียกใช้รายการในพื้นที่ทํางานหลังจากการปรับใช้
ตัวเลือกที่ 2 - การปรับใช้ตาม Git โดยใช้การสร้างสภาพแวดล้อม
ด้วยตัวเลือกนี้ การปรับใช้ทั้งหมดมาจากสาขาเดียวกันของที่เก็บ Git (หลัก) แต่ละขั้นตอนในไปป์ไลน์การเผยแพร่มีไปป์ไลน์สร้างและเผยแพร่เฉพาะ ไปป์ไลน์เหล่านี้อาจใช้สภาพแวดล้อมการสร้างเพื่อเรียกใช้การทดสอบหน่วยและสคริปต์ที่เปลี่ยนข้อกําหนดบางอย่างในรายการก่อนที่จะอัปโหลดไปยังพื้นที่ทํางาน ตัวอย่างเช่น คุณอาจต้องการเปลี่ยนแปลงการเชื่อมต่อแหล่งข้อมูล การเชื่อมต่อระหว่างรายการในพื้นที่ทํางาน หรือค่าของพารามิเตอร์เพื่อปรับปรุงการกําหนดค่าสําหรับขั้นตอนที่ถูกต้อง
เมื่อ PR ไปยัง สาขานักพัฒนา ได้รับอนุมัติและผสานรวม:
- ไปป์ไลน์รุ่นจะถูกทริกเกอร์เพื่อหมุนสภาพแวดล้อมการสร้างใหม่และเรียกใช้การทดสอบหน่วยสําหรับขั้นตอนการพัฒนา จากนั้น จะมีการทริกเกอร์ไปป์ไลน์การเผยแพร่เพื่ออัปโหลดเนื้อหาไปยังสภาพแวดล้อมการสร้าง เรียกใช้สคริปต์เพื่อเปลี่ยนการกําหนดค่าบางอย่าง ปรับการกําหนดค่าเป็นขั้นตอนการพัฒนา และใช้ API ข้อกําหนดการอัปเดตของ Fabric เพื่ออัปโหลดไฟล์ไปยังพื้นที่ทํางาน
- เมื่อกระบวนการนี้เสร็จสมบูรณ์ รวมถึงการนําเข้าข้อมูลและการอนุมัติจากผู้จัดการการวางจําหน่าย สามารถสร้างไปป์ไลน์รุ่นและรุ่นถัดไปสําหรับขั้นตอนการทดสอบได้ ลําดับขั้นเหล่านี้จะถูกสร้างขึ้นในกระบวนการคล้ายกับที่อธิบายไว้ในขั้นตอนแรก สําหรับขั้นตอนการทดสอบ อาจจําเป็นต้องมีการทดสอบอัตโนมัติหรือด้วยตนเองอื่น ๆ หลังจากการปรับใช้ เพื่อตรวจสอบความถูกต้องของการเปลี่ยนแปลงที่พร้อมที่จะเผยแพร่ไปยังขั้นตอน Prod
- เมื่อการทดสอบอัตโนมัติและด้วยตนเองทั้งหมดเสร็จสมบูรณ์ ผู้จัดการฝ่ายเผยแพร่สามารถอนุมัติและเริ่ม ใช้งานไปป์ไลน์รุ่น และ เผยแพร่ ไปยัง ขั้นตอน Prod ได้ เนื่องจากขั้นตอน Prod มักจะมีการกําหนดค่าที่แตกต่างจากขั้นตอนการทดสอบ/พัฒนา สิ่งสําคัญคือต้องทดสอบการเปลี่ยนแปลงหลังจากการปรับใช้ นอกจากนี้ การปรับใช้ควรทริกเกอร์การนําเข้าข้อมูลเพิ่มเติมตามการเปลี่ยนแปลง เพื่อลดความไม่พร้อมใช้งานที่อาจเกิดขึ้นให้กับผู้บริโภค
คุณควรพิจารณาใช้ตัวเลือก #2 เมื่อใด
- เมื่อคุณต้องการใช้ Git เป็นแหล่งเก็บข้อมูลจริงเพียงแหล่งเดียว และต้นกําเนิดของการปรับใช้ทั้งหมด
- เมื่อทีมของคุณทําตาม เวิร์กโฟลว์ที่ยึดตาม Trunk เป็นกลยุทธ์การแบ่งสาขา
- คุณจําเป็นต้องสร้างสภาพแวดล้อม (ด้วยสคริปต์แบบกําหนดเอง) เพื่อเปลี่ยนแอตทริบิวต์เฉพาะของพื้นที่ทํางาน เช่น connectionId และ lakehouseId ก่อนที่จะปรับใช้
- คุณต้องมีไปป์ไลน์เผยแพร่ (สคริปต์แบบกําหนดเอง) เพื่อดึงข้อมูลเนื้อหารายการจาก git และเรียกใช้ API รายการ Fabric ที่สอดคล้องกันสําหรับการสร้าง อัปเดต หรือลบรายการ Fabric ที่ปรับเปลี่ยนแล้ว
ตัวเลือกที่ 3 - ปรับใช้โดยใช้ไปป์ไลน์การปรับใช้ Fabric
ด้วยตัวเลือกนี้ Git เชื่อมต่อกันจนกว่าจะถึง ขั้นตอนการพัฒนา เท่านั้น จากขั้นตอนการพัฒนา การปรับใช้เกิดขึ้นโดยตรงระหว่างพื้นที่ทํางานของ Dev/Test/Prod โดยใช้ไปป์ไลน์การปรับใช้ Fabric ในขณะที่เครื่องมือนั้นเป็นเครื่องมือภายในสําหรับ Fabric นักพัฒนาสามารถใช้ API ของไปป์ไลน์การปรับใช้เพื่อปรับแต่งการปรับใช้เป็นส่วนหนึ่งของไปป์ไลน์การเผยแพร่ Azure หรือเวิร์กโฟลว์ GitHub ได้ API เหล่านี้ช่วยให้ทีมสามารถสร้างกระบวนการสร้างและเผยแพร่ที่คล้ายกันเช่นเดียวกับในตัวเลือกอื่น ๆ โดยใช้การทดสอบอัตโนมัติ (ที่สามารถทําได้ในพื้นที่ทํางานเองหรือก่อนขั้นตอนการพัฒนา) การอนุมัติ ฯลฯ
เมื่อ PR ไปยัง สาขาหลัก ได้รับอนุมัติและผสานรวม:
- สร้างไปป์ไลน์ถูกทริกเกอร์ที่อัปโหลดการเปลี่ยนแปลงไปยังขั้นตอนการพัฒนาโดยใช้ Fabric Git API หากจําเป็น ไปป์ไลน์สามารถทริกเกอร์ API อื่นเพื่อเริ่มการดําเนินการ/การทดสอบหลังการปรับใช้ในขั้นตอนการพัฒนา
- หลังจากการปรับใช้ dev เสร็จสมบูรณ์ ไปป์ไลน์เผยแพร่จะเตะใน เพื่อปรับใช้การเปลี่ยนแปลงจากขั้นตอน dev เพื่อทดสอบขั้นตอน ควรทําการทดสอบอัตโนมัติและด้วยตนเองหลังจากการปรับใช้เพื่อให้แน่ใจว่าการเปลี่ยนแปลงได้รับการทดสอบอย่างดีก่อนที่จะถึงการผลิต
- หลังจากการทดสอบเสร็จสมบูรณ์และผู้จัดการเผยแพร่จะอนุมัติการปรับใช้ไปยัง ขั้นตอน Prod การเผยแพร่ไปยัง Prod จะเตะเข้าและทําการปรับใช้ให้เสร็จสมบูรณ์
คุณควรพิจารณาใช้ตัวเลือก #3 เมื่อใด
- เมื่อคุณกําลังใช้ตัวควบคุมแหล่งข้อมูลเพื่อวัตถุประสงค์ในการพัฒนาเท่านั้น และต้องการปรับใช้การเปลี่ยนแปลงโดยตรงระหว่างขั้นตอนของไปป์ไลน์การเผยแพร่
- เมื่อกฎการปรับใช้ การผูกอัตโนมัติและ API อื่น ๆ ที่พร้อมใช้งานนั้นเพียงพอที่จะจัดการการกําหนดค่าระหว่างขั้นตอนของไปป์ไลน์การเผยแพร่
- เมื่อคุณต้องการใช้ฟังก์ชันการทํางานอื่น ๆ ของไปป์ไลน์การปรับใช้ Fabric เช่นดูการเปลี่ยนแปลงใน Fabric ประวัติการปรับใช้ฯลฯ
- พิจารณาด้วยว่าการปรับใช้ในไปป์ไลน์การปรับใช้ Fabric มีโครงสร้างเชิงเส้น และจําเป็นต้องมีสิทธิ์อื่น ๆ ในการสร้างและจัดการไปป์ไลน์
ตัวเลือกที่ 4 - CI/CD สําหรับ ISV ใน Fabric (จัดการลูกค้า/โซลูชันหลายราย)
ตัวเลือกนี้แตกต่างจากตัวอื่น ซึ่งเกี่ยวข้องมากที่สุดสําหรับผู้จัดจําหน่ายซอฟต์แวร์อิสระ (ISV) ที่สร้างแอปพลิเคชัน SaaS สําหรับลูกค้าของตนที่ด้านบนสุดของ Fabric ISV มักจะมีพื้นที่ทํางานแยกต่างหากสําหรับลูกค้าแต่ละราย และสามารถมีพื้นที่ทํางานได้มากถึงหลายร้อยหรือหลายพันพื้นที่ทํางาน เมื่อโครงสร้างของการวิเคราะห์ที่ให้แก่ลูกค้าแต่ละรายมีความคล้ายคลึงกันและนอกกรอบ เราขอแนะนําให้มีกระบวนการพัฒนาและการทดสอบแบบรวมศูนย์ที่แยกออกให้กับลูกค้าแต่ละรายในลําดับขั้น Prod เท่านั้น
ตัวเลือกนี้จะยึดตามตัวเลือก #2 เมื่อ PR เป็น PR หลักได้รับอนุมัติและผสานรวม:
- ไปป์ไลน์รุ่นจะถูกทริกเกอร์เพื่อหมุนสภาพแวดล้อมการสร้างใหม่และเรียกใช้การทดสอบหน่วยสําหรับขั้นตอนการพัฒนา เมื่อการทดสอบเสร็จสมบูรณ์ ระบบจะทริกเกอร์ไปป์ไลน์การเผยแพร่ ไปป์ไลน์นี้สามารถอัปโหลดเนื้อหาไปยังสภาพแวดล้อมการสร้าง เรียกใช้สคริปต์เพื่อเปลี่ยนการกําหนดค่าบางอย่าง ปรับการกําหนดค่าเป็นขั้นตอนการพัฒนา และจากนั้นใช้ API ข้อกําหนดรายการอัปเดตของ Fabric เพื่ออัปโหลดไฟล์ไปยังพื้นที่ทํางาน
- หลังจากกระบวนการนี้เสร็จสมบูรณ์ รวมถึงการนําเข้าข้อมูลและการอนุมัติจากผู้จัดการการเผยแพร่ ไปป์ไลน์รุ่นและรุ่นถัดไปสําหรับขั้นตอนการทดสอบสามารถเริ่มต้นได้ กระบวนการนี้จะคล้ายกับที่อธิบายไว้ในขั้นตอนแรก สําหรับ ขั้นตอนการทดสอบ อาจจําเป็นต้องใช้การทดสอบอัตโนมัติหรือด้วยตนเองอื่น ๆ หลังจากการปรับใช้ เพื่อตรวจสอบความถูกต้องของการเปลี่ยนแปลงที่พร้อมที่จะเผยแพร่ไปยัง ขั้นตอน Prod ที่มีคุณภาพสูง
- เมื่อการทดสอบทั้งหมดผ่านและกระบวนการอนุมัติเสร็จสมบูรณ์แล้ว การปรับใช้กับ ลูกค้า Prod จะสามารถเริ่มต้นได้ ลูกค้าแต่ละรายมีการวางจําหน่ายของตนเองด้วยพารามิเตอร์ของตนเองเพื่อให้การกําหนดค่าเฉพาะและการเชื่อมต่อข้อมูลสามารถเกิดขึ้นได้ในพื้นที่ทํางานของลูกค้าที่เกี่ยวข้อง การเปลี่ยนแปลงการกําหนดค่าอาจเกิดขึ้นได้ผ่านสคริปต์ในสภาพแวดล้อมรุ่น หรือใช้ API หลังการปรับใช้ การเผยแพร่ทั้งหมดสามารถเกิดขึ้นพร้อมกันได้เนื่องจากไม่ได้เกี่ยวข้องและไม่เกี่ยวข้องกัน
คุณควรพิจารณาใช้ตัวเลือก #4 เมื่อใด
- คุณคือแอปพลิเคชันการสร้างของ ISV ที่ด้านบนสุดของ Fabric
- คุณกําลังใช้พื้นที่ทํางานที่แตกต่างกันสําหรับลูกค้าแต่ละรายเพื่อจัดการการเช่าหลายรายการในแอปพลิเคชันของคุณ
- สําหรับการแยกเพิ่มเติม หรือสําหรับการทดสอบเฉพาะสําหรับลูกค้าที่แตกต่างกัน คุณอาจต้องการให้มีผู้เช่าหลายรายในขั้นตอนก่อนหน้าของการพัฒนาหรือการทดสอบ ในกรณีดังกล่าว ให้พิจารณาว่าด้วยจํานวนพื้นที่ทํางานที่จําเป็นต้องเช่าหลายรายการจะเพิ่มขึ้นอย่างมาก
สรุป
บทความนี้สรุปตัวเลือก CI/CD หลักสําหรับทีมที่ต้องการสร้างกระบวนการ CI/CD อัตโนมัติใน Fabric ในขณะที่เราสรุปตัวเลือกสี่ตัวเลือก ข้อจํากัดในชีวิตจริงและสถาปัตยกรรมโซลูชันอาจให้ยืมตัวเลือกแบบไฮบริดหรือตัวเลือกที่แตกต่างกันโดยสิ้นเชิง คุณสามารถใช้บทความนี้เพื่อแนะนําคุณผ่านตัวเลือกต่าง ๆ และวิธีการสร้างแต่คุณไม่ได้ถูกบังคับให้เลือกเพียงหนึ่งตัวเลือกเท่านั้น
สถานการณ์หรือรายการเฉพาะบางอย่างอาจมี ข้อจํากัดที่ทําให้ คุณไม่สามารถปรับใช้สถานการณ์เหล่านี้ได้
เช่นเดียวกันสําหรับการใช้เครื่องมือ ในขณะที่เรากล่าวถึงเครื่องมือต่าง ๆ ที่นี่ คุณอาจเลือกเครื่องมืออื่น ๆ ที่สามารถให้ฟังก์ชันการทํางานในระดับเดียวกันได้ พิจารณาว่า Fabric ได้รวมกับเครื่องมือบางอย่างที่ดีกว่า ดังนั้นการเลือกเครื่องมืออื่นจึงส่งผลให้มีข้อจํากัดเพิ่มเติมซึ่งจําเป็นต้องใช้การแก้ปัญหาชั่วคราวที่แตกต่างกัน