เลือกตัวเลือกเวิร์กโฟลว์ Fabric CI/CD ที่ดีที่สุดสําหรับคุณ

บทความนี้นําเสนอทางเลือกต่าง ๆ สําหรับนักพัฒนา Fabric ในการสร้างกระบวนการ CI/CD ใน Fabric โดยอิงจากสถานการณ์ที่ลูกค้าพบบ่อย บทความนี้มุ่งเน้นไปที่ การปรับใช้ อย่างต่อเนื่อง (CD) ของกระบวนการ CI/CD สําหรับการอภิปรายเกี่ยวกับส่วนการบูรณาการต่อเนื่อง (CI) โปรดดูที่ กระบวนการพัฒนาใน Microsoft Fabric

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

ข้อกำหนดเบื้องต้น

ในการสร้างกระบวนการ CI/CD โดยใช้ตัวเลือกในบทความนี้ คุณต้อง:

• การสมัครใช้งาน Microsoft Fabric

• พื้นที่ทํางาน Fabric (คุณต้องเป็นผู้ดูแลระบบพื้นที่ทํางานเพื่อกําหนดค่าการปรับใช้)

• สําหรับตัวเลือกที่ใช้ Git (1, 2 และ 4) ผู้ให้บริการ Git ที่รองรับ (Azure DevOps หรือ GitHub) ที่เชื่อมต่อผ่านการรวม Git

กระบวนการพัฒนา

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

Git sync รองรับทั้งการยืนยันการเปลี่ยนแปลง workspace ไปยัง Git และการอัปเดต workspace จาก Git ลูกศร PR แสดงทิศทางที่คุณรวมการเปลี่ยนแปลงฟีเจอร์เข้ากับสาขาการพัฒนาที่ใช้ร่วมกัน ไม่ใช่การซิงค์แบบสองทิศทาง

กระบวนการนําออกใช้

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

ตารางต่อไปนี้สรุปตัวเลือกที่จะช่วยคุณเลือก หลายทีมรวมกันมากกว่าหนึ่งทีม

¹ ในตัวเลือกที่ 2 มีเพียงพื้นที่ ทํางาน Dev เท่านั้นที่เชื่อมต่อกับ Git พื้นที่ ทํางานทดสอบ และ Prod ไม่ได้เชื่อมต่อกับ Git การส่งแท็กปล่อยบน Main จะกระตุ้น pipeline ที่นําเวอร์ชันนั้นไปใช้งานใน Test หลังจากการตรวจสอบและอนุมัติสําเร็จ pipeline จะปรับใช้แท็กเดียวกันและ commit SHA ไปยัง Prod

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

ตัวเลือกที่ 1 และ 2 แตกต่างกันในเรื่องการจัดระเบียบและโปรโมทการปล่อยเวอร์ชัน ไม่ใช่การเลือกเครื่องมือเฉพาะ ทั้งสองตัวเลือกสามารถใช้ API ของ fabric-cicd หรือ Fabric Items และการกําหนดพารามิเตอร์เฉพาะสภาพแวดล้อมได้ ตัวเลือกที่ 1 ส่งเสริมการเปลี่ยนแปลงผ่านการแยกสาขาของสเตจ ตัวเลือกที่ 2 ใช้แท็กปล่อยบน Main เพื่อกระตุ้นการปรับใช้คอมมิตเดียวกันไปยัง Test และหลังจากตรวจสอบและอนุมัติแล้ว จะส่งไปยัง Prod

แผนการปรับใช้ไม่ใช่ตัวเลือกเวิร์กโฟลว์แยกต่างหาก คุณสามารถใช้แผนที่รองรับการดําเนินการ Git ในตัวเลือกที่ 1 โดยมี deployment pipelines ในตัวเลือกที่ 3 หรือเรียก Bulk Import Item Definitions API โดยตรงในตัวเลือกที่ 1, 2 และ 4 ไลบรารีไม่ fabric-cicd รองรับแผนการปรับใช้ รวมถึงเมื่อคุณใช้โหมดนําเข้าแบบกลุ่ม แผนควบคุมลําดับการปรับใช้ การพึ่งพา และการดําเนินการ ขณะที่เวิร์กโฟลว์ที่เลือกยังคงกําหนดแหล่งข้อมูลความจริง สิ่งที่แต่ละขั้นตอนจะนําไปใช้ และการกําหนดค่าขั้นตอน

ตัวเลือกที่ 1 - การปรับใช้ตามนิยามจากสาขา Git แต่ละขั้นตอน

ด้วยตัวเลือกนี้ การติดตั้งทั้งหมดจะมาจาก Git แต่ละขั้นตอนจะมีสาขาหลักเฉพาะ ได้แก่ Dev, Test และ Prod ในตัวอย่างนี้ PR ส่งเสริมการเปลี่ยนแปลงระหว่างสาขาเหล่านั้น และแต่ละพื้นที่ทํางานจะได้รับคํานิยามจากสาขาของสเตจนั้น คุณสามารถติดตั้งผ่านการผสานรวม Git, fabric-cicd หรือ Fabric Items API เมื่อคุณใช้ fabric-cicd หรือ Items API พื้นที่ทํางานเป้าหมายไม่จําเป็นต้องเชื่อมต่อ Git ฟีเจอร์ที่กําหนดคือสาขาแยกสําหรับแต่ละขั้นตอน ไม่ใช่เครื่องมือปรับใช้

เมื่อ PR ไปยัง สาขา Dev ได้รับการอนุมัติและผสานรวม:

1. อัปเดตพื้นที่ ทํางาน Dev จาก Dev branch เช่น การผสานรวมกับ Git รันการทดสอบหน่วยและการดําเนินการหลังการนําไปใช้งานที่จําเป็น
2. สร้าง PR ไปยังสาขา Test พร้อมการเปลี่ยนแปลงที่คุณต้องการส่งเสริม คุณสามารถใช้สาขาปล่อยเพื่อเลือกการเปลี่ยนแปลงเหล่านั้นได้ตามใจชอบ ใช้กระบวนการตรวจสอบและอนุมัติของทีมคุณ
3. ปรับใช้ commit เฉพาะจากสาขา Test ไปยังพื้นที่ทํางาน Test โดยใช้การผสานรวม Git, fabric-cicd หรือ API ของ Fabric Items ใช้การกําหนดค่าเฉพาะขั้นตอนและรันการทดสอบอัตโนมัติหรือแบบแมนนวล
4. สร้าง PR ไปยังสาขา Prod เพื่อโปรโมตการเปลี่ยนแปลงที่ได้รับการตรวจสอบแล้ว ตรวจสอบคําจํากัดความที่ได้เพื่อให้แน่ใจว่าตรงกับเวอร์ชันที่ทดสอบ ยกเว้นการกําหนดค่าเฉพาะขั้นตอนที่ตั้งใจ หากคุณเพิ่มการเปลี่ยนแปลงอื่น ๆ ให้ตรวจสอบความถูกต้องใน Test ก่อนเลื่อนขั้น
5. หลังจากได้รับการอนุมัติแล้ว ให้ปรับใช้สาขา Prod ไปยังพื้นที่ทํางาน Prod โดยใช้เครื่องมือปรับใช้ที่คุณเลือก ดําเนินการตรวจสอบและประมวลผลข้อมูลหลังการติดตั้งที่จําเป็น

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

คอมโพเนนต์ใดบ้างที่สามารถใช้ในการทําตัวเลือก #1 ได้?

• การผสานรวมกับ Git: เชื่อมต่อแต่ละพื้นที่ทํางานกับสาขาสเตจของมัน อัปเดตผ่าน Fabric UI หรืออัตโนมัติอัปเดตด้วย Fabric Git APIs
• fabric-cicd: ตรวจสอบสาขาของสเตจและเผยแพร่คํานิยามรายการพร้อมพารามิเตอร์เฉพาะสภาพแวดล้อม พื้นที่ทํางานเป้าหมายไม่จําเป็นต้องเชื่อมต่อ Git
• Fabric Items APIs: ปรับใช้นิยามจากสาขาของสเตจโดยเรียกใช้ Create item และ Update item definition หรือ Bulk Import Item Definitions API เมื่อคุณเรียกใช้ API โดยตรง ระบบอัตโนมัติของคุณจะเตรียมคําจํากัดความและการกําหนดค่าเฉพาะของแต่ละขั้นตอน

สําหรับตัวอย่างการใช้งาน ดูที่ fabric-cicd และ Azure DevOps tutorial หรือ Fabric CI/CD with Bulk Import Item Definitions API

คุณควรพิจารณาใช้ตัวเลือก #1 เมื่อใด

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

ตัวเลือกที่ 2 - การปรับใช้ตามนิยามจาก commit การปล่อยร่วมกัน

ด้วยตัวเลือกนี้ นักพัฒนาจะทํางานบนสาขา Dev ที่เชื่อมต่อกับพื้นที่ทํางานของ Dev สาขา หลัก คือสาขาปล่อย: ประกอบด้วยเฉพาะการเปลี่ยนแปลงที่คุณเลือกจะปล่อยเท่านั้น พื้นที่ ทํางานทดสอบ และ Prod ไม่ได้เชื่อมต่อกับ Git การส่งแท็กปล่อยบน Main จะกระตุ้นกระบวนการทํางานของ GitHub Actions หรือ Azure DevOps pipeline มันจะปรับใช้เวอร์ชันที่ติดแท็กไปยัง Test รันการตรวจสอบ และรอการอนุมัติจากการผลิตก่อนที่จะปรับใช้แท็กเดียวกันและ commit SHA ไปยัง Prodpipeline อาจใช้สภาพแวดล้อม build เพื่อรัน unit tests และปรับ item definition ก่อนอัปโหลด ตัวอย่างเช่น คุณอาจเปลี่ยนการเชื่อมต่อแหล่งข้อมูล การอ้างอิงไปยังรายการอื่น ๆ หรือค่าพารามิเตอร์สําหรับขั้นตอนเป้าหมาย ไม่ใช่ทุกการพึ่งพารายการที่ต้องการการเปลี่ยนแปลงเหล่านี้ บางตัวจะผูกโดยอัตโนมัติผ่าน Logical ID เมื่อถูกนําไปใช้งานในพื้นที่ทํางานใหม่ โปรดดูรายละเอียดที่หัวข้อทําความเข้าใจการผูกการขึ้นต่อกันในการปรับใช้ข้ามพื้นที่ทํางาน

การไหลของระบบปล่อยทํางานดังนี้:

1. นักพัฒนาจะรวม PR ที่ได้รับการอนุมัติเข้าไปในสาขา Dev และพื้นที่ทํางาน Dev จะได้รับการอัปเดตจาก Git
2. เพื่อเตรียมการปล่อย ให้สร้าง PR ที่คัดเลือกการเปลี่ยนแปลงที่คุณต้องการปล่อยจาก Dev ไปยัง Main PR ควรมีกระบวนการตรวจสอบและอนุมัติเหมือนกับ PR อื่น ๆ ในทีมหรือองค์กรของคุณ
3. สร้างแท็กปล่อยในคอมมิตที่เลือกบน Main ตัวอย่างเช่นv1.5.0 กดแท็กเพื่อกระตุ้นเวิร์กโฟลว์ GitHub Actions หรือ pipeline Azure DevOps ที่ตั้งค่าสําหรับแท็กปล่อย
4. pipeline จะ resolve tag เป็น commit SHA บันทึกทั้งสอง check out commit นั้น รัน unit test และปรับการตั้งค่าสําหรับ Test มันอัปโหลดคํานิยามรายการเหล่านั้นเข้าสู่พื้นที่ทดสอบโดยใช้ fabric-cicd หรือ Bulk Import Item Definitions API สําหรับรายละเอียด ดูที่ ส่วนประกอบใดบ้างที่สามารถใช้เพื่อใช้งานตัวเลือก #2? ทดสอบอัตโนมัติหรือแบบแมนนวลหลังการติดตั้ง หากการตรวจสอบไม่สําเร็จ ให้หยุดการเลื่อนขั้นเป็น Prod
5. หลังจากการตรวจสอบสําเร็จ pipeline จะรอที่เกตอนุมัติการผลิตที่กําหนดค่าไว้ ใช้การตรวจสอบการอนุมัติสภาพแวดล้อม GitHub หรือการตรวจสอบการอนุมัติสภาพแวดล้อม Azure DevOps
6. หลังจากอนุมัติแล้ว ให้ปรับใช้แท็กปล่อยเดียวกันและ SHA commit ที่บันทึกไว้ไปยัง Prod เฉพาะการกําหนดค่าต่อขั้นตอน เช่น ชุดค่าของไลบรารีตัวแปรหรือไฟล์พารามิเตอร์เท่านั้น ที่แตกต่างจาก Test รันการตรวจสอบเฉพาะในการผลิตและกระตุ้นการรับข้อมูลใด ๆ ที่การเปลี่ยนแปลงต้องการ เพื่อลดความไม่พร้อมใช้งานสําหรับผู้บริโภค

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

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

ส่วนประกอบใดบ้างที่สามารถใช้เพื่อใช้ตัวเลือก #2

• Fabric-cicd - ไลบรารี Python ที่ออกแบบมาเพื่อใช้กับพื้นที่ทํางาน Microsoft Fabric ไลบรารีนี้รองรับระบบอัตโนมัติแบบ Continuous Integration / Continuous Deployment (CI/CD) แบบโค้ดเป็นอันดับแรกเพื่อรวมพื้นที่ทํางานเข้ากับเฟรมเวิร์กการปรับใช้ได้อย่างราบรื่น สําหรับตัวอย่างแบบ end-to-end ที่สมบูรณ์ ให้ทําตาม บทช่วยสอน fabric-cicd และ Azure DevOps ของเรา Fabric-CICD รองรับโหมดการเผยแพร่สองแบบ:
  • API การกําหนดรายการ (ค่าเริ่มต้น): เผยแพร่รายการทีละรายการโดยใช้ Fabric Create item และ Update definition API
  • การนําเข้าแบบกลุ่ม (ทดลอง): เผยแพร่รายการทั้งหมดในการเรียกใช้ครั้งเดียวโดยใช้ API Bulk Import Item Definitions ในการใช้โหมดนี้ ให้เปิดใช้งานแฟล็กและenable_experimental_featuresenable_bulk_publishฟีเจอร์ สําหรับข้อมูลเพิ่มเติม ดูที่ fabric-cicd bulk publish
• Bulk-Import-Item-Definitions-API - API รองรับทั้งการสร้างรายการใหม่และการอัปเดตรายการที่มีอยู่ ในขณะที่อาศัยการจัดการการขึ้นต่อกันในตัวของ Fabric เพื่อให้แน่ใจว่ามีการปรับใช้รายการในลําดับที่ถูกต้อง สิ่งนี้ช่วยให้สามารถปรับใช้ได้อย่างสม่ําเสมอและทําซ้ําได้ในสภาพแวดล้อมการทดสอบและการผลิตโดยไม่ต้องมีการแทรกแซงด้วยตนเอง สําหรับตัวอย่างบทช่วยสอน ให้ทําตาม Fabric CI/CD ของเราด้วย API คําจํากัดความรายการนําเข้าจํานวนมาก

คุณควรพิจารณาใช้ตัวเลือก #2 เมื่อใด

• เมื่อคุณต้องการพารามิเตอร์เฉพาะสภาพแวดล้อมของนิยามรายการก่อนการปรับใช้ ฟีเจอร์ พารามิเตอร์ fabric-cicd ใช้ parameter.yml ไฟล์เพื่อแทนที่ค่าของแต่ละสภาพแวดล้อมเป้าหมาย รวมถึง connection ID และ lakehouse ID โดยไม่ต้องรักษานิยามรายการแยกสําหรับแต่ละขั้นตอน รองรับการค้นหาและแทนที่ การแทนที่ค่าที่เลือกด้วยเส้นทาง JSON และการแก้ปัญหาแบบไดนามิกของรหัสไอเท็มเป้าหมายในพื้นที่ทํางาน ความสามารถนี้ยังมีในตัวเลือกที่ 1 เมื่อคุณใช้ fabric-cicd การผสานรวม Git เพียงอย่างเดียวไม่สามารถให้การแทนที่เวลาการติดตั้งนี้ได้
• เมื่อคุณต้องการใช้ Git เป็นแหล่งเก็บข้อมูลจริงเพียงแหล่งเดียว และต้นกําเนิดของการปรับใช้ทั้งหมด
• เมื่อคุณต้องการเลือกการเปลี่ยนแปลงในแต่ละเวอร์ชัน ให้นําไปใช้ในเวอร์ชันที่มีแท็กและทดสอบแล้วไปยัง Prod

ตัวเลือกที่ 3 - ปรับใช้โดยใช้ไปป์ไลน์การปรับใช้ Fabric

ด้วยตัวเลือกนี้ Git เชื่อมต่อกันจนกว่าจะถึง ขั้นตอนการพัฒนา เท่านั้น จากขั้นตอนการพัฒนา การปรับใช้เกิดขึ้นโดยตรงระหว่างพื้นที่ทํางานของ Dev/Test/Prod โดยใช้ไปป์ไลน์การปรับใช้ Fabric คุณสามารถปรับใช้ระหว่างขั้นตอนได้โดยตรงจาก Fabric UI หรือใช้ API ของกระบวนการปรับใช้เพื่อจัดการการปรับใช้เป็นส่วนหนึ่งของกระบวนการปล่อย Azure หรือเวิร์กโฟลว์ของ GitHub API เหล่านี้ช่วยให้ทีมสามารถสร้างกระบวนการสร้างและเผยแพร่ที่คล้ายกันเช่นเดียวกับในตัวเลือกอื่น ๆ โดยใช้การทดสอบอัตโนมัติ (ที่สามารถทําได้ในพื้นที่ทํางานเองหรือก่อนขั้นตอนการพัฒนา) การอนุมัติ ฯลฯ

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

เมื่อคุณอนุมัติและรวม PR เข้ากับสาขาที่เชื่อมต่อกับพื้นที่ ทํางาน Dev :

1. อัปเดตพื้นที่ทํางาน Dev จาก Git โดยใช้ Fabric UI หรือ Fabric Git API รันการดําเนินการและทดสอบหลังการอัปเดตที่จําเป็น
2. ปรับใช้การเปลี่ยนแปลงจาก Dev ไปยัง Test โดยใช้ Fabric deployment pipelines ไม่ว่าจะจาก Fabric UI หรือผ่าน API ของ deployment pipelines รันการทดสอบอัตโนมัติหรือด้วยตนเองใน Test ก่อนเลื่อนการเปลี่ยนแปลงไปยัง Prod
3. หลังจากการทดสอบผ่านและผู้จัดการการปล่อยอนุมัติแล้ว ให้ปรับใช้เนื้อหาที่ผ่านการตรวจสอบจาก Test ไปยัง Prod อย่าอัปเดตเนื้อหาที่เลือกใน Test ระหว่างการตรวจสอบและปรับใช้ไปยัง Prod โดยไม่ทดสอบอีกครั้ง

คุณสามารถดําเนินการเหล่านี้จาก Fabric UI หรือทําให้อัตโนมัติด้วย API ใน Azure Pipelines หรือ GitHub Actions คุณไม่จําเป็นต้องมี pipeline สร้างและปล่อยภายนอกสําหรับ workflow ที่อิงกับ UI

คุณควรพิจารณาใช้ตัวเลือก #3 เมื่อใด

• เมื่อทีมของคุณชื่นชอบประสบการณ์การติดตั้งในตัวของ Fabric และความสามารถที่ตอบสนองความต้องการการติดตั้งของคุณ คุณสามารถปรับใช้ระหว่างพื้นที่ทํางานจาก Fabric UI ได้โดยไม่ต้องดูแลกระบวนการปล่อยภายนอก และใช้ API สําหรับการทํางานอัตโนมัติเมื่อจําเป็น แนวทางนี้ยังเหมาะกับทีมที่มีประสบการณ์จํากัดกับเครื่องมือ DevOps เช่น Azure Pipelines หรือ GitHub Actions
• เมื่อคุณกําลังใช้ตัวควบคุมแหล่งข้อมูลเพื่อวัตถุประสงค์ในการพัฒนาเท่านั้น และต้องการปรับใช้การเปลี่ยนแปลงโดยตรงระหว่างขั้นตอนของไปป์ไลน์การเผยแพร่
• เมื่อกฎการปรับใช้ การผูกอัตโนมัติและ API อื่น ๆ ที่พร้อมใช้งานนั้นเพียงพอที่จะจัดการการกําหนดค่าระหว่างขั้นตอนของไปป์ไลน์การเผยแพร่
• เมื่อคุณต้องการใช้ฟังก์ชันการทํางานอื่น ๆ ของไปป์ไลน์การปรับใช้ Fabric เช่นดูการเปลี่ยนแปลงใน Fabric ประวัติการปรับใช้ฯลฯ
• พิจารณาด้วยว่าการปรับใช้ในไปป์ไลน์การปรับใช้ Fabric มีโครงสร้างเชิงเส้น และจําเป็นต้องมีสิทธิ์อื่น ๆ ในการสร้างและจัดการไปป์ไลน์

ตัวเลือกที่ 4 - CI/CD สําหรับ ISV ใน Fabric (จัดการลูกค้า/โซลูชันหลายราย)

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

ตัวเลือกนี้อ้างอิงจาก ตัวเลือก #2:

1. นักพัฒนาจะทํางานกับ Dev branch และ Dev workspace และเลือกเปลี่ยนแปลงที่ต้องการปล่อยจาก Dev ไปยัง Main ตามที่อธิบายไว้ในตัวเลือก #2
2. สร้างและผลักแท็กปล่อยบน commit ที่เลือกบน Main เป็นต้นv1.5.0 แท็กนี้จะเรียกใช้งานเวิร์กโฟลว์ GitHub Actions หรือ pipeline Azure DevOps
3. pipeline จะแปลงแท็กเป็น SHA ที่ commit บันทึกทั้งสอง รันการทดสอบหน่วย และปรับคําจํากัดความที่ติดแท็กสําหรับ shared Test มันจะปรับใช้โดยใช้ fabric-cicd หรือ Bulk Import Item Definitions API ตามที่อธิบายไว้ในตัวเลือก #2 ทดสอบอัตโนมัติหรือแบบแมนนวลหลังการติดตั้ง ถ้าการตรวจสอบไม่สําเร็จ ให้หยุดการเลื่อนขั้น แก้ไขปัญหาใน Dev นําการแก้ไขไปใช้ Main และสร้างแท็กใหม่สําหรับรันถัดไป
4. หลังจากการตรวจสอบสําเร็จและได้รับการอนุมัติการผลิตที่กําหนดค่าไว้แล้ว ให้ติดตั้งแท็กเดียวกันและ SHA commit ที่บันทึกไว้ไปยังพื้นที่ ทํางาน Prod ของลูกค้าแต่ละราย ใช้พารามิเตอร์และการเชื่อมต่อเฉพาะของลูกค้าก่อนการปรับใช้หรือผ่าน API หลังการปรับใช้ การติดตั้งลูกค้าอิสระสามารถทํางานควบคู่กันได้ บันทึกแท็ก, commit SHA และเป้าหมายลูกค้าในประวัติการปรับใช้สภาพแวดล้อมเพื่อให้สามารถติดตามเวอร์ชันที่ปรับใช้ของลูกค้าแต่ละรายได้

คุณควรพิจารณาใช้ตัวเลือก #4 เมื่อใด

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

สรุป

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

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

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

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

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