LEVEL 3 · เข้าสู่ CD
CI → CD: Delivery vs Deployment
ถึงครึ่งหลังของเล่ม — เราข้ามจาก "ตรวจว่าโค้ดดี" (CI) ไปสู่ "ส่งโค้ดขึ้นใช้งานจริง" (CD) บทนี้ปักหมุดเส้นแบ่งที่บทที่ 2 เกริ่นไว้ ให้ชัดถึงระดับปฏิบัติ เพราะการเลือกผิดระหว่าง Delivery กับ Deployment คือการเลือกระดับความเสี่ยงที่ทีมรับได้
9.1 เส้นแบ่งเดียว: ใครเป็นคนกดปุ่มขึ้น production
9.2 แล้วควรเลือกแบบไหน
| Continuous Delivery | Continuous Deployment | |
|---|---|---|
| การขึ้น prod | อัตโนมัติถึงประตู แล้วคนกดอนุมัติ | อัตโนมัติทั้งเส้น ไม่มีคนคั่น |
| ต้องการ | ความเชื่อมั่นปานกลาง + จังหวะที่คนคุม | ชุดทดสอบ + monitoring ที่เชื่อมั่นสูงมาก |
| เหมาะกับ | ระบบที่ปล่อยผิดแล้วกระทบหนัก, มีข้อบังคับ | เว็บ/บริการที่ปล่อยถี่ ๆ และ rollback ได้เร็ว |
| ความถี่ปล่อย | เมื่อทีมพร้อม (วัน/สัปดาห์) | หลายครั้งต่อวันได้ |
คำแนะนำเชิงปฏิบัติ: เริ่มที่ Continuous Delivery เกือบทุกครั้ง ปล่อยให้ pipeline เตรียมทุกอย่างให้พร้อมโดยอัตโนมัติ แต่คงปุ่มที่มนุษย์กดไว้ก่อน เมื่อคุณ deploy ด้วยปุ่มนั้นหลายสิบครั้งจนไม่เคยมีเซอร์ไพรส์ และมี monitoring/rollback ที่ไว้ใจได้ ค่อยตัดปุ่มออกเพื่อก้าวสู่ Continuous Deployment — การก้าวข้ามนี้ควรมาจากความเชื่อมั่นที่พิสูจน์แล้ว ไม่ใช่ความมักง่าย
9.3 สิ่งที่ทำให้ Deployment เต็มรูปแบบเป็นไปได้
การปล่อยขึ้น prod อัตโนมัติจะปลอดภัยก็ต่อเมื่อมีตาข่ายรองรับครบ: ชุดทดสอบครอบคลุมพอจะเชื่อได้, monitoring ที่จับได้ทันทีเมื่อ prod เริ่มเพี้ยน, ความสามารถ rollback อัตโนมัติเมื่อสุขภาพระบบตก (บทที่ 11), และกลยุทธ์ปล่อยที่จำกัดวงความเสียหาย (เช่น canary) ขาดตาข่ายเหล่านี้ Continuous Deployment ก็คือการวิ่งโดยไม่มีเบรก
✅ สรุปบทที่ 9 — Delivery และ Deployment ใช้ CI/build ชุดเดียวกัน ต่างกันที่ มี "ประตูอนุมัติของมนุษย์" ก่อนขึ้น prod หรือไม่ · Delivery = พร้อมเสมอ คนเลือกเวลาปล่อย, Deployment = ผ่าน CI แล้วขึ้นเอง · เริ่มที่ Delivery ก่อน แล้วค่อยขยับเมื่อความเชื่อมั่นพิสูจน์แล้ว · Deployment เต็มรูปต้องมี test + monitoring + rollback + กลยุทธ์ปล่อยรองรับ