LEVEL 3 · เข้าสู่ CD
กลยุทธ์ Deploy & Rollback
"deploy" ไม่ได้มีแบบเดียว วิธีที่คุณเปลี่ยนจากเวอร์ชันเก่าเป็นใหม่บน production กำหนดว่า ถ้าเวอร์ชันใหม่มีปัญหา จะมีผู้ใช้กี่คนที่เจอ และคุณถอยกลับได้เร็วแค่ไหน นี่คือหัวใจของ CD ที่ปลอดภัย
11.1 สี่กลยุทธ์หลัก
| กลยุทธ์ | ทำอย่างไร | แลกอะไร |
|---|---|---|
| Recreate | ดับเวอร์ชันเก่าทั้งหมด แล้วเปิดใหม่ | ง่ายสุด แต่มีช่วง downtime |
| Rolling | ทยอยเปลี่ยนเครื่องทีละกลุ่ม | ไม่ดับ แต่ช่วงเปลี่ยนมีสองเวอร์ชันปนกัน |
| Blue-Green | ยกชุดใหม่ขึ้นคู่ขนาน แล้วสลับ traffic ทีเดียว | rollback ไวมาก แต่ใช้ทรัพยากร 2 เท่าชั่วคราว |
| Canary | ปล่อยให้ผู้ใช้ส่วนน้อยก่อน เฝ้าดู แล้วค่อยขยาย | จำกัดวงความเสียหายดีสุด แต่ซับซ้อนสุด |
11.2 Rollback — แผนถอยที่ต้องมีก่อนเดินหน้า
กฎเหล็กของ CD: อย่า deploy อะไรที่คุณถอยกลับไม่ได้ ความสามารถ rollback ที่เร็วและเชื่อถือได้ คือสิ่งที่ทำให้กล้าปล่อยบ่อย เพราะ "ปล่อยแล้วพัง" ไม่ใช่หายนะ แค่กด/รันถอยกลับเวอร์ชันก่อนหน้า Blue-Green ทำ rollback ได้แทบจะทันที (เสียบ router กลับ) ส่วนระบบที่ดีจะ rollback อัตโนมัติ เมื่อ health check หรือ metric หลังปล่อยตก โดยไม่ต้องรอคนสังเกต
✅ สรุปบทที่ 11 — สี่กลยุทธ์: recreate (ง่าย มี downtime), rolling (ทยอย ไม่ดับ), blue-green (ยกคู่ขนาน สลับ/ถอยไว), canary (ปล่อยทีละน้อย จำกัดวงดีสุด) · กฎเหล็ก: อย่า deploy สิ่งที่ถอยกลับไม่ได้ — rollback ที่ไว (อัตโนมัติยิ่งดี) คือเหตุผลที่กล้าปล่อยบ่อย · ทำ DB migration แบบเข้ากันได้สองทางเพื่อให้ถอยได้เสมอ