CI/CD คืออะไร? อธิบายแบบที่ไม่ต้องมีพื้นฐาน

เริ่มจากปัญหาก่อน

ลองนึกภาพว่าคุณเขียน feature ใหม่เสร็จ จะเอาขึ้น production เลยจะต้องทำอะไรบ้าง

• รัน test ดูว่าโค้ดที่เพิ่งเขียนไปไม่ทำของเดิมพัง
• build โปรเจคให้ออกมาเป็น artifact (เช่น npm run build)
• เอา build ไปวางบน server
• restart service ให้ใช้โค้ดใหม่
• เช็ค log ว่าไม่มีอะไรพัง

ถ้าทำมือทุกขั้น ครั้งหนึ่งใช้เวลา 10-30 นาที เผลอลืมขั้นไหน หรือลืม pull migration → server ตาย ลูกค้าด่า

CI/CD คือการให้ "เครื่อง" ทำขั้นตอนพวกนี้แทนเรา

แยกคำให้ชัด

CI = Continuous Integration
ทุกครั้งที่ commit/push โค้ด ให้ระบบ pull โค้ดมา รัน test รัน lint build ดูว่าผ่านมั้ย ถ้าไม่ผ่านห้าม merge

จุดประสงค์: catch bug เร็ว ไม่ให้โค้ดที่พังหลุดเข้า main branch

CD = Continuous Delivery หรือ Continuous Deployment

สองอันต่างกันนิดเดียว แต่สำคัญ:

• Delivery: ระบบเตรียม build พร้อม deploy แล้ว แต่ต้องมีคนกดปุ่ม approve ก่อน
• Deployment: ผ่าน CI ปุ๊บ deploy ขึ้น production อัตโนมัติเลย ไม่ต้องกด

ทีมเริ่มต้นแนะนำ Delivery ก่อน เพราะปลอดภัยกว่า ค่อยขยับเป็น Deployment เมื่อมั่นใจว่า test coverage ดีพอ

ก่อนกับหลัง เห็นภาพชัด

ก่อนมี CI/CD:

1. เขียนโค้ดเสร็จ commit
2. zip ไฟล์ส่งให้คนอื่น code review
3. โอเคแล้วก็ FTP ขึ้น server
4. SSH เข้าไป pull migration
5. restart service
6. F5 หน้าเว็บแล้วลุ้น

หลังมี CI/CD:

1. เขียนโค้ดเสร็จ push branch
2. เปิด Pull Request → ระบบรัน test ให้
3. คน review → approve → merge เข้า main
4. ระบบ deploy ขึ้น staging อัตโนมัติ
5. ทีมทดสอบบน staging → กด promote ไป production

ขั้นตอนเดิมแต่ไม่ต้องนั่งทำเอง

Pipeline ทั่วไปประกอบด้วยอะไร

ลำดับเหตุการณ์ใน pipeline ที่เห็นบ่อย:

push code
    ↓
lint (ESLint, Prettier)
    ↓
unit test (Jest, Vitest)
    ↓
build (compile, bundle)
    ↓
integration test (optional)
    ↓
deploy ไป staging
    ↓
smoke test
    ↓
deploy ไป production

ถ้าขั้นไหนพัง pipeline หยุด แจ้งทีมทาง Slack/Discord/Email

เครื่องมือที่ใช้กันเยอะ

• GitHub Actions — ฟรีสำหรับ public repo, free tier ใช้ได้กับ private repo (มี limit นาที/เดือน) ตั้งง่ายที่สุด
• GitLab CI — built-in มากับ GitLab อยู่แล้ว ดีถ้าทีมใช้ GitLab
• Jenkins — เก่าแก่ self-host customize ได้สุด แต่ดูแลยาก
• CircleCI / Travis CI — เคยฮิต ตอนนี้คนย้ายไป GitHub Actions เกือบหมด

ถ้าเริ่มใหม่ปี 2025-2026 → GitHub Actions แทบจะ default แล้ว

ตัวอย่าง workflow แรก

ไฟล์ .github/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test

push ไฟล์นี้ขึ้น GitHub → ทุกครั้งที่มี PR ระบบจะรัน lint + test ให้อัตโนมัติ

ข้อผิดพลาดที่เจอบ่อยตอนเริ่ม

• Test ใช้เวลานาน จนคนอืดรอ → แก้โดยรัน test parallel + cache dependencies
• Secret หลุดลง log → อย่า echo $API_KEY ใน workflow
• Deploy โดยไม่มี rollback plan → ควรเก็บ artifact เก่าไว้อย่างน้อย 3 versions
• Pipeline สำเร็จแต่ของจริงพัง → ต้องเขียน test ที่ลึกพอ ไม่ใช่แค่ unit test ผ่านแล้วจบ

คุ้มจะลงทุนตั้งมั้ย

ถ้า project เป็น hobby คนเดียว push ไม่บ่อย — ตั้งหรือไม่ตั้งก็ได้ แต่ตั้งครั้งเดียวใช้ตลอดอายุ project

ถ้า project มีคนใช้ มี user → ตั้งเลยตั้งแต่วันแรก ครั้งหนึ่งที่เผลอ deploy bug ขึ้น production แล้วต้อง rollback ตอนตี 3 จะเข้าใจ

ก้าวต่อไป

อ่านบทความถัดไปเรื่อง ตั้ง GitHub Actions ครั้งแรก — ตั้ง CI/CD ตั้งแต่ศูนย์ทีละขั้น จบใน 30 นาที