ทักทาย
สวัสดีครับ จากปกติที่ผมจะเขียน blog เป็นภาษาอังกฤษเสมอ แต่โพสนี้ตั้งใจเขียนให้กับ Power Apps developer ในไทยโดยเฉพาะ เลยจะเขียนโดยตั้งต้นจากภาษาไทยเป็นหลัก เวอร์ชั่นอังกฤษจะตามมาในภายหลัง
ที่มา
ช่วงตั้งแต่ปี 2023 เป็นต้นมา ฐานของผู้ใช้และนักพัฒนา Power Apps ในไทยนั้นเติบโตขึ้นมาก ผมเริ่มได้เห็นหลายๆบริษัทมีการเปิดรับสมัครตำแหน่ง Power Platform Developer โดยเฉพาะ หรือหลายๆที่ก็ได้มีการผลักดันให้พนักงานที่ถึงแม้จะไม่ใช่โปรแกรมเมอร์เต็มตัวให้มาเรียนรู้ Power Apps
และหลายๆที่ก็ได้มีแอปที่พัฒนาและใช้งานจริงอยู่ เพียงแต่หลายๆที่จะเจอปัญหาคล้ายๆกัน และผมเดาว่าถ้าคุณได้มีการทำแอปใช้กันเองถึงระดับหนึ่ง คุณจะเริ่มเจอปัญหาพวกนี้
- มีแอปตัวเดียว เวลาแก้ยังไม่เสร็จ user ก็ใช้งานไม่ได้
- จะแยกแอปเป็น 2 ตัว ตัวนึงสำหรับ developer ตัวนึงสำหรับ production (ใช้งานจริง) เวลาจะอัพเดทก็ลำบาก อัพเดททีนึงต้องไล่แก้ config หลายจุด
- แยกแอปออกเป็น 2 ตัวแล้วแต่บางทีก็แก้ตัวนึง ไม่ได้แก้อีกตัวนึง เป็นปัญหาว่าแอป 2 ตัวนั้นโค้ดภายในไม่เหมือนกัน เจอปัญหาไม่เหมือนกัน
ซึ่งไม่แปลกเลยที่จะเจอปัญหาพวกนี้หากเราไม่ได้ทำตามหลักการ ALM ที่ดี
ALM (Application Lifecycle Management) อธิบายให้เข้าใจง่ายๆคือหลักการการพัฒนาแอปพลิเคชันที่เป็นระบบ ที่จะทำให้เราสามารถดูแล แก้ไขแอปของเราไปได้ในระยะยาวโดยไม่เกิดปัญหาหรือความสับสน
ซึ่งตัว Power Platform เองก็มีเครื่องมีที่ถูกออกแบบมาเพื่อตอบโจทย์การทำ ALM ที่ดี นั่นก็คือ Solution ซึ่งไม่แปลกที่คุณอาจไม่รู้จักหากคุณยังเพิ่งเริ่มกับ Power Apps ในช่วงแรกที่คุณเพิ่งจะหัดทำแอป คุณยังไม่ต้องรู้จักมันก็ได้ แต่เมื่อใดที่แอปที่คุณทำเริ่มซับซ้อนขึ้น เริ่มมีหลายตัวขึ้น คุณจะเริ่มต้องใช้มันแล้วล่ะ
Environment ของ Power Platform
ในโลกของการพัฒนาแอปพลิเคชัน เราจำเป็นต้องมีการแยก environment ออกเป็นหลายๆส่วน เพื่อให้ง่ายต่อการจัดการ ซึ่งของฝั่ง Power Platform ก็มีารแบ่งเหมือนกัน โดยทั่วไปแล้วก็จะแบ่งเป็น
- Dev Environment – สำหรับให้นักพัฒนาแอป คนทำแอปใช้ การสร้างแอป การสร้าง flow หรือการแก้ไขทุกอย่างจะถูกสร้างขึ้นที่นี่
- Test Environment – สำหรับใช้ทดสอบแอป โดยหลังจากที่แอปนั้นถูกทำขึ้นมาแล้ว ต้องมีการทดสอบก่อนที่จะนำไปใช้งานจริง เราจะต้องนำตัวแอปที่เราทำที่ Dev มาติดตั้งที่ Test Environment เพื่อให้ user หรือ tester ทดสอบใช้งาน (บางที่อาจจะเรียกว่า UAT, SIT, QAS)
- Production Environment – สำหรับใช้งานจริง โดยหลังจากที่แอปนั้นถูกทดสอบจนมั่นใจแล้วว่าใช้งานได้ ตัวแอปจะถูกนำมาติดตั้งที่ Production Environment และ user ที่ใช้งานระบบจะใช้งานผ่านตัวแอปที่อยู่บน environment นี้
ซึ่งใน 3 environment นี้จะถูกแยกกันอย่างเด็ดขาดทั้งในเรื่องของข้อมูล, user และ permission เพื่อที่ว่าถ้าหากเกิดปัญหาระหว่างการพัฒนาแอปที่ Dev ข้อมูลที่อยูบน Production จะไม่ส่งผลกระทบ user จะสามารถใช้งานได้ปกติ ส่วนนักพัฒนาก็สามารถแก้ไขและทดสอบให้มั่นใจได้ก่อนที่จะนำขึ้นมาบน Production นั่นเอง
แล้วถามว่า ถ้าเราทำแอปที่ Dev ไว้ เราจะนำแอปไปติดตั้งที่ Test หรือ Production ได้อย่างไร ถ้าเรามี 5 แอป มี 20 flow เราต้อง Export Import ทีละอันเลยรึเปล่า
จุดนี้เองที่เราต้องใช้ Solution เข้ามาช่วย
Solution คืออะไร
คิดว่าหลายคนน่าจะสังเกตเห็นเมนูนี้อยู่ใน Power Apps Maker Portal มาสักพักแล้ว แต่ยังไม่เข้าใจว่ามันเอาไว้ทำอะไร วันนี้เราจะมาเจาะลึกตรงนี้กัน
Solution อธิบายง่ายๆไม่เน้นวิชาการ มันเปรียบเสมือนกล่องๆหนึ่ง ที่เราสามารถใส่ App, Flow, Table และอื่นๆอีกมากมายไว้ข้างใน เพื่อที่เวลานำไปติดตั้งที่อื่น เราจะได้นำไปทีเดียวทั้งกล่องและติดตั้งมันทีเดียวเลย
เอาล่ะ เรามาลองสร้าง Solution กันเลย ผมจะเน้นที่จุดสำคัญนะ อาจจะไม่อธิบายละเอียดทุกปุ่ม เอาแค่จุดที่คิดว่าคนทั่วไปน่าจะได้ใช้
- Display name – ชื่อของ Solution โดยปกติเราก็จะตั้งเป็นชื่อแอป/ชื่อโปรเจ็คของเรา (แก้ไขภายหลังได้)
- Name – ชื่อของ Solution ที่เป็นชื่อเอาไว้อ้างอิงของระบบ (แก้ไขภายหลังไม่ได้)
- Publisher – เอาไว้ระบุว่าใครเป็นคนสร้างและรับผิดชอบ Solution นี้ โดยในครั้งแรกคุณอาจเห็นเฉพาะของเดิมๆที่ระบบมีให้ เช่น CDS Default Publisher อะไรพวกนี้ ผมแนะนำให้คุณกด New publisher เป็นของตัวเองได้เลย โดยหากคุณกดสร้าง คุณสามารถกำหนดสิ่งต่อไปนี้ได้
- Display name – ชื่อ Publisher ตรงนี้ตั้งเป็นชื่อตัวเอง ชื่อบริษัท ชื่อทีมที่ทำแอป แล้วแต่เลย
- Name – ชื่อ Publisher ที่เอาไว้อ้างอิงของระบบ (แก้ไขภายหลังไม่ได้)
- Description – คำอธิบาย
- Prefix – คำขึ้นต้นของ object ที่จะถูกสร้างใน solution ตรงนี้ก็แนะนำตั้งเป็นชื่อย่อที่สัมพันธ์กับชื่อ Display name เช่น Microsoft Corporation เป็น msft
- Version – เวอร์ชั่นของ Solution เริ่มแรกแนะนำเป็น 1.0.0.0 ไว้ก่อน เดี๋ยวเราทำไปเรื่อยๆมันจะขยับขึ้นเอง
เมื่อตั้งค่าเสร็จแล้วก็กด Create ได้เลย เราก็จะได้ Solution ของเรามา
ส่วนประกอบของ Solution
เมื่อคุณเข้ามาภายใน Solution ตรงนี้ก็เปรียบเสมือนพื้นที่ในกล่องๆหนึ่ง คุณสามารถกดสร้าง App, Flow, Table (ของ Dataverse) ได้จากในนี้เลย (ส่วนการสร้างแอปและ flow ทำเหมือนกับแอปทั่วไป)
หรือถ้าคุณมีแอปหรือ flow ที่สร้างไว้อยู่แล้ว ก็สามารถกด Add existing แล้วดึงเข้ามาอยู่ภายใน Solution ได้เช่นกัน โดยสิ่งที่อยู่ใน solution ผมจะขอเรียกว่า object
แต่มีข้อควรระวังอย่างนึง คือถ้าหากว่า object ใน solution ของเรามีการอ้างอิงถึง object อื่น เช่น
ถ้าหากว่าแอป My Awesome App ของผม มีการเชื่อมกับ flow MAWEAPP – Flow process A ผมก็จำเป็นที่จะต้องดึงทั้งตัวแอปและตัว flow เข้ามาอยู่ใน Solution ด้วย ไม่อย่างนั้นผมจะติดปัญหาในขั้นตอนท้ายๆ
แต่ Power Platform ก็มีตัวช่วยเรา ก็คือเราสามารถกดดูได้ว่า Object นี้ เชื่อมโยงกับ object ใดอยู่บ้าง
โดยเราสามารถตรวจสอบได้โดยการกดที่ปุ่ม … ที่ object และเลือก Advanced > Show dependencies ระบบก็จะแสดงให้เห็นถึงการเชื่อมโยงกันของ object แต่ละตัว
Environment Variable
อีกหนึ่งสิ่งที่จำเป็นของการนำแอปไปติดตั้งบน environment อื่นคือเรามักจะมีค่าบางอย่างที่ต้องเปลี่ยน config ตามด้วย เช่น
- แอปที่เป็นตัว Dev ของเราเชื่อมโยงกับ SharePoint Site > PowerSP
- แอปที่เป็นตัว Test ของเราเชื่อมโยงกับ SharePoint Site > PowerSP-PROD
ถ้าหากเราไม่ใช้ Environment Variable ทุกครั้งที่เรามีการนำแอปไปติดตั้ง เราต้องไปไล่เปลี่ยนตรงนี้เองทีละจุด ซึ่งผมจะไม่ทำแบบนั้นแน่ๆ
แทนที่จะทำแบบนั้น ผมจะใช้ Environment Variable เข้ามาช่วย โดยการ
1. ทำการสร้าง Environment Variable ที่อ้างอิงถึง SharePoint Site ของเรา
- Display Name – ชื่อของ Variable ตั้งเป็นชื่อเดียวกับชื่อ SharePoint Site ก็ได้
- Data Type – ประเภทของ Variable ในที่นี้ของเราจะอ้างอิงถึง SharePoint ซึ่งนับเป็น Data source
- Connection – เลือก connection ซึ่งโดยปกติก็จะขึ้นเป็นอีเมลของคุณ
- Parameter Type – เลือก Site เพราะ Variable นี้เราอ้างอิงถึง Site
- Current site – เลือก Site
- Default site value – เลือก Site
กด Save คุณก็จะได้ Environment Variable ที่อ้างอิงถึง SharePoint Site
2. ทำการสร้าง Environment Variable ที่อ้างอิงถึง SharePoint List ของเรา
เมื่อสักครู่เรามี Variable ที่อ้างอิงถึง Site ไปแล้ว ต่อไปเราต้องทำ Variable ที่อ้างอิงถึง List บ้าง ขั้นตอนเหมือนกัน ต่างกันตรงที่เลือก Parameter Type
- Parameter Type – เลือก List
- Site – เลือกชื่อ Site โดยจะเห็นเป็นชื่อของ Environment Variable ที่ได้สร้างมาก่อนหน้านี้
- Current list – เลือกชื่อ List
- Default list value – เลือกชื่อ List
กด Save คุณก็จะได้ Environment Variable ที่เชื่อมโยงไปยัง List หากมีหลาย List ที่ต้องใช้ก็ให้เพิ่มมาเรื่อยๆจนครบ
3. การนำ Environment Variable ไปใช้
เรามี Environment Variable แล้ว ถัดมาเราจะนำมันไปใช้กับแอปและ flow ของเรา
สำหรับ Canvas App เราสามารถนำมาใช้ได้เหมือนกับ Data source ทั่วไปเลย เพียงแต่ ณ ตอนที่เลือก Site ให้กดไปที่แท็ป Advanced เราถึงจะเห็นชื่อ Environment Variable ของเรา
เมื่อกดเข้ามาแล้วคราวนี้พอเป็นการเลือก List ก็ให้กดที่ Advanced เหมือนเดิม และเลือกชื่อ List
เท่านี้เราก็จะได้ Data source ที่มาจาก Environment Variable
สำหรับ Power Automate flow นั้นตรงไปตรงมา โดยหากเป็น flow ที่อยู่ภายใน Solution แล้ว คุณจะสามารถกดเลือกใช้ Environment เหล่านี้ได้จากกล่อง Dynamic content เลย
การ Export Solution
หลังจากที่เราทำแอปของเราเสร็จหรือว่าเพียงพอต่อการทดสอบ/ใช้งานแล้ว ขั้นตอนต่อไปคือการนำแอปของเราออกไปติดตั้งลงบน Environment อื่น
เนื่องจาก ณ ตอนนี้ Solution ของผมอยู่ใน Environment ที่ชื่อ Development ซึ่งชัดเจนว่าเป็น Dev Environment
ดังนั้นผมจึงต้อง Export Solution นี้ออกมา โดยการกดที่แท็ป Overview และเลือก Export
กด Publish และกด Next
ทำการกำหนดเวอร์ชั่น โดยเวอร์ชั่นจะต้องมากกว่าหรือเท่ากับเวอร์ชั่นเดิมเท่านั้น ไม่สามารถถอยหลังได้ เช่น current version คือ 1.0.0.0 ต่อไปต้องเป็น 1.0.0.1 หรือมากกว่า ตรงนี้เรากำหนดเองได้ ไม่จำเป็นต้องเพิ่มทีละ 1 ก็ได้
ส่วนตัวผมจะชอบตั้งแบบนี้
- ถ้าเป็นการแก้ไขเล็กๆน้อยๆ ไม่มีการแก้ process หรือแก้ฟีเจอร์ใดๆ ผมจะขยับเลขหลักสุดท้าย (X.X.X.X+1)
- ถ้าเป็นการแก้ไขฟีเจอร์การทำงาน แต่ process ยังเหมือนเดิม จะขยับเลขหลักที่ 3 (X.X.X+1.0)
- ถ้าเป็นการแก้ไขที่กระทบ process จะขยับเลขหลักที่ 2 (X.X+1.0.0)
- ถ้าเป็นการแก้ไขที่กระทบ process แทบทั้งหมดจะขยับเลขหลักที่ 1 (X+1.0.0.0)
Export as ตรงนี้สำคัญมาก
Solution มี 2 ประเภท โดยที่เราทำมาทั้งหมดจนถึงตอนนี้คือ Unmanaged solution แต่ตอน export จะมีให้เลือก 2 ประเภท ได้แก่ Managed และ Unmanaged ซึ่งแบ่งตามการใช้งานดังนี้ (ซึ่งผมแนะนำให้ทำแบบเดียวกับผม)
| จุดประสงค์ | เหมาะสำหรับนำไปยัง | ให้เลือกเป็น |
|---|---|---|
| ต้องการ Export ออกไปเพื่อนำไป dev ต่อที่ environment อื่น | Other dev. environment | Unmanaged |
| ต้องการ Export ออกไปเพื่อ Test หรือใช้งานจริง โดยจะไม่มีการไปแก้โค้ดที่นั่นแล้ว | Test environment, Production environment | Managed |
ถามว่าทำไมการนำไปที่ Test หรือ Production environment ให้เลือกเป็น Managed นั่นก็เพราะว่า Managed solution นั้นจะไม่อนุญาตให้มีการแก้ไขโค้ดหรือ flow ใดๆของ object ที่อยู่ภายในที่นั่น ทำให้เรามั่นใจได้ว่าตัวแอปของเรานั้นเหมือนกันกับตัวที่อยู่บน dev environment แน่นอน
ถ้าหากว่าเราต้องมีการอัพเดทหรือแก้ไขใดๆ จะเป็นการ Export จาก Dev แล้วนำไป Import เพื่ออัพเดท
เราจะไม่มีการไปแก้โค้ดใดๆที่ Production เด็ดขาด ไม่มี ห้ามมี และไม่ควรมี
หลังจาก Export เสร็จเราจะสามารถ Download ออกมาเป็นไฟล์ zip โดยไฟล์นี้แหละ คือ solution ของเรา
การ Import Solution
หลังจากที่เราได้ไฟล์ zip ของ solution มาแล้ว เราจะนำไปติดตั้งที่ environment ปลายทาง ซึ่งอาจจะเป็น Test หรือ Production
ให้กดเลือกไปที่ Environment ที่ต้องการได้เลย
มาที่เมนู Solution แล้วกด Import solution
กด Browse เลือกไฟล์ zip ของ solution เสร็จแล้วกด Next
ตรวจสอบ connection หากมีตัวไหนขึ้นให้ทำการ login ให้ทำการ login ให้เรียบร้อย แล้วกด Next
ทำการเปลี่ยนค่าของ Environment Variable ของเรา โดยอย่างที่ผมสร้างไว้จะมี 2 ตัว ผมก็แค่ทำการเปลี่ยนให้ไปเชื่อมโยงกับ SharePoint Site และ List ที่ผมต้องการ
แทนที่ผมจะต้องเปลี่ยนทุกๆจุดทั้งในแอปและใน flow ผมเปลี่ยนที่นี่ที่เดียว
กด Import ได้เลย
บางครั้งมันอาจจะขึ้นข้อความตัวสีแดงมาฟ้องว่า You do not have access.. ไม่ต้องสนใจครับ
หลังจาก Import เสร็จสิ้น คุณจะเห็น Solution ของคุณปรากฎขึ้น พร้อมกับทุกๆ object ที่อยู่ภายใน
โดย object ที่อยู่ภายใน Managed Solution จะไม่สามารถแก้ไขได้
ถ้าต้องการแก้ไขอัพเดทแอป ทำอย่างไร
ทุกๆ Object ที่อยู่ใน Managed solution จะไม่สามารถแก้ไขได้
แต่หากคุณต้องการแก้ไขหรืออัพเดทตัวแอปเพิ่มเติม สามารถทำได้โดยการที่ คุณต้องแก้ไขตัวแอปที่ Dev environment ให้เรียบร้อย แล้วก็ทำขั้นตอนเดิม คือการ Export และนำมา Import เหมือนเดิมเลยครับ
ระบบของ Solution จะจัดการให้คุณทั้งหมด หากคุณมีการลบ object ใดๆออกจากที่ต้นทาง เมื่อนำมา Import ระบบก็จะลบออกที่ปลายทางให้ด้วย (เฉพาะกรณี Export เป็น Managed Solution)
ดังนั้นมั่นใจได้เลยว่าที่ Dev กับ Production จะเหมือนกัน 100% ไม่มีเซอร์ไพรส์
บทสรุป
- ด้วยการใช้ Solution จะช่วยลดขั้นตอน manual ที่คุณต้องดำเนินการในการอัพเดทแอปแต่ละครั้ง
- การทำครั้งแรกอาจจะกินเวลาสักหน่อย แต่ครั้งถัดๆไปไม่ว่าแอปของคุณจะมี Object ภายในจำนวนมากแค่ใด คุณก็สามารถ Deploy ได้ภายในไม่กี่คลิก
- อีกทั้งยังทำให้การพัฒนาแอปเป็นไปตามขั้นตอน Application Lifecycle Management ที่ควรจะเป็น
เกี่ยวกับ Solution ยังมีรายละเอียดมากมายอีกพอสมควรที่ถัดไปจะเป็นระดับของ Intermediate – Advanced แล้ว ถ้ามีโอกาสจะมาแชร์ให้ทราบกันแน่นอนครับ
