ทดสอบ schema ใหม่บน production ตรง ๆ ได้ไหมหรือต้องแยก branch ก่อนเสมอ

หนึ่งในความเสี่ยงที่พบบ่อยที่สุดของทีมพัฒนาที่ใช้ฐานข้อมูลจริงตั้งแต่ช่วงพัฒนา คือการรัน migration หรือแก้ schema บนฐานข้อมูล production ตรง ๆ เพราะไม่มีสภาพแวดล้อมแยกให้ทดสอบก่อน ถ้า migration นั้นมีข้อผิดพลาด ผลกระทบจะเกิดกับผู้ใช้จริงทันที ไม่ใช่แค่เสียเวลาแก้ไข

หลายทีมแก้ปัญหานี้ด้วยการสร้างฐานข้อมูล staging แยกไว้เอง แต่การดูแลให้ staging กับ production ข้อมูลและ schema sync กันตลอดเวลาก็เป็นภาระอีกชั้นหนึ่งที่ต้องดูแลต่อเนื่อง Supabase Branching ถูกออกแบบมาเพื่อลดภาระตรงนี้โดยเฉพาะ

บทความนี้จะอธิบายว่า Branching ของ Supabase ทำงานยังไง ต่างจากการทำ staging database เองยังไง และมีข้อจำกัดอะไรที่ควรรู้ก่อนตัดสินใจใช้

Supabase Branching คืออะไร ทำงานต่างจาก staging database เองยังไง

Supabase Branching สร้างสำเนาของโปรเจกต์ทั้งชุดขึ้นมาเป็น branch แยก ไม่ใช่แค่ก็อปปี้ตารางข้อมูลอย่างเดียว แต่รวมถึง schema, migration history, extension, และ configuration อื่น ๆ ของโปรเจกต์ด้วย ทำให้ branch ที่สร้างขึ้นมามีสภาพแวดล้อมใกล้เคียงกับ production มากกว่าการสร้าง staging database แยกเองที่มักจะ config ไม่ตรงกันทีละนิดจนต่างจาก production ไปเรื่อย ๆ

จุดที่ต่างจากการทำ staging เองชัดเจนคือ branch แต่ละอันผูกกับ git branch ได้โดยตรง เมื่อสร้าง pull request ใหม่ Supabase สามารถสร้าง branch ของฐานข้อมูลที่ตรงกับ branch โค้ดนั้นให้อัตโนมัติ ทำให้ทีมทดสอบ migration พร้อมกับโค้ดฝั่ง frontend และ backend ในสภาพแวดล้อมเดียวกันได้จริง

เมื่อทดสอบเสร็จและพร้อม merge โค้ดกลับเข้า main การ merge migration เข้า production ก็ทำผ่านขั้นตอนเดียวกัน ลดความเสี่ยงจากการต้องจำเองว่า migration ตัวไหนรันไปแล้วหรือยังในแต่ละสภาพแวดล้อม

workflow การใช้ branching ในทีมพัฒนาจริงเป็นยังไง

workflow ทั่วไปเริ่มจากนักพัฒนาสร้าง branch ใหม่สำหรับฟีเจอร์ที่กำลังทำ แล้วสร้าง branch ของฐานข้อมูลคู่กัน จากนั้นแก้ schema หรือเขียน migration ทดสอบบน branch นั้นได้อย่างอิสระ โดยไม่กระทบข้อมูลจริงหรือ branch ของเพื่อนร่วมทีมคนอื่นเลย:

1. สร้าง branch โค้ดใหม่ตามปกติ แล้วเชื่อมกับ branch ฐานข้อมูลใหม่ผ่านการตั้งค่าของ Supabase
2. เขียนและทดสอบ migration บน branch นั้น รวมถึงทดสอบ policy ใหม่หรือแก้ schema ที่ต้องการ
3. ให้ทีมอื่นรีวิวทั้งโค้ดและการเปลี่ยนแปลง schema พร้อมกันผ่าน pull request เดียว
4. เมื่อรีวิวผ่านแล้ว merge เข้า main โค้ดและ migration จะถูกนำไป apply กับ production ตามขั้นตอนที่ตั้งไว้
5. ลบ branch ฐานข้อมูลทิ้งหลัง merge เสร็จ เพื่อไม่ให้มี branch ค้างจำนวนมากที่ไม่มีใครใช้แล้ว

Preview branch กับ Persistent branch ต่างกันยังไง เลือกใช้แบบไหน

Preview branch สร้างขึ้นแบบผูกกับ pull request แต่ละใบโดยอัตโนมัติ มีอายุตามอายุของ PR นั้น พอ PR ถูก merge หรือปิดไป branch ที่สร้างไว้ก็จะถูกลบทิ้งไปตามการตั้งค่า เหมาะกับงานทดสอบฟีเจอร์เฉพาะที่รู้อยู่แล้วว่าจะจบลงด้วยการ merge หรือทิ้งในเร็ว ๆ นี้ ไม่ต้องมีใครมาคอยจำว่าต้องลบ branch เมื่อไหร่

Persistent branch ไม่ผูกกับ PR ใดโดยเฉพาะ ต้องสร้างและลบเองตามที่ทีมกำหนด เหมาะกับสภาพแวดล้อมที่ต้องมีอยู่ตลอดเวลา เช่น staging environment ที่ทีม QA ใช้ทดสอบต่อเนื่องทุกวัน หรือ environment สำหรับ demo ให้ลูกค้าดูที่ต้องพร้อมใช้งานได้ทุกเมื่อ ไม่ใช่แค่ช่วงที่มี PR เปิดอยู่เท่านั้น

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

จัดการ branch ผ่าน Supabase CLI ต้องรู้คำสั่งไหนบ้าง

การจัดการ branch ผ่าน CLI เริ่มจาก link โปรเจกต์ก่อนด้วย supabase link --project-ref จากนั้นสร้าง branch ใหม่ด้วย supabase branches create <ชื่อ branch> ดูรายการ branch ที่มีอยู่ทั้งหมดด้วย supabase branches list และดึงรายละเอียดของ branch หนึ่งด้วย supabase branches get เมื่อเลิกใช้แล้วลบด้วย supabase branches delete เพื่อไม่ให้มี branch ค้างสะสมโดยไม่มีใครใช้

จุดสำคัญที่ต้องรู้คือไฟล์ migration ต้องอยู่ในโฟลเดอร์ supabase/migrations ก่อนสร้าง branch เพราะ branch ใหม่จะ apply migration ที่มีอยู่ในโฟลเดอร์นี้ให้อัตโนมัติตามลำดับ ถ้าเขียน migration ไว้แล้วแต่ยังไม่ commit เข้า repository branch ที่ระบบสร้างขึ้นผ่าน CI จะไม่เห็น migration นั้นเลย ทีมที่ทำงานพร้อมกันหลายคนควรตกลงลำดับการตั้งชื่อไฟล์ migration ให้ชัดเจนตั้งแต่ต้น เพื่อลดโอกาสที่ migration ของสองคนจะชนกันตอน merge เข้า branch เดียวกัน

ทำแบบนี้แล้วพัง เพราะ...: บางทีมแก้ schema ผ่าน Supabase Studio ตรง ๆ บน branch โดยไม่สร้างไฟล์ migration เก็บไว้ใน repository เมื่อ branch นั้นถูกลบทิ้งหรือมีการสร้าง branch ใหม่ขึ้นมาแทน การเปลี่ยนแปลงที่ทำผ่าน Studio ตรง ๆ จะหายไปทันทีเพราะไม่มี migration file บันทึกไว้ที่ไหนเลย ทุกการเปลี่ยนแปลง schema จึงควรเขียนเป็น migration file เสมอ ไม่ว่าจะทดสอบบน branch หรือทำบน production ก็ตาม

ทดสอบอะไรได้บ้างบน branch ที่หลายทีมมองข้าม

หลายทีมนึกถึง branching แค่ในมุมทดสอบว่า migration รันผ่านไหม แต่จริง ๆ แล้ว branch สามารถใช้ทดสอบ RLS policy ใหม่ได้ด้วย เพราะ policy ก็เป็นส่วนหนึ่งของ schema เช่นกัน การทดสอบ policy บน branch ก่อน merge ช่วยลดความเสี่ยงที่จะเผลอเปิดช่องโหว่ข้อมูลตอนขึ้น production ตามที่อธิบายไว้ใน Supabase RLS คืออะไร

อีกสิ่งที่ทดสอบได้คือ Supabase Edge Functions ที่ผูกกับฐานข้อมูล เพราะ branch สามารถ deploy ฟังก์ชันคู่กับ schema เวอร์ชันใหม่ได้ ทำให้เห็นว่าโค้ดฟังก์ชันกับ schema ใหม่ทำงานร่วมกันถูกต้องก่อน merge จริง ไม่ต้องรอไป debug ตอนขึ้น production

การทดสอบ data migration ที่ซับซ้อน เช่นแปลงข้อมูลเก่าให้เข้ากับ schema ใหม่ ก็ทำได้บน branch โดยใช้ข้อมูลตัวอย่างที่ใกล้เคียงของจริง ช่วยจับปัญหาเรื่อง performance หรือ edge case ของข้อมูลได้ก่อนที่จะกระทบข้อมูลจริง

ข้อจำกัดของ branching ที่ควรรู้ก่อนใช้

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

ข้อมูลใน branch ไม่ได้ sync กับ production แบบสองทาง การเปลี่ยนแปลงข้อมูลใน branch จะไม่ไหลกลับเข้า production เอง ต้องผ่านขั้นตอน merge migration ตามที่ตั้งใจเท่านั้น ถ้าทีมเข้าใจผิดคิดว่าแก้ข้อมูลใน branch แล้วจะอัปเดต production ไปด้วย อาจทำให้ข้อมูลไม่ตรงกันโดยไม่รู้ตัว

branch ที่สร้างจาก production ขนาดใหญ่มาก อาจใช้เวลาสร้างนานกว่าที่คาดไว้ เพราะต้องคัดลอก schema และ configuration ทั้งชุด ทีมที่ต้องการ branch เร็ว ๆ เพื่อทดสอบเล็กน้อย เช่นทดสอบ policy ของ Supabase Storage ควรวางแผนเรื่องเวลานี้ไว้ล่วงหน้าด้วย

โปรเจกต์แบบไหนที่ยังไม่จำเป็นต้องใช้ branching

ทีมขนาดเล็กมากที่มีนักพัฒนาคนเดียวหรือสองคน และยังอยู่ในช่วงเริ่มต้นที่ schema เปลี่ยนแทบทุกวัน อาจยังไม่ได้ประโยชน์เต็มที่จาก branching เพราะภาระในการสร้างและลบ branch อาจมากกว่าความเสี่ยงที่ป้องกันได้จริงในช่วงนั้น การทดสอบบนฐานข้อมูล development เครื่องเดียวอาจเพียงพอแล้วสำหรับช่วงเริ่มต้น

โปรเจกต์ที่ schema นิ่งมากและแทบไม่มี migration ใหม่เกิดขึ้นบ่อย ก็อาจไม่ต้องใช้ branching อย่างเข้มข้น เพราะความเสี่ยงจากการแก้ schema ผิดพลาดมีน้อยกว่าโปรเจกต์ที่เปลี่ยน schema บ่อย

จุดที่ควรเริ่มพิจารณาใช้ branching จริงจังคือเมื่อทีมโตขึ้น มีนักพัฒนาหลายคนทำงานพร้อมกันบน schema เดียวกัน หรือเมื่อ migration แต่ละครั้งเริ่มมีความเสี่ยงสูงขึ้นเพราะข้อมูล production มีปริมาณมากแล้ว

ถ้า migration ที่ merge ไปแล้วมีปัญหา แก้ยังไง

แม้จะทดสอบบน branch มาอย่างดีแล้ว ก็ยังมีโอกาสที่ migration จะมีปัญหาหลัง merge เข้า production จริง เพราะข้อมูลจริงอาจมี edge case ที่ข้อมูลตัวอย่างใน branch ไม่ครอบคลุม เช่นกรณีสิทธิ์ผู้ใช้ที่ผูกกับระบบยืนยันตัวตนตามที่อธิบายไว้ใน Supabase Auth คืออะไร การมีแผนรับมือไว้ล่วงหน้าจึงสำคัญพอกับการทดสอบก่อน merge

แนวทางที่ปลอดภัยกว่าคือเขียน migration ให้ reversible เท่าที่ทำได้ เช่นแยกขั้นตอนการเพิ่มคอลัมน์ใหม่ออกจากขั้นตอนการลบคอลัมน์เก่า เพื่อให้สามารถ rollback บางส่วนได้โดยไม่ต้อง restore ฐานข้อมูลทั้งชุด ซึ่งเป็นขั้นตอนที่ใช้เวลานานกว่ามากถ้าข้อมูล production มีปริมาณสูง

การมี branch สำรองที่สร้างไว้ก่อน merge ก็ช่วยได้ในกรณีที่ต้องเปรียบเทียบพฤติกรรมก่อนกับหลังการเปลี่ยนแปลง เพื่อยืนยันว่าปัญหาที่เกิดขึ้นมาจาก migration ล่าสุดจริงหรือมาจากสาเหตุอื่น

สรุป

Supabase Branching ช่วยลดความเสี่ยงจากการทดสอบ schema หรือ migration บนฐานข้อมูล production ตรง ๆ โดยสร้างสำเนาของโปรเจกต์ทั้งชุดขึ้นมาเป็น branch แยก ที่ผูกกับ git branch ได้โดยตรง ทำให้ทดสอบทั้งโค้ดและการเปลี่ยนแปลงฐานข้อมูลไปพร้อมกันในสภาพแวดล้อมเดียว

ทีมที่กำลังเติบโตและมีนักพัฒนาหลายคนทำงานบน schema เดียวกัน ควรพิจารณาใช้ branching อย่างจริงจัง แต่ต้องมีวินัยในการลบ branch ที่ไม่ใช้แล้ว และเข้าใจว่าข้อมูลใน branch ไม่ได้ sync กลับ production อัตโนมัติ ต้องผ่านขั้นตอน merge migration ตามที่ตั้งใจเท่านั้น

• branch คัดลอกทั้ง schema, migration history, และ configuration ไม่ใช่แค่ข้อมูล
• ผูกกับ git branch ได้โดยตรง ทดสอบโค้ดและฐานข้อมูลพร้อมกันในสภาพแวดล้อมเดียว
• policy และ Edge Functions ก็ทดสอบได้บน branch ก่อน merge เข้า production
• แต่ละ branch มีค่าใช้จ่าย ควรลบทิ้งเมื่อใช้งานเสร็จเพื่อควบคุมต้นทุน

คำถามที่พบบ่อย