ต่อจากเรื่องภาพรวมของเครื่องมือใน Power Apps 101 : Introduction – ทำความรู้จัก PowerApps คืออะไร? ทำไมใครๆ ก็สร้างแอปได้ รอบนี้ขอเจาะลึกเรื่องหนึ่งที่หลายทีมมักข้ามไปตอนเริ่มโปรเจกต์ นั่นคือเรื่อง Environment
การสร้างแอปพลิเคชันหรือระบบอัตโนมัติบน Power Platform ให้ประสบความสำเร็จในระดับองค์กร ไม่ได้วัดกันแค่ความเร็วในการพัฒนาเพียงอย่างเดียว แต่ขึ้นอยู่กับ “ความเสถียรและความปลอดภัยของระบบ” ในระยะยาวด้วย หลายองค์กรมักตกหลุมพรางจากการทดลองแก้ไขฟีเจอร์หรือปรับปรุงฐานข้อมูลบนแอปพลิเคชันที่เปิดใช้งานจริง จนสร้างความเสียหายให้แก่ข้อมูลธุรกิจโดยไม่ตั้งใจ บทความนี้จะพาทุกคนไปทำความเข้าใจสถาปัตยกรรม Power Platform Environments ตั้งแต่แนวคิดพื้นฐาน เหตุผลที่ต้องแยกพื้นที่ Dev, Test, Prod ไปจนถึงประเภทของ Environment เพื่อให้ทีมของคุณสามารถพัฒนาโซลูชันได้อย่างมั่นใจและเป็นระบบ
Power Platform Environments คืออะไร
พื้นที่จัดเก็บแบบปิด (Container) บนคลาวด์ที่ใช้แยกแยะและบริหารจัดการองค์ประกอบต่างๆ ของ Microsoft Power Platform เช่น Power Apps, Power Automate, Power Pages และ Dataverse โดยแต่ละ Environment จะมีฐานข้อมูล การตั้งค่าการเชื่อมต่อ (Connections) และสิทธิ์ความปลอดภัยเป็นของตัวเองอย่างเด็ดขาดโดยไม่ปะปนกับพื้นที่อื่น
ทำไมองค์กรถึงต้องแยก Environment
ในหน้างานจริง เคยมีเคสตัวอย่างที่ทีมพัฒนานึกสนุก ทดลองแก้ไขฟอร์มรับแจ้งเรื่องร้องเรียนโดยไปแก้บนแอปพลิเคชันตัวจริงที่พนักงานทั้งบริษัทใช้งานอยู่ทุกวัน ปรากฏว่าในช่วงเวลานั้นมีพนักงานกดบันทึกข้อมูลเข้ามาพอดี ส่งผลให้ข้อมูลชุดนั้นสูญหายไปอย่างไร้ร่องรอย และทีมงานต้องเสียเวลามานั่งกู้ระบบกันยกใหญ่
ปัญหาคลาสสิกเหล่านี้สามารถป้องกันได้ทันที หากมีการแบ่งสัดส่วน Environment ออกเป็น 3 ระดับมาตรฐานอย่างชัดเจน:
- Development (Dev) : พื้นที่สำหรับทดลอง ลองผิดลองถูก และพัฒนาฟีเจอร์ใหม่ๆ เป็นสนามเด็กเล่นของนักพัฒนาที่ต่อให้แอปจะพัง ข้อมูลจะล่ม หรือโค้ดจะ error ขนาดไหน ก็ไม่มีทางส่งผลกระทบต่อคนอื่นในองค์กร
- Test / UAT (User Acceptance Testing) : พื้นที่สำหรับจำลองสถานการณ์จริง เพื่อเปิดให้ผู้ใช้งานจริงหรือทีม QA เข้ามาทดลองกดระบบ ตรวจสอบความถูกต้อง และเช็กว่าฟังก์ชันทั้งหมดตอบโจทย์ความต้องการทางธุรกิจก่อนนำไปปล่อยจริง
- Production (Prod) : พื้นที่ใช้งานจริงสำหรับพนักงานหรือลูกค้าทั่วองค์กร ห้ามมีการเข้ามาทดลองโค้ด ทดสอบระบบ หรือกดเล่นในพื้นที่นี้เด็ดขาด เพื่อรักษาเสถียรภาพและความปลอดภัยของข้อมูลธุรกิจ
ประเภทของ Environment ใน Power Platform ที่มีให้เลือกใช้งาน
ในการบริหารจัดการระบบ Microsoft Power Platform จะมีการแบ่งประเภทของ Environment ออกตามวัตถุประสงค์การใช้งานหลัก ดังนี้:
| ประเภท Environment | วัตถุประสงค์การใช้งาน | ลักษณะสำคัญ |
| Production | ใช้งานจริงระดับองค์กร | พื้นที่สำหรับรันแอปพลิเคชันและเวิร์กโฟลว์ใช้งานจริงระดับองค์กร มีระบบสำรองข้อมูล (Backup) อัตโนมัติ การดูแลความปลอดภัยขั้นสูง และต้องได้รับการบริหารจัดการอย่างรัดกุมที่สุด |
| Sandbox | ทดสอบระบบและประมวลผล | Environment แยกสำหรับงานทดสอบระบบโดยเฉพาะ มีจุดเด่นคือสามารถจำลอง (Copy) ข้อมูลชุดเดียวกับ Production ลงมาทดสอบได้ และสามารถรีเซ็ตค่ากลับมาเป็นค่าเริ่มต้นได้ง่ายเมื่อจบโปรเจกต์ |
| Developer | หัดใช้งานและทำ PoC ส่วนตัว | สิทธิ์การใช้งานฟรีที่แถมมาพร้อมกับไลเซนส์ Microsoft 365 (จำกัด 1 บัญชีต่อ 1 สิทธิ์) เหมาะสำหรับการหัดเขียนโค้ด ทดลองระบบ หรือทำ Proof of Concept (PoC) ส่วนตัว แต่มีข้อจำกัดคือเป็นพื้นที่ใช้งานคนเดียว ไม่สามารถแชร์ร่วมกับผู้อื่นได้ |
| Trial | ทดสอบฟีเจอร์ใหม่ชั่วคราว | Environment สำหรับทดลองใช้งานฟีเจอร์ใหม่ๆ หรือฟังก์ชันขั้นสูงแบบจำกัดระยะเวลา (เช่น 30 วัน) เมื่อหมดอายุระบบจะทำการลบข้อมูลและปิดการใช้งานโดยอัตโนมัติ เหมาะสำหรับการประเมินความคุ้มค่าก่อนตัดสินใจซื้อจริง |
ขั้นตอนสร้าง Environment
เข้าไปที่ Power Platform Admin Center ก่อน (admin.powerplatform.microsoft.com) ต้องมีสิทธิ์ Global Admin หรือ Power Platform Admin ถึงจะสร้างได้
- กด New environment จากนั้นตั้งชื่อให้สื่อความหมาย อย่าตั้งชื่อคลุมเครือแบบ Test1 Test2 เพราะพอผ่านไปสักพักจะจำไม่ได้ว่าอันไหนคืออันไหน แนะนำให้ใส่ทั้งชื่อโปรเจกต์และประเภทไปเลย เช่น HR-Approval-Dev
- เลือก Type ให้ตรงกับที่จะใช้งานจริง (Production หรือ Sandbox ตามที่อธิบายไปก่อนหน้า)
- เลือก Region ให้ตรงกับที่บริษัทตั้งอยู่หรือกฎเกณฑ์ที่ต้องปฏิบัติตาม เรื่องนี้สำคัญกว่าที่คิด เพราะย้าย region ทีหลังทำไม่ได้ ต้องสร้างใหม่เท่านั้น
- ถ้าต้องใช้ตาราง หรือ Model-driven app ให้ติ๊กเพิ่ม Dataverse database ตอนสร้างเลย จะได้ไม่ต้องมาเพิ่มทีหลัง
- สุดท้ายกำหนด Security group ว่าใครเข้าถึง Environment นี้ได้บ้าง ถ้าไม่กำหนด ทุกคนในองค์กรจะเห็นหมด
เรื่องที่คนเพิ่งเริ่มมักพลาด
- ใช้ Default environment ทำทุกอย่าง อันนี้เจอบ่อยสุด Default environment มันมาพร้อมกับ tenant ตั้งแต่แรก ไม่มีเจ้าของ ไม่มีใครดูแล และลบไม่ได้ด้วย ถ้าเผลอเอาไปทำงานจริงจังจะจัดการทีหลังลำบากมาก
- ลืมกำหนด Security group จนคนทั้งบริษัทเข้าถึง Environment ที่ควรจะเป็นของทีมเดียว
- สร้าง Environment ใหม่ทุกครั้งที่มีโปรเจกต์เล็ก ๆ จนสุดท้ายมี Environment เกลื่อนจำไม่ได้ว่าอันไหนยังใช้อยู่ อันไหนเลิกใช้แล้ว ทางที่ดีควรมีผู้ดูแลโดยเฉพาะคอยดูแลภาพรวมทั้งหมด
- ไม่เช็ค capacity ก่อนสร้าง Dataverse database เพราะพื้นที่เก็บข้อมูลของ Dataverse ใช้โควตารวมของทั้ง tenant ถ้าสร้างเยอะไปพื้นที่อาจไม่พอสำหรับ Environment ที่สำคัญกว่า
— THE MATRIX × MICROSOFT —
อ้างอิง : https://learn.microsoft.com/en-us/power-platform/admin/environments-overview