คุณจัดการ rollback อย่างไรเมื่อการ deploy ล้มเหลว?

Question

Accepted Answer

เมื่อการ deploy ทำให้เกิดปัญหา คุณต้อง **rollback** อย่างรวดเร็วกลับสู่สภาพที่ทำงานได้เพื่อลดผลกระทบต่อผู้ใช้ให้น้อยที่สุด กลยุทธ์ rollback ที่มีประสิทธิภาพ และแนวปฏิบัติที่เกี่ยวข้องอย่าง monitoring การ rollback อัตโนมัติ และการแก้ไปข้างหน้า (forward-fixing) เป็นสิ่งจำเป็นสำหรับการ deploy ที่น่าเชื่อถือ

## ทำไมความสามารถในการ rollback จึงสำคัญ

```text
Deployments sometimes introduce problems (bugs, errors, performance issues) that get
through testing. When that happens in production:
  → you need to restore a WORKING state QUICKLY (minimize user impact/downtime)
  → a fast, reliable rollback is essential — being able to undo a bad deploy fast
→ "How do we roll back?" must be answered BEFORE you need it.
```

## แนวทางการ rollback

```text
✓ REDEPLOY the previous version — deploy the last known-good artifact/version
  (versioned artifacts make this easy: deploy v1.2.2 to undo v1.2.3)
✓ BLUE-GREEN → instant rollback by switching traffic back to the old environment
✓ CANARY → if the canary shows problems, stop the rollout (only a few users affected)
✓ Database changes → trickier (need backward-compatible migrations; see below)
✓ Feature FLAGS → disable a problematic feature without redeploying (instant "rollback"
  of behavior)
```

## ข้อพิจารณาสำคัญ

```text
⚠️ DATABASE migrations → rollbacks are hard if a migration is destructive/incompatible:
  → use BACKWARD-COMPATIBLE migrations (so the old code works with the new schema)
  → decouple schema changes from code; expand-then-contract patterns
✓ MONITORING → detect problems FAST (so you know to roll back) — alerts on errors/metrics
✓ AUTOMATED rollback → some pipelines auto-rollback on failed health checks
✓ FORWARD FIX → sometimes fixing forward (a quick patch) is better than rolling back
✓ Practice/test rollbacks → ensure they actually work when needed
```

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

การเข้าใจกลยุทธ์ rollback มีความสำคัญ เพราะ **การ deploy บางครั้งล้มเหลว และการกู้คืนได้อย่างรวดเร็วเป็นสิ่งจำเป็นต่อความน่าเชื่อถือ** จึงเป็นความรู้ที่มีคุณค่าในทางปฏิบัติสำหรับการ deploy สู่ production

แม้จะมีการทดสอบที่ดี การ deploy ก็ทำให้เกิดปัญหาใน production เป็นครั้งคราว และเมื่อเกิดขึ้น การ **กู้คืนสภาพที่ทำงานได้อย่างรวดเร็ว** (เพื่อลดผลกระทบต่อผู้ใช้และ downtime) เป็นสิ่งวิกฤต ทำให้ความสามารถในการ rollback เป็นส่วนสำคัญของการ deploy ที่น่าเชื่อถือ และเป็นสิ่งที่ควรวางแผน **ก่อน** ที่จะต้องการมัน

การเข้าใจ **แนวทางการ rollback** ได้แก่ การ redeploy version ก่อนหน้า (ทำได้ง่ายด้วย artifacts ที่มี version) การ rollback ทันทีของ **blue-green** (สลับ traffic กลับ) การหยุดการ rollout ของ **canary** (จำกัดผลกระทบ) และการใช้ **feature flags** เพื่อปิด feature ที่มีปัญหาโดยไม่ต้อง redeploy ให้ตัวเลือกที่เหมาะกับกลยุทธ์การ deploy ที่ต่างกัน

การเข้าใจ **ข้อพิจารณาสำคัญ** สะท้อนแนวปฏิบัติการ deploy ที่สมบูรณ์: **database migrations ทำให้การ rollback ยาก** (เพราะการเปลี่ยน schema ที่ทำลายหรือเข้ากันไม่ได้ไม่สามารถ undo ได้ง่ายๆ) ดังนั้นการใช้ **backward-compatible migrations** (เพื่อให้โค้ดเก่าทำงานกับ schema ใหม่ได้) และ pattern อย่าง expand-then-contract จึงเป็นสิ่งจำเป็น เป็นข้อกังวลในโลกจริงที่ยุ่งยากและสำคัญอย่างแท้จริง

การเข้าใจบทบาทของ **monitoring** (การตรวจจับปัญหาได้เร็วเพื่อให้รู้ว่าต้อง rollback) **การ rollback อัตโนมัติ** (เมื่อ health check ล้มเหลว) ตัวเลือกของ **forward-fixing** (บางครั้งการแก้ไปข้างหน้าด้วย patch เร็วๆ ดีกว่าการ rollback) และความสำคัญของ **การทดสอบ rollback** (ให้มั่นใจว่ามันทำงานเมื่อจำเป็น) สะท้อนการคิดอย่างครอบคลุมเกี่ยวกับการกู้คืนจากการ deploy

เนื่องจากการ deploy สามารถล้มเหลวและการกู้คืนอย่างรวดเร็วเป็นสิ่งจำเป็นต่อความน่าเชื่อถือ (ลดผลกระทบต่อผู้ใช้) และเนื่องจากการเข้าใจแนวทางการ rollback ความท้าทายของ database-migration และแนวปฏิบัติสนับสนุน (monitoring การทำให้อัตโนมัติ forward-fixing) เปิดให้การกู้คืนจากการ deploy ที่ไม่ดีได้อย่างมีประสิทธิภาพ การเข้าใจกลยุทธ์ rollback จึงเป็นความรู้ที่มีคุณค่าและสำคัญในทางปฏิบัติสำหรับการ deploy สู่ production ที่น่าเชื่อถือ เป็นแง่มุมวิกฤตของความปลอดภัยในการ deploy สะท้อนความสมบูรณ์ในการดำเนินการที่จะจัดการกับความล้มเหลวที่หลีกเลี่ยงไม่ได้ซึ่งเกิดขึ้นแม้จะมี CI/CD ที่ดี