ParitLAB
← Lab Notes

คู่มือการใช้งาน · 2026-09-15

Deploy ระบบใหม่โดยพิสูจน์ว่าข้อมูลลูกค้าเดิมไม่เปลี่ยน

เผยแพร่โดย ParitLAB
บันทึกจากการออกแบบ พัฒนา และทดสอบผลิตภัณฑ์ของเรา

deployment, backup, data integrity, production, database migration

คำว่า “Deploy สำเร็จ” ไม่ควรหมายถึงหน้าเว็บเปิดได้เท่านั้น หากการอัปเดตแตะระบบลูกค้า License หรือคำสั่งซื้อ เราต้องตอบได้ด้วยว่าข้อมูลเดิมยังอยู่ครบ ParitLAB ใช้การตรวจหลายชั้นเพื่อแยกความสำเร็จของ Code ออกจากความถูกต้องของข้อมูล

เริ่มจากระบุข้อมูลที่ห้ามเปลี่ยน

ก่อน Deploy เรากำหนดตารางที่เกี่ยวข้อง เช่น Users, Projects, Licenses, Orders และตารางกำหนดสิทธิ์ จากนั้นอ่านข้อมูลตามลำดับ Primary key ที่แน่นอน นับจำนวนแถว และสร้าง SHA-256 hash ของข้อมูลที่ Serialise แล้ว การเรียงลำดับสำคัญ เพราะข้อมูลชุดเดียวกันที่อ่านคนละลำดับจะได้ Hash ต่างกันทั้งที่ไม่มีค่าใดเปลี่ยน

สำรอง Code และ Snapshot แยกกัน

ไฟล์ PHP, CSS และ JavaScript เดิมถูกเก็บไว้ในโฟลเดอร์ Backup ที่มี Timestamp ส่วนข้อมูลฐานข้อมูลบันทึกเป็น Snapshot แยกต่างหากและไม่วางใน Public web root การแยกสองส่วนนี้ช่วยให้ย้อนดูได้ว่า Code ก่อน Deploy เป็นอะไร และข้อมูลก่อน Migration มีสถานะอย่างไร โดยไม่ต้องเดาจาก Version ปัจจุบัน

Schema แบบ Additive ลดพื้นที่ความเสียหาย

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

อัปโหลดผ่านไฟล์ Stage

ไฟล์ใหม่ถูกอัปโหลดเป็นชื่อชั่วคราวก่อน ตรวจขนาดและ Hash ให้ตรงกับไฟล์ Local แล้วจึง Rename ไปแทนไฟล์จริง วิธีนี้ลดช่วงเวลาที่เซิร์ฟเวอร์อาจอ่านไฟล์ซึ่งอัปโหลดไม่ครบ ก่อนเขียนทับยังตรวจอีกครั้งว่าไฟล์ Production ไม่ถูกแก้โดยงานอื่นหลังจากเริ่ม Deploy

ตรวจหลัง Migration และหลัง Deploy

หลัง Code ใหม่สร้าง Schema ระบบอ่านตารางเดิมซ้ำด้วย Query เดิม หาก Count หรือ Hash เปลี่ยนโดยงานนี้ไม่ได้ตั้งใจ การ Deploy ต้องหยุดทันที สำหรับคอลัมน์ใหม่ เราตรวจแยกว่า Schema ถูกสร้างครบและค่า Permission เริ่มต้นยังเป็นศูนย์ สุดท้ายจึงตรวจ HTTP status, Redirect ของผู้ที่ยังไม่ Login และ Asset ที่ Browser ต้องโหลด

Hash บอกอะไรและไม่บอกอะไร

Hash ที่ตรงกันพิสูจน์ว่าข้อมูลที่เลือกตรวจมีค่าและลำดับเหมือนเดิม แต่ไม่ได้พิสูจน์ว่า Business logic ใหม่ถูกต้องทั้งหมด จึงยังต้องมี Test ด้านสิทธิ์และทดสอบหน้าเว็บจริงร่วมด้วย ในทางกลับกัน Test หน้าเว็บที่ผ่านก็ไม่สามารถพิสูจน์ว่าข้อมูลทุกแถวปลอดภัยได้ ทั้งสองหลักฐานจึงทำหน้าที่คนละอย่างและควรเก็บคู่กัน

Checklist ที่ใช้ได้กับงานขนาดเล็ก

  1. Lint และ Test Code ก่อนเชื่อมต่อ Production
  2. สำรองไฟล์ที่จะเปลี่ยนทุกไฟล์
  3. บันทึก Count และ Hash ของข้อมูลสำคัญ
  4. ใช้ Migration ที่ย้อนเหตุผลได้และมีค่าเริ่มต้นปลอดภัย
  5. อัปโหลดแบบ Stage แล้ว Rename
  6. ตรวจข้อมูลซ้ำและทดสอบเส้นทางหลักหลัง Deploy