WordPress Staging, Git Deploy และ Rollback บน Hosting: Workflow สำหรับฟรีแลนซ์ที่ดูแลหลายเว็บ

WordPress Staging คือสำเนาเว็บสำหรับทดสอบก่อนขึ้นจริง สรุป Workflow บน Hosting ตั้งแต่สร้าง Staging เก็บโค้ดใน Git, Deploy ไปจนถึง Rollback เมื่อพัง

โดย admin2 พ.ย. 2569 09:00 น. อัปเดต 3 พ.ย. 2569 อ่าน 10 นาที

แชร์Facebook X LINE LinkedIn

WordPress Staging คือสำเนาของเว็บจริงที่แยกไว้สำหรับทดสอบการอัปเดตปลั๊กอิน ธีม หรือโค้ดใหม่ ก่อนนำขึ้นเว็บจริง (production) เมื่อใช้ร่วมกับ Git และขั้นตอน deploy ที่ชัดเจน จะลดความเสี่ยงที่เว็บลูกค้าพังกลางวัน และทำให้ถอยกลับได้ภายในไม่กี่นาทีเมื่อมีปัญหา

ฟรีแลนซ์และทีมเล็กที่ดูแลเว็บลูกค้าหลายสิบเว็บมักแก้ไฟล์ตรงบน production เพราะเร็วกว่า วิธีนี้ทำงานได้จนถึงวันที่อัปเดตปลั๊กอินแล้วหน้าชำระเงินพัง บทความนี้เสนอ workflow ที่ตั้งได้บน Hosting ทั่วไป โดยไม่ต้องมีระบบ CI/CD ขนาดใหญ่

Workflow ภาพรวม

Local (เครื่องนักพัฒนา) → Git Repository → WordPress Staging → Production

หลักการสำคัญคือ โค้ดไหลขึ้น ข้อมูลไหลลง

โค้ด (ธีม, ปลั๊กอินที่เขียนเอง, การตั้งค่า) ไหลจาก Git → Staging → Production
ข้อมูล (ฐานข้อมูล, ไฟล์ที่อัปโหลด) ไหลจาก Production → Staging เพื่อทดสอบกับข้อมูลจริง

การ push ฐานข้อมูลจาก WordPress Staging ทับ production เป็นความผิดพลาดที่ร้ายแรงที่สุด โดยเฉพาะร้าน WooCommerce เพราะออเดอร์และสมาชิกใหม่ที่เกิดระหว่างนั้นจะหายทั้งหมด

ขั้นตอนที่ 1: สร้าง WordPress Staging บน Hosting

ทางเลือกที่พบบ่อยมีสองแบบ

วิธี	ข้อดี	ข้อควรระวัง
ใช้เครื่องมือของแผงควบคุม (เช่น WP Toolkit บน Plesk)	กดโคลนได้ทันที, sync ไฟล์และฐานข้อมูลได้	ต้องเลือกให้ดีว่า sync อะไรขึ้น production
สร้างเองบนซับโดเมนด้วย WP-CLI	ควบคุมได้ทุกขั้น, ใช้ได้กับทุกแผงควบคุม	ต้องทำ search-replace URL เอง

[ตรวจสอบ: ยืนยันว่าแผงควบคุมของ THAI DATA HOSTING มี WP Toolkit หรือเครื่องมือโคลนเว็บแบบใด]

ถ้าสร้างเองบนซับโดเมน เช่น staging.example.com ให้คัดลอกไฟล์และฐานข้อมูลมา แล้วเปลี่ยน URL ด้วย wp search-replace

wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --dry-run

ใช้ --dry-run ดูก่อนเสมอ แล้วค่อยรันจริง คำสั่งนี้จัดการข้อมูลแบบ serialized ที่ WordPress เก็บไว้ได้ถูกต้อง ต่างจากการ find-replace ในไฟล์ SQL ด้วยตัวแก้ไขข้อความ

ขั้นตอนที่ 2: ป้องกันไม่ให้ WordPress Staging หลุดออกสู่สาธารณะ

WordPress Staging ที่เปิดให้ทุกคนเข้าได้สร้างปัญหาสามอย่าง คือ Google เก็บเป็นเนื้อหาซ้ำ ลูกค้าจริงหลงเข้าไปสั่งซื้อ และข้อมูลลูกค้าจาก production ถูกเปิดเผย ควรทำครบทั้งสามข้อนี้

ตั้งรหัสผ่านระดับเซิร์ฟเวอร์ (HTTP Basic Auth) ให้ทั้งซับโดเมน
ตั้ง Discourage search engines ในหน้า Reading ของ WordPress
ปิดการส่งอีเมลออกจาก staging เพื่อไม่ให้ลูกค้าได้รับอีเมลยืนยันออเดอร์ซ้ำ

นอกจากนี้ ถ้าคัดลอกข้อมูลลูกค้าจาก production มาใช้ ข้อมูลส่วนบุคคลจะอยู่บน staging ด้วย ควรจำกัดผู้เข้าถึงให้เหลือเท่าที่จำเป็น หรือทำ data masking ก่อน

ขั้นตอนที่ 3: เก็บอะไรใน Git และไม่เก็บอะไร

เก็บใน Git	ไม่เก็บใน Git
ธีมและ child theme ที่เขียนเอง	`wp-config.php` (มีรหัสผ่านฐานข้อมูล)
ปลั๊กอินที่เขียนเอง	`wp-content/uploads/`
`mu-plugins`	ปลั๊กอินจาก repository สาธารณะ (ติดตั้งด้วย WP-CLI หรือ Composer แทน)
ไฟล์ตั้งค่าเว็บเซิร์ฟเวอร์ที่ปรับเอง	ไฟล์ cache และ log

ตัวอย่าง .gitignore พื้นฐาน

wp-config.php
wp-content/uploads/
wp-content/cache/
wp-content/upgrade/
*.log

ขั้นตอนที่ 4: Deploy จาก Git ขึ้น WordPress Staging และ Production

แผงควบคุมอย่าง Plesk มีส่วนขยาย Git ที่ดึงโค้ดจาก repository และ deploy ไปยังโฟลเดอร์ที่กำหนดได้ ทั้งแบบกดเองและแบบอัตโนมัติเมื่อมีการ push (เอกสาร Plesk) แนวทางที่แนะนำคือ

branch staging deploy อัตโนมัติไปที่ WordPress Staging
branch main deploy ไป production แบบกดเองหลังทดสอบผ่าน

ถ้าแผงควบคุมไม่มีเครื่องมือ Git ใช้ SSH ดึงโค้ดเองได้

cd ~/httpdocs/wp-content/themes/client-theme
git fetch origin && git checkout --detach origin/main

ขั้นตอนที่ 5: Rollback เมื่อ Deploy แล้วพัง

แผนถอยต้องเตรียมก่อน deploy ไม่ใช่คิดตอนเว็บพัง ให้แยกสองกรณี

กรณีโค้ดพัง ถอยด้วย Git ทันที เพราะทุก deploy มี commit อ้างอิง

git checkout --detach <commit-ก่อนหน้า>

แนะนำให้ติด tag ทุกครั้งที่ deploy ขึ้น production เช่น release-2026-10-30 จะถอยได้เร็วกว่าการไล่หา commit

กรณีอัปเดตปลั๊กอินแล้วพัง ถอยเวอร์ชันด้วย WP-CLI

wp plugin install woocommerce --version=<เวอร์ชันเดิม> --force

กรณีฐานข้อมูลเสียหาย ต้องกู้จาก backup ซึ่งจะเสียข้อมูลที่เกิดหลังจุด backup จึงควรทำ backup ฐานข้อมูลทันทีก่อนทุก deploy ที่มี migration แนวทางวางระบบ backup อ่านต่อได้ที่ backup ข้อมูล server อย่างไรให้รอดพ้น Ransomware

ขยาย Workflow สำหรับฟรีแลนซ์ที่ดูแลหลายสิบเว็บ

เมื่อดูแลเว็บจำนวนมาก ความสม่ำเสมอสำคัญกว่าเครื่องมือ ข้อแนะนำจากการใช้งานจริง

ตั้งชื่อ staging ให้เป็นรูปแบบเดียวกันทุกเว็บ เช่น staging.โดเมนลูกค้า
ใช้ WP-CLI กับสคริปต์ชุดเดียวกันตรวจเวอร์ชันและอัปเดตทุกเว็บ
ทำบันทึก deploy สั้นๆ ทุกครั้ง ว่าเปลี่ยนอะไร เวลาไหน และ commit ไหน
กำหนดหน้าต่างเวลา deploy กับลูกค้า เช่น ไม่ deploy วันศุกร์เย็น

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

WordPress Staging ใช้ฐานข้อมูลเดียวกับ Production ได้ไหม?

ไม่ได้ ต้องแยกฐานข้อมูล เพราะการทดสอบบน WordPress Staging จะเขียนข้อมูลทับเว็บจริงทันที และ URL ของเว็บถูกเก็บในฐานข้อมูลด้วย

Sync WordPress Staging ขึ้น Production ทั้งเว็บได้ไหม?

ทำได้กับเว็บที่เนื้อหาไม่เปลี่ยนระหว่างทดสอบ เช่น เว็บบริษัท แต่ไม่ควรทำกับร้านค้าออนไลน์หรือเว็บสมาชิก ให้ deploy เฉพาะโค้ดและไฟล์ แล้วตั้งค่าที่ต้องเปลี่ยนบน production โดยตรง

ต้องใช้ Git ถึงจะทำ WordPress Staging ได้ไหม?

ไม่จำเป็น WordPress Staging ใช้ได้โดยไม่มี Git แต่ Git ทำให้รู้ว่าเปลี่ยนอะไรไปบ้าง และถอยกลับได้แม่นยำ จึงคุ้มค่าสำหรับคนที่ดูแลหลายเว็บ

WordPress Staging กินโควตาพื้นที่ Hosting ไหม?

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

สรุป

Workflow ที่ปลอดภัยคือ โค้ดไหลขึ้นผ่าน Git → WordPress Staging → Production ส่วนข้อมูลไหลลงจาก production มาที่ staging ป้องกัน staging ไม่ให้เปิดสู่สาธารณะ และเตรียมแผน rollback ทั้งโค้ด ปลั๊กอิน และฐานข้อมูลไว้ก่อน deploy ทุกครั้ง

WordPress Hosting ของ THAI DATA HOSTING รองรับการสร้างซับโดเมนสำหรับ staging และเข้าใช้งาน SSH [ตรวจสอบ: ยืนยันการรองรับ SSH, WP-CLI และ Git บนแพ็กเกจ] หากต้องการวางระบบ deploy สำหรับเว็บลูกค้าหลายเว็บ ปรึกษาทีม THAI DATA HOSTING

แท็กFreelance Git Staging WordPress

แชร์Facebook X LINE LinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน