LEVEL 0 · ปูพื้นจากศูนย์

แบบจำลองความคิดหลัก

บทนี้สำคัญที่สุดในเล่ม เช่นเดียวกับบทที่ 2 ของเล่ม Git ถ้าคุณเข้าใจสองแนวคิดต่อไปนี้ — กายวิภาคของ pipeline และ เส้นแบ่งสามระดับของ CI/CD — รายละเอียด YAML ที่เหลือทั้งเล่มจะกลายเป็นเรื่องเดาได้ ไม่ใช่เรื่องท่องจำ

2.1 Pipeline คือสายพานประกอบอัตโนมัติ

แก่นของ CI/CD คือ pipeline — ชุดขั้นตอนที่ทำงานเรียงต่อกันโดยอัตโนมัติเมื่อมีเหตุการณ์มากระตุ้น มองมันเป็นสายพานในโรงงาน: โค้ดดิบเข้าทางหนึ่ง ผ่านสถานีตรวจและประกอบทีละสถานี แล้วออกอีกทางเป็นซอฟต์แวร์ที่พร้อมใช้งาน ทุกแพลตฟอร์ม (GitHub Actions, GitLab CI, Jenkins, CircleCI) ใช้คำศัพท์ต่างกันแต่โครงสร้างเดียวกันนี้เสมอ:

FIG 2.1 — ลำดับชั้น: event ปลุก → workflow (ทั้ง pipeline) → ประกอบด้วยหลาย job (รันขนานกันได้ แต่ละอันบน runner ของตัวเอง) → แต่ละ job มีหลาย step ที่รันเรียงกันบนเครื่องเดียว

จำลำดับชั้นนี้ไว้ให้แม่น เพราะมันคือโครงของทุกอย่าง:

ชั้น	คืออะไร	กฎสำคัญ
Event (trigger)	เหตุการณ์ที่ปลุก pipeline	push, PR, tag, ตามเวลา, กดเอง
Workflow / Pipeline	ทั้งกระบวนการ เขียนไว้ในไฟล์ YAML	หนึ่งไฟล์ = หนึ่ง pipeline
Job	กลุ่มงานที่รันบนเครื่องหนึ่งเครื่อง	หลาย job รันขนานกันโดยปริยาย
Step	คำสั่งย่อยในแต่ละ job	step รันเรียงกัน แชร์พื้นที่ทำงาน
Runner	เครื่อง (จริง/เสมือน) ที่รัน job	เริ่มสะอาดทุกครั้ง ไม่มีของค้าง

2.2 เส้นแบ่งสามระดับ: Integration → Delivery → Deployment

คนสับสน "CD" มากที่สุด เพราะมันย่อได้สองคำที่ต่างกัน ความจริงคือมันคือ สามขั้นที่ซ้อนกันเป็นชั้น ๆ แต่ละขั้นเพิ่มความอัตโนมัติขึ้นไปอีกระดับ:

FIG 2.2 — แต่ละขั้นครอบขั้นก่อนหน้าไว้ทั้งหมด · ความต่างเดียวระหว่าง Delivery กับ Deployment คือ มี “มนุษย์กดปุ่ม” คั่นก่อนขึ้น production หรือไม่

เส้นแบ่งที่ต้องจำให้ขึ้นใจ: Continuous Delivery = ระบบทำให้ "พร้อมปล่อย" อัตโนมัติ แต่การกดปล่อยจริงเป็นการตัดสินใจของคน ส่วน Continuous Deployment = ตัดมนุษย์ออกจากสมการ ผ่าน CI/ทดสอบเมื่อไรก็ขึ้น production เมื่อนั้นทันที ทีมส่วนใหญ่เริ่มจาก Delivery แล้วค่อยขยับไป Deployment เมื่อความเชื่อมั่นในชุดทดสอบสูงพอ (ลงลึกในบทที่ 9)

2.3 หลักการที่อยู่เบื้องหลังทั้งหมด

ก่อนลงรายละเอียด จำหลักสามข้อนี้ไว้ มันคือ "ทำไม" ที่อยู่ใต้ทุกคำสั่งในเล่ม:

ทำซ้ำได้เสมอ (reproducible) — pipeline เริ่มจากเครื่องสะอาดทุกครั้ง สิ่งที่ผ่านบน CI ต้องผ่านเหมือนกันไม่ว่าใครรัน "มันรันได้บนเครื่องผม" จึงไม่ใช่ข้ออ้างอีกต่อไป
เร็วเข้าไว้ (fast feedback) — pipeline ที่ใช้เวลา 40 นาทีคือ pipeline ที่ไม่มีใครรอดู ความเร็วคือฟีเจอร์
ล้มให้ดัง (fail loud) — เมื่อมีอะไรพัง ต้องหยุดและแจ้งทันที ไม่ใช่ปล่อยผ่านเงียบ ๆ แล้วให้ของเสียไหลขึ้น production

✅ สรุปบทที่ 2 — pipeline = สายพานอัตโนมัติ มีลำดับชั้น event → workflow → job (ขนาน) → step (เรียง) บน runner · CI/CD คือสามชั้นซ้อนกัน: Integration (build+test) ⊂ Delivery (พร้อมปล่อย กดเอง) ⊂ Deployment (ขึ้น prod อัตโนมัติ) · เส้นแบ่ง Delivery/Deployment คือ "มีคนกดปุ่มไหม" · หลักการใต้ทุกอย่าง: ทำซ้ำได้ · เร็ว · ล้มให้ดัง

อ่านแบบเต็มเล่ม