DevOps สำหรับเว็บไซต์แบรนด์ตัวเอง: CI/CD Pipeline, Automated Testing, การ Deploy และ Rollback และการจัดการ Environment
1. ทำไมเว็บไซต์แบรนด์ตัวเองต้องมี pipeline ไม่ใช่ “SSH เข้าไปแก้”
วิธี deploy ที่เว็บไซต์แบรนด์ตัวเองใช้กันทั่วไปมีสามแบบ: ลากไฟล์ผ่าน FTP, SSH เข้าไป git pull เอง, กด restart ในแผงควบคุมอย่าง Baota ทั้งสามวิธีใช้ได้ตอน traffic ต่ำกว่า 5,000 ต่อเดือน แต่พอแก้โค้ด แก้ database และแก้ plugin ของบุคคลที่สามพร้อมกัน อัตราการเกิดอุบัติเหตุจะพุ่งขึ้นแบบทวีคูณ คุณค่าของ CI/CD ไม่ใช่ทำให้ deploy เร็วขึ้น แต่ทำให้ทุกการเปลี่ยนแปลงทำซ้ำได้ ตรวจสอบย้อนหลังได้ และ rollback ได้
เกณฑ์ตัดสินง่ายๆ อย่างหนึ่ง: ถ้าในทีมไม่มีคนที่สองที่ deploy แทนคุณได้อย่างปลอดภัยตอนคุณลาพัก แปลว่าขั้นตอน deploy ของคุณยังไม่ได้ automate เว็บไซต์แบรนด์ตัวเองแบบ B2B ความถี่ในการอัปเดตเนื้อหาไม่สูง แต่การแก้ไขที่เกี่ยวกับฟอร์ม การชำระเงิน และ structured data เพื่อ SEO ถ้าขึ้น production แล้วพลาด จะกระทบ inquiry โดยตรง เรื่องปัญหาที่เชื่อมโยงกับฝั่ง performance ดูได้ที่Core Web Vitals จังหวะการ optimize ของ
| วิธีติดตั้ง | เวลาต่อครั้ง | โอกาสเกิดข้อผิดพลาด | ความสามารถ rollback | ช่วงที่เหมาะใช้งาน |
|---|---|---|---|---|
| ลากไฟล์ผ่าน FTP เอง | 10 ถึง 30 นาที | สูง (ลืมส่งไฟล์เป็นเรื่องปกติ) | ไม่มี พึ่ง backup | เว็บต้นแบบ ทดสอบคนเดียว |
| SSH เข้าไป git pull แล้ว restart | 5 ถึง 10 นาที | ปานกลาง (environment ต่างกัน) | ใช้ git reset ได้ | เว็บเล็กที่ traffic <5,000 ต่อเดือน |
| CI/CD pipeline | 15 ถึง 25 นาที | ต่ำ (มี gate อัตโนมัติ) | สลับเวอร์ชันด้วยคลิกเดียว | เว็บจริง ทำงานหลายคน |
| GitOps + K8s | 10 ถึง 15 นาที | ต่ำมาก | rollback แบบ declarative | หลาย instance หลาย environment |
2. ออกแบบ 5 gate ของ pipeline อย่างไร
อย่าเพิ่งตั้งเป้า “commit แล้วขึ้น production ทันที” ตั้งแต่แรก pipeline ของเว็บไซต์แบรนด์ตัวเองแนะนำให้แบ่งเป็นห้าขั้น ถ้าขั้นไหน fail ให้หยุดทันที: build, unit test, staging smoke test, canary, full rollout ขั้น build ล็อกเวอร์ชัน dependency และสร้าง image ที่แก้ไขไม่ได้ ขั้น unit test รัน unit test และ static code check ขั้น staging รัน E2E smoke test บน staging environment ที่โครงสร้างเหมือน production ขั้น canary เปิด traffic 5% ก่อนแล้วเฝ้าดู 15 นาที พอตัวชี้วัดปกติแล้วจึงเปิด 100%
ต้องคุมงบเวลาของแต่ละขั้นให้แน่น ห้ามยืด: build ไม่เกิน 5 นาที, unit test ไม่เกิน 3 นาที, staging ไม่เกิน 10 นาที, เฝ้าดู canary 15 นาที รวมแล้วไม่เกิน 35 นาที ถ้าเกินกว่านี้ นักพัฒนาจะเลือกข้าม pipeline ไป deploy มือเอง แล้วระบบอัตโนมัติก็กลายเป็นของประดับ การทำงานร่วมกันของ CDN cache กับ static asset ดูที่CDN เร่งความเร็วทั่วโลก。
| ระยะ | ขั้นตอนที่ต้องรัน | เกณฑ์ผ่าน | การจัดการเมื่อล้มเหลว |
|---|---|---|---|
| Build | ติดตั้ง dependency, แพ็ก image, สแกน image | ไม่มีช่องโหว่ระดับสูง, image <1GB | บล็อก ไม่ไปขั้นถัดไป |
| Unit test | unit test, static analysis, ตรวจ type | coverage ≥70%, ไม่มี warning ระดับบล็อก | บล็อก แจ้งคนที่ commit |
| Smoke test บน staging | E2E 3 เส้นทาง: หน้าแรก, รายการสินค้า, ฟอร์มสอบถาม | ผ่านทั้งหมด, error rate ของ API 0% | บล็อก เก็บ log ไว้ |
| Canary | สลับ 5% → 25% → 100% เฝ้าดูขั้นละ 15 นาที | error rate <1%, P95 latency ไม่เพิ่มเกิน 20% | สลับกลับเวอร์ชันเก่าอัตโนมัติ |
| Full rollout | สลับ 100% เก็บเวอร์ชันเข้าระบบ | เฝ้าดู 30 นาทีไม่มีปัญหา | ให้คนเข้าไป rollback |
สาม、Automated testing: เว็บไซต์ standalone ควรเขียน test case อะไรบ้าง
ทีมเล็กมักสุดโต่งสองทาง: ทางหนึ่งคือไม่มี test เลย พึ่งการทดสอบมือทั้งหมด อีกทางคือตั้งเป้า coverage 90% ตั้งแต่แรก ความจริงของเว็บไซต์ standalone คือ business logic ไม่ซับซ้อน แต่ฟอร์ม, SEO และหลายภาษา สามส่วนนี้พอพลาดแล้วกระทบตรง ๆ แนะนำให้แบ่ง test เป็นสามชั้น เรียงตามผลตอบแทนเทียบกับแรงที่ลง
ชั้นแรกคือ unit test ครอบคลุม utility function, การคำนวณราคา, การตรวจสอบฟอร์ม ตั้งเป้า coverage 70% ก็พอ ไม่ต้องไล่ให้ถึง 100% ชั้นที่สองคือ E2E smoke test ดูแลแค่สามเส้นทางหลัก: เปิดหน้าแรก, กดดูรายละเอียดจากรายการสินค้า, ส่งฟอร์มสอบถามสำเร็จ ชั้นที่สามคือ regression test ก่อนปล่อยเวอร์ชันทุกครั้ง ให้คนไล่ทดสอบ 10 หน้าหลักบน staging หนึ่งรอบ ข้อมูล structured data และการตรวจ Schema ดูที่Structured data Schema。
| ชั้นการทดสอบ | จำนวน test case ที่แนะนำ | เวลาที่ใช้ต่อรอบ | เป้าหมาย coverage | ลำดับความสำคัญในการลงแรง |
|---|---|---|---|---|
| Unit test | 30 ถึง 80 เคส | 1 ถึง 3 นาที | utility function, ราคา, การตรวจสอบ | สูงสุด |
| API test | 10 ถึง 20 เคส | 2 ถึง 5 นาที | การส่งฟอร์ม, CRM webhook | สูง |
| E2E smoke test | 3 ถึง 5 เส้นทาง | 5 ถึง 10 นาที | สามเส้นทางหลัก: หน้าแรก/รายละเอียด/สอบถาม | สูง |
| Visual regression | 10 ถึง 20 ภาพหน้าจอ | 10 ถึง 15 นาที | หน้าหลักบน desktop และ mobile | ปานกลาง |
| Regression ด้วยคน | 10 หน้า | 30 นาที | หลายภาษา, การชำระเงิน, อีเมลฟอร์ม | ก่อนปล่อยเวอร์ชันทุกครั้ง |
สี่、Deploy และ rollback: การ rollback image กับการ rollback ข้อมูลคนละเรื่องกัน
อุบัติเหตุที่พบบ่อยที่สุดตอน rollback คือ: โค้ด rollback แล้ว แต่ schema ของฐานข้อมูลไม่ได้ rollback ผลคือโค้ดเวอร์ชันใหม่เชื่อมต่อกับโครงสร้างตารางเก่าไม่ได้ วิธีที่ถูกคือแยกการเปลี่ยนแปลงโค้ดกับการเปลี่ยนแปลงฐานข้อมูลออกเป็นสอง pipeline ที่เป็นอิสระต่อกัน การเปลี่ยนแปลงโค้ดใช้ blue-green หรือ rolling deployment สลับได้ทุกเมื่อ ส่วนการเปลี่ยนแปลงฐานข้อมูลต้องเข้ากันได้กับเวอร์ชันก่อนหน้า ใช้กลยุทธ์ expand-contract: เพิ่มคอลัมน์ใหม่ก่อนโดยไม่แตะคอลัมน์เก่า พอสลับโค้ดเสร็จแล้วค่อย migrate ข้อมูล สุดท้ายค่อยลบคอลัมน์เก่า
เกณฑ์ตัดสินที่นำไปใช้ได้จริง: การเปลี่ยนแปลงใดก็ตามที่กระทบโครงสร้างฐานข้อมูล ต้องรันซ้อม “อัปเกรด → ใช้งาน → ย้อนกลับ → อัปเกรดอีกครั้ง” บนเครื่อง local ด้วยสำเนาข้อมูล production ที่ปิดข้อมูลส่วนบุคคลให้ครบก่อนทุกครั้ง ถ้ารันไม่ผ่านห้ามขึ้น production วิธีทำ backup และ restore แบบละเอียดดูได้ที่การสำรองและกู้คืนเว็บไซต์。
| ประเภทการเปลี่ยนแปลง | วิธีย้อนกลับ | ระยะเวลาที่คาดไว้ | สิ่งที่ต้องเตรียม |
|---|---|---|---|
| ไฟล์ static/เทมเพลตล้วน | รีเฟรช CDN + สลับกลับ image เก่า | 2 ถึง 5 นาที | เก็บไว้ 10 เวอร์ชันล่าสุด |
| โค้ดแอป (ไม่มีการเปลี่ยน DB) | blue-green สลับกลับ environment เก่า | 3 นาที | เก็บ environment เก่าไว้ 30 นาที |
| เพิ่มคอลัมน์/เพิ่มตารางในฐานข้อมูล | เข้ากันได้กับเวอร์ชันก่อนหน้า ไม่ต้องย้อนกลับ | 0 | คอลัมน์ใหม่ยอมให้เป็น NULL |
| เปลี่ยนชนิดคอลัมน์/ลบคอลัมน์ในฐานข้อมูล | ห้ามขึ้นตรง แบ่งเป็นสองรอบ | ข้ามสองเวอร์ชัน | ขยายก่อน ค่อยลดทีหลัง |
| เปลี่ยนค่าคอนฟิก | ย้อนกลับได้ในคลิกเดียวจากศูนย์คอนฟิก | 1 นาที | เก็บคอนฟิกไว้ในระบบควบคุมเวอร์ชัน |
ห้า: การจัดการ environment สามชุดพอไหม
environment ขั้นต่ำที่ใช้ได้จริงสำหรับเว็บไซต์ของตัวเองมีสามชุด: dev สำหรับพัฒนาในเครื่อง, staging สำหรับทดสอบก่อนปล่อย, prod สำหรับผู้ใช้จริง staging ต้องมีโครงสร้างเหมือน prod ทุกอย่าง ทั้งเวอร์ชัน PHP/Node เวอร์ชันฐานข้อมูล ส่วนขยาย และกฎ CDN กับดักที่เจอบ่อยที่สุดคือ staging ใช้ SQLite แต่ prod ใช้ MySQL พอขึ้นจริงถึงรู้ว่าฟังก์ชันวันที่ทำงานไม่เหมือนกัน
การแยกคอนฟิกเป็นข้อบังคับ รหัสผ่านฐานข้อมูล API key ของบุคคลที่สาม และคีย์การชำระเงินทั้งหมดต้องผ่าน environment variable หรือศูนย์คอนฟิก ห้ามเข้า repository ของโค้ด วิธีตรวจง่ายๆ คือเปิด repository ให้เป็น public บน GitHub แล้วไม่มีคีย์จริงรั่วออกมาเลย ถือว่าผ่าน เว็บหลายภาษาจะมีปัญหาซ้อนเรื่องแคชคำแปลเพิ่มเข้ามา ดูได้ที่ขั้นตอนการเผยแพร่เนื้อหาหลายภาษา。
| environment | ใช้ทำอะไร | แหล่งข้อมูล | ตัวกระตุ้นการ deploy | เปิดให้คนนอกเข้าถึงไหม |
|---|---|---|---|---|
| local | พัฒนาในเครื่อง | ข้อมูล seed/สำเนาที่ปิดข้อมูลส่วนบุคคล | นักพัฒนาสั่งเอง | ไม่ |
| dev | รวมโค้ดทุกวัน | สแนปช็อต production ที่ปิดข้อมูลส่วนบุคคล | ทุกครั้งที่ merge เข้า main branch | ใส่ Basic Auth |
| staging | ตรวจรับก่อนขึ้นจริง | สแนปช็อตที่ปิดข้อมูลส่วนบุคคลทุกสัปดาห์ | อัตโนมัติหลังติด tag | ใส่ Basic Auth |
| prod | ผู้ใช้จริง | ข้อมูล production | กดปล่อยเองในคลิกเดียว | สาธารณะ |
FAQ คำถามที่พบบ่อย
เว็บไซต์ของคนคนเดียวจำเป็นต้องใช้ CI/CD ไหม จะหนักเกินไปหรือเปล่า
ควรทำ unit test coverage เท่าไรจึงจะเหมาะ
canary release มีความหมายกับเว็บไซต์ของตัวเองที่มีทราฟฟิกน้อยไหม
ถ้า database migration พังต้อง rollback ยังไง?
staging environment ควรใช้ข้อมูลจริงไหม?
CI/CD pipeline ใช้เวลานานแค่ไหนถึงจะถือว่าผ่าน?
ทิ้งท้าย
DevOps maturity ของเว็บไซต์อิสระไม่จำเป็นต้องเทียบกับบริษัทเทคยักษ์ ทีมเล็ก 2 คน ใช้ GitHub Actions บวก Docker image บวกสคริปต์ blue-green ก็เปลี่ยนการ deploy จาก “ลากไฟล์ด้วยมือตอนตีสาม” เป็น “กดปุ่มเดียวตอนเข้างาน” ได้ สิ่งที่กำหนดอัตราการเกิดเหตุจริง ๆ ไม่ใช่เครื่องมือใหม่แค่ไหน แต่คือมีเขียนการจัดการ environment, database rollback, การสังเกต canary สามอย่างนี้ลงใน pipeline หรือไม่
แนะนำให้ทำ 3 ขั้นตอน ขั้นแรกในสัปดาห์แรก เขียนสคริปต์แทนการ deploy ด้วยมือ ให้ deploy ได้ด้วยคำสั่งเดียว สัปดาห์ที่สองเพิ่ม unit test และ E2E smoke gate สัปดาห์ที่สามทำ blue-green deployment และ rollback ด้วยคลิกเดียว ครบสามขั้นแล้ว ความถี่ในการ deploy จะเพิ่มจากสัปดาห์ละครั้งเป็นหลายครั้งต่อวัน และเวลาเฉลี่ยในการกู้คืนจากเหตุขัดข้องจะอยู่ภายใน 10 นาที ส่วนการตั้งค่าการแจ้งเตือนและมอนิเตอร์เว็บไซต์ดูได้ที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์。
ประโยคที่จำได้ง่าย: จุดหมายปลายทางของ CI/CD ไม่ใช่ “deploy เร็ว” แต่คือ “เกิดเรื่องแล้วกล้านอน” — rollback ภายใน 3 นาที ทีมถึงจะกล้าออกเวอร์ชันทุกวัน