วิธีตั้งค่า Staging Environment สำหรับแอปของคุณ

การตั้งค่า staging environment คือการนำแอปอีกสำเนาไปดีพลอยที่ URL ส่วนตัวของตัวเอง ให้มีฐานข้อมูลและ API key ทดสอบของตัวเอง และทำให้การตั้งค่าใกล้เคียงกับโปรดักชันมากที่สุด จากนั้นปล่อยทุกการเปลี่ยนแปลงสำคัญไปที่ staging ก่อน ทดสอบขั้นตอนที่สำคัญ และค่อยเผยแพร่ขึ้นโปรดักชันเมื่อ staging ดูถูกต้องแล้ว

หากคุณยังไม่คุ้นกับแนวคิดนี้ staging environment คืออะไร จะอธิบายแนวคิดให้ก่อน คู่มือนี้เป็นการตั้งค่าเชิงปฏิบัติ สำหรับคนที่สร้างด้วยเครื่องมือ AI มากกว่าคนที่ดูแลระบบ DevOps เต็มเวลา

Dev, staging และ production

แอปขนาดเล็กส่วนใหญ่ต้องมีสามที่ แม้ที่แรกอาจเป็นแค่ตัว preview ของเครื่องมือสร้างของคุณ:

จุดประสงค์ของ staging คือให้ทำงานเหมือนโปรดักชัน ทั้งโค้ด สแตก และประเภทการตั้งค่าเดียวกัน แต่ความผิดพลาดที่นั่นไม่ทำร้ายใคร

ขั้นที่ 1: ตัดสินใจว่า staging ต้องตรงกับอะไรบ้าง

Staging มีประโยชน์ก็ต่อเมื่อปัญหาปรากฏที่นั่นก่อนจะปรากฏในโปรดักชัน ให้ตรงกันในเรื่อง:

• โค้ดเดียวกัน ปล่อยด้วยวิธีเดียวกัน
• สแตกและเวอร์ชันเดียวกัน เช่น เฟรมเวิร์ก รันไทม์ ชนิดของฐานข้อมูล
• ประเภทการตั้งค่าเดียวกัน ชื่อตัวแปร environment เดียวกัน แต่ใช้ค่าทดสอบ
• บริการเดียวกัน หากโปรดักชันมีเว็บแอปและ API staging ก็ต้องมีทั้งสองอย่าง

ขนาดและข้อมูลต่างกันได้ (เครื่องที่เล็กกว่าก็ใช้ได้)

ขั้นที่ 2: สร้างสำเนา

วิธีที่ง่ายที่สุดคือดีพลอยโปรเจกต์เดิมอีกครั้งที่ URL อื่น เช่น staging.yourapp.com หรือ yourapp-staging.example.com

วิธีทำขึ้นอยู่กับโฮสต์ของคุณ:

• โฮสต์ที่มีการดีพลอย preview หรือ staging ในตัว สามารถสร้างให้อัตโนมัติสำหรับ branch ของ Git ได้
• โฮสต์ที่ไม่มีฟีเจอร์นี้ สร้างแอปหรือโปรเจกต์ที่สองจากโค้ดเดียวกัน แล้วดีพลอยแยกกัน
• โค้ดอยู่ใน Git เก็บ branch staging หรือ main ที่ดีพลอยไป staging และดีพลอยขึ้นโปรดักชันจากการปล่อยเวอร์ชัน ดู วิธีใช้ Git กับแอปที่สร้างด้วย AI

ขั้นที่ 3: ให้ staging มีฐานข้อมูลของตัวเอง

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

• สร้างฐานข้อมูลแยกสำหรับ staging
• เติมด้วย seed data คือข้อมูลปลอมที่สมจริงที่ AI สร้างให้คุณได้
• หากต้องการสำเนาข้อมูลโปรดักชัน ให้ลบหรือสุ่มชื่อ อีเมล และทุกอย่างที่เป็นข้อมูลส่วนบุคคลก่อน

เขียนสคริปต์ seed ที่เติมฐานข้อมูลว่างด้วยข้อมูลทดสอบที่สมจริง: ลูกค้า 20 ราย ออเดอร์ 50 รายการในสถานะต่าง ๆ และผู้ดูแลระบบสองคน ใช้ชื่อปลอมที่เห็นได้ชัดและอีเมลแบบ example.com

ก่อนจะเชื่อใจการตั้งค่า ให้ยืนยันว่าแต่ละสำเนาเชื่อมต่อกับฐานข้อมูลตัวไหน ถามตรง ๆ:

แอปนี้เชื่อมต่อกับฐานข้อมูลตัวไหน และการตั้งค่านั้นมาจากไหน แสดงชื่อตัวแปรให้ดู ไม่ต้องแสดงรหัสผ่าน

ขั้นที่ 4: ใช้คีย์ทดสอบและการตั้งค่าแยก

ทุกอย่างที่ติดต่อกับบริการภายนอกควรใช้ข้อมูลรับรอง ทดสอบ ใน staging:

• การชำระเงิน ในโหมดทดสอบ (เช่น คีย์ทดสอบของ Stripe) เพื่อไม่ให้มีการตัดบัตรจริง
• อีเมล ส่งไป sandbox หรือส่งเฉพาะไปยังที่อยู่ของคุณเอง เพื่อไม่ให้ลูกค้าได้รับข้อความทดสอบ
• AI และ API แบบเสียเงินอื่น ๆ ด้วยคีย์แยกและเพดานการใช้จ่ายที่ต่ำ
• Webhook ชี้ไปที่ URL ของ staging ไม่ใช่โปรดักชัน

ให้ ชื่อ ตัวแปรเหมือนกันในทั้งสอง environment และเปลี่ยนเฉพาะ ค่า วิธีนี้โค้ดไม่ต้องรู้ว่ากำลังรันอยู่ที่ไหน ดูเพิ่มเติมที่ วิธีเก็บ API key ให้ปลอดภัย

ขั้นที่ 5: ทำให้ staging เป็นส่วนตัว

Staging ไม่ควรเป็นสาธารณะ:

• ใส่ไว้หลังการเข้าสู่ระบบ รหัสผ่าน หรือรายการอนุญาตอีเมลของทีม
• หยุดไม่ให้เสิร์ชเอนจินจัดทำดัชนีด้วยแท็ก noindex หรือ header X-Robots-Tag
• อย่าลิงก์ไปยัง staging จากเว็บสาธารณะ
• ทำให้มันดูต่างออกไป แบนเนอร์สี "STAGING" ช่วยป้องกันการทดสอบผิดแท็บ

เพิ่มแบนเนอร์สีเหลืองสดที่ด้านบนทุกหน้า ที่ระบุว่า "STAGING — ใช้ข้อมูลทดสอบเท่านั้น" เมื่อตัวแปร APP_ENV เป็น "staging" และเพิ่มแท็ก noindex meta ในกรณีนั้นด้วย

ขั้นที่ 6: สร้างกิจวัตรการปล่อยเวอร์ชัน

Staging จะมีประโยชน์ก็ต่อเมื่อคุณใช้ทุกครั้ง กิจวัตรง่าย ๆ:

1. ทำการเปลี่ยนแปลงใน development และตรวจใน preview
2. ปล่อยไป staging
3. ไล่ดูขั้นตอนหลัก: สมัคร เข้าสู่ระบบ ฟีเจอร์หลัก การชำระเงิน และทุกอย่างที่การเปลี่ยนแปลงแตะถึง
4. หากมีอะไรพัง ให้แก้และปล่อยไป staging อีกครั้ง
5. เผยแพร่เวอร์ชันเดียวกันไปโปรดักชัน
6. ตรวจโปรดักชันอย่างรวดเร็ว ด้วยขั้นตอนเดียวกันแบบสั้น ๆ

เขียนขั้นตอนหลักเป็นสคริปต์ทดสอบสั้น ๆ ดู วิธีทดสอบแอปก่อนเปิดตัว สำหรับสิ่งที่ควรรวมไว้

ขั้นที่ 7: จัดการการเปลี่ยนแปลงฐานข้อมูลอย่างระมัดระวัง

การเปลี่ยนแปลงโครงสร้างฐานข้อมูล เช่น การเพิ่มคอลัมน์หรือเปลี่ยนชื่อตาราง คือจุดที่ staging คุ้มค่าที่สุด

• รันการเปลี่ยนแปลงโครงสร้างทุกครั้งบน staging ก่อน
• ตรวจว่าข้อมูลที่มีอยู่ยังอยู่ครบ ไม่ใช่แค่ว่าฟีเจอร์ใหม่ทำงาน
• สำรองข้อมูลโปรดักชันก่อนรันการเปลี่ยนแปลงเดียวกันที่นั่น ดู วิธีสำรองฐานข้อมูลของแอป
• เลือกการเปลี่ยนแปลงที่เพิ่มมากกว่าเปลี่ยนชื่อหรือลบ เพื่อให้เวอร์ชันเก่ายังทำงานได้หากต้องย้อนกลับ

พรอมต์ตัวอย่าง

อธิบายว่าจะเกิดอะไรกับข้อมูลที่มีอยู่ หากเรารันการเปลี่ยนแปลงฐานข้อมูลนี้บนโปรดักชัน มีอะไรถูกลบหรือเปลี่ยนชื่อไหม

ทำให้การตั้งค่าเฉพาะ environment ทั้งหมด เช่น URL ของ API คีย์ ผู้ส่งอีเมล และ URL ของเว็บไซต์เอง มาจากตัวแปร environment ที่มีชื่อเดียวกันทั้งใน staging และโปรดักชัน แสดงรายการให้ดู

เขียนรายการตรวจสอบสั้น ๆ ของขั้นตอนที่ฉันควรทดสอบบน staging ก่อนการปล่อยแต่ละครั้ง โดยอิงจากสิ่งที่แอปนี้ทำ

ข้อผิดพลาดที่พบบ่อย

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

เช็กลิสต์

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

Staging บน Mythex

ฟีเจอร์ Publish ของ Mythex ให้ URL สดหนึ่งรายการต่อแอป ไม่มีสวิตช์ staging แยกต่างหาก ในทางปฏิบัติคุณมีสองทางเลือก:

• Preview เป็นการตรวจก่อนปล่อย ทุกโปรเจกต์รันในพื้นที่ทำงานบนคลาวด์ส่วนตัวพร้อม Preview แบบสด /test ให้เอเจนต์คลิกผ่านเหมือนผู้ใช้ และลิงก์ Share ให้ลูกค้าหรือเพื่อนร่วมทีมตรวจ preview ได้โดยไม่ต้องเผยแพร่ ดู Preview และ Code ซึ่งเพียงพอสำหรับโปรเจกต์เดี่ยวหลายโปรเจกต์
• โปรเจกต์ที่สองเป็น staging ในแพ็ก Pro ให้ส่งออกโปรเจกต์ แล้วนำเข้าเป็นโปรเจกต์ใหม่ ให้โปรเจกต์นั้นมีฐานข้อมูลและความลับคีย์ทดสอบของตัวเอง และเผยแพร่ด้วย slug ของตัวเอง ปล่อยไปที่นั่นก่อนเผยแพร่โปรเจกต์โปรดักชัน

ไม่ว่าจะเลือกทางไหน ให้ถามเอเจนต์ก่อนทดสอบสิ่งที่ทำลายข้อมูลว่า preview และแอปที่เผยแพร่ใช้ฐานข้อมูลตัวไหน และใช้ checkpoint เพื่อย้อนการเปลี่ยนแปลงที่มีปัญหา สำหรับการนำแอปขึ้นใช้งานจริงในภาพกว้าง ดู วิธีนำต้นแบบ AI ขึ้นโปรดักชัน

คำถาม