พื้นฐานของ ALM โดย Microsoft Power Platform
บทความนี้อธิบายถึงส่วนประกอบ เครื่องมือ และกระบวนการที่จำเป็น ในการปรับใช้การจัดการวงจรชีวิตโปรแกรมประยุกต์ (ALM)
สภาพแวดล้อม
สภาพแวดล้อมคือพื้นที่สำหรับจัดเก็บ จัดการ และแชร์ข้อมูลทางธุรกิจ แอป และกระบวนการทางธุรกิจต่าง ๆ ขององค์กรของคุณ นอกจากนี้ยังทำหน้าที่เป็นที่เก็บ เพื่อแยกแอปที่อาจมีบทบาท ข้อกำหนดด้านความปลอดภัยหรือกลุ่มเป้าหมายที่ต่างกัน แต่ละสภาพแวดล้อมสามารถมีฐานข้อมูล Microsoft Dataverse ได้ฐานข้อมูลเดียวเท่านั้น
ข้อสำคัญ
เมื่อคุณสร้างสภาพแวดล้อม คุณสามารถเลือกที่จะติดตั้งแอป Dynamics 365 เช่น Dynamics 365 Sales และ Dynamics 365 Marketing จำเป็นต้องพิจารณาในเวลานั้นว่าจำเป็นต้องมีแอปเหล่านี้หรือไม่ เพราะไม่สามารถถอนการติดตั้งหรือติดตั้งได้ในภายหลังได้ หากคุณไม่ได้กำลังสร้างแอปเหล่านี้ และจะไม่ต้องการแอปเหล่านี้ในอนาคต เราขอแนะนำให้คุณไม่ติดตั้งแอปเหล่านี้ในสภาพแวดล้อมของคุณ สิ่งนี้จะช่วยหลีกเลี่ยงความซับซ้อนในการขึ้นต่อกัน เมื่อคุณกระจายโซลูชันระหว่างสภาพแวดล้อม
ประเภทของสภาพแวดล้อมที่ใช้ใน ALM
ใช้ศูนย์การจัดการ Power Platform คุณสามารถสร้างประเภทสภาพแวดล้อม Dataverse เหล่านี้:
Sandbox สภาพแวดล้อม Sandbox เป็นสภาพแวดล้อมใด ๆ ที่ไม่ก่อให้เกิดผลผลิตของ Dataverse สภาพแวดล้อมแบบ Sandbox ซึ่งแยกต่างหากจากการใช้งานจริง คือตำแหน่งที่ใช้เพื่อพัฒนาและทดสอบการเปลี่ยนแปลงแอปพลิเคชันได้อย่างปลอดภัยโดยมีความเสี่ยงต่ำ สภาพแวดล้อม Sandbox รวมถึงความสามารถที่อาจเป็นอันตรายในสภาพแวดล้อมการใช้งานจริง เช่น การดำเนินการรีเซ็ต ลบ และคัดลอก ข้อมูลเพิ่มเติม: จัดการสภาพแวดล้อม Sandbox
การใช้งานจริง สภาพแวดล้อมที่ใช้งานแอปและซอฟต์แวร์อื่น ๆ ตามวัตถุประสงค์
ชุมชน แผนชุมชน Power Apps ช่วยให้คุณเข้าถึงฟังก์ชั่นพิเศษของ Power Apps Dataverse และ Power Automate สำหรับการใช้งานส่วนบุคคล แผนนี้โดยหลักมีไว้สำหรับวัตถุประสงค์เพื่อการเรียนรู้ หรือการสร้างโซลูชันทางธุรกิจที่จะกระจายให้ การทดสอบการทำงาน AppSource แม้ว่าคุณจะไม่สามารถแบ่งปันสินทรัพย์จากสภาพแวดล้อมของนักพัฒนาแผนชุมชนกับคนอื่น แต่คุณสามารถเข้าร่วมได้ Azure DevOps Pipelines สภาพแวดล้อมของนักพัฒนาเป็นสภาพแวดล้อมแบบผู้ใช้เดียว และไม่สามารถใช้เพื่อเรียกใช้หรือแชร์แอปที่ใช้งานจริง
ค่าเริ่มต้น สภาพแวดล้อมเริ่มต้นเดียวจะถูกสร้างขึ้นสำหรับผู้เช่าแต่ละราย และแชร์โดยผู้ใช้ทั้งหมดในผู้เช่านั้นโดยอัตโนมัติ ผู้เช่าระบุลูกค้า ซึ่งสามารถมีการสมัครสมาชิกและบริการของ Microsoft หนึ่งรายการที่เกี่ยวข้องหรือมากกว่า เมื่อใดก็ตามที่ผู้ใช้ใหม่ลงทะเบียนสำหรับ Power Apps พวกเขาจะถูกเพิ่มไปยังบทบาทผู้สร้างของสภาพแวดล้อมเริ่มต้นโดยอัตโนมัติ สภาพแวดล้อมเริ่มต้นถูกสร้างขึ้นในภูมิภาคที่ใกล้เคียงที่สุดกับภูมิภาคเริ่มต้นของ Azure Active Directory (Azure AD) ผู้เช่าและถูกตั้งชื่อว่า: "{ชื่อผู้เช่า Azure AD} (ค่าเริ่มต้น)"
สร้างและใช้สภาพแวดล้อมสำหรับวัตถุประสงค์เฉพาะ เช่น การพัฒนา การทดสอบ หรือการใช้งานจริง
ใครควรมีสิทธิ์เข้าถึง
กำหนดและจัดการความปลอดภัยของทรัพยากรและข้อมูลของคุณ 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 จะสามารถปรับปรุงความเร็ว ความน่าเชื่อถือ และประสบการณ์การใช้งานแอปได้อย่างมาก นอกจากนี้ยังช่วยให้มั่นใจว่านักพัฒนาหลายคน ทั้งนักพัฒนาแบบดั้งเดิมที่เขียนโค้ด และผู้พัฒนาทั่วไปสามารถร่วมกันมีส่วนร่วมในการสร้างโปรแกรมประยุกต์
ดูบทความต่อไปนี้ ที่กล่าวถึงรายการหลายรายการที่ต้องพิจารณาตั้งแต่เริ่มต้นของการพัฒนาโปรแกรมประยุกต์: