แชร์ผ่าน


พื้นฐานของ ALM โดย Microsoft Power Platform

บทความนี้อธิบายถึงส่วนประกอบ เครื่องมือ และกระบวนการที่จำเป็น ในการปรับใช้การจัดการวงจรชีวิตแอปพลิเคชัน (ALM)

สภาพแวดล้อม

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

สำคัญ

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

ประเภทของสภาพแวดล้อมที่ใช้ใน ALM

ใช้ศูนย์การจัดการ Power Platform คุณสามารถสร้างประเภทสภาพแวดล้อม Power Platform เหล่านี้:

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

  • การผลิต สภาพแวดล้อมที่แอปและซอฟต์แวร์อื่นๆ ถูกนำมาใช้งานเพื่อการใช้งานตามจุดประสงค์

  • นักพัฒนา (เดิมเรียกว่าชุมชน) แผนนักพัฒนา Power Apps ช่วยให้คุณเข้าถึงฟังก์ชันแบบพรีเมียมของ Power Apps, Dataverse และ Power Automate สำหรับการใช้งานส่วนบุคคล แผนนี้มีขึ้นเพื่อสร้างและทดสอบกับ Power Apps, Power Automate และ Microsoft Dataverse หรือเพื่อการเรียนรู้ สภาพแวดล้อมของนักพัฒนาเป็นสภาพแวดล้อมแบบผู้ใช้เดียว และไม่สามารถใช้เพื่อเรียกใช้หรือแชร์แอปที่ใช้งานจริง

  • ค่าเริ่มต้น ระบบจะสร้างสภาพแวดล้อมเริ่มต้นเดียวโดยอัตโนมัติสำหรับผู้เช่าแต่ละรายและแบ่งปันโดยผู้ใช้ทั้งหมดในผู้เช่านั้น ผู้เช่าจะระบุลูกค้าซึ่งอาจมีการสมัครรับข้อมูลและบริการที่เกี่ยวข้องหนึ่งรายการหรือมากกว่านั้น Microsoft เมื่อใดก็ตามที่ผู้ใช้ใหม่ลงทะเบียนสำหรับ Power Apps พวกเขาจะถูกเพิ่มไปยังบทบาทผู้สร้างของสภาพแวดล้อมเริ่มต้นโดยอัตโนมัติ สภาพแวดล้อมเริ่มต้นถูกสร้างขึ้นในภูมิภาคที่ใกล้เคียงที่สุดกับภูมิภาคเริ่มต้นของผู้เช่า Microsoft Entra และถูกตั้งชื่อว่า: "{ชื่อผู้เช่า Microsoft Entra} (ค่าเริ่มต้น)"

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับสภาพแวดล้อม ดูที่ ภาพรวมของสภาพแวดล้อม

ใครควรมีสิทธิ์เข้าถึง

กำหนดและจัดการความปลอดภัยของทรัพยากรและข้อมูลของคุณใน Microsoft Dataverse Microsoft Power Platform มอบบทบาทผู้ดูแลระบบระดับสภาพแวดล้อมเพื่อดำเนินงาน Dataverse รวมถึง Security role ที่กำหนดระดับการเข้าถึงแอป ส่วนประกอบแอป และผู้สร้างแอป และผู้ใช้ที่มีอยู่ภายใน Dataverse

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

ข้อมูลเพิ่มเติม:

โซลูชัน

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

โซลูชันมีคุณสมบัติเหล่านี้:

  • ซึ่งรวมถึงข้อมูลเมตาและเอนทิตีบางอย่างที่มีข้อมูลการกำหนดค่า โซลูชันไม่มีข้อมูลทางธุรกิจใด ๆ

  • ซึ่งสามารถมีส่วนประกอบ Microsoft Power Platform ที่แตกต่างกันเช่นแอปที่เป็นแบบโมเดล แอปพื้นที่ทำงาน แผนผังไซต์ โฟลว์ เอนทิตี ฟอร์ม ตัวเชื่อมต่อที่กำหนดเอง ทรัพยากรของเว็บ ชุดตัวเลือก แผนภูมิและฟิลด์ โปรดสังเกตว่าไม่สามารถรวมเอนทิตีทั้งหมดในโซลูชันได้ ตัวอย่างเช่น ไม่สามารถเพิ่มตารางระบบ Application User, Custom API และ Organization Setting ไปยังโซลูชัน

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

  • โซลูชั่นที่ได้รับการจัดการถูกใช้เพื่อปรับใช้กับสภาพแวดล้อมที่ไม่ใช่สภาพแวดล้อมการพัฒนาสำหรับโซลูชันนั้น ซึ่งรวมถึงการทดสอบการทดสอบการยอมรับของผู้ใช้ (UAT) การทดสอบการรวมระบบ (SIT) และสภาพแวดล้อมการทำงานจริง โซลูชันที่ถูกจัดการสามารถรับการบริการ (ปรับปรุง แก้ไข และลบ) ได้อย่างอิสระจากโซลูชันที่ถูกการจัดการอื่น ๆ ในสภาพแวดล้อม ในฐานะที่เป็นแนวปฏิบัติที่ดีที่สุด ALM โซลูชั่นที่มีการจัดการควรถูกสร้างขึ้นโดยเซิร์ฟเวอร์การสร้าง และถือเป็นอาร์ทิแฟกการสร้าง

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

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

  • การอัพเกรดโซลูชันจะติดตั้งชั้นของโซลูชันใหม่เหนือชั้นฐานและโปรแกรมปรับปรุงที่มีอยู่ทันที

    • การนำการปรับรุ่นโซลูชันไปใช้นั้นจะลบโปรแกรมปรับปรุงที่มีอยู่ทั้งหมดและชั้นพื้นฐาน

    • การอัปเกรดโซลูชันจะลบส่วนประกอบที่มีอยู่ แต่ไม่รวมอยู่ในเวอร์ชันอัปเกรดอีกต่อไป

ข้อมูลเพิ่มเติม: แนวคิดของโซลูชัน

การควบคุมแหล่งที่มา

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

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

กลยุทธ์การแบ่งสาขาและการรวม

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

กระบวนการควบคุมแหล่งที่มาโดยใช้โซลูชัน

มีวิธีการหลักที่คุณใช้ได้ เมื่อทำงานกับโซลูชันในระบบควบคุมต้นทาง:

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

การควบคุมต้นทางโดยใช้โซลูชัน

ข้อมูลเพิ่มเติม: สร้างงานเครื่องมือ

อัตโนมัติ

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

ข้อมูลเพิ่มเติม: อะไรคือ Microsoft Power Platform Build Tools

การพัฒนาทีมโดยใช้การควบคุมแหล่งที่มาที่ใช้ร่วมกัน

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

ข้อมูลเพิ่มเติม: สถานการณ์ที่ 5: สนับสนุนการพัฒนาทีม

การรวมและการใช้งานอย่างต่อเนื่อง

คุณสามารถใช้ระบบควบคุมต้นทางใดก็ได้ และสร้างขั้นตอนการทำงานเพื่อเริ่มต้นการรวมอย่างต่อเนื่องและการปรับใช้อย่างต่อเนื่อง (CI/CD) อย่างไรก็ตามคู่มือนี้มุ่งเน้นไปที่ GitHub และ Azure DevOps GitHub เป็นแพลตฟอร์มการพัฒนาที่ใช้โดยนักพัฒนาหลายล้านคน Azure DevOps ให้บริการนักพัฒนาเพื่อสนับสนุนทีมงานในการวางแผน การทำงานร่วมกันในการพัฒนาโค้ดและสร้างและปรับใช้แอปพลิเคชัน

ในการเริ่มต้นใช้งาน คุณต้องมีสิ่งเหล่านี้:

  • บัญชี GitHub ที่คุณสามารถสร้างที่เก็บได้ หากคุณไม่มี คุณสามารถ สร้างได้ฟรี

  • Azure DevOps องค์กร หากคุณไม่มี คุณสามารถ สร้างได้ฟรี

ข้อมูลเพิ่มเติม: สร้างไปป์ไลน์แรกของคุณ

การให้สิทธิ์การใช้งาน

ในการสร้างหรือแก้ไขแอปและโฟลว์โดยใช้ Power Apps และ Power Automate ตามลำดับ ผู้ใช้จะต้องมีสิทธิ์ต่อผู้ใช้สำหรับ Power Apps หรือ Power Automate หรือสิทธิ์การใช้งานแอปพลิเคชัน Dynamics 365 ที่เหมาะสม สำหรับข้อมูลเพิ่มเติมดู ภาพรวมของการให้สิทธิ์ Microsoft Power Platform เราขอแนะนำให้ติดต่อตัวแทนบัญชีของคุณเพื่อหารือเกี่ยวกับความต้องการใบอนุญาตของคุณ Microsoft

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

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

ดูบทความต่อไปนี้ ที่กล่าวถึงรายการหลายรายการที่ต้องพิจารณาตั้งแต่เริ่มต้นของการพัฒนาแอปพลิเคชัน: