คำแนะนำสำหรับการกำหนดเครื่องมือและกระบวนการให้เป็นมาตรฐาน

นำไปใช้กับคำแนะนำรายการตรวจสอบความเป็นเลิศในการดำเนินงานของ Power Platform Well-Architected:

OE:04	เพิ่มประสิทธิภาพการพัฒนาซอฟต์แวร์และกระบวนการประกันคุณภาพโดยปฏิบัติตามแนวทางปฏิบัติที่ได้รับการพิสูจน์แล้วในอุตสาหกรรมสำหรับการพัฒนาและการทดสอบ สำหรับการกำหนดบทบาทที่ชัดเจน ให้กำหนดแนวทางปฏิบัติสำหรับส่วนประกอบต่างๆ ให้เป็นมาตรฐาน เช่น เครื่องมือ การควบคุมแหล่งที่มา รูปแบบการออกแบบแอปพลิเคชัน คู่มือ และคู่มือสไตล์

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

กลยุทธ์การออกแบบที่สำคัญ

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

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

ใช้เครื่องมือที่มีอยู่ในแพลตฟอร์ม

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

เครื่องมือควรมีฟังก์ชันดังต่อไปนี้:

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

ในบางกรณี เครื่องมือหรือชุดเครื่องมือหนึ่งอย่างอาจมีหลายฟังก์ชัน ตรวจสอบให้แน่ใจว่าคุณเข้าใจความสามารถของเครื่องมือและข้อจำกัดต่างๆ เพื่อให้ตรงตามความต้องการของคุณในฟังก์ชันต่างๆ

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

ใช้เครื่องมือ AI เมื่อใช้งานได้จริง เครื่องมือ AI สามารถช่วยในการพัฒนา การตรวจสอบ และการปรับโค้ดให้เหมาะสมได้

กำหนดกรอบการกำกับดูแลสำหรับการพัฒนาร่วมกัน

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

สร้างมาตรฐานให้กับระบบควบคุมแหล่งที่มาและแนวทางปฏิบัติของคุณ

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

ตรวจสอบให้แน่ใจว่าการกำหนดเวอร์ชันของโซลูชันนั้นแม่นยำ โดยปฏิบัติตามหลักเกณฑ์ของ Sprint และนักพัฒนาที่กำหนดไว้ใน ใช้แนวทางปฏิบัติ Scrum สำหรับทีมของคุณใน Azure Boards ผลการทดสอบจากคำขอดึงอาจอยู่ในรูปแบบของภาพหน้าจอหรือวิดีโอที่แสดงฟังก์ชันการทำงานที่สร้างขึ้น การทำให้กระบวนการกำกับดูแลการดึงคำขอเป็นแบบอัตโนมัติช่วยให้มั่นใจในคุณภาพของโค้ดโดยไม่ต้องมีการตรวจทานสำหรับการตรวจสอบพื้นฐานด้วยตนเอง เช่น เวอร์ชันของโซลูชัน

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

ประเมินผลเมตริกเพื่อวัดประสิทธิภาพ

ทีมพัฒนาและการประกันคุณภาพสามารถปรับปรุงได้ก็ต่อเมื่อพวกเขาประเมินประสิทธิผลในเชิงปริมาณเท่านั้น ในการวัดผลด้านประสิทธิภาพ พวกเขาต้องระบุเมตริกที่วัด ความเร็วของนักพัฒนา และกำหนดตัวบ่งชี้ประสิทธิภาพหลัก (KPI)

ตัวอย่างของเมตริกเหล่านี้ ได้แก่:

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

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

สร้างมาตรฐานให้กับวิธีที่ทีมจัดการเวิร์กโหลดของคุณเขียน ตรวจทาน และจัดทำเอกสารโค้ด

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

คู่มือสไตล์ควรครอบคลุมถึง:

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

เรียนรู้เพิ่มเติมเกี่ยวกับ แนวทางการเขียนโค้ด Power Automate และ แนวทางการเขียนโค้ด Power Apps

เคล็ดลับ

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

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

ใช้มาตรฐานและหลักเกณฑ์ในการจัดการปัญหาหนี้ทางเทคนิค

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

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

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

ใช้แนวทางการเลื่อนไปทางซ้ายเพื่อทดสอบ

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

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

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

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

การอำนวยความสะดวก Power Platform

ไปป์ไลน์ใน Power Platform มุ่งหวังที่จะทำให้การจัดการวงจรชีวิตของแอปพลิเคชัน (ALM) เท่าเทียมกันสำหรับลูกค้า Power Platform และ Dynamics 365 โดยการนำระบบอัตโนมัติของ ALM และความสามารถในการรวมอย่างต่อเนื่องและการจัดส่งอย่างต่อเนื่อง (CI/CD) มาใส่ในบริการ

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

Microsoft Power Platform Build Tools สำหรับ Azure DevOps สามารถใช้เพื่อทำให้งานการสร้างและปรับใช้งานทั่วไปที่เกี่ยวข้องกับแอปที่สร้างบน Power Platform เป็นแบบอัตโนมัติ

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

Web API ตัวตรวจสอบ Power Apps มีกลไกในการเรียกใช้การตรวจสอบการวิเคราะห์แบบคงที่กับการปรับแต่ง และส่วนขยายให้กับแพลตฟอร์ม Microsoft Dataverse

Test Studio ให้คุณสามารถสร้างการทดสอบ UI ทั้งระบบสำหรับแอปพื้นที่ทำงานของคุณ

ทำการทดสอบอัตโนมัติกับ Azure Pipelines

เครื่องมือตรวจสอบโค้ด Power CAT ช่วยให้คุณสามารถดำเนินการตรวจสอบโค้ดได้

Power CAT Copilot Studio Kit ช่วยให้คุณสามารถกำหนดค่าเอเจนต์และการทดสอบ เมื่อเรียกใช้การทดสอบแต่ละรายการกับ Copilot Studio API (Direct Line) การตอบของเอเจนต์จะได้รับการประเมินเทียบกับผลลัพธ์ที่คาดไว้

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

Microsoft Power Platform CLI (PAC CLI) เป็นเครื่องมือบรรทัดคำสั่งที่รองรับการนำเข้าและส่งออกโซลูชัน Power Platform และการบรรจุและการแยกออกจากไฟล์ต้นฉบับของโซลูชัน Power Platform PAC CLI มีให้บริการในรูปแบบ เครื่องมือบรรทัดคำสั่งแบบสแตนด์อโลน หรือเป็น ส่วนขยายสำหรับ Visual Studio Code

เครื่องมือและบริการอื่นๆ ที่สามารถช่วยคุณสร้างมาตรฐานการพัฒนา ได้แก่:

• Azure DevOps เป็นคอลเลกชันบริการที่คุณสามารถใช้เพื่อสร้างแนวทางปฏิบัติในการพัฒนาที่มีการทำงานร่วมกัน มีประสิทธิภาพ และสอดคล้องกัน Azure DevOps รวมโซลูชันต่อไปนี้:

  • ไปป์ไลน์ Azure บริการระบบคลาวด์ที่ให้บริการสร้างและเผยแพร่เพื่อรองรับ CI/CD ของแอปพลิเคชันของคุณ
  • Azure Boards เครื่องมือการจัดการงานบนเว็บที่รองรับแนวทางปฏิบัติแบบคล่องตัว เช่น Scrum และ Kanban
  • Azure Repos เครื่องมือควบคุมเวอร์ชันที่รองรับระบบควบคุมเวอร์ชันแบบกระจาย Git และระบบควบคุมเวอร์ชัน Team Foundation
  • Azure Test Plans เป็นโซลูชันการจัดการกับการทดสอบบนเบราว์เซอร์ ซึ่งมีความสามารถที่จำเป็นสำหรับการทดสอบด้วยตนเองตามแผน การทดสอบการยอมรับของผู้ใช้ การทดสอบเชิงสำรวจ และการรวบรวมข้อคิดเห็นจากผู้เกี่ยวข้อง

• GitHub Projects เครื่องมือการจัดการงานที่คุณสามารถใช้สร้างบอร์ดคัมบัง รายงาน แดชบอร์ด และฟังก์ชันอื่นๆ

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

การกำกับดูแลการพัฒนาโค้ด

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

รายการตรวจสอบความเป็นเลิศในการดำเนินงาน