เอางานขึ้นเว็บจริง

จากเครื่องเรา ไปถึงผู้ใช้

เส้นทางของงานหนึ่งชิ้น ตั้งแต่เขียนจนผู้ใช้ได้ใช้ มักเป็นแบบนี้

1. ทำงานใน branch ของตัวเอง
2. เปิด Pull Request
3. CI ตรวจอัตโนมัติ
4. คนตรวจ แล้วรวมเข้า branch หลัก
5. deploy ขึ้นเซิร์ฟเวอร์จริง
6. ตรวจว่าเว็บจริงยังทำงานดี

บทที่แล้วพาไปถึงขั้นที่ 4 บทนี้ต่อจากนั้นจนจบ

CI: ด่านตรวจอัตโนมัติ

CI ย่อมาจาก Continuous Integration คือระบบที่รันการตรวจทุกครั้งที่มีคนส่งงานเข้ามา บนเครื่องที่สะอาด ไม่มีของค้างจากเครื่องใคร การตรวจที่พบบ่อยคือ

• ตรวจรูปแบบโค้ดและหาจุดผิดพลาดที่เห็นได้ชัด
• รันเทสต์ทั้งหมดจาก บทที่ 8: เทสต์: ให้เครื่องช่วยตรวจ
• ลอง build เว็บจริง ว่าประกอบเป็นเว็บที่ใช้งานได้

ผลจะขึ้นในหน้า Pull Request เป็นเครื่องหมายผ่านสีเขียวหรือไม่ผ่านสีแดง กติกาง่าย ๆ คือ แดงแม้ข้อเดียว ไม่รวมงาน

Deploy: เอางานขึ้นเซิร์ฟเวอร์จริง

deploy คือการเอาโค้ดจาก branch หลักไป build และเปิดให้ผู้ใช้ใช้งานบนเซิร์ฟเวอร์ บริการที่ทำเรื่องนี้ให้อัตโนมัติมีหลายเจ้า (ณ ตุลาคม 2026 เช่น Railway, Vercel และ Netlify) หลักการที่ใช้ได้กับทุกเจ้า

1. deploy เฉพาะงานที่ CI ผ่านแล้ว
2. รู้ว่ามีอะไรจะขึ้นบ้าง เขียนรายการงานที่จะขึ้นในรอบนี้
3. ก้อนเล็กและบ่อย ถ้าพัง หาสาเหตุง่าย
4. deploy ตอนที่มีคนว่างเฝ้าดูผลได้ ไม่ใช่ก่อนปิดเครื่องกลับบ้าน

ก่อน deploy ลองให้ agent ช่วยรวบรวมข้อมูลแบบนี้

ก่อน deploy ช่วยสรุป:
1. งานที่จะขึ้นรอบนี้มีอะไรบ้าง
2. มีการเปลี่ยนฐานข้อมูลไหม ถ้ามี ย้อนกลับได้หรือไม่
3. CI ของ commit ล่าสุดใน branch หลักผ่านทุกด่านไหม
4. หลัง deploy ควรตรวจหน้าไหน และทำอะไรบ้าง
5. ถ้าพัง จะย้อนกลับยังไง

หลัง deploy: ตรวจว่าเว็บจริงยังทำงาน

deploy สำเร็จไม่ได้แปลว่าเว็บทำงานถูก ต้องตรวจเว็บจริงหลังขึ้นทุกครั้ง

การตรวจแบบนี้ทำให้อัตโนมัติได้ เรียกว่า smoke test เว็บนี้มีเทสต์ชื่อ Production Smoke ที่เปิดหน้าสำคัญบนเว็บจริงทันทีหลัง deploy ทุกครั้ง ถ้าไม่ผ่าน เจ้าของจะรู้ภายในไม่กี่นาที

ย้อนกลับเมื่อพัง

วางแผนย้อนกลับก่อน deploy เสมอ วิธีที่ใช้บ่อยมีสองทาง

1. ย้อนกลับในบริการ hosting บริการส่วนใหญ่ให้กดเอาเวอร์ชันก่อนหน้ากลับมาได้ทันที เร็วที่สุด
2. revert แล้ว deploy ใหม่ ใช้ git revert ย้อนผลของงานที่มีปัญหาตามที่เรียนใน บทที่ 10: เก็บงานด้วย Git และ Pull Request แล้ว deploy อีกครั้ง

ทั้งสองวิธีย้อนได้แค่ โค้ด ส่วนข้อมูลในฐานข้อมูลไม่ย้อนตามไปด้วย ซึ่งพาไปสู่หัวข้อสุดท้าย

ฐานข้อมูล: ส่วนที่ย้อนกลับยากที่สุด

การเปลี่ยนโครงสร้างฐานข้อมูล เช่น เพิ่มหรือลบคอลัมน์ เรียกว่า migration ถ้าลบคอลัมน์ไปแล้ว ข้อมูลในคอลัมน์นั้นหายถาวร การย้อนโค้ดกลับก็ไม่ได้ข้อมูลคืนมา

อีกเรื่องที่มือใหม่มักไม่รู้คือ ระหว่าง deploy เวอร์ชันเก่ายังทำงานรับผู้ใช้อยู่ช่วงหนึ่ง ถ้า migration ลบคอลัมน์ที่โค้ดเก่ายังใช้ เว็บจะพังในช่วงนั้นทันที

กติกาที่ปลอดภัยคือ เพิ่มก่อน ลบทีหลัง

1. รอบแรก deploy โค้ดที่เลิกใช้ของเก่า
2. รอบถัดไป เมื่อมั่นใจว่าไม่มีอะไรใช้ของเก่าแล้ว จึง deploy migration ที่ลบมัน

จบเส้นทางแรก

ถึงตรงนี้คุณรู้แล้วว่างานของ dev ยุค AI คืออะไร โค้ดและเว็บทำงานยังไง เขียนโจทย์ให้ agent ยังไง ตรวจงานยังไง และเอางานขึ้นใช้จริงอย่างปลอดภัยยังไง

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

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

1. รวมงานทั้งที่ CI ยังแดง เพราะรีบ สุดท้ายต้องเสียเวลาแก้บนเว็บจริงมากกว่า
2. deploy งานก้อนใหญ่ทีเดียว ถ้าพังจะไม่รู้ว่ามาจากงานไหน
3. ไม่มีแผนย้อนกลับ ต้องมาคิดตอนที่เว็บกำลังพัง
4. ลบคอลัมน์ในฐานข้อมูลพร้อมกับโค้ดใหม่ในรอบเดียว โค้ดเก่าที่ยังทำงานระหว่าง deploy จะพัง
5. แก้โค้ดตรงบนเซิร์ฟเวอร์ งานนั้นไม่อยู่ใน Git และจะหายไปใน deploy ครั้งถัดไป

เช็กความเข้าใจ