คำแนะนำสำหรับการออกแบบห่วงโซ่อุปทานการพัฒนาปริมาณงาน
นำไปใช้กับคำแนะนำรายการตรวจสอบความเป็นเลิศในการปฏิบัติงานที่ได้รับการออกแบบอย่างดีนี้: Power Platform
| โออี:06 | สร้างห่วงโซ่อุปทานปริมาณงานที่ขับเคลื่อนการเปลี่ยนแปลงที่เสนอผ่านไปป์ไลน์อัตโนมัติที่คาดการณ์ได้ ไปป์ไลน์ทดสอบและส่งเสริมการเปลี่ยนแปลงเหล่านั้นในสภาพแวดล้อม เพิ่มประสิทธิภาพ ห่วงโซ่อุปทาน เพื่อให้ภาระงานของคุณเชื่อถือได้ ปลอดภัย คุ้มต้นทุน และทำงานได้ดี |
|---|
คู่มือนี้อธิบายคำแนะนำสำหรับการออกแบบห่วงโซ่อุปทานการพัฒนาปริมาณงานที่อิงจากไปป์ไลน์การผสานรวมอย่างต่อเนื่องและการส่งมอบอย่างต่อเนื่อง (CI/CD) ในปริมาณงานบนคลาวด์ ห่วงโซ่อุปทานคือชุดเครื่องมือและกระบวนการมาตรฐานที่คุณใช้เพื่อส่งผลต่อการกำหนดค่าและการเปลี่ยนแปลงปริมาณงานทั่วสภาพแวดล้อม พัฒนาห่วงโซ่อุปทานเพื่อให้แน่ใจว่าคุณมีวิธีการที่เป็นมาตรฐานและคาดการณ์ได้ในการรักษาปริมาณงานของคุณ ไปป์ไลน์ CI/CD เป็นการแสดงห่วงโซ่อุปทานอย่างชัดเจน แต่คุณควรมีห่วงโซ่อุปทานเดียว คุณอาจมีท่อหลายท่อที่ปฏิบัติตามกระบวนการเดียวกันและใช้เครื่องมือเดียวกัน
รวมห่วงโซ่อุปทานเพื่อปกป้องปริมาณงานของคุณจากความเสียหายที่อาจเกิดขึ้นเมื่อคุณไม่ได้จัดการการเปลี่ยนแปลงปริมาณงานอย่างเหมาะสม ควรตระหนักถึงสถานะภาระงานของคุณอยู่เสมอ เพื่อที่คุณจะได้ไม่เสี่ยงต่อการเกิดพฤติกรรมที่ไม่อาจคาดเดาได้ ความเสี่ยงนี้จะเพิ่มขึ้นหากคุณต้องใช้เวลานานในการย้อนรอยการเปลี่ยนแปลงที่ไม่ได้รับการอธิบายเมื่อมีปัญหาเกิดขึ้น เพื่อลดความเสี่ยงเหล่านี้ ให้สร้างมาตรฐานให้กับกระบวนการและเครื่องมือที่กำหนดห่วงโซ่อุปทานของคุณ และตรวจสอบให้แน่ใจว่าทีมปริมาณงานของคุณมุ่งมั่นใช้งานอย่างเต็มที่
กลยุทธ์การออกแบบที่สำคัญ
คำแนะนำต่อไปนี้สามารถช่วยให้คุณกำหนดหลักการสำคัญของห่วงโซ่อุปทานของคุณได้
ทำการเปลี่ยนแปลงปริมาณงานที่เสนอผ่านกระบวนการและเครื่องมือของห่วงโซ่อุปทาน บังคับใช้นโยบายการปรับใช้ตามเทมเพลตอัตโนมัติที่เข้มงวด วิธีการนี้ช่วยให้มั่นใจว่าการกำหนดค่าปริมาณงานของคุณในทุกสภาพแวดล้อมนั้นมีมาตรฐาน มีนิยามชัดเจน และควบคุมอย่างเข้มงวด สำหรับสภาพแวดล้อมในห่วงโซ่การส่งเสริมการขายรหัส อย่าทำการอัปเดตโดยใช้กระบวนการด้วยตนเองหรือการโต้ตอบของมนุษย์ รวมการเปลี่ยนแปลงทั้งหมดเข้ากับสภาพแวดล้อมผ่านไปป์ไลน์โดยปฏิบัติตามแนวทางปฏิบัติในการปรับใช้ที่คุณกำหนด เพื่อช่วยบังคับใช้นโยบายนี้ ให้พิจารณาจำกัดการเข้าถึงแบบอ่านอย่างเดียวเป็นค่าเริ่มต้น และใช้การตรวจสอบการอนุญาตการเข้าถึงเพื่ออนุญาตการเข้าถึงแบบเขียน
สิ่งสำคัญของหลักการนี้คือการเปลี่ยนแปลงทั้งหมดเป็น การเปลี่ยนแปลงที่เสนอ จนกว่าจะนำไปใช้จริง ด้วยการทดสอบอัตโนมัติ เช่น การผสานรวมและการทดสอบพื้นฐานของระบบ คุณสามารถทำให้ห่วงโซ่อุปทานของคุณปฏิเสธการเปลี่ยนแปลงได้โดยอัตโนมัติ
ใช้แอสเซทโค้ดและอาร์ติแฟกต์ชุดเดียวในทุกสภาพแวดล้อมและไปป์ไลน์ จุดบอดที่พบบ่อยสำหรับองค์กรคือเมื่อสภาพแวดล้อมที่ไม่ใช่การทำงานจริงแตกต่างจากสภาพแวดล้อมการทำงานจริง การสร้างสภาพแวดล้อมการทำงานจริงและที่ไม่ใช่การทำงานจริงด้วยตนเองอาจส่งผลให้เกิดการตั้งค่าคอนฟิกที่ไม่ตรงกันระหว่างสภาพแวดล้อม ความไม่ตรงกันนี้จะทำให้การทดสอบช้าลง และทำให้มีแนวโน้มมากขึ้นที่การเปลี่ยนแปลงอาจเป็นอันตรายต่อระบบการทำงานจริง
สะท้อนโครงสร้างองค์กรของคุณในการออกแบบห่วงโซ่อุปทานและไปป์ไลน์ คุณอาจแยกองค์กรของคุณเป็นไซโลระหว่างทีม แต่ละทีมอาจจัดการส่วนหนึ่งของห่วงโซ่อุปทาน ตัวอย่างเช่น หลายองค์กรมีทีมที่จัดการการตั้งค่าความปลอดภัยและการปฏิบัติตามข้อกำหนด หรือการกำหนดค่าสภาพแวดล้อม ทีมเหล่านี้แยกจากทีมพัฒนาที่จัดการการพัฒนาแอปพลิเคชัน การทดสอบ และการปรับใช้ มีหลายวิธีในการจัดระเบียบทีมที่เกี่ยวข้องกับห่วงโซ่อุปทาน ห่วงโซ่อุปทานของคุณต้องอาศัยทุกทีมที่ทำงานร่วมกันอย่างราบรื่น ตรวจสอบให้แน่ใจว่าทุกทีมปฏิบัติตามกระบวนการมาตรฐานและใช้เครื่องมือมาตรฐานเพื่อทำให้ห่วงโซ่อุปทานมีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้
ห่วงโซ่อุปทาน ของคุณอาจต้องพึ่งพาผู้ขายรายที่สาม หากคุณเอาท์ซอร์สส่วนต่างๆ ของวงจรชีวิตเวิร์กโหลด ผู้ขายเหล่านี้มีความสำคัญต่อความสำเร็จของ ห่วงโซ่อุปทาน ของคุณพอๆ กับทรัพยากรภายใน ตรวจสอบให้แน่ใจว่ามีข้อตกลงร่วมกันระหว่างทีมทั้งหมดเกี่ยวกับกระบวนการและเครื่องมือที่คุณใช้
สร้างมาตรฐานวิธีการปรับใช้ของคุณ พูดคุยกับเจ้าของผลิตภัณฑ์เกี่ยวกับจำนวนการหยุดทำงานของการทำงานจริงที่ยอมรับได้สำหรับปริมาณงานของคุณ คุณสามารถเลือกวิธีการปรับใช้ที่เหมาะกับความต้องการของคุณ โดยขึ้นอยู่กับเวลาหยุดทำงานที่ยอมรับได้ (หากมี) ตามหลักการแล้ว คุณควรดำเนินการปรับใช้ระหว่างช่วงการบำรุงรักษาเพื่อลดความซับซ้อนและความเสี่ยง
วางแผนกลยุทธ์การทดสอบแบบองค์รวม หลักการสำคัญประการหนึ่งของความน่าเชื่อถือของระบบคือหลักการ "เลื่อนไปทางซ้าย" การพัฒนาและการปรับใช้แอปพลิเคชันเป็นกระบวนการที่แสดงในรูปชุดขั้นตอนจากซ้ายไปขวา คุณไม่ควรจำกัดการทดสอบไว้ที่จุดสิ้นสุดของกระบวนการ ให้เลื่อนการทดสอบไปที่จุดเริ่มต้นหรือไปทางซ้ายให้มากที่สุด การซ่อมแซมข้อผิดพลาดจะถูกกว่าเมื่อคุณพบข้อผิดพลาดตั้งแต่เนิ่นๆ อาจมีค่าใช้จ่ายสูงหรือแก้ไขไม่ได้เลยในภายหลังในวงจรชีวิตแอปพลิเคชัน
เมื่อเป็นไปได้ ให้ใช้การทดสอบอัตโนมัติเพื่อให้มั่นใจว่ามีความสอดคล้องกัน รวมการทดสอบประเภทต่อไปนี้ในการออกแบบห่วงโซ่อุปทานของคุณ:
การทดสอบยูนิต: การทดสอบยูนิตโดยทั่วไปจะดำเนินการเป็นส่วนหนึ่งของกิจวัตรการรวมอย่างต่อเนื่อง การทดสอบหน่วยควรจะครอบคลุมและรวดเร็ว ควรครอบคลุมโค้ดได้ 100 เปอร์เซ็นต์ ใช้การทดสอบหน่วยกับเนื้อหาโค้ดทั้งหมด รวมถึงเทมเพลตและสคริปต์
การทดสอบควัน: การทดสอบควันจะช่วยยืนยันว่าสามารถรับภาระงานในสภาพแวดล้อมการทดสอบได้ และดำเนินการได้ตามที่คาดหวัง การทดสอบพื้นฐานของระบบไม่ได้ตรวจสอบการทำงานร่วมกันของส่วนประกอบต่างๆ การทดสอบพื้นฐานของระบบจะตรวจสอบว่าวิธีการปรับใช้สำหรับโครงสร้างพื้นฐานและแอปพลิเคชันใช้งานได้หรือไม่ และระบบตอบสนองตามที่ตั้งใจไว้หรือไม่หลังจากกระบวนการเสร็จสิ้น
การทดสอบบูรณาการ: การทดสอบบูรณาการช่วยให้แน่ใจว่าส่วนประกอบของแอปพลิเคชันทำงานแยกกัน และจากนั้นจึงกำหนดว่าส่วนประกอบต่างๆ สามารถโต้ตอบกันได้หรือไม่ อาจใช้เวลานานพอสมควรในการเรียกใช้ชุดทดสอบการรวมขนาดใหญ่ ดังนั้น จึงควรนำหลักการเลื่อนซ้ายมาใช้และทำการทดสอบในช่วงต้นของวงจรชีวิตการพัฒนาซอฟต์แวร์ สำรองการทดสอบการรวมสำหรับสถานการณ์ที่คุณไม่สามารถทดสอบด้วยการทดสอบพื้นฐานของระบบหรือการทดสอบหน่วย คุณสามารถเรียกใช้กระบวนการทดสอบที่ใช้เวลานานในช่วงเวลาปกติได้หากจำเป็น ช่วงเวลาปกติเป็นการประนีประนอมที่ดี และตรวจพบปัญหาการทำงานร่วมกันระหว่างส่วนประกอบของแอปพลิเคชันไม่เกินหนึ่งวันหลังจากเปิดตัว สถานการณ์การทดสอบบางสถานการณ์ได้รับประโยชน์จากการเรียกใช้ด้วยตนเอง ใช้การทดสอบด้วยตนเองเมื่อคุณต้องการนำองค์ประกอบการโต้ตอบของมนุษย์มาสู่การทดสอบ
การทดสอบการยอมรับ: คุณสามารถดำเนินการทดสอบการยอมรับด้วยตนเองได้ ขึ้นอยู่กับบริบท โดยอาจเป็นแบบอัตโนมัติบางส่วนหรือทั้งหมดก็ได้ การทดสอบการยอมรับจะกำหนดว่าระบบซอฟต์แวร์มีคุณสมบัติตรงตามข้อมูลจำเพาะที่กำหนดหรือไม่ วัตถุประสงค์หลักของการทดสอบนี้คือเพื่อประเมินความสอดคล้องของระบบกับข้อกำหนดทางธุรกิจและเพื่อพิจารณาว่าระบบตรงตามเกณฑ์ที่กำหนดสำหรับการส่งมอบให้กับผู้ใช้หรือไม่
นำเกตคุณภาพไปใช้ตลอดกระบวนการส่งเสริมโค้ดของคุณด้วยการทดสอบ ปรับใช้โค้ดของคุณในสภาพแวดล้อมระดับต่ำ เช่น การประกันคุณภาพและการทดสอบ และยกระดับขึ้นผ่านสภาพแวดล้อมที่สูงขึ้น เช่น การจัดเตรียมและการใช้งานจริง เมื่อการปรับใช้งานของคุณผ่านการตรวจสอบคุณภาพ ตรวจสอบให้แน่ใจว่าเป็นไปตามเป้าหมายคุณภาพของคุณก่อนที่การเปลี่ยนแปลงจะถูกนำไปใช้งานจริง ความต้องการทางธุรกิจของคุณจะเป็นตัวกำหนดว่าจุดเน้นของการตรวจสอบคุณภาพของคุณคืออะไร นอกจากนี้ ให้พิจารณาหลักการพื้นฐานที่ออกแบบสถาปัตยกรรมมาอย่างดีด้วย ได้แก่ ความปลอดภัย ความน่าเชื่อถือ และประสิทธิภาพการทำงาน Power Platform
และให้รวมขั้นตอนการอนุมัติเข้ากับการตรวจสอบคุณภาพของคุณ กำหนดอย่างชัดเจนและทำให้เวิร์กโฟลว์การอนุมัติเป็นอัตโนมัติเมื่อเหมาะสม กำหนดเกณฑ์การยอมรับคุณภาพลงในระบบอัตโนมัติของคุณ เพื่อให้คุณสามารถเคลื่อนตัวผ่านประตูของคุณได้อย่างมีประสิทธิภาพและปลอดภัย
การอำนวยความสะดวก Power Platform
ไปป์ไลน์ใน Power Platform มีจุดมุ่งหมายเพื่อทำให้การจัดการวงจรชีวิตแอปพลิเคชัน (ALM) เป็นประชาธิปไตยสำหรับ Power Platform และลูกค้า Dynamics 365 โดยนำการทำงานอัตโนมัติของ ALM และการบูรณาการอย่างต่อเนื่องและความสามารถในการส่งมอบอย่างต่อเนื่อง (CI/CD) เข้ามาในบริการ
Microsoft Power Platform Build Tools สำหรับ Azure DevOps สามารถใช้ในการสร้างและปรับใช้งานทั่วไปที่เกี่ยวข้องกับแอปที่สร้างบน Power Platform โดยอัตโนมัติ
GitHub Actions ช่วยให้ผู้พัฒนาสามารถสร้างเวิร์กโฟลว์วงจรชีวิตการพัฒนาซอฟต์แวร์อัตโนมัติได้ Power Platform ด้วย GitHub Actions สำหรับ Microsoft Power Platform คุณสามารถสร้างเวิร์กโฟลว์ในที่เก็บของคุณเพื่อสร้าง ทดสอบ แพคเกจ นำออกใช้ และปรับใช้แอป ดำเนินการระบบอัตโนมัติ และจัดการบอทและส่วนประกอบอื่นๆ ที่สร้างขึ้นใน Power Platform
ALM Accelerator คือเครื่องมือโอเพ่นซอร์สที่ประกอบด้วยชุดแอปพลิเคชัน สคริปต์ และไปป์ไลน์ที่ออกแบบมาเพื่อทำกระบวนการบูรณาการต่อเนื่อง/ส่งมอบต่อเนื่องให้เป็นอัตโนมัติ
ทำการทดสอบอัตโนมัติด้วย Azure Pipelines
Power Apps API เว็บตัวตรวจสอบ ให้กลไกในการรันการตรวจสอบการวิเคราะห์แบบคงที่กับการปรับแต่งและส่วนขยายของ Microsoft Dataverse แพลตฟอร์ม
Microsoft Power Platform CLI (PAC CLI) เป็นเครื่องมือบรรทัดคำสั่งที่รองรับการนำเข้าและส่งออก Power Platform โซลูชัน รวมถึงการแพ็กและการแกะจากไฟล์ต้นทางของ Power Platform โซลูชัน PAC CLI มีให้ใช้งานในรูปแบบ เครื่องมือบรรทัดคำสั่งแบบสแตนด์อโลน หรือเป็น ส่วนขยายสำหรับ Visual Studio โค้ด
คุณสามารถใช้ Terraform, Bicep และ Azure Resource Manager สำหรับการปรับใช้โครงสร้างพื้นฐานที่ไม่เปลี่ยนรูปแบบเป็นโค้ด (IaC) ขึ้นอยู่กับความต้องการของคุณและความคุ้นเคยของทีมกับเครื่องมือ คุณอาจใช้เครื่องมือเหล่านี้อย่างน้อยหนึ่งอย่างสำหรับการปรับใช้และการจัดการทรัพยากร
การจัดตำแหน่งองค์กร
Cloud Adoption Framework ให้คำแนะนำสำหรับทีมกลางเพื่อจัดเตรียมโซนเริ่มต้นของปริมาณงาน โซนการลงจอดของเวิร์กโหลดคือบริเวณที่ ห่วงโซ่อุปทาน ที่กำหนดเองของเวิร์กโหลดจะปรับใช้แอปพลิเคชัน
เรียนรู้เพิ่มเติมใน โซนลงจอดของ Azure คืออะไร และ หลักการออกแบบโซนลงจอดของ Azure