จัดระเบียบโซลูชันของคุณ

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

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

ส่วนต่อไปนี้แสดงกลยุทธ์สามประการที่จัดเรียงจากที่ง่ายที่สุดไปยังที่ซับซ้อนที่สุดและเน้นข้อดีและข้อเสียที่เกี่ยวข้อง

กลยุทธ์โซลูชันเดียว

การกําหนดค่าทั้งหมดจะถูกจัดกลุ่มเป็นหนึ่งโซลูชันที่ไม่มีการจัดการในระหว่างการพัฒนา ซึ่งจะถูกส่งออกเป็นโซลูชันที่มีการจัดการเดียวสําหรับการปรับใช้ในภายหลัง

แนะนําสําหรับ:

• การใช้งานในระดับกลางขนาดเล็ก
• สถานการณ์ที่การแยกส่วนข้อมูลในอนาคตไม่น่าเป็นไปได้

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

หมายเหตุ

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

โซลูชันหลายตัวในสภาพแวดล้อมการพัฒนาเดียวกัน

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

แนะนําสําหรับ:

• การใช้งานในระดับกลางขนาดเล็กที่มีพื้นที่การทํางานเฉพาะและอิสระซึ่งไม่ใช้คอมโพเนนต์ร่วมกัน

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

หมายเหตุ

เมื่อคุณมีโซลูชันหลายตัวในสภาพแวดล้อมการพัฒนาเดียวกัน หลังจากนําเข้าโซลูชันที่มีการจัดการไปยังสภาพแวดล้อมเป้าหมายของคุณ แล้วคุณมักจะสร้างเลเยอร์ ข้อมูลเพิ่มเติม: เลเยอร์โซลูชันและลักษณะการทํางานของการผสาน

สิ่งสําคัญคือคุณต้อง:

• อย่ารวมคอมโพเนนต์ที่ไม่มีการจัดการเดียวกันในโซลูชันมากกว่าหนึ่งโซลูชัน
• มีโซลูชันเดียวเท่านั้นที่มีตารางทั้งหมดของคุณ ไม่มีโซลูชันสองชุดที่แต่ละชุดมีตาราง เนื่องจากมักมีความเสี่ยงของความสัมพันธ์เดียวระหว่างตาราง ซึ่งสร้างการขึ้นต่อกันระหว่างโซลูชัน และทำให้เกิดปัญหาในการอัปเกรดหรือลบโซลูชันในสภาพแวดล้อมเป้าหมายในภายหลัง
• ใช้ผู้เผยแพร่โซลูชันเดียวเท่านั้น ผู้เผยแพร่โซลูชันเป็นเจ้าของคอมโพเนนต์ของโซลูชันที่มีการจัดการ และความสัมพันธ์ไม่สามารถเปลี่ยนในภายหลัง ตัวอย่างเช่น ถ้ามีการนําเข้าตารางแบบกําหนดเองผ่านโซลูชัน A ที่มี Publisher X คุณจะไม่สามารถย้ายตารางนั้นไปยังโซลูชัน B ด้วย Publisher Y ได้ในภายหลัง ตัวเลือกเดียวคือการลบตาราง อัปเกรดโซลูชัน A เพื่อลบตารางออกจากระบบเป้าหมาย จากนั้นสร้างตารางในโซลูชัน B ด้วย Publisher Y และนําเข้าโซลูชัน B กระบวนการนี้ส่งผลให้สูญเสียข้อมูลทั้งหมดที่เก็บในตารางแบบกําหนดเอง เว้นแต่ว่าข้อมูลจะถูกโยกย้ายไว้ล่วงหน้า
• หลีกเลี่ยงการสร้างการขึ้นต่อกันระหว่างโซลูชัน การพึ่งพาอาศัยกันกำหนดลำดับการนำเข้าและอาจทำให้เกิดปัญหาได้ ตัวอย่างเช่น ถ้าคุณมีโซลูชันหนึ่งสําหรับตารางและอีกโซลูชันหนึ่งสําหรับโฟลว์ระบบคลาวด์ และโฟลว์อาศัยคอลัมน์แบบกําหนดเอง โฟลว์จะทํางานในการพัฒนาเนื่องจากมีคอลัมน์อยู่ อย่างไรก็ตาม หากมีการนําเข้าโซลูชันโฟลว์ระบบคลาวด์ในสภาพแวดล้อมเป้าหมาย เท่านั้น กระบวนการนําเข้าอาจไม่จดจําการขึ้นต่อกันบนคอลัมน์แบบกําหนดเอง ผลที่ได้คือโซลูชันโฟลว์ได้รับการติดตั้งสำเร็จแต่ฟลูว์ไม่สามารถทำงานได้ ข้อมูลเพิ่มเติม: ตัวอย่างของการขึ้นต่อกันที่สร้างขึ้นโดยโซลูชันหลายตัว

ตัวอย่างของการขึ้นต่อกันที่สร้างขึ้นโดยโซลูชันหลายตัว

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

โซลูชันหลายตัวพร้อมสภาพแวดล้อมการพัฒนาเฉพาะ

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

แนะนําสําหรับ:

• โครงการองค์กรขนาดใหญ่
• ทีมที่มีนักพัฒนาหรือคู่ค้าหลายราย
• สถานการณ์ที่จําเป็นต้องมีการกํากับดูแลอย่างเข้มงวดและไปป์ไลน์ CI/CD

ประโยชน์	ความเสียเปรียบ
ง่ายต่อการขยายและพัฒนาระบบของคุณโดยการเพิ่มหรืออัปเดตโมดูลโดยไม่ส่งผลกระทบต่อผู้อื่น	โครงสร้างพื้นฐานและค่าใช้จ่ายในการบํารุงรักษาที่สูงขึ้น
ทีมหลายคนสามารถทํางานคู่ขนานกับโมดูลที่แตกต่างกันได้โดยไม่มีความขัดแย้งกับการเปลี่ยนแปลงของกันและกัน	จําเป็นต้องใช้กลยุทธ์ด้านสภาพแวดล้อมและการกํากับดูแล
ใช้การทดสอบอัตโนมัติและแนวทางปฏิบัติ DevOps ได้ง่ายขึ้น	การปรับใช้ที่ซับซ้อนมากขึ้น
โซลูชันขนาดเล็กกว่าจะปรับใช้ได้เร็วกว่า โดยเฉพาะอย่างยิ่งในไปป์ไลน์ CI/CD ถ้าคุณจําเป็นต้องปรับใช้แอปเฉพาะ
ข้อบกพร่องหรือการถดถอยจะง่ายต่อการติดตามเมื่อมีการแยกการเปลี่ยนแปลงไปยังโมดูลเฉพาะ

วิธีการสร้างการจัดเลเยอร์โซลูชันของคุณ

หมายเหตุ

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

1. ในสภาพแวดล้อมการพัฒนา "พื้นฐาน" คุณมีโซลูชันพื้นฐานของคุณด้วยตารางที่ไม่มีการจัดการทั่วไปและไม่มีตารางอื่น ๆ จากนั้นส่งออกโซลูชันนี้ในรูปแบบที่จัดการแล้ว
2. คุณตั้งค่าสภาพแวดล้อมการพัฒนาที่สองสําหรับส่วนขยายหรือเลเยอร์ "แอป" ที่จะอยู่ด้านบนของเลเยอร์ฐานในภายหลัง
3. คุณนําเข้าเลเยอร์พื้นฐานที่มีการจัดการลงในสภาพแวดล้อมการพัฒนาเลเยอร์ของแอปและสร้างโซลูชันที่ไม่มีการจัดการสําหรับเลเยอร์ของแอป
4. ตอนนี้คุณสามารถขยายแบบจําลองข้อมูลโดยการเพิ่มตาราง คอลัมน์ ความสัมพันธ์ของตาราง ปลั๊กอิน โฟลว์ และอื่น ๆ เพิ่มเติมไปยังโซลูชัน "แอป" ที่เฉพาะเจาะจง จากนั้น ส่งออกโซลูชันของแอปเป็นแบบที่มีการจัดการ โปรดสังเกตว่าโซลูชันแอปยังคงขึ้นอยู่กับโซลูชันเลเยอร์พื้นฐาน แต่การจัดการโซลูชันหลายวิธีเป็นวิธีที่ดีกว่า พิจารณาตัวอย่างที่กล่าวถึงก่อนโฟลว์ที่อาศัยคอลัมน์แบบกําหนดเอง ในกรณีส่วนใหญ่ ทั้งคอลัมน์แบบกําหนดเองและโฟลว์อยู่ในโซลูชันแอปเดียวกัน แต่แม้ว่าคอลัมน์แบบกําหนดเองเป็นส่วนหนึ่งของโซลูชันพื้นฐาน คุณต้องดําเนินการและปรับใช้โซลูชันฐานที่มีการจัดการก่อน มิฉะนั้น โฟลว์ภายในโซลูชันแอปจะไม่สามารถสร้างได้
5. ในสภาพแวดล้อมการทำงานจริงของคุณ คุณนำเข้าเลเยอร์ฐานที่มีการจัดการ แล้วจากนั้น นำเข้าเลเยอร์แอปที่มีการจัดการ การดําเนินการนี้จะสร้างเลเยอร์ที่มีการจัดการสองชั้นในสภาพแวดล้อมที่มีการขึ้นต่อกันที่ชัดเจนระหว่างโซลูชันที่มีการจัดการ
6. ทําซ้ํารูปแบบนี้เพื่อให้มีโซลูชันที่แตกต่างกันมากเท่าที่คุณต้องการ แม้ว่าเราจะแนะนำให้คุณรักษาจำนวนโซลูชันให้น้อยที่สุดเท่าที่จะเป็นไปได้ เพื่อให้สามารถจัดการเลเยอร์โซลูชันของคุณได้

บทความที่เกี่ยวข้อง

ใช้การแบ่งเซกเมนต์ตาราง
สถานการณ์สมมติที่ 5: การสนับสนุนการพัฒนาทีม