ใช้วิธีการ ALM ที่ปรับขนาดได้โดยใช้ Microsoft Package Deployer

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

สถาปัตยกรรมอ้างอิงนี้รวม Microsoft Package Deployer, Git, Azure DevOps และ Power Platform CLI สําหรับ ALM ที่ปรับขนาดได้ ซึ่งรวมการควบคุมซอร์สโค้ด การตรวจสอบเพียร์ การปรับใช้อัตโนมัติ การจัดการโปรแกรมแก้ไขด่วน และการติดตามการปรับใช้ย้อนหลัง

Tip

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

แผนภาพสถาปัตยกรรม

เวิร์กโฟลว์

เวิร์กโฟลว์ต่อไปนี้สอดคล้องกับลําดับขั้นที่แสดงในแผนภาพสถาปัตยกรรม

ขั้นตอนที่ 1: พัฒนาและส่งการแก้ไข

นักพัฒนาใช้ Visual Studio Code ร่วมกับ Power Platform CLI เพื่อเตรียมการเปลี่ยนแปลงสำหรับการตรวจสอบโดยเพื่อนร่วมงาน

1. นักพัฒนาใช้ Visual Studio Code เพื่อจัดการการเชื่อมต่อสภาพแวดล้อมผ่าน ส่วนขยาย Power Platform Tools Visual Studio Code ส่วนขยายมีฟังก์ชันการทํางานเพื่อจัดการโปรไฟล์การตรวจสอบสิทธิ์ที่จัดเก็บการเชื่อมต่อของนักพัฒนากับสภาพแวดล้อมในเทนเนนต์ที่แตกต่างกัน

2. นักพัฒนาสร้างสาขาใน Visual Studio Code สําหรับงานของตนเอง

3. นักพัฒนาแยกโซลูชันจาก Dataverse และตั้งค่าเวอร์ชันโซลูชันโดยใช้ task ของ Power Platform CLI ที่กำหนดไว้ใน Visual Studio Code กระบวนการนี้รวมถึงการแตกไฟล์ .zip ของโซลูชันและวางไฟล์ที่แตกออกมาในโฟลเดอร์เฉพาะ

4. นักพัฒนาซอฟต์แวร์จึงเลือก ("cherry-pick") การเปลี่ยนแปลงที่เกี่ยวข้องกับงานที่เสร็จสมบูรณ์ของตน ซึ่งช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลงที่ไม่สมบูรณ์จากนักพัฒนารายอื่นในสภาพแวดล้อมการพัฒนาที่ใช้ร่วมกันจะไม่ถูกคอมมิต

5. นักพัฒนาซอฟต์แวร์จึงส่งการเปลี่ยนแปลงที่เลือกแบบ cherry-pick ไปยัง Git เป็นพูลรีเควสต์เพื่อการตรวจสอบโดยเพื่อน

ลําดับขั้นที่ 2: สร้างและตรวจสอบแพคเกจการปรับใช้

ที่เก็บ Git, Package Deployer และ Azure Pipelines จะถูกใช้เพื่อสร้างและปรับใช้แพคเกจ

1. ที่เก็บ Git

   1. ที่เก็บประกอบด้วยคอมโพเนนต์ที่อยู่ภายใต้การควบคุมซอร์สจาก Dataverse

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

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

2. Package Deployer

   1. Microsoft Package Deployer สร้างแพคเกจที่ประกอบด้วยโซลูชันและข้อมูลที่จําเป็นสําหรับการปรับใช้กับสภาพแวดล้อมปลายทาง เช่น การทดสอบและการผลิต นอกจากนี้ยังอนุญาตให้มีคุณลักษณะที่ขยายได้ผ่านรหัส C# เพื่อดําเนินการตรรกะเพิ่มเติมก่อน ระหว่าง หรือหลังการปรับใช้

   2. วางโครงการ Package Deployer ไว้ในที่เก็บเดียวกับโซลูชันที่แยกไฟล์แล้ว ซึ่งประกอบด้วยโฟลเดอร์และไฟล์ต่อไปนี้:

   • PkgAssets ประกอบด้วย .zip โซลูชันและไฟล์ข้อมูลทั้งหมดที่จะปรับใช้เป็นส่วนหนึ่งของแพคเกจ

   • ImportConfig.xml กําหนดลําดับในการปรับใช้โซลูชัน ไฟล์นี้ยังประกอบด้วยการตั้งค่าการปรับใช้สําหรับแต่ละโซลูชัน เช่น ไม่ว่าจะเขียนทับการปรับแต่งที่ไม่มีการจัดการในระหว่างการปรับใช้หรือไม่

3. สร้างไปป์ไลน์งาน

   ไปป์ไลน์ Azure สร้างโซลูชัน Package Deployer:

   1. ไปป์ไลน์จะแพ็คคอมโพเนนต์ของโซลูชันในซอร์สคอนโทรลลงในไฟล์ .zip และวางไว้ในโฟลเดอร์ PkgAssets

   2. จากนั้นไปป์ไลน์จะคอมมิตไลบรารี dynamic-link (DLL) ของแพคเกจที่อัปเดตแล้วไปยังระบบควบคุมซอร์สโค้ด

4. ไปป์ไลน์การดีพลอย

   1. ไปป์ไลน์การบิลด์จะทริกเกอร์ไปป์ไลน์ Azure นี้เมื่อเสร็จสมบูรณ์

   2. ไปป์ไลน์การปรับใช้เป็นไปป์ไลน์แบบหลายขั้นตอน:

      1. ขั้นแรก: สร้างอาร์ติแฟกต์ไปป์ไลน์สำหรับการปรับใช้ที่ประกอบด้วยแพคเกจจากโครงการ Package Deployer

      2. ขั้นที่สอง: ปรับใช้แพคเกจจากอาร์ติแฟกต์ไปยังสภาพแวดล้อม CI (การผสานรวมอย่างต่อเนื่อง)

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

         2. ปรับใช้กับสภาพแวดล้อม QA (การประกันคุณภาพ), MIG (การโยกย้าย) และ INT (การผสานรวม) พร้อมกันหรือแบบลำดับ จํานวนของขั้นตอนการปรับใช้ขึ้นอยู่กับสภาพแวดล้อมที่ใช้งานอยู่และโฟลว์การปรับใช้

ลําดับขั้นที่ 3: อนุมัติและเผยแพร่

ขั้นตอนนี้สนับสนุนการจัดส่งอย่างต่อเนื่องผ่านการออกรีลีสแบบควบคุม

1. การเผยแพร่แบบคลาสสิก ใช้อาร์ติแฟกต์ที่สร้างโดยไปป์ไลน์ก่อนหน้า และสามารถกำหนดค่าให้บังคับใช้การอนุญาตก่อนการปรับใช้ ใช้สำหรับสภาพแวดล้อมที่มีการควบคุมมากที่สุด เช่น UAT และ Production

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

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

ลําดับขั้นที่ 4: ปรับใช้และซิงโครไนซ์โปรแกรมแก้ไขด่วน

ขั้นตอนนี้สนับสนุนการปรับใช้โปรแกรมแก้ไขด่วนไปยังสภาพแวดล้อมการผลิตและการพัฒนา

นักพัฒนาทริกเกอร์ไปป์ไลน์ Azure นี้ด้วยตนเองและระบุชื่อตรรกะของโซลูชันแพตช์ ไปป์ไลน์:

1. แยกแพตช์เป็นทั้งแบบไม่มีการจัดการและแบบมีการจัดการจากสภาพแวดล้อม Hotfix

2. ปรับใช้แพตช์ที่มีการจัดการกับสภาพแวดล้อมการผลิต

3. ปรับใช้แพตช์แบบไม่มีการจัดการไปยังสภาพแวดล้อมการพัฒนา

   1. เรียกใช้สคริปต์ PowerShell ที่ใช้ การดําเนินการ AddSolutionComponent Dataverse และผสานคอมโพเนนต์โปรแกรมแก้ไขลงในโซลูชันหลัก เป็นขั้นตอนสุดท้าย สคริปต์จะลบแพตช์ออกจากสภาพแวดล้อมการพัฒนา

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

   3. เมื่อมีการปรับใช้โซลูชันไปยังระบบผลิตจริงด้วยเวอร์ชันที่สูงกว่าแพตช์ การอัปเกรดจะลบแพตช์

ลําดับขั้นที่ 5: สํารองโซลูชันการพัฒนา

Azure ไปป์ไลน์นี้จะทํางานตามกําหนดการในการสํารองข้อมูลโซลูชันการพัฒนาไปยังที่เก็บ Git ที่แยกต่างหาก

ขั้นตอนการทำงาน:

1. แยกโซลูชันทั้งที่ไม่มีการจัดการและโซลูชันที่มีการจัดการ

2. แตกไฟล์โซลูชัน

3. บันทึกการเปลี่ยนแปลงไปยังที่เก็บข้อมูลสํารอง

4. ทําให้ที่เก็บหลักทันสมัยอยู่เสมอด้วยคุณลักษณะที่ทีมคอมมิตแล้ว ในขณะที่ที่เก็บข้อมูลสํารองเก็บเวอร์ชันล่าสุด ณ เวลาที่ทริกเกอร์ตามกำหนดการทำงาน วิธีนี้ช่วยให้คุณสามารถควบคุมการปรับใช้สายหลักได้มากขึ้น

ส่วนประกอบ

สถาปัตยกรรมอ้างอิงนี้ใช้คอมโพเนนต์ต่อไปนี้:

• Visual Studio Code สําหรับ:

  • การจัดการสาขาในพื้นที่
  • การจัดการโปรไฟล์สิทธิ์การใช้งานด้วยส่วนขยาย Power Platform.
  • การแยกโซลูชันด้วย Power Platform CLI
  • การรวมการเปลี่ยนแปลงที่เลือกไว้ในการคอมมิต Git

• ที่เก็บ Git สําหรับ:

  • การควบคุมเวอร์ชัน
  • การตรวจทานพูลรีเควสต์โดยเพื่อนร่วมทีม

• Azure Boards สําหรับ:

  • การจัดการงานค้าง
  • การตรวจสอบย้อนกลับของไปป์ไลน์การปรับใช้รายการงานและรีลีส

• Azure DevOps ไปป์ไลน์เพื่อใช้ CI/CD สําหรับการปรับใช้โซลูชัน

• รีลีสของ Azureสําหรับการปรับใช้วัตถุที่ผ่านการทดสอบไปยังสภาพแวดล้อมอันดับต้น ๆ

รายละเอียดของสถานการณ์จำลอง

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

คุณสามารถใช้วิธีนี้กับหลายอุตสาหกรรมที่มีโซลูชัน Power Platform และ Dynamics 365 ขนาดใหญ่ที่ซับซ้อนซึ่งใช้ Dataverse ตัวอย่างเช่น การค้าปลีก, การเงิน, การผลิต, การดูแลสุขภาพ, ภาครัฐ, พลังงาน, การสื่อสารโทรคมนาคม, การศึกษา, ยานยนต์, องค์กรไม่แสวงหากำไร, การเล่นเกม, สื่อและความบันเทิง, การเดินทางและการโรงแรม, สิ่งอำนวยความสะดวกและอสังหาริมทรัพย์, อุตสาหกรรมการบินและอวกาศ, การเกษตร และกีฬา ใช้วิธีนี้เพื่อสร้างกระบวนการปรับใช้และตรวจสอบที่ปรับขนาดตามทีมพัฒนาและปริมาณงานของคุณ

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

พิจารณาวิธีการนี้เมื่อกําหนดกลยุทธ์สภาพแวดล้อมในระหว่างระยะค้นหาความต้องการของโครงการ

โซลูชันนี้เหมาะสมที่สุดสำหรับ:

• การติดตั้งใช้งาน Dataverse ขนาดใหญ่ที่พัฒนาโดยนักพัฒนาหลายคนในอุตสาหกรรมต่าง ๆ
• องค์กรที่จําเป็นต้องมีการควบคุมการเปลี่ยนแปลงที่แข็งแกร่ง การตรวจสอบย้อนกลับ และการสนับสนุนสําหรับการพัฒนาแบบขนาน

ผู้มีส่วนได้ส่วนเสียหลักได้แก่:

• ทีมไอที
• ทีมเทคนิค
• ผู้จัดการโครงการ

คุณสามารถใช้โซลูชันนี้เพื่อ:

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

ข้อควรพิจารณา

ข้อควรพิจารณาเหล่านี้ใช้เสาหลักของ Power Platform Well-Architected ซึ่งเป็นชุดหลักการชี้นําเพื่อช่วยปรับปรุงคุณภาพของปริมาณงาน เรียนรู้เพิ่มเติมเกี่ยวกับ Microsoft Power Platform Well-Architected

Reliability

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

• ไปป์ไลน์แบบหลายขั้นตอน: ลดความเสี่ยงในการปรับใช้โดยการตรวจสอบในแต่ละขั้นตอน

• สภาพแวดล้อม CI เฉพาะ: ตรวจจับความล้มเหลวได้ตั้งแต่เนิ่น ๆ โดยไม่ส่งผลกระทบต่อสภาพแวดล้อมอื่น ๆ

• Package deployer: รับประกันการปรับใช้และการจัดลําดับโซลูชันที่สอดคล้องกันผ่าน ImportConfig.xml

• ไปป์ไลน์โปรแกรมแก้ไขด่วน: จัดเตรียมแนวทางที่เป็นระบบสำหรับนำการแก้ไขด่วนไปใช้ในสภาพแวดล้อมทั้งการผลิตและการพัฒนา

• ไปป์ไลน์การสํารองข้อมูล: เก็บสแนปช็อตตามกําหนดเวลาของโซลูชัน DEV เพื่อให้มั่นใจถึงตัวเลือกการคืนค่า

Security

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

• การเชื่อมต่อบริการโดยใช้ service principal: ปกป้องด้วยการควบคุมการเข้าถึงตามบทบาทและการรักษาความปลอดภัยของ Dataverse ที่มีการควบคุม

• ด่านการยืนยันตัวตน: บังคับให้ยืนยันตัวตนอีกครั้งและขออนุมัติก่อนที่จะปรับใช้ไปยังระบบ production

• นโยบายแบรนช์: จําเป็นต้องมีการตรวจทานโดยเพื่อนร่วมงานก่อนผสานการเปลี่ยนแปลงลงในแบรนช์ที่ได้รับการป้องกัน

• สิทธิ์ ADO: จำกัดการเข้าถึงไปป์ไลน์และรีลีสไปยังผู้ใช้ที่ได้รับอนุญาต

ความเป็นเลิศในการดำเนินงาน

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

• การรวม Azure Boards: ให้การตรวจสอบย้อนกลับอย่างเต็มรูปแบบจากรายการงานไปจนถึงพูลรีเควสต์ บิลด์ และรีลีส

• การตรวจทานโดยเพื่อนร่วมงานและกลยุทธ์การแตกสาขา: ปรับปรุงคุณภาพโค้ดและลดความเสี่ยงการถดถอย

• การปรับใช้แบบกำหนดลำดับขั้นพร้อมขั้นตอนการอนุมัติ: ตรวจสอบให้แน่ใจว่ามีการควบคุมการปรับใช้คุณสมบัติใหม่

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

ประสิทธิภาพการทำงาน

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

• การปรับใช้แบบขนาน: เพิ่มปริมาณงานการปรับใช้และลดเวลารอ

• Power Platform CLI และการเลือกเฉพาะการเปลี่ยนแปลง: ปรับการแยกโซลูชันให้เหมาะสมและควบคุมการเปลี่ยนแปลงที่คอมมิตแล้ว

• เทมเพลต YAML สําหรับไปป์ไลน์เฉพาะ: สนับสนุนการนํากลับมาใช้ใหม่และการดูแลระบบที่ลดลง

• สภาพแวดล้อม CI: เร่งการตรวจสอบความถูกต้องโดยไม่ขึ้นกับการตรวจสอบโดยมนุษย์

การปรับปรุงประสบการณ์ใช้งาน

ทีมมีประสบการณ์ที่คล่องตัว โปร่งใส และสอดคล้องกันผ่านวงจรการพัฒนาและการปรับใช้

• Visual Studio Code และส่วนขยาย Power Platform Tools สำหรับ Visual Studio Code: ใช้เครื่องมือที่ทันสมัยและช่วยให้ได้รับประสบการณ์ที่ราบรื่นระหว่าง IDE และ Dataverse

• คำขอดึง: ส่งเสริมการทำงานร่วมกันและการแชร์ความรู้

• การขยายของ Package Deployer (ขั้นตอนก่อนหรือโพสต์): เพิ่มขั้นตอนการปรับใช้เพิ่มเติม เช่น นําเข้าข้อมูล การอัปเดตระเบียน และการตรวจสอบความถูกต้องของการปรับใช้

• รายการงานที่เชื่อมโยงกับประวัติการปรับใช้: ให้คําบรรยายของการเปลี่ยนแปลง

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

หลังจากที่คุณนำแนวทาง ALM ไปใช้ ให้ตั้งค่ากระบวนการที่มีโครงสร้างเพื่อสร้างบันทึกประจำรุ่นที่สื่อสารการเปลี่ยนแปลงและการอัปเดตได้อย่างชัดเจน

ตัวอย่างเช่น คุณอาจใช้:

• การเขียนสคริปต์เพื่ออ่านรายการงานที่เชื่อมโยงและสร้างข้อมูลสรุป
• ตัวแทน Microsoft Copilot Studio เพื่อดึงรายละเอียดจาก Azure DevOps API ผ่านเซิร์ฟเวอร์ Model Context Protocol (MCP) และสร้างบันทึกย่อประจํารุ่นโดยอัตโนมัติ

ผู้สนับสนุน

Microsoft ดูแลบทความนี้ ผู้เขียนต่อไปนี้ได้เขียนบทความนี้

ผู้เขียนหลัก:

• Gonçalo Fernandes, Power Platform/Dynamics 365 Solution Architect

แหล่งข้อมูลที่เกี่ยวข้อง

• บทนําสู่โซลูชัน Microsoft Dataverse
• สร้างแพตช์เพื่อลดความซับซ้อนในการอัปเดตโซลูชัน
• สร้างแพคเกจสําหรับเครื่องมือ Package Deployer
• Microsoft Power Platform CLI คืออะไร?
• ติดตั้งส่วนขยาย Visual Studio Code เครื่องมือ Power Platform
• สร้างโครงการใหม่ใน Visual Studio
• การอ้างอิง Schema YAML สําหรับ Azure Pipelines
• ไปป์ไลน์เผยแพร่แบบคลาสสิก
• การควบคุมซอร์สโค้ดใน VS Code
• เริ่มต้นใช้งาน PowerShell