ภาพรวมของการรวม Git ใน Power Platform

ตัวควบคุมต้นฉบับช่วยให้ทีมพัฒนาสามารถซิงค์โซลูชันและออบเจ็กต์โซลูชันในสภาพแวดล้อม Microsoft Dataverse อย่างน้อยหนึ่งรายการโดยใช้ที่เก็บ Git ของ Azure DevOps ฟังก์ชันการรวมตัวควบคุมต้นฉบับมีให้ใช้งานแบบเนทีฟภายในประสบการณ์โซลูชัน เพื่อให้มั่นใจว่านักพัฒนาสมัครเล่น นักพัฒนาที่เน้นโค้ดเป็นหลัก และผู้ดูแลระบบจะได้รับประโยชน์จากการควบคุมเวอร์ชัน การติดตามการเปลี่ยนแปลง และการทำงานร่วมกันเป็นทีมที่ราบรื่นในเครื่องมือและสภาพแวดล้อมต่างๆ การรวม Git มีวัตถุประสงค์เพื่อใช้กับสภาพแวดล้อมของนักพัฒนาซอฟต์แวร์ ไม่ใช่ในสภาพแวดล้อมการทดสอบหรือการผลิตของคุณ โดยที่สามารถปรับใช้ได้โดยใช้การสร้างเพื่อสร้างอาร์ทิแฟกต์ของโซลูชันและไปป์ไลน์ในการปรับใช้ Power Platform

ในบทความนี้ คุณจะพบแนวคิดหลักและประโยชน์บางประการของการใช้ตัวควบคุมต้นฉบับที่เปิดใช้งาน Git กับสภาพแวดล้อม Dataverse และโซลูชันของคุณ สำหรับข้อมูลเกี่ยวกับ Git ใน Azure DevOps ให้ไปที่ที่เก็บ Git ของ Azure DevOps

ALM ใน Power Platform และ Dataverse

Power Platform มอบความสามารถที่พร้อมใช้งานทันทีมากมายที่ช่วยให้องค์กรสามารถจัดการการจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) สำหรับโซลูชันของตนได้ รวมถึงความสามารถในการแพ็คเกจโซลูชันเป็นคอนเทนเนอร์สำหรับวัตถุประเภทต่างๆ มากมายในแพลตฟอร์ม จัดการสภาพแวดล้อมที่เกี่ยวข้องกับวงจรชีวิตแอปพลิเคชัน และปรับใช้โซลูชันโดยใช้ ไปป์ไลน์ใน Power Platform นอกจากนี้ยังมีหลายวิธีในการรวมที่เก็บ Git เข้ากับ Power Platform การใช้เครื่องมือสำหรับนักพัฒนา ด้วยการผสานรวม Git ใน Dataverse กระบวนการนี้จึงง่ายขึ้นและคล่องตัวสำหรับผู้สร้างในการทำงานกับโซลูชันของตนด้วยวิธีที่คุ้นเคยและโต้ตอบกับตัวควบคุมต้นฉบับผ่านอินเทอร์เฟซที่เรียบง่ายใน Power Apps (make.powerapps.com)

ประโยชน์

• ตัวควบคุมต้นฉบับเป็นแหล่งที่มาของข้อมูล: ภายในบางองค์กร แหล่งข้อมูลสำหรับการปรับใช้ใน Dataverse คือสภาพแวดล้อมของผู้สร้างที่สร้างโซลูชัน ตัวขับเคลื่อนหลักสำหรับลักษณะการทำงานนี้คือการรวม Git ที่ไม่ใช่เนทีฟใช้เทคนิคและเครื่องมือขั้นสูง ซึ่งต้องใช้ความเชี่ยวชาญด้านไอทีระดับมืออาชีพในการเริ่มต้น ด้วยการผสานรวมแบบเนทีฟฟของ Git ใน Dataverse ตัวควบคุมต้นฉบับสามารถเปิดใช้งานได้ในไม่กี่ขั้นตอนและมีอินเทอร์เฟซที่คุ้นเคยสำหรับผู้สร้างในการทำงานกับโซลูชันของตน
• ความปลอดภัย การตรวจสอบ และการปฏิบัติตามข้อกำหนดโดยใช้แนวทางปฏิบัติที่ดีที่สุดของ SDLC: แนวทางปฏิบัติที่ดีที่สุดของวงจรการพัฒนาซอฟต์แวร์ (SDLC) คือชุดของแนวทางและกระบวนการที่ช่วยให้คุณจัดการโครงการพัฒนาซอฟต์แวร์ของคุณได้อย่างมีประสิทธิภาพ เมื่อใช้การรวม Git ใน Dataverse คุณจะปฏิบัติตามแนวทางปฏิบัติของ SDLC เช่น การควบคุมเวอร์ชัน การตรวจสอบโค้ด และการวิเคราะห์ซอร์สโค้ดแบบคงที่ เพื่อให้มั่นใจในคุณภาพ ความน่าเชื่อถือ และความปลอดภัยของโซลูชันของคุณ การรวม Git ใน Dataverse ยังมีคุณลักษณะต่างๆ เช่น การตรวจสอบ การปฏิบัติตามข้อกำหนด และการตรวจสอบย้อนกลับ ซึ่งช่วยให้คุณติดตามการเปลี่ยนแปลงในโซลูชันของคุณและทำงานร่วมกับสมาชิกในทีมคนอื่นๆ ได้อย่างมีประสิทธิภาพ
• สภาพแวดล้อมการพัฒนาที่มีอายุสั้น: ด้วยการจัดเก็บสำเนาการปรับแต่งและการกำหนดค่าของสภาพแวดล้อมของคุณในตัวควบคุมต้นฉบับ คุณสามารถคืนสภาพสภาพแวดล้อมการพัฒนาจากตัวควบคุมต้นฉบับได้อย่างรวดเร็วและง่ายดายใน Dataverse สิ่งนี้ช่วยให้คุณสร้างสภาพแวดล้อมอายุสั้นเพื่อวัตถุประสงค์ในการพัฒนาและทดสอบได้ สภาพแวดล้อมที่มีอายุสั้นช่วยให้คุณสามารถเพิ่มพื้นที่เก็บข้อมูลทดลองกับคุณลักษณะใหม่ ทดสอบ และทำซ้ำในโซลูชันของคุณโดยไม่ต้องพึ่งพาสภาพแวดล้อมถาวร
• ทีมพัฒนาฟิวชัน: ทีมพัฒนาฟิวชันคือทีมที่ประกอบด้วยทั้งนักพัฒนาและผู้สร้างที่ทำงานร่วมกันเพื่อสร้างโซลูชัน ด้วยการใช้การรวม Git ใน Dataverse ผู้ใช้เหล่านี้สามารถสร้างได้อย่างอิสระในสภาพแวดล้อมที่แยกจากกันและทำงานร่วมกับผู้อื่นโดยการซิงค์กับที่เก็บตัวควบคุมต้นฉบับทั่วไป การรวมตัวควบคุมต้นฉบับช่วยให้คุณใช้ทักษะและความเชี่ยวชาญของทั้งนักพัฒนาและผู้สร้างเพื่อสร้างโซลูชันคุณภาพสูงที่ตอบสนองความต้องการขององค์กรของคุณ
• การป้องกัน: การใช้ตัวควบคุมต้นฉบับเป็นแหล่งข้อมูลสำหรับโซลูชันของคุณช่วยให้คุณสามารถกู้คืนจากการเปลี่ยนแปลงที่ไม่ได้ตั้งใจในโซลูชันของคุณได้อย่างรวดเร็วและง่ายดาย ด้วยการจัดเก็บโซลูชันของคุณในตัวควบคุมต้นฉบับ คุณจะสามารถคืนค่าเป็นสถานะหรือเวอร์ชันก่อนหน้าได้

แนวคิดหลัก

โซลูชันที่มีการจัดการเทียบกับที่ไม่มีการจัดการ

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

การจัดรูปแบบไฟล์สำหรับวัตถุโซลูชัน

การนำการรวม Git เข้ามาใช้ใน Dataverse ทำให้เกิดการเปลี่ยนแปลงในวิธีการแสดงโซลูชันและวัตถุโซลูชันในระบบควบคุมแหล่งที่มา เมื่อคุณยืนยันและผลักดันการเปลี่ยนแปลงไปยังการควบคุมแหล่งที่มา วัตถุโซลูชันจะถูกเก็บไว้ในรูปแบบเฉพาะที่เข้ากันได้กับ Git รูปแบบนี้ใช้เพื่อแสดงวัตถุโซลูชันในลักษณะที่อ่านและเข้าใจง่าย และสามารถใช้ติดตามการเปลี่ยนแปลงของวัตถุโซลูชันในช่วงเวลาต่างๆ ได้ รูปแบบไฟล์สำหรับวัตถุโซลูชันได้รับการออกแบบมาให้มนุษย์สามารถอ่านได้และสามารถใช้เพื่อดูการเปลี่ยนแปลงในวัตถุโซลูชันในการควบคุมแหล่งที่มาได้ นอกจากนี้ เพื่อให้สามารถจัดเก็บโซลูชันหลายรายการในที่เก็บข้อมูลและโฟลเดอร์เดียวกันได้ วัตถุโซลูชันในการควบคุมแหล่งที่มาจะไม่ถูกทำซ้ำสำหรับโซลูชันแต่ละรายการอีกต่อไป วัตถุโซลูชันจะถูกเก็บไว้ในตำแหน่งเดียวและสามารถแชร์ได้ระหว่างโซลูชันหลาย ๆ รายการในที่เก็บข้อมูลและโฟลเดอร์เดียวกัน

การพัฒนา Code-first ด้วย Git

การพัฒนา Code-first ใน Power Platform ได้รับการเปิดใช้งานโดยใช้เครื่องมือการพัฒนา เช่น Power Platform CLI, Visual Studio และส่วนขยาย Visual Studio Code การให้นักพัฒนาที่เน้นเขียนโค้ดเป็นหลักมีส่วนร่วมในกระบวนการพัฒนาโซลูชันเป็นเรื่องยากหากขาดการบูรณาการการควบคุมแหล่งที่มา เนื่องจากวัตถุต่างๆ เช่น Power Apps ตัวควบคุมกรอบงานส่วนประกอบและ Dataverse ปลั๊กอิน จะถูกปรับใช้กับโซลูชันในรูปแบบสินทรัพย์แบบแพ็กเกจที่สร้างจากโค้ดแหล่งที่มาและไม่สามารถแก้ไขได้โดยตรงใน Power Apps (make.powerapps.com) หากไม่มีการควบคุมแหล่งที่มาเป็นส่วนหนึ่งของกระบวนการพัฒนาสำหรับวัตถุที่ใช้โค้ดน้อยและวัตถุที่เน้นโค้ดเป็นหลัก การจัดการการเปลี่ยนแปลงในโซลูชันและการรับรองว่าการเปลี่ยนแปลงต่างๆ จะถูกติดตามและปรับใช้ในลักษณะที่ควบคุมได้นั้นเป็นเรื่องยาก

เมื่อเปิดใช้งานการรวม Git ใน Dataverse คุณจะได้พบกับนักพัฒนาแบบ code-first ในที่ที่พวกเขาทำงาน และมอบประสบการณ์ที่ราบรื่นสำหรับทั้งนักพัฒนาแบบ low-code และ code-first อย่างไรก็ตาม มีข้อควรพิจารณาบางประการที่ต้องคำนึงถึงเมื่อจัดการวัตถุที่ใช้โค้ดเป็นอันดับแรกในสภาพแวดล้อมที่ใช้โค้ดต่ำ

การพัฒนาแบบฟิวชันด้วยการการรวม Dataverse Git

Power Platform ให้ความสามารถสำหรับการพัฒนาทั้งแบบ low-code และ code-first บทความนี้จะกล่าวถึงกระบวนการพัฒนาที่เน้นการเขียนโค้ดเป็นอันดับแรกที่เกี่ยวข้องกับ Dataverse และการรวม Git และให้คำแนะนำเกี่ยวกับวิธีการจัดการวัตถุที่เน้นการเขียนโค้ดเป็นอันดับแรกและวัตถุที่ใช้โค้ดน้อยในสภาพแวดล้อมเดียว วัตถุ เช่น Power Apps ตัวควบคุมกรอบงานส่วนประกอบ Dataverse ปลั๊กอิน และกิจกรรมเวิร์กโฟลว์แบบกำหนดเอง เป็นตัวอย่างของวัตถุที่เน้นโค้ดเป็นอันดับแรกที่สามารถจัดการได้ในการควบคุมแหล่งที่มา

วัตถุที่เขียนโค้ดเป็นอันดับแรกและเขียนโค้ดน้อยในสภาพแวดล้อมเดียว

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

หากคุณกำลังปรับใช้วัตถุที่เขียนโค้ดเป็นอันดับแรกโดยตรงไปยังโซลูชันที่ไม่ได้รับการจัดการในสภาพแวดล้อมของผู้สร้าง เมื่อวัตถุเหล่านั้นได้รับการยืนยันไปยังการควบคุมต้นทาง เฉพาะเวอร์ชันที่คอมไพล์ (สร้างแล้ว) เท่านั้นที่จะถูกเก็บไว้ในการควบคุมต้นทาง ตัวอย่างเช่น DLL ไบนารี หากปลั๊กอิน หรือบันเดิล JavaScript ที่ทรานสไพล์และปรับให้เหมาะสมสำหรับตัวควบคุม Power Apps component framework ผลลัพธ์คือ คุณจะมีสำเนาของอ็อบเจ็กต์สองชุดในระบบควบคุมต้นฉบับ โดยชุดหนึ่งแสดงโดยเวอร์ชันที่สร้างขึ้น และอีกชุดแสดงโดยโค้ดต้นฉบับ การจัดเก็บไฟล์ไบนารีในที่เก็บของคุณอาจทำให้เกิดความสับสนและความขัดแย้งได้ หากซอร์สโค้ดและเวอร์ชันที่สร้างไม่ได้ซิงค์กัน แนวทางปฏิบัตินี้ไม่แนะนำ เนื่องจากซอร์สโค้ดควรเป็นแหล่งข้อมูลเดียวสำหรับอ็อบเจ็กต์ และควรเก็บสำเนาไว้เพียงชุดเดียว

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

ขั้นตอนถัดไป

การตั้งค่าการรวม Dataverse Git