กลยุทธ์การ deploy ที่พบบ่อย (blue-green, canary, rolling) มีอะไรบ้าง?

Question

Accepted Answer

**กลยุทธ์การ deploy** กำหนดว่า version ใหม่จะถูกปล่อยสู่ production อย่างไร โดยสร้างสมดุลระหว่าง **ความปลอดภัย** **downtime** และ **ความเสี่ยง** กลยุทธ์ที่พบบ่อยได้แก่การ deploy แบบ **rolling**, **blue-green** และ **canary** ซึ่งแต่ละแบบมีการแลกเปลี่ยน (trade-off) ที่ต่างกัน

## Rolling deployment

```text
Gradually replace old instances with new ones, a few at a time:
  [v1][v1][v1][v1] → [v2][v1][v1][v1] → [v2][v2][v1][v1] → ... → [v2][v2][v2][v2]
  ✓ no downtime (some instances always serving); no extra full environment needed
  ✗ both versions run during the rollout; slower; rollback = roll back instance by instance
```

## Blue-green deployment

```text
Run TWO identical environments — BLUE (current) and GREEN (new version):
  → deploy v2 to GREEN; test it; then SWITCH all traffic from blue to green at once
  → BLUE stays as instant rollback (switch back if green has issues)
  ✓ instant switch; instant rollback; test green before going live; no in-between state
  ✗ needs DOUBLE the infrastructure (two full environments)
```

## Canary deployment

```text
Release the new version to a SMALL subset of users first, then gradually increase:
  → 5% of traffic → v2 (monitor errors/metrics) → 25% → 50% → 100% if healthy
  → if problems appear, roll back having affected only a few users
  ✓ limits blast radius (catch issues with minimal impact); data-driven gradual rollout
  ✗ more complex (traffic splitting, monitoring); slower full rollout
```

## การเลือก

```text
ROLLING → simple, no extra infra, gradual (a common default)
BLUE-GREEN → instant switch + instant rollback, safe testing (if you can afford 2x infra)
CANARY → safest for risky changes (limit blast radius), needs good monitoring
→ Choose by risk tolerance, infrastructure, and monitoring maturity.
```

## ทำไมจึงสำคัญ

การเข้าใจกลยุทธ์การ deploy มีคุณค่าสำหรับ **การปล่อยซอฟต์แวร์อย่างปลอดภัยโดยมีความเสี่ยงและ downtime น้อยที่สุด** จึงเป็นความรู้ที่สำคัญในทางปฏิบัติสำหรับการ deploy สู่ production

วิธีที่ version ใหม่ถูกปล่อยสู่ production ส่งผลต่อความปลอดภัยและความเสี่ยงอย่างมีนัยสำคัญ และกลยุทธ์ต่างๆ มีการแลกเปลี่ยนที่ต่างกัน **Rolling deployment** (การค่อยๆ แทนที่ instance เก่าด้วยใหม่) ให้การปล่อยแบบไม่มี downtime โดยไม่ต้องมี infrastructure เพิ่มเติม เป็นค่าเริ่มต้นที่เรียบง่ายและพบบ่อย แม้ทั้งสอง version จะรันระหว่างการ rollout **Blue-green deployment** (การรันสอง environment ที่เหมือนกันและสลับ traffic จาก environment ปัจจุบันไปยังใหม่ในครั้งเดียว) เปิดให้ **การสลับและ rollback ได้ทันที** (สลับกลับไปยัง environment เก่าหากมีปัญหา) พร้อมความสามารถในการทดสอบ version ใหม่ก่อนใช้งานจริง โดยแลกกับการต้องการ infrastructure สองเท่า มีคุณค่าเมื่อการ rollback ที่เร็วและการทดสอบก่อนสลับมีความสำคัญ **Canary deployment** (การปล่อยให้ผู้ใช้กลุ่มเล็กก่อน monitor แล้วค่อยๆ เพิ่ม) **ปลอดภัยที่สุดสำหรับการเปลี่ยนแปลงที่เสี่ยง** เพราะ **จำกัด blast radius** จับปัญหาในขณะที่กระทบผู้ใช้เพียงไม่กี่คนก่อนการ rollout เต็มรูปแบบ แม้จะต้องการการแบ่ง traffic และ monitoring ที่ดี

การเข้าใจกลยุทธ์เหล่านี้และ **การเลือกอย่างเหมาะสม** (rolling สำหรับความเรียบง่าย blue-green สำหรับการ rollback ทันทีและการทดสอบที่ปลอดภัยหาก infrastructure เอื้ออำนวย canary สำหรับการเปลี่ยนแปลงที่เสี่ยงพร้อม monitoring ที่ดี) ตามความสามารถในการรับความเสี่ยง infrastructure และความสมบูรณ์ของ monitoring สะท้อนวิจารณญาณการ deploy ที่ดี

กลยุทธ์เหล่านี้คือวิธีที่ทีมบรรลุการปล่อยที่ปลอดภัย downtime ต่ำ และความเสี่ยงต่ำ ซึ่งสำคัญต่อการดำเนินการ production ที่น่าเชื่อถือ

เนื่องจากการปล่อยซอฟต์แวร์สู่ production อย่างปลอดภัย (ลด downtime และความเสี่ยงให้น้อยที่สุด) เป็นข้อกังวลสำคัญและกลยุทธ์การ deploy มีการแลกเปลี่ยนที่ต่างกันในการบรรลุสิ่งนี้ และเนื่องจากการเข้าใจการ deploy แบบ rolling, blue-green และ canary และเมื่อใดควรใช้แต่ละแบบเปิดให้การปล่อยที่ปลอดภัย การเข้าใจกลยุทธ์การ deploy จึงเป็นความรู้ที่มีคุณค่าและสำคัญในทางปฏิบัติสำหรับการส่งมอบซอฟต์แวร์สู่ production เป็นหัวข้อสำคัญสำหรับการปล่อยการเปลี่ยนแปลงอย่างน่าเชื่อถือและปลอดภัย สะท้อนความเข้าใจว่าจะจัดการความเสี่ยงที่มีอยู่ในการ deploy สู่ production อย่างไร