เบื้องหลัง CI/CD Pipeline ของ Enersys — จาก git push ถึงเว็บไซต์ Live ใน 5 นาที

ทำไมต้องเล่าเรื่อง Pipeline ของตัวเอง?

เวลาเราพูดเรื่อง CI/CD กับลูกค้า คำถามที่ได้ยินบ่อยที่สุดคือ "แล้วพวกคุณเองใช้อะไร?"

เราเชื่อว่าวิธีที่ดีที่สุดในการพิสูจน์ความเชี่ยวชาญคือการโชว์ว่าเราใช้สิ่งที่เราแนะนำกับตัวเองด้วย บทความนี้จะเปิดเบื้องหลัง Pipeline จริงที่ส่งมอบเว็บไซต์ enersys.co.th — ตั้งแต่นักพัฒนากด push จนถึงเว็บไซต์ Live

ภาพรวม: จาก Code สู่ Production

Pipeline ของเราแบ่งเป็น 2 เส้นทางหลัก ที่ trigger จากเหตุการณ์ต่างกัน:

1. PR Validation — ทุกครั้งที่เปิด Pull Request ระบบจะ Build และทดสอบอัตโนมัติ
2. Release & Deploy — เมื่อ Tag version ใหม่ ระบบจะ Build, Push, และ Deploy ขึ้น Production

ทั้งสอง Pipeline รันบน Self-Hosted Runner ที่ตั้งอยู่บนเครื่อง Ubuntu ของเราเอง — ไม่ใช่ GitHub-hosted runner ที่ต้องเสียเวลา provision VM ใหม่ทุกครั้ง

เส้นทางที่ 1: PR Validation

ทุกครั้งที่นักพัฒนาเปิด Pull Request จะมี 2 Workflow ทำงานพร้อมกัน:

Build Validation

Workflow แรกทดสอบว่า Docker Image ทั้ง 2 ตัว (Web และ API) สามารถ Build สำเร็จหรือไม่ — แต่ ไม่ Push ไปที่ Registry เป็นการตรวจสอบว่าโค้ดใหม่ไม่ทำให้ Build พัง

สิ่งที่น่าสนใจคือเราใช้ Docker Buildx Cache ที่เก็บไว้บน Self-Hosted Runner — ครั้งถัดไปที่ Build, Layer ที่ไม่เปลี่ยนจะถูกข้ามไปทันที ทำให้ Build ที่ปกติใช้เวลาหลายนาที เหลือแค่ไม่กี่วินาที

Lighthouse Performance Audit

Workflow ที่สองจริงจังกว่า — มันจะ Build เว็บไซต์ทั้งหมด แล้ว Serve ขึ้นมาจริงๆ บน localhost เพื่อรัน Lighthouse Audit 3 รอบ

เกณฑ์ที่ต้องผ่าน:

• Performance ≥ 60% — ถ้าต่ำกว่านี้ PR จะ Fail ทันที
• Accessibility ≥ 80% — เราให้ความสำคัญกับการเข้าถึง
• SEO ≥ 80% — เว็บไซต์ต้องพร้อมสำหรับ Search Engine
• Best Practices ≥ 80% — มาตรฐานพื้นฐาน

ผลลัพธ์ถูกเก็บเป็น Artifact ไว้ดูย้อนหลังได้ 30 วัน ทำให้เราติดตามได้ว่า Performance เปลี่ยนแปลงอย่างไรในแต่ละ PR

เส้นทางที่ 2: Release & Deploy

เมื่อ PR ผ่านการ Review และ Merge แล้ว ขั้นตอนถัดไปคือการ Tag version เช่น v1.1.178 — นี่คือ Trigger ที่ทำให้ทุกอย่างเกิดขึ้น:

ขั้นตอนที่ 1: Docker Multi-Stage Build

หัวใจของ Pipeline คือ Docker Build แบบ Multi-Stage — เทคนิคที่ทำให้ Production Image เล็กและปลอดภัยที่สุดเท่าที่จะทำได้:

Web Frontend (3 Stages):

Stage แรกติดตั้ง Dependencies ทั้งหมดที่ต้องใช้ใน Monorepo Stage ที่สองรัน Build เพื่อ Export เว็บไซต์เป็น Static HTML/CSS/JS และ Stage สุดท้ายคือตัว Production จริง — Nginx Alpine ที่เสิร์ฟเฉพาะ Static Files ไม่มี Node.js ไม่มี Source Code ไม่มี Dependencies ที่ไม่จำเป็น

ผลลัพธ์คือ Image ขนาดประมาณ 22 MB ที่เบาและเร็ว

API Backend (2 Stages):

Stage แรก Compile TypeScript เป็น JavaScript พร้อม Generate Prisma Client Stage สุดท้ายเก็บเฉพาะ Compiled Code, Prisma Client และ Production Dependencies — ลบ Dev Dependencies, Source Code และ Build Tools ออกทั้งหมด

ขั้นตอนที่ 2: Push ไป Container Registry

Image ทั้ง 2 ตัวถูก Push ไปที่ DigitalOcean Container Registry พร้อม 2 Tags:

• Tag เฉพาะ version เช่น v1.1.178 — สำหรับ Rollback ถ้าจำเป็น
• Tag latest — สำหรับ Reference ล่าสุด

ขั้นตอนที่ 3: Kubernetes Deployment

Pipeline จัดการ Kubernetes แบบครบวงจร:

Secrets & Configuration — สร้าง Secrets สำหรับ Database Connection, API Keys ต่างๆ (Mailgun, LINE Messaging, Google Forms) ทั้งหมดจัดการผ่าน GitHub Secrets ไม่มีค่า Sensitive ใดถูก Hardcode

Rolling Update — Kubernetes จะค่อยๆ เปลี่ยน Pod ทีละตัว:

• Pod ใหม่เริ่มทำงานและรอให้ Readiness Probe ผ่าน (ตรวจสอบ /healthz ทุก 5 วินาที)
• เมื่อ Pod ใหม่พร้อม Traffic จะถูกเปลี่ยนเส้นทาง
• Pod เก่าถูก Drain อย่างสุภาพ
• ไม่มี Downtime แม้แต่วินาทีเดียว

ขั้นตอนที่ 4: Autopublish

หลัง Deploy สำเร็จ Pipeline จะ Commit Kubernetes Manifest ที่อัปเดตแล้วกลับไปที่ main — ทำให้ Git Repository เป็น Single Source of Truth เสมอ ดูจาก Manifest ก็รู้ว่า Production กำลังรันอะไร Version อะไร