Staging Environment คืออะไร? ทดสอบก่อนเปิดใช้งานจริง

Staging environment คือสำเนาส่วนตัวของแอปที่ตั้งค่าให้ใกล้เคียงกับเวอร์ชันจริงที่สุด เพื่อทดสอบการเปลี่ยนแปลงก่อนที่ผู้ใช้จริงจะเห็น มันใช้ฐานข้อมูลของตัวเอง ข้อมูลทดสอบ และ API key ทดสอบ ดังนั้นฟีเจอร์ที่พังหรือการเปลี่ยนข้อมูลที่ผิดพลาดที่นั่นจะไม่กระทบใครนอกทีมของคุณ เมื่อการเปลี่ยนแปลงดูถูกต้องใน staging คุณจึงปล่อยไปยัง production ซึ่งเป็นแอปจริงที่ลูกค้าของคุณใช้งาน

ทำไม staging จึงสำคัญเมื่อคุณสร้างด้วย AI

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

การมีที่ตรวจสอบการเปลี่ยนแปลงก่อนเปิดใช้งานจริงช่วยให้คุณ:

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

ตัวอย่างในชีวิตประจำวัน

ลองนึกถึงการซ้อมใหญ่ของโรงละคร

• Development คือห้องซ้อม ที่นักแสดงลองบทพูด หยุด เริ่มใหม่ และทดลอง
• Staging คือการซ้อมใหญ่ ใส่ชุดเต็มยศ อยู่บนเวทีจริง มีไฟจริง ทุกอย่างเหมือนคืนเปิดการแสดง ยกเว้นว่าไม่มีผู้ชมที่จ่ายเงิน
• Production คือคืนเปิดการแสดง ความผิดพลาดเกิดขึ้นต่อหน้าทุกคน

ปัญหาส่วนใหญ่ที่คุณไม่อยากให้เกิดในคืนเปิดการแสดงจะปรากฏในการซ้อมใหญ่ เช่น การเปลี่ยนชุดที่ใช้เวลานานเกินไป หรือไฟที่เปิดผิดจังหวะ นั่นคือหน้าที่ของ staging อย่างแท้จริง

สามสภาพแวดล้อมที่พบบ่อย

แต่ละสภาพแวดล้อมแตกต่างกันหลักๆ ที่การตั้งค่า: เชื่อมกับฐานข้อมูลไหน ใช้คีย์อะไร อยู่ที่ URL ใด นี่คือเหตุผลที่แอปที่ดีอ่านการตั้งค่าเหล่านี้จาก environment variables และ secrets แทนการเขียนค่าตายตัวในโค้ด โค้ดชุดเดียวกันจึงรันได้ในทุกสภาพแวดล้อมด้วยการตั้งค่าที่ต่างกัน

ตัวอย่างประกอบ: เปลี่ยนกฎการยกเลิกการจองของแอปร้านทำผม

คุณมีแอปจองคิวร้านทำผมที่มีลูกค้าจ่ายเงินจริง คุณอยากเปลี่ยนกฎให้ลูกค้ายกเลิกได้ถึง 24 ชั่วโมงก่อนนัด จากเดิม 48 ชั่วโมง และให้คืนเงินอัตโนมัติ

1. สร้างใน development คุณขอการเปลี่ยนแปลงจาก AI builder AI จะอัปเดตลอจิกการยกเลิกและการเรียกคืนเงินไปยังผู้ให้บริการชำระเงินของคุณ

2. ปล่อยไปยัง staging Staging รันโค้ดเดียวกัน เชื่อมกับฐานข้อมูล staging ที่มีการจองทดสอบ และคีย์ โหมดทดสอบ ของผู้ให้บริการชำระเงิน

3. ทดสอบขั้นตอนจริง คุณและเพื่อนร่วมงาน:

• จองนัดทดสอบสำหรับพรุ่งนี้ แล้วยกเลิกก่อนเวลา 30 ชั่วโมง ควรได้รับเงินคืน
• ลองยกเลิกก่อนเวลา 10 ชั่วโมง ควรถูกปฏิเสธพร้อมข้อความที่ชัดเจน
• ตรวจว่าเงินคืนปรากฏในแดชบอร์ดโหมดทดสอบของผู้ให้บริการชำระเงิน
• ตรวจว่าอีเมลยืนยันระบุ 24 ชั่วโมง ไม่ใช่ 48

4. พบบั๊ก ใน staging คุณสังเกตเห็นว่ากฎใช้เขตเวลาของเซิร์ฟเวอร์ ไม่ใช่ของร้าน ทำให้เวลาตัดสินคลาดไปหนึ่งชั่วโมง คุณแก้แล้วทดสอบอีกครั้ง

5. ปล่อยไปยัง production ตอนนี้การเปลี่ยนแปลงจึงจะถึงลูกค้าจริง โดยบั๊กเรื่องเขตเวลาถูกจับได้แล้ว

หากไม่มี staging ขั้นตอนที่ 4 จะเกิดขึ้นกับการคืนเงินของลูกค้าจริง

คำศัพท์สำคัญ

ความเข้าใจผิดที่พบบ่อย

• "Staging ใช้ฐานข้อมูล production ร่วมกันได้" นี่คือทางลัดที่อันตรายที่สุด การทดสอบที่ลบหรือแก้ไขข้อมูลจะกระทบลูกค้าจริง ให้ staging มีฐานข้อมูลของตัวเอง
• "ถ้าทำงานใน staging แล้ว มันพังใน production ไม่ได้" Staging ลดความเสี่ยงแต่ไม่ได้กำจัดมันออกไป ทราฟฟิกจริง ข้อมูลจริง และบริการภายนอกยังสามารถทำให้คุณประหลาดใจได้ จงเก็บวิธีย้อนกลับไว้
• "Staging ต้องมีค่าใช้จ่ายสูง" มันเล็กได้ ต้องมีการตั้งค่าเหมือน production แต่ไม่จำเป็นต้องมีขนาดเท่ากัน
• "ใช้คีย์การชำระเงินจริงใน staging เพื่อให้สมจริง" ให้ใช้โหมดทดสอบของผู้ให้บริการ สมจริงไม่ได้หมายถึงเงินจริง
• "Staging มีไว้สำหรับทีมใหญ่เท่านั้น" แนวคิด ทดสอบในที่ปลอดภัยก่อน มีประโยชน์แม้สำหรับคนเดียว ระดับของขั้นตอนขึ้นอยู่กับความเสี่ยง
• "Staging ควรเปิดสาธารณะเพื่อให้คนลองใช้" ให้เก็บไว้เป็นส่วนตัวหรือมีการป้องกัน และป้องกันไม่ให้เครื่องมือค้นหาจัดทำดัชนี เพื่อไม่ให้ใครเข้าใจผิดว่าเป็นแอปจริง

สิ่งที่ควรขอจาก AI builder ของคุณ

• "ให้ทุกการตั้งค่าที่ขึ้นกับสภาพแวดล้อม ทั้งฐานข้อมูล API key และ URL ของเว็บไซต์ มาจาก environment variables"
• "เพิ่มสคริปต์ seed ที่เติมข้อมูลทดสอบที่สมจริงลงในฐานข้อมูลที่ไม่ใช่ production"
• "ใช้โหมดทดสอบของผู้ให้บริการชำระเงินไปจนกว่าฉันจะบอกว่าพร้อมเปิดตัว"
• "ก่อนการเปลี่ยนแปลงนี้จะขึ้นใช้งานจริง ให้ระบุขั้นตอนที่ฉันควรทดสอบ และสิ่งที่ควรเกิดขึ้นในแต่ละขั้นตอน"
• "การเปลี่ยนแปลงนี้จะกระทบข้อมูลที่มีอยู่หรือไม่ แสดง migration ให้ฉันดูก่อน"
• "ตรวจให้แน่ใจว่าสำเนาที่ไม่ใช่ production ของเว็บไซต์ไม่ถูกจัดทำดัชนีโดยเครื่องมือค้นหา"

สำหรับขั้นตอนการตั้งค่าทีละขั้น ดู วิธีตั้งค่า staging environment เมื่อการปล่อยเกิดขึ้นบ่อย การทำให้เส้นทางจากโค้ดไปยัง staging และ production เป็นอัตโนมัติคือหน้าที่ของ CI/CD

การทดสอบก่อนปล่อยใน Mythex

Mythex ไม่มีสวิตช์แยก "staging กับ production" การเผยแพร่ให้คุณหนึ่ง URL สาธารณะที่ใช้งานจริง และเอกสารก็อธิบายไว้ชัดเจน (แอปหลายบริการ) สิ่งที่มีให้คือเส้นแบ่งที่ชัดเจนระหว่างการสร้างกับการเปิดใช้งานจริง:

• Preview รันแอปของคุณในแซนด์บ็อกซ์บนคลาวด์ส่วนตัวขณะที่คุณสร้าง การเปลี่ยนแปลงจะปรากฏที่นั่นก่อน ไม่ใช่บนแอปที่ใช้งานอยู่
• Share สร้าง ลิงก์ preview เพื่อให้ลูกค้าหรือเพื่อนร่วมทีมดูงานที่กำลังทำอยู่ได้โดยไม่ต้องมีบัญชี Mythex และโดยที่คุณไม่ต้องเผยแพร่ ลิงก์จะแสดงแซนด์บ็อกซ์ในสถานะปัจจุบัน รวมถึงการเปลี่ยนแปลงระหว่างการสร้าง และคุณลบได้ทุกเมื่อ
• Publish บันทึกสแนปช็อตของโปรเจกต์และนำขึ้นระบบ จนกว่าคุณจะเผยแพร่อีกครั้ง แอปที่ใช้งานอยู่จะคงสภาพเดิม
• Checkpoints ถูกบันทึกหลังเอเจนต์ทำงานสำเร็จแต่ละรอบ เพื่อให้คุณย้อนไฟล์โปรเจกต์ได้หากการเปลี่ยนแปลงผิดพลาด

ให้ถือ Preview เป็นการซ้อมของคุณ: ให้ผู้ให้บริการชำระเงินอยู่ในโหมดทดสอบจนกว่าจะเปิดตัว และทดสอบขั้นตอนสำคัญก่อนเผยแพร่ทุกครั้ง เมื่อมีลูกค้าจริงเกี่ยวข้อง ให้ถามเอเจนต์ว่า Preview ของคุณใช้ฐานข้อมูลและคีย์ใดอยู่ ก่อนทดสอบอะไรที่เขียนหรือลบข้อมูล หากคุณต้องการการตั้งค่า staging แยกโดยสมบูรณ์พร้อมฐานข้อมูลของตัวเอง ให้ขอให้เอเจนต์อธิบายตัวเลือกสำหรับโปรเจกต์ของคุณ หรือ — บน Pro — ส่งออกโปรเจกต์หรือซิงก์ไปยัง GitHub แล้วรันบนโครงสร้างพื้นฐานที่คุณควบคุมเอง

คำถาม