หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
เรียนรู้วิธีการรวม Git และไปป์ไลน์การปรับใช้ทํางานกับ API สําหรับ GraphQL ใน Microsoft Fabric บทความนี้ช่วยให้คุณเข้าใจวิธีการตั้งค่าการเชื่อมต่อกับที่เก็บของคุณ จัดการ API สําหรับ GraphQL และปรับใช้กับสภาพแวดล้อมต่าง ๆ
ใครใช้การควบคุมแหล่งที่มาและการปรับใช้
ไปป์ไลน์การรวมและการปรับใช้ Git มีความสําคัญสําหรับ:
- วิศวกรข้อมูลที่ จัดการการกําหนดค่า Fabric GraphQL API ผ่านการควบคุมเวอร์ชันและเวิร์กโฟลว์ CI/CD
- ผู้ดูแลระบบพื้นที่ทํางาน Fabric ประสานงานการปรับใช้ในพื้นที่ทํางาน Fabric การพัฒนา ทดสอบ และการผลิต
- ทีม DevOps ใช้ไปป์ไลน์การปรับใช้สําหรับ Fabric API ในสภาพแวดล้อมและความจุที่หลากหลาย
- ทีมแพลตฟอร์ม ที่ต้องการความสามารถในการกํากับดูแล การติดตาม และการย้อนกลับสําหรับการเปลี่ยนแปลง Fabric API
ใช้การควบคุมแหล่งที่มาและไปป์ไลน์การปรับใช้เมื่อคุณต้องการจัดการ GraphQL API ซึ่งเป็นส่วนหนึ่งของวงจรการพัฒนาที่มีโครงสร้างที่มีสภาพแวดล้อมที่หลากหลาย
หมายเหตุ
API สําหรับตัวควบคุมแหล่งข้อมูล GraphQL และการปรับใช้อยู่ใน ตัวอย่างในขณะนี้
ข้อกําหนดเบื้องต้น
- คุณต้องมี API สําหรับ GraphQL ใน Fabric สําหรับข้อมูลเพิ่มเติม ดู สร้าง API สําหรับ GraphQL ใน Fabric และเพิ่มข้อมูล
ภาพรวม
ผ้ามีเครื่องมือที่มีประสิทธิภาพสําหรับ CI/CD (การรวมอย่างต่อเนื่องและการปรับใช้อย่างต่อเนื่อง) และการจัดการวงจรชีวิตการพัฒนาผ่านสองคอมโพเนนต์หลัก: การรวม Git (CI) และ ไปป์ไลน์การปรับใช้ (CD) พื้นที่ทํางานทําหน้าที่เป็นองค์ประกอบส่วนกลางสําหรับทั้งขั้นตอนการซิงโครไนซ์ Git และการปรับใช้
การรวม Git (CI): ซิงโครไนซ์รายการพื้นที่ทํางาน (เช่น โค้ด การกําหนดค่า API) กับ ที่เก็บการควบคุมเวอร์ชัน ทําให้สามารถควบคุมเวอร์ชันและการติดตามการเปลี่ยนแปลงผ่าน Git
ไปป์ไลน์การปรับใช้ (CD): เปิดใช้งานการสร้างขั้นตอน (เช่น การพัฒนา การทดสอบ การผลิต) ด้วยพื้นที่ทํางานที่เชื่อมโยง รายการที่สนับสนุนในแต่ละขั้นตอนจะถูกจําลองไปยังขั้นตอนต่อไปโดยอัตโนมัติ และการเปลี่ยนแปลงในการปรับใช้ทริกเกอร์พื้นที่ทํางานในไปป์ไลน์การเผยแพร่ คุณสามารถกําหนดค่าไปป์ไลน์เพื่อให้แน่ใจว่ามีการทดสอบและปรับใช้การเปลี่ยนแปลงอย่างมีประสิทธิภาพทั่วทั้งสภาพแวดล้อม
Fabric สนับสนุนเวิร์กโฟลว์ CI/CD ต่าง ๆ ที่ปรับให้เข้ากับสถานการณ์ทั่วไป สําหรับข้อมูลเพิ่มเติม โปรดดู ตัวเลือกเวิร์กโฟลว์ CI/CD ใน Fabric
หมายเหตุ
เฉพาะข้อมูลเมตาเท่านั้นที่จะถูกคัดลอกระหว่างการปรับใช้ และข้อมูลจะไม่ถูกคัดลอก
รายการจากพื้นที่ทํางานจะถูกจัดเก็บไว้ในที่เก็บ Git ที่เกี่ยวข้องเป็นโครงสร้างพื้นฐานเป็นโค้ด (IaC) การเปลี่ยนแปลงรหัสในที่เก็บสามารถทริกเกอร์การปรับใช้ในไปป์ไลน์ได้ วิธีนี้ช่วยให้คุณมีการเปลี่ยนแปลงโค้ดโดยอัตโนมัติที่ทําซ้ําในขั้นตอนต่างๆ สําหรับการทดสอบและเผยแพร่การผลิต
วิธีการรับรองความถูกต้องแหล่งข้อมูล
เมื่อสร้าง API สําหรับ GraphQL คุณเลือกวิธีที่ไคลเอ็นต์รับรองความถูกต้องและเข้าถึงแหล่งข้อมูลของคุณ ตัวเลือกนี้มีนัยสําคัญสําหรับไปป์ไลน์การปรับใช้และพฤติกรรมการผูกอัตโนมัติ การทําความเข้าใจวิธีการรับรองความถูกต้องเหล่านี้เป็นสิ่งสําคัญสําหรับการวางแผนเวิร์กโฟลว์ CI/CD ของคุณ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการผูกอัตโนมัติและกระบวนการปรับใช้ โปรดดู ทําความเข้าใจกระบวนการปรับใช้
มีตัวเลือกการเชื่อมต่อสองแบบที่พร้อมใช้งานเมื่อเชื่อมต่อแหล่งข้อมูลกับ API สําหรับ GraphQL ของคุณ: การลงชื่อเพียงครั้งเดียว (SSO) และ ข้อมูลประจําตัวที่บันทึกไว้
ลงชื่อเข้าระบบครั้งเดียว (SSO)
ด้วย SSO ไคลเอ็นต์ API จะใช้ข้อมูลประจําตัวของตนเองเพื่อเข้าถึงแหล่งข้อมูล ผู้ใช้ API ที่รับรองความถูกต้องต้องมีสิทธิ์ทั้ง API และแหล่งข้อมูลต้นแบบ
ใช้ SSO เมื่อ:
- การเปิดเผยแหล่งข้อมูล Fabric (เลคเฮาส์ คลังสินค้า ปลายทางการวิเคราะห์ SQL)
- คุณต้องการให้ผู้ใช้เข้าถึงข้อมูลตามสิทธิ์ของแต่ละบุคคล
- คุณต้องมีนโยบายการรักษาความปลอดภัยระดับแถวหรือนโยบายการเข้าถึงข้อมูลอื่นๆ เพื่อนําไปใช้ต่อผู้ใช้
ข้อกําหนดการอนุญาต:
- ผู้ใช้ API ต้องมีสิทธิ์ ดําเนินการ บน GraphQL API (เรียกใช้การสืบค้นและการกลายพันธุ์)
- ผู้ใช้ API ต้องมีสิทธิ์อ่านหรือเขียนบนแหล่งข้อมูล
- อีกวิธีหนึ่งคือ เพิ่มผู้ใช้เป็นสมาชิกพื้นที่ทํางานที่มีบทบาท ผู้สนับสนุน ซึ่งมีทั้ง API และแหล่งข้อมูลอยู่
พฤติกรรมการผูกอัตโนมัติในไปป์ไลน์การปรับใช้: เมื่อคุณใช้งาน API โดยใช้ SSO จากพื้นที่ทํางานต้นทาง (เช่น Dev) ไปยังพื้นที่ทํางานเป้าหมาย (เช่น ทดสอบ) ให้ทําดังนี้
- แหล่งข้อมูลและ GraphQL API ถูกปรับใช้กับพื้นที่ทํางานเป้าหมาย
- API ในพื้นที่ทํางานเป้าหมายจะผูกกับสําเนาแหล่งข้อมูลภายในเครื่องในพื้นที่ทํางานเป้าหมายโดยอัตโนมัติ
- แต่ละสภาพแวดล้อม (Dev, Test, Production) ใช้อินสแตนซ์แหล่งข้อมูลของตนเอง
หมายเหตุ
มีข้อจํากัดเฉพาะเมื่อใช้ SSO กับตําแหน่งข้อมูล SQL Analytics ดูรายละเอียดที่ข้อจํากัดปัจจุบัน
ข้อมูลประจําตัวที่บันทึกไว้
ด้วยข้อมูลประจําตัวที่บันทึกไว้ ข้อมูลประจําตัวที่แชร์เพียงรายการเดียวจะตรวจสอบสิทธิ์ระหว่าง API และแหล่งข้อมูล ผู้ใช้ API ต้องมีสิทธิ์เข้าถึง API เท่านั้น ไม่ใช่แหล่งข้อมูลพื้นฐาน
ใช้ข้อมูลเข้าสู่ระบบที่บันทึกไว้เมื่อ:
- การเปิดเผยแหล่งข้อมูล Azure (ฐานข้อมูล Azure SQL ฐานข้อมูลภายนอก)
- คุณต้องการการจัดการสิทธิ์ที่ง่ายขึ้น (ผู้ใช้ต้องมีสิทธิ์เข้าถึง API เท่านั้น)
- ผู้ใช้ API ทุกคนควรเข้าถึงข้อมูลเดียวกันด้วยสิทธิ์เดียวกัน
- คุณต้องมีข้อมูลเข้าสู่ระบบที่สอดคล้องกันในคําขอ API ทั้งหมด
ข้อกําหนดการอนุญาต:
- ผู้ใช้ API ต้องการสิทธิ์ ดําเนินการ บน GraphQL API เท่านั้น (เรียกใช้การสืบค้นและการกลายพันธุ์)
- ข้อมูลประจําตัวที่บันทึกไว้เองต้องมีสิทธิ์ที่เหมาะสมในแหล่งข้อมูล
- นักพัฒนาที่ปรับใช้ API ต้องมีสิทธิ์เข้าถึงข้อมูลเข้าสู่ระบบที่บันทึกไว้
พฤติกรรมการผูกอัตโนมัติในไปป์ไลน์การปรับใช้: เมื่อคุณปรับใช้ API โดยใช้ข้อมูลเข้าสู่ระบบที่บันทึกไว้จากพื้นที่ทํางานต้นทาง (Dev) ไปยังพื้นที่ทํางานเป้าหมาย (ทดสอบ):
- แหล่งข้อมูลถูกปรับใช้กับพื้นที่ทํางานเป้าหมาย
- API ในพื้นที่ทํางานเป้าหมาย ยังคงเชื่อมต่อกับ แหล่งข้อมูลในพื้นที่ทํางานต้นทาง (Dev)
- การผูกอัตโนมัติไม่เกิดขึ้น - API ที่ปรับใช้จะยังคงใช้ข้อมูลประจําตัวที่บันทึกไว้ซึ่งชี้ไปยังแหล่งข้อมูลเดิม
- คุณต้องกําหนดค่าการเชื่อมต่อใหม่ด้วยตนเองหรือสร้างข้อมูลประจําตัวที่บันทึกไว้ใหม่ในแต่ละสภาพแวดล้อมเป้าหมาย
สําคัญ
เมื่อคุณเลือกวิธีการรับรองความถูกต้องสําหรับ API แล้ว จะมีผลกับแหล่งข้อมูลทั้งหมดที่เพิ่มลงใน API นั้น คุณไม่สามารถผสม SSO และข้อมูลเข้าสู่ระบบที่บันทึกไว้ใน API เดียวกันได้
การเชื่อมต่อข้ามพื้นที่ทํางาน
หาก API ของคุณในพื้นที่ทํางานต้นทาง (Dev) เชื่อมต่อกับแหล่งข้อมูลในพื้นที่ทํางานอื่น API ที่ปรับใช้ในพื้นที่ทํางานเป้าหมาย (ทดสอบ) จะยังคงเชื่อมต่อกับแหล่งข้อมูลภายนอกนั้นโดยไม่คํานึงถึงวิธีการรับรองความถูกต้อง การผูกอัตโนมัติจะทํางานเฉพาะเมื่อทั้ง API และแหล่งข้อมูลอยู่ในพื้นที่ทํางานต้นทางเดียวกัน
ไดอะแกรมต่อไปนี้แสดงสถานการณ์การปรับใช้เหล่านี้:
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าวิธีการรับรองความถูกต้องเหล่านี้เมื่อสร้าง API ของคุณ โปรดดู เชื่อมต่อกับแหล่งข้อมูล
API สําหรับการรวม GraphQL Git
Fabric API สําหรับ GraphQL รองรับการรวม Git ทําให้คุณสามารถจัดการ GraphQL API เป็นโค้ดภายในระบบควบคุมเวอร์ชันของคุณได้ การผสานรวมนี้ให้ประวัติเวอร์ชัน การทํางานร่วมกันผ่านสาขาและคําขอดึงข้อมูล ความสามารถในการย้อนกลับการเปลี่ยนแปลง และเส้นทางการตรวจสอบที่สมบูรณ์ของการแก้ไข API เมื่อถือว่าการกําหนดค่า GraphQL API ของคุณเป็นโครงสร้างพื้นฐานเป็นโค้ด (IaC) คุณจะสามารถใช้แนวทางปฏิบัติที่ดีที่สุดสําหรับการพัฒนาซอฟต์แวร์กับเลเยอร์การเข้าถึงข้อมูลของคุณได้
การรวม Git เป็นสิ่งจําเป็นสําหรับ:
- การควบคุมเวอร์ชัน: ติดตามการเปลี่ยนแปลงทั้งหมดในสคีมา GraphQL การเชื่อมต่อแหล่งข้อมูล และความสัมพันธ์เมื่อเวลาผ่านไป
- การทํางานร่วมกัน: ทํางานร่วมกับสมาชิกในทีมโดยใช้สาขา คําขอดึงข้อมูล และการตรวจสอบโค้ด
- ความสามารถในการย้อนกลับ: เปลี่ยนกลับเป็นการกําหนดค่า API ก่อนหน้าเมื่อเกิดปัญหา
- การโปรโมตสภาพแวดล้อม: ใช้ Git เป็นแหล่งข้อมูลสําหรับการปรับใช้ API ในสภาพแวดล้อมต่างๆ
เชื่อมต่อพื้นที่ทํางานของคุณกับ Git
วิธีเปิดใช้งานการรวม Git สําหรับ GraphQL API ของคุณ:
- เปิดการตั้งค่าพื้นที่ทํางานสําหรับพื้นที่ทํางานที่มี API สําหรับ GraphQL ของคุณ
- กําหนดค่าการเชื่อมต่อ Git กับที่เก็บของคุณ (Azure DevOps, GitHub หรือผู้ให้บริการ Git อื่นๆ)
- เมื่อเชื่อมต่อแล้ว รายการพื้นที่ทํางานทั้งหมด รวมถึง API สําหรับ GraphQL จะปรากฏในแผงควบคุมแหล่งที่มา
สําหรับคําแนะนําในการตั้งค่าโดยละเอียด โปรดดู เริ่มต้นใช้งานการรวม Git
คอมมิตและซิงค์ GraphQL API ของคุณ
หลังจากเชื่อมต่อกับ Git แล้ว คุณสามารถคอมมิตการกําหนดค่า API สําหรับการกําหนดค่า GraphQL ไปยังที่เก็บได้ การคอมมิตแต่ละครั้งจะสร้างสแนปช็อตของคําจํากัดความ API ของคุณ ซึ่งรวมถึง:
- คําจํากัดความของ Schema GraphQL
- การเชื่อมต่อแหล่งข้อมูลและการตั้งค่าการรับรองความถูกต้อง
- การตั้งค่าคอนฟิกความสัมพันธ์
- คําจํากัดความแบบสอบถามและการกลายพันธุ์
เมื่อยอมรับแล้ว GraphQL API ของคุณจะปรากฏในที่เก็บ Git ของคุณพร้อมลําดับชั้นของโฟลเดอร์ที่มีโครงสร้าง จากจุดนี้ คุณสามารถใช้ประโยชน์จากเวิร์กโฟลว์ Git มาตรฐาน เช่น การสร้างคําขอดึงข้อมูล การจัดการสาขา และการทํางานร่วมกับทีมของคุณผ่านการตรวจสอบโค้ด สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการทํางานกับสาขา โปรดดู จัดการสาขา
การแสดง GraphQL API ใน Git
แต่ละรายการ API สําหรับ GraphQL จะถูกจัดเก็บไว้ใน Git ด้วยโครงสร้างโฟลเดอร์ที่กําหนดไว้อย่างดีซึ่งแสดงถึงทุกแง่มุมของการกําหนดค่า API ของคุณ:
ไฟล์คําจํากัดความ API ประกอบด้วยข้อมูลเมตาทั้งหมดที่จําเป็นในการสร้าง GraphQL API ของคุณใหม่ในพื้นที่ทํางาน Fabric ใดๆ ซึ่งรวมถึงข้อกําหนด Schema การแม็ปแหล่งข้อมูล และการตั้งค่าการกําหนดค่า เมื่อคุณซิงค์จาก Git กลับไปยังพื้นที่ทํางาน Fabric ระบบจะใช้ไฟล์คําจํากัดความเหล่านี้เพื่อกู้คืน API ของคุณอย่างแม่นยําเหมือนเมื่อคอมมิต:
การทํางานกับไฟล์คําจํากัดความ API:
รูปแบบคําจํากัดความ GraphQL API เป็นไปตามมาตรฐาน Infrastructure as Code (IaC) ของ Fabric คุณสามารถดูและแก้ไขไฟล์เหล่านี้ได้โดยตรงในที่เก็บ Git ของคุณ แม้ว่าการแก้ไขส่วนใหญ่ควรทําผ่านพอร์ทัล Fabric เพื่อให้แน่ใจว่า Schema มีความถูกต้อง ไฟล์คําจํากัดความมีประโยชน์อย่างยิ่งสําหรับ:
- การตรวจสอบโค้ด: สมาชิกในทีมสามารถตรวจสอบการเปลี่ยนแปลง API ในคําขอดึงข้อมูลได้
- เอกสารประกอบ: ไฟล์ทําหน้าที่เป็นเอกสารประกอบโครงสร้าง API ของคุณ
- ระบบอัตโนมัติ: ไปป์ไลน์ CI/CD สามารถอ่านไฟล์เหล่านี้เพื่อทําความเข้าใจการกําหนดค่า API
- การกู้คืนจากภัยพิบัติ: คําจํากัดความ API ที่สมบูรณ์จะถูกเก็บรักษาไว้ในการควบคุมเวอร์ชัน
สําหรับข้อมูลโดยละเอียดเกี่ยวกับรูปแบบ ไวยากรณ์ และตัวอย่างข้อกําหนด GraphQL API โปรดดูเอกสารประกอบ API ระนาบควบคุม Fabric:
API สําหรับ GraphQL ในไปป์ไลน์การปรับใช้
ไปป์ไลน์การปรับใช้ช่วยให้คุณสามารถเลื่อนระดับ API ของคุณสําหรับการกําหนดค่า GraphQL ในสภาพแวดล้อมต่างๆ (โดยทั่วไปคือการพัฒนา การทดสอบ และการผลิต) เมื่อคุณปรับใช้ API สําหรับ GraphQL ผ่านไปป์ไลน์ เฉพาะข้อมูลเมตาของ API เท่านั้นที่จะถูกคัดลอก รวมถึงข้อกําหนด Schema การเชื่อมต่อแหล่งข้อมูล และการกําหนดค่าความสัมพันธ์ ข้อมูลจริงจะยังคงอยู่ในแหล่งข้อมูลที่เชื่อมต่อและจะไม่ถูกคัดลอกระหว่างการปรับใช้
ข้อควรพิจารณาในการปรับใช้ที่สําคัญ:
ก่อนปรับใช้ ให้ทําความเข้าใจว่าวิธีการรับรองความถูกต้องและการจัดระเบียบพื้นที่ทํางานส่งผลต่อการปรับใช้ของคุณอย่างไร:
- API ที่ใช้ Single Sign-On (SSO) สามารถผูกกับแหล่งข้อมูลภายในเครื่องในพื้นที่ทํางานเป้าหมายได้โดยอัตโนมัติ (เมื่อมีการปรับใช้แหล่งข้อมูลจากพื้นที่ทํางานต้นทางเดียวกันด้วย)
- API ที่ใช้ ข้อมูลเข้าสู่ระบบที่บันทึก ไว้จะไม่ผูกอัตโนมัติและยังคงเชื่อมต่อกับแหล่งข้อมูลของพื้นที่ทํางานต้นทาง
- แหล่งข้อมูลข้ามพื้นที่ทํางานจะไม่ผูกอัตโนมัติ โดยไม่คํานึงถึงวิธีการรับรองความถูกต้อง
สําหรับความเข้าใจที่ครอบคลุมของกระบวนการปรับใช้ โปรดดู ทําความเข้าใจกระบวนการปรับใช้
ปรับใช้ API ของคุณสําหรับ GraphQL
ในการปรับใช้ API ของคุณสําหรับ GraphQL โดยใช้ไปป์ไลน์การปรับใช้:
สร้างไปป์ไลน์การปรับใช้ใหม่หรือเปิดไปป์ไลน์ที่มีอยู่ สําหรับคําแนะนําโดยละเอียด โปรดดู เริ่มต้นใช้งานไปป์ไลน์การปรับใช้
กําหนดพื้นที่ทํางานให้กับขั้นตอนไปป์ไลน์ (การพัฒนา ทดสอบ การผลิต) ตามกลยุทธ์การปรับใช้ของคุณ แต่ละขั้นตอนควรมีพื้นที่ทํางานเฉพาะ
ตรวจทานและเปรียบเทียบรายการระหว่างขั้นตอน ไปป์ไลน์แสดงให้เห็นว่า API ใดสําหรับ GraphQL มีการเปลี่ยนแปลง โดยระบุโดยจํานวนรายการในพื้นที่ที่ไฮไลต์ การเปรียบเทียบนี้ช่วยให้คุณเข้าใจสิ่งที่จะได้รับผลกระทบจากการปรับใช้
เลือก API สําหรับ GraphQL และรายการที่เกี่ยวข้อง (เช่น แหล่งข้อมูลที่เชื่อมต่อ) ที่คุณต้องการปรับใช้ จากนั้นเลือก ปรับใช้ เพื่อย้ายไปยังขั้นตอนถัดไป
ตรวจทานกล่องโต้ตอบการยืนยันการปรับใช้ ซึ่งแสดงรายการทั้งหมดที่กําลังจะปรับใช้ เลือก ปรับใช้ เพื่อดําเนินการต่อ
ข้อจำกัดปัจจุบัน
เมื่อปรับใช้ API สําหรับ GraphQL ผ่านไปป์ไลน์การปรับใช้ การผูกอัตโนมัติ มีข้อจํากัดดังต่อไปนี้:
รายการย่อย: การผูกอัตโนมัติไม่ทํางานเมื่อ API เชื่อมต่อกับตําแหน่งข้อมูล SQL Analytics ที่เป็นลูกของแหล่งข้อมูลหลัก (เช่น Lakehouse) API ที่ปรับใช้ยังคงเชื่อมต่อกับปลายทางของพื้นที่ทํางานต้นทาง
ข้อมูลเข้าสู่ระบบที่บันทึกไว้: API ที่ใช้วิธีการตรวจสอบสิทธิ์ข้อมูลเข้าสู่ระบบที่บันทึกไว้ไม่รองรับการผูกอัตโนมัติ API ยังคงเชื่อมต่อกับแหล่งข้อมูลของพื้นที่ทํางานต้นทางหลังจากการปรับใช้
สําหรับข้อมูลโดยละเอียดเกี่ยวกับวิธีการรับรองความถูกต้องและลักษณะการผูกอัตโนมัติ โปรดดู วิธีการรับรองความถูกต้องของแหล่งข้อมูล