LEVEL 0 · ปูพื้นจากศูนย์
CI/CD คืออะไร & ทำไมต้องมี
ในเล่ม Git คุณเรียนวิธีบันทึกและรวมโค้ดของหลายคนเข้าด้วยกัน แต่มีคำถามที่ค้างอยู่: หลังจาก git push แล้ว ใครเป็นคนตรวจว่าโค้ดที่เพิ่งรวมเข้ามายัง build ได้ เทสต์ผ่าน และไม่ทำของเดิมพัง? ถ้าคำตอบคือ "คนในทีมต้องมานั่งตรวจเองทุกครั้ง" นั่นคือจุดที่ทุกอย่างเริ่มช้าและพลาดง่าย CI/CD คือการยกงานตรวจสอบและส่งมอบทั้งหมดนั้นให้ เครื่องทำอัตโนมัติทุกครั้งที่โค้ดเปลี่ยน
ตัวย่อสองชุดนี้แยกเป็นสองเรื่องที่ต่อเนื่องกัน:
- CI — Continuous Integration (การรวมโค้ดอย่างต่อเนื่อง): รวมงานของทุกคนเข้าสายหลักบ่อย ๆ แล้วให้ระบบ build + test อัตโนมัติทันที เพื่อจับปัญหาให้เร็วที่สุด
- CD — Continuous Delivery / Deployment (การส่งมอบ/ปล่อยขึ้นใช้งานอย่างต่อเนื่อง): เมื่อโค้ดผ่าน CI แล้ว ก็ แพ็กและส่งขึ้นไปใช้งานจริงอัตโนมัติ หรือเตรียมให้พร้อมกดปล่อยได้ทันที
1.1 ปัญหาที่ CI เกิดมาเพื่อแก้ — "integration hell"
ลองนึกถึงทีมที่แต่ละคนแยกไปเขียนฟีเจอร์ของตัวเองคนละ branch เป็นเวลาหนึ่งเดือน โดยไม่รวมกลับเลย พอถึงวันรวม (integrate) ทุกคนพบว่าโค้ดชนกันเต็มไปหมด สมมติฐานไม่ตรงกัน ของที่เคยทำงานกลับพัง — ต้องเสียเวลาเป็นสัปดาห์แก้ "วันรวมร่าง" นี้คือสิ่งที่เรียกว่า integration hell
CI พลิกปัญหานี้ด้วยหลักง่าย ๆ ข้อเดียว: ถ้าการรวมเจ็บ ก็รวมให้บ่อยขึ้นจนมันไม่เจ็บ รวมวันละหลายครั้ง ทีละนิด แล้วให้เครื่องตรวจทุกครั้ง ปัญหาจะถูกจับตั้งแต่ยังเล็กและรู้ทันทีว่าเกิดจาก commit ไหน
1.2 หัวใจคือ "วงจรป้อนกลับที่สั้น"
คุณค่าที่แท้จริงของ CI/CD ไม่ใช่ "ความอัตโนมัติ" เอง แต่คือ ความเร็วของวงจรป้อนกลับ (feedback loop) — ระยะเวลาตั้งแต่คุณเขียนโค้ดผิด จนถึงตอนที่มีคน/อะไรบางอย่างบอกคุณว่ามันผิด ยิ่งวงจรนี้สั้น ค่าแก้ยิ่งถูก เพราะคุณยังจำได้ว่าเพิ่งแก้อะไรไป และบั๊กยังไม่ทันแพร่ไปไหน
| บั๊กถูกจับเมื่อ | ค่าใช้จ่ายในการแก้ |
|---|---|
| ตอนเขียน (ในเครื่องตัวเอง) | แทบฟรี — แก้ทันที |
| ตอน CI รันหลัง push (ไม่กี่นาทีต่อมา) | ถูก — ยังจำ context ได้ |
| ตอน reviewer หรือ QA เจอ (วันต่อมา) | ปานกลาง — ต้องวนกลับมาคิดใหม่ |
| ตอนลูกค้าเจอบน production | แพงที่สุด — กระทบจริง + เร่งแก้ |
CI/CD คือเครื่องจักรที่ดัน "จุดที่จับบั๊กได้" ให้ขยับขึ้นไปบนสุดของตารางนี้ให้มากที่สุด
🧭 CI/CD ต่อยอดจาก Git โดยตรง — ทุกอย่างในเล่มนี้เริ่มทำงานจากเหตุการณ์ใน Git ที่คุณเรียนมาแล้ว —
git pushและการเปิด Pull Request คือ "ทริกเกอร์" ที่ปลุก pipeline ให้ตื่นขึ้นมาทำงาน ถ้ายังไม่แม่นเรื่อง branch กับ PR แนะนำให้ทบทวนบทที่ 4–5 และ 10 ของเล่ม Git ก่อน
✅ สรุปบทที่ 1 — CI = รวมโค้ดบ่อย ๆ แล้วให้เครื่อง build+test ทุกครั้ง · CD = ส่ง/ปล่อยขึ้นใช้งานอัตโนมัติเมื่อผ่าน CI · เกิดมาเพื่อฆ่า "integration hell" ด้วยการรวมถี่จนไม่เจ็บ · หัวใจคือ วงจรป้อนกลับที่สั้น — จับบั๊กยิ่งเร็ว ยิ่งถูก · pipeline ถูกปลุกโดยเหตุการณ์ใน Git เช่น push และ PR