𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗙𝗮𝗯𝗿𝗶𝗰 𝗖𝗜/𝗖𝗗: 𝗧𝗵𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗚𝗮𝗽
การ Deployment ของคุณเสร็จสิ้นอย่างราบรื่น Azure DevOps pipeline ของคุณผ่านการทดสอบ และ Production workspace ก็ดูสมบูรณ์แบบ
แต่แล้วเช้าวันจันทร์ก็มาถึง
การรีเฟรช Semantic model ล้มเหลว Lakehouse partitions เสียหาย และรายงาน (Reports) เกิดอาการ Timeout สำหรับผู้ใช้ทุกคน
นี่คือด้านของ Microsoft Fabric CI/CD ที่บทช่วยสอนส่วนใหญ่มักมองข้าม
แหล่งข้อมูลภาษาอังกฤษส่วนใหญ่มักแสดงการตั้งค่าแบบ "hello world" พวกเขาแสดงวิธีซิงค์ไอเทมต่างๆ แต่ไม่ได้แสดงวิธีรันสภาพแวดล้อมแบบ Production จริงๆ
ผมได้ศึกษาเอกสารจากชุมชนนักพัฒนาชาวญี่ปุ่นบน Qiita ซึ่งพวกเขาได้ค้นพบปัญหาที่แท้จริงของการ Deployment Fabric ให้พร้อมใช้งานในระดับ Production
Fabric มองทุกอย่างเป็น items ซึ่งรวมถึง semantic models, lakehouses, pipelines, reports และ notebooks โดยมีเป้าหมายคือการจัดการไอเทมเหล่านี้เสมือนเป็น code
เวิร์กโฟลว์มาตรฐานมีลักษณะดังนี้:
- Source control: ส่งออก (Export) ไอเทมเป็นคำจำกัดความแบบ JSON ใน repo ของคุณ
- Build stage: ตรวจสอบความถูกต้อง (Validate) ของการกำหนดค่า (configurations) และความเชื่อมโยง (dependencies)
- Release stage: Deploy ไปยัง target workspaces โดยใช้ environment parameters
แต่เวิร์กโฟลว์ที่เรียบง่ายนี้จะล้มเหลวเมื่อต้องขยายขนาด (at scale) และนี่คือเหตุผล:
Dependency errors บทช่วยสอนบอกว่าคุณสามารถ Deploy ไอเทมในลำดับใดก็ได้ แต่นั่นไม่เป็นความจริง เพราะ Semantic model ต้องพึ่งพา Lakehouse หากคุณ Deploy model ก่อนที่ Lakehouse จะอัปเดต การรีเฟรชก็จะล้มเหลว
API limits บทช่วยสอนมักแนะนำให้ใช้ pipeline เดียวสำหรับทุกอย่าง แต่สำหรับ Workspace ขนาดใหญ่ การ Deploy พร้อมกันหลายรายการอาจทำให้ติดข้อจำกัดด้านอัตราการเรียกใช้งาน (rate limits) ของ Fabric API คุณจึงจำเป็นต้องมีตรรกะ (logic) เพื่อชะลอความเร็วของกระบวนการลง
Capacity differences Model อาจทำงานได้ปกติในสภาพแวดล้อมสำหรับทดสอบ (test environment) แต่กลับล้มเหลวใน Production เนื่องจาก Production workspaces มักจะมีระดับ Capacity (capacity tiers) และข้อจำกัดด้านฟีเจอร์ที่แตกต่างกัน
หากคุณต้องการเปลี่ยนจากการทำตามบทช่วยสอนไปสู่การตั้งค่าแบบ Production จริง ให้ปฏิบัติตามกฎเหล่านี้:
- ใช้การ Deployment แบบเรียงลำดับ (sequential deployment) โดยกำหนดลำดับของไอเทมตามความเชื่อมโยง (dependencies) ของพวกมัน
- ใช้ระบบ workspace locking เพื่อป้องกันไม่ให้มีสอง pipeline ทำงานพร้อมกัน ซึ่งจะช่วยป้องกันความเสียหายของข้อมูลใน workspace (workspace corruption)
- เก็บ backup workspace ไว้ เพื่อใช้เป็นเป้าหมายในการ rollback หากการ Deployment ล้มเหลว
- ใช้ capacity-aware parameters โดยทดสอบการตั้งค่าของคุณกับ capacity จริงใน Production
เครื่องมือมีอยู่แล้ว รูปแบบนี้ใช้งานได้จริง คุณเพียงแค่ต้องเตรียมพร้อมรับมือกับความล้มเหลวที่บทช่วยสอนมักจะข้ามไป
ทีมของคุณเคยเจอปัญหาการ Deployment ที่บทช่วยสอนไม่ได้กล่าวถึงบ้างไหม? และมีอะไรอีกบ้างที่ควรอยู่ในรายการตรวจสอบ (checklist) สำหรับการใช้งานจริง?
Microsoft Fabric CI/CD: ช่องว่างในการ Deployment ที่ไม่มีใครพูดถึง
Microsoft Fabric กำลังเข้ามาเปลี่ยนโฉมหน้าของโลก Data Analytics และ Data Engineering อย่างสิ้นเชิง ด้วยความสามารถแบบ SaaS ที่รวมทุกอย่างไว้ในที่เดียว อย่างไรก็ตาม เมื่อเราพยายามนำแพลตฟอร์มนี้มาใช้ในระดับองค์กร (Enterprise-grade) เราจะพบกับปัญหาสำคัญอย่างหนึ่งที่มักจะถูกมองข้ามไป นั่นคือ "ช่องว่างในการ Deployment" (Deployment Gap)
สถานะปัจจุบันของ CI/CD ใน Microsoft Fabric
ในปัจจุบัน Microsoft Fabric มีเครื่องมือหลักสองอย่างที่ช่วยในการจัดการวงจรชีวิตของไอเทม (Lifecycle management) เพื่อสนับสนุนกระบวนการ CI/CD:
1. Git Integration
การเชื่อมต่อ Workspace เข้ากับ Git repository (เช่น Azure DevOps หรือ GitHub) ช่วยให้เราสามารถจัดการเวอร์ชัน (Version Control) ของไอเทมต่างๆ ใน Fabric ได้ เช่น Notebooks, Reports และ Semantic Models การทำเช่นนี้ช่วยให้ทีมพัฒนาสามารถทำงานร่วมกันได้ดีขึ้นและสามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าได้เมื่อเกิดข้อผิดพลาด
2. Deployment Pipelines
เป็นฟีเจอร์ที่ช่วยให้เราสามารถย้ายไอเทมจาก Workspace หนึ่งไปยังอีก Workspace หนึ่ง (เช่น จาก Dev ไปยัง Test หรือ Prod) ได้อย่างเป็นระบบ ช่วยลดความผิดพลาดจากการย้ายไอเทมด้วยมือ (Manual deployment)
ช่องว่างในการ Deployment (The Deployment Gap)
แม้ว่าเราจะมีเครื่องมือในการย้าย "Metadata" (โครงสร้างและคำสั่ง) ได้อย่างราบรื่น แต่ปัญหาที่แท้จริงคือสิ่งที่อยู่ "เบื้องหลัง" Metadata เหล่านั้น ช่องว่างที่เกิดขึ้นไม่ได้อยู่ที่การย้ายโค้ด แต่อยู่ที่การรับประกันว่าโค้ดนั้นจะทำงานได้อย่างถูกต้องในสภาพแวดล้อมใหม่
1. Metadata vs. Data
การทำ CI/CD ใน Microsoft Fabric ส่วนใหญ่เน้นไปที่การย้าย Metadata แต่สิ่งที่ทำให้ Pipeline พังบ่อยที่สุดคือ "ข้อมูล" (Data) ที่อยู่ในแต่ละสภาพแวดล้อม การย้าย Notebook ไปยัง Prod ไม่ได้หมายความว่า Notebook นั้นจะทำงานได้ทันที หากข้อมูลใน Prod มีโครงสร้างหรือปริมาณที่แตกต่างจาก Dev อย่างสิ้นเชิง
2. การขาดการทดสอบแบบอัตโนมัติ (The Lack of Automated Testing)
ในโลกของ Software Engineering เรามี Unit Testing และ Integration Testing เพื่อตรวจสอบความถูกต้องของโค้ดก่อนการ Deployment แต่ใน Microsoft Fabric เรายังขาดวิธีการมาตรฐานในการรันการทดสอบเหล่านี้โดยอัตโนมัติภายใน Pipeline เรามักจะพบว่าไอเทมถูก Deploy ไปยัง Prod สำเร็จ (Metadata ผ่าน) แต่กลับทำงานล้มเหลวเมื่อรันจริง (Logic/Data พัง)
3. ความแตกต่างของสภาพแวดล้อม (Environment Parity)
ความแตกต่างในด้าน Capacity หรือปริมาณข้อมูลระหว่าง Workspace ในแต่ละสภาพแวดล้อมอาจทำให้เกิดพฤติกรรมที่ไม่คาดคิด สิ่งที่ทำงานได้อย่างรวดเร็วใน Dev Workspace ที่มีข้อมูลน้อย อาจจะทำงานช้าจน Timeout หรือล้มเหลวใน Prod Workspace ที่มีข้อมูลมหาศาล
วิธีการปิดช่องว่างนี้
เพื่อที่จะก้าวข้ามปัญหานี้ เราจำเป็นต้องเปลี่ยนแนวคิดจากการเป็นเพียง "การย้ายไอเทม" (Moving items) ไปสู่การทำ "การตรวจสอบความถูกต้อง" (Validation) อย่างแท้จริง:
- Data Validation: ต้องมีการตรวจสอบความถูกต้องของข้อมูลในสภาพแวดล้อมปลายทางก่อนและหลังการ Deployment
- Automated Testing Frameworks: เริ่มนำ Framework สำหรับการทดสอบมาใช้กับ Notebooks หรือ Data Pipelines เพื่อรันการทดสอบแบบอัตโนมัติในขั้นตอน CI
- Infrastructure as Code (IaC) mindset: มองการตั้งค่า Capacity และสภาพแวดล้อมให้เป็นส่วนหนึ่งของกระบวนการ Deployment เพื่อลดความแตกต่างระหว่างสภาพแวดล้อม
การทำ CI/CD ใน Microsoft Fabric ยังอยู่ในช่วงเริ่มต้น แม้ว่าเครื่องมือพื้นฐานจะพร้อมใช้งานแล้ว แต่การสร้างกระบวนการที่เชื่อถือได้และสามารถตรวจสอบความถูกต้องของทั้ง Metadata และ Data คือกุญแจสำคัญที่จะทำให้การใช้งานในระดับองค์กรประสบความสำเร็จอย่างแท้จริง