เช็คลิสต์ก่อน Deploy เว็บจริง: 7 ข้อ ที่นักพัฒนาต้องทำก่อนแชร์ลิงก์
ส่งลิงก์ให้เพื่อนแล้วโดนบอกว่าเปิดไม่ได้ หรือข้อมูลหาย คือประสบการณ์ที่นักพัฒนาหลายคนเจอตอน deploy (การนำโปรเจกต์ขึ้นสู่ server จริงเพื่อให้คนอื่นเข้าถึงได้) ครั้งแรก ปัญหาเหล่านี้ป้องกันได้ทั้งหมดถ้าเช็คให้ครบก่อน ความต่างระหว่างโค้ดที่รันได้ในเครื่องตัวเองกับโค้ดที่ทำงานได้บน production server จริงๆ นั้นมีหลายจุดที่คาดไม่ถึง บทความนี้รวบรวม 7 ข้อที่ควรตรวจสอบก่อน deploy ทุกครั้ง เพื่อไม่ให้ต้องมาแก้กลางดึกหลังแชร์ลิงก์ออกไปแล้ว
Build ผ่านหรือยัง? ทำไมต้อง Test Production Build ก่อน Deploy?
ข้อแรกคือรัน production build (กระบวนการ compile และ optimize โค้ดให้พร้อม deploy) แล้วแก้ error ทุกอันให้หมดก่อน เหตุผลที่ต้องทำขั้นตอนนี้คือโค้ดที่รันใน development mode กับ production build ทำงานต่างกัน development mode มี hot reload, verbose error messages, และไม่ทำ optimization ส่วน production build จะ minify โค้ด, tree-shake (ตัด code ที่ไม่ได้ใช้ออก), และ optimize assets ต่างๆ
บ่อยครั้งที่โค้ดรันได้ใน dev แต่ build ไม่ผ่านเนื่องจาก TypeScript errors ที่ถูก suppress ไว้, imports ที่ผิดพลาด หรือ environment-specific code ที่เขียนไว้เฉพาะ dev mode ให้รัน npm run build หรือคำสั่ง build ของ framework ที่ใช้ แล้วตรวจสอบว่าไม่มี error ก่อนทุกครั้ง จากนั้นรัน production server ในเครื่องตัวเองก่อนเพื่อยืนยันว่า build artifact ทำงานได้จริง
ถ้าพบ error ตอนนี้ดีกว่าพบหลัง deploy เสมอ เพราะแก้ไขง่ายกว่าและไม่กระทบผู้ใช้จริง
Environment Variables ตั้งค่าบน Hosting Platform แล้วหรือยัง?
Environment variables (ตัวแปรที่เก็บค่าสำคัญเช่น API key, database URL, secret key) คือสาเหตุที่พบบ่อยที่สุดที่ทำให้แอปทำงานบน localhost แต่ล้มเหลวบน production ไฟล์ .env ที่ใช้ใน development ไม่ได้ upload ขึ้น server โดยอัตโนมัติ ต้องตั้งค่าผ่าน dashboard ของ hosting platform โดยตรง เช่น Vercel, Railway, Render, หรือ AWS Elastic Beanstalk
สิ่งที่ต้อง migrate ขึ้น server ได้แก่ database connection string, JWT secret สำหรับ authentication, third-party API keys เช่น Stripe, SendGrid, Cloudinary, และ URL ของ services ต่างๆ ที่แอปใช้ ตรวจสอบว่า URL เปลี่ยนจาก localhost ไปเป็น production URL แล้วด้วย
ห้าม commit ไฟล์ .env หรือ secret ใดๆ ลง Git repository เด็ดขาด แม้แต่ใน private repository ให้ใช้ .gitignore เพื่อ exclude ไฟล์เหล่านี้เสมอ และตรวจสอบ git history ว่าไม่มี secret ถูก commit ไปก่อนหน้าด้วย
Database เชื่อมต่อจากระยะไกลได้ไหม?
ตอน develop ในเครื่องตัวเอง database มักจะเป็น localhost ที่รันอยู่บน machine เดียวกัน แต่หลัง deploy production server อยู่บน cloud และต้องเชื่อมต่อกับ database ผ่าน network จริงๆ มีหลายจุดที่อาจล้มเหลว ได้แก่ database ไม่ได้เปิด port ให้ external connections, firewall rules บน database server ไม่อนุญาต IP ของ production server, connection string ยังชี้ไปที่ localhost, หรือ production database ยังไม่ได้รัน schema migration
ถ้าใช้ managed database service เช่น Supabase, PlanetScale, MongoDB Atlas ให้ตรวจสอบ network settings ว่า allow connection จาก server จริง ถ้าใช้ self-hosted database ต้องเปิด port ที่ถูกต้องและตั้ง authentication ให้ถูกต้อง ทดสอบการเชื่อมต่อจาก production server โดยตรงก่อน deploy application จริง
อย่าลืม run database migrations บน production database ด้วย เพราะ schema ใน production อาจยังไม่ตรงกับ codebase ล่าสุด
Frontend กับ API URL ตรงกันไหม? CORS ตั้งค่าถูกต้องหรือเปล่า?
ปัญหาที่พบบ่อยมากอีกอย่างคือ frontend ยังชี้ไปที่ http://localhost:3001 แทนที่จะเป็น production API URL จริงๆ ตรวจสอบทุก API call ใน frontend code ว่าใช้ environment variable สำหรับ base URL แทนที่จะ hardcode ค่า localhost ไว้ตรงๆ
CORS (Cross-Origin Resource Sharing กลไกที่ browser ใช้ป้องกัน request ข้าม domain) คือสาเหตุที่ 2 ที่พบบ่อย ถ้า backend ตั้งค่า CORS allowed origins เป็น http://localhost:3000 แต่ frontend ที่ deploy ไปอยู่ที่ https://myapp.vercel.app ทุก request จะถูก browser block ทันทีด้วย error “CORS policy” ให้เพิ่ม production domain ของ frontend เข้าไปใน allowed origins บน server ก่อน deploy เสมอ
ถ้าใช้ Next.js หรือ framework ที่มี full-stack ในตัว ปัญหา CORS อาจไม่เกิดเพราะ frontend กับ backend อยู่ที่ same origin แต่ถ้า deploy frontend และ backend แยก server กัน ต้องตั้ง CORS ให้ถูกต้องทุกครั้ง
Refresh หน้าหรือ Direct URL ใช้งานได้ไหม? Routing ตั้งค่าถูกต้องหรือเปล่า?
นี่คือปัญหาที่มือใหม่พบบ่อยมากแต่ไม่คาดคิดล่วงหน้า React Router, Vue Router, Angular Router ทำงานบน client-side routing หมายความว่า URL เช่น /dashboard หรือ /profile/123 ถูกจัดการโดย JavaScript ใน browser ไม่ใช่โดย server
ใน development mode framework มักจะจัดการเรื่องนี้ให้อัตโนมัติ แต่หลัง deploy บน static hosting หรือ web server ถ้าผู้ใช้เปิด URL https://myapp.com/dashboard ตรงๆ หรือ refresh หน้า server จะพยายามหาไฟล์ชื่อ “dashboard” ซึ่งไม่มีอยู่ และตอบกลับด้วย 404 Not Found ทางแก้คือตั้งค่า server ให้ redirect ทุก request ที่ไม่พบไฟล์กลับไปที่ index.html แล้วให้ React จัดการ routing ต่อ โดยบน Vercel ทำผ่าน vercel.json, บน Nginx ทำผ่าน try_files directive
ทดสอบ User Flow จริงบนเว็บที่ Deploy แล้วหรือยัง?
การเปิดหน้าแรกได้ไม่ได้แปลว่าแอปทำงานได้ ต้องทดสอบ flow จริงๆ ที่ผู้ใช้จะทำ ได้แก่ สมัครสมาชิกด้วย email จริง, login ด้วย account ที่สมัครไป, ส่งฟอร์มและตรวจสอบว่าข้อมูลบันทึกจริง, reload หน้าและตรวจสอบว่าข้อมูลยังอยู่, ลอง flow ที่ต้อง authentication เช่นดูหน้า profile หรือ dashboard
ระหว่างทดสอบให้เปิด server log ไว้ด้วย เพราะ error บางอย่างไม่แสดงบน browser แต่จะปรากฏใน log เช่น database connection error, unhandled exception, หรือ rate limit ที่ถูกตั้งไว้บน hosting platform ถ้าใช้ managed hosting เช่น Vercel หรือ Railway มักมี log viewer ใน dashboard
ทดสอบด้วย browser ต่างๆ ด้วยถ้าเป็นไปได้ เพราะบางครั้ง CSS หรือ JavaScript API ที่ใช้อาจไม่ทำงานใน browser เก่ากว่าที่คาด
บทสรุป: รันในเครื่องได้ ไม่เท่ากับ Deploy แล้วทำงานถูก
“Works on my machine” คือประโยคที่นักพัฒนาควรหลีกเลี่ยง สภาพแวดล้อมใน development กับ production ต่างกันหลายจุด ตั้งแต่ environment variables, network configuration, server specs ไปจนถึง OS ที่รัน เช็คลิสต์ 7 ข้อที่ผ่านมาครอบคลุมจุดที่มักเกิดปัญหาบ่อยที่สุดใน production deployment
ทำให้การ check เหล่านี้เป็น routine ก่อน deploy ทุกครั้ง ไม่ว่าจะเป็นโปรเจกต์ส่วนตัวหรืองานจริง สร้างเป็น checklist และ commit ไว้ใน repository เพื่อให้ทีมทุกคนทำตามขั้นตอนเดียวกัน นิสัยนี้จะลดเวลา debugging บน production ได้อย่างมีนัยสำคัญ
คำถามที่พบบ่อยเกี่ยวกับการ Deploy เว็บ
ความแตกต่างระหว่าง development environment กับ production environment คืออะไร?
Development environment คือสภาพแวดล้อมที่นักพัฒนาใช้เขียนและทดสอบโค้ดในเครื่องตัวเอง มักมี hot reload, verbose error messages, และ debug tools เพื่อช่วยในการพัฒนา ส่วน production environment คือสภาพแวดล้อมที่ผู้ใช้จริงเข้าถึง มีการ optimize performance, security hardening, และ error handling ที่แตกต่างกัน ปัญหาหลักคือนักพัฒนาทดสอบเฉพาะใน development แล้วสมมติว่า production จะทำงานเหมือนกัน ซึ่งมักไม่เป็นความจริง เพราะ environment variables, network settings, และ server configuration แตกต่างกัน
ทำไมถึงห้าม commit ไฟล์ .env ขึ้น Git?
ไฟล์ .env เก็บข้อมูลที่เป็นความลับเช่น database password, API keys สำหรับบริการที่มีค่าใช้จ่าย, JWT secrets สำหรับ authentication ถ้า commit ขึ้น repository แม้แต่ private repository ข้อมูลเหล่านี้จะอยู่ใน git history ตลอดไป และถ้าเผลอทำ repository เป็น public หรือถูก hack ข้อมูลทั้งหมดจะรั่วออกไป ใช้ .gitignore เพื่อ exclude ไฟล์ .env เสมอ และใช้ environment variable management ของ hosting platform แทน
CORS error คืออะไร แก้ยังไง?
CORS (Cross-Origin Resource Sharing) คือกลไกความปลอดภัยที่ browser ใช้ป้องกันไม่ให้ JavaScript บนหนึ่ง domain ส่ง request ไปยัง domain อื่นโดยไม่ได้รับอนุญาต ถ้าเห็น error “CORS policy” ใน browser console แปลว่า server ยังไม่ได้อนุญาต domain ของ frontend ให้ส่ง request มา วิธีแก้คือเพิ่ม production domain ของ frontend เข้าไปใน CORS allowed origins บน server เช่น ถ้าใช้ Express.js ให้ตั้งค่า cors middleware ให้ถูกต้อง CORS เป็น server configuration ไม่ใช่ browser bug ดังนั้นแก้ที่ server เท่านั้น
ควรเลือก hosting platform ไหนสำหรับ Full Stack app แรก?
สำหรับผู้เริ่มต้น Vercel เหมาะสำหรับ frontend หรือ Next.js app ที่มี serverless functions Railway หรือ Render เหมาะสำหรับ Node.js backend ที่ต้องรันตลอดเวลา Supabase เหมาะสำหรับ managed PostgreSQL database ที่ตั้งค่าง่าย ทุก platform มี free tier ให้ทดลองก่อน ข้อดีของ managed platform คือจัดการ infrastructure ให้ส่วนใหญ่ ทำให้โฟกัสกับ code ได้มากกว่า และมี logging และ monitoring built-in ซึ่งช่วยมากเวลา debug production issues
ควรทดสอบอะไรบ้างหลัง deploy เสร็จ ก่อนแชร์ให้คนอื่น?
ทดสอบ critical user flows ทั้งหมดด้วยตัวเองบนเว็บที่ deploy แล้ว ไม่ใช่ใน localhost ได้แก่ สมัครสมาชิกและ login ด้วย email ใหม่ ทำ action หลักที่แอปออกแบบมา (เช่น submit form, create record, upload file) refresh หน้าแล้วตรวจสอบว่าข้อมูลยังอยู่ เปิด URL ของแต่ละหน้าตรงๆ ไม่ผ่านการคลิกจากหน้าแรก ลอง logout แล้ว login ใหม่ และดู server log ว่าไม่มี error ที่ไม่คาดคิด ถ้าทุกข้อผ่านค่อยแชร์ลิงก์
Deploy ได้จริง คือทักษะที่แยก Full Stack Developer จาก Beginner
เช็คลิสต์ 7 ข้อนี้ไม่ใช่เรื่องซับซ้อน แต่เป็นสิ่งที่คนที่ deploy เว็บครั้งแรกมักข้ามไปเพราะคิดว่า “รันในเครื่องได้แล้วก็น่าจะโอเค” ความจริงคือ production environment มีตัวแปรที่ต่างจาก localhost ทุกข้อ ตั้งแต่ environment configuration, network topology ไปจนถึงวิธีที่ server จัดการ static files และ routing
นักพัฒนา Full Stack ที่เชี่ยวชาญจะทำ pre-deploy checklist เป็นนิสัย บางทีม commit checklist ไว้ใน repository เป็น DEPLOYMENT.md เพื่อให้ทุกคนในทีมทำตามขั้นตอนเดียวกัน ซึ่งช่วยลด production incidents ได้มาก
ถ้าอยากเรียนรู้การพัฒนาเว็บแบบครบวงจร ตั้งแต่เขียน backend, สร้าง frontend, ต่อ database จนถึง deploy บน cloud คอร์ส FullStack Developer ของ FutureSkill สอนทุกขั้นตอนเหล่านี้รวมถึง best practices ที่ใช้ในการทำงานจริง ดูรายละเอียดคอร์สได้ที่ https://page.futureskill.co/fullstackn
Views: 6
