โรลแบ็ก (Rollback) ในการพัฒนา: คืออะไร วิธีดำเนินการ และทำงานอย่างไร

โรลแบ็กในการพัฒนาคืออะไร

โรลแบ็ก — การดำเนินการที่ส่งคืนระบบกลับสู่สถานะเสถียรก่อนหน้า ในบริบทของการพัฒนา สิ่งนี้อาจหมายถึงการยกเลิกคอมมิตใน Git การโรลแบ็กธุรกรรมในฐานข้อมูล หรือการกลับไปยังเวอร์ชันก่อนหน้าของแอปพลิเคชันบนเซิร์ฟเวอร์ คำศัพท์นี้มาจากภาษาอังกฤษ “rollback” และฝังรากลึกอยู่ในคำศัพท์ของนักพัฒนาทุกแพลตฟอร์ม

ความจำเป็นในการโรลแบ็กเกิดขึ้นเมื่อการเปลี่ยนแปลงใหม่ ทำให้ฟังก์ชันการทำงานเสียหาย ทำให้เกิดข้อผิดพลาด หรือไม่ผ่านการตรวจสอบคุณภาพ ในกระบวนการพัฒนาที่จัดอย่างดี โรลแบ็กไม่ใช่สัญญาณของความล้มเหลว แต่เป็นขั้นตอนมาตรฐานที่ฝังอยู่ในเวิร์กโฟลว์ ยิ่งทีมสามารถโรลแบ็กการเปลี่ยนแปลงที่มีปัญหาได้เร็วเท่าใด ผลกระทบของบั๊กต่อผู้ใช้ก็จะยิ่งน้อยลงเท่านั้น

เครื่องมือต่าง ๆ มีกลไกโรลแบ็กที่แตกต่างกัน Git ให้ตัวเลือกระหว่าง revert ที่ปลอดภัยและ reset ที่ทำลายล้าง ฐานข้อมูลรองรับการโรลแบ็กธุรกรรม และระบบ CI/CD สามารถสลับทราฟฟิกระหว่างเวอร์ชันได้ การเลือกแนวทางขึ้นอยู่กับบริบทและข้อกำหนดในการรักษาประวัติการเปลี่ยนแปลง

Git revert vs git reset: ต่างกันอย่างไร

Git revert — วิธีโรลแบ็กที่ปลอดภัยซึ่งสร้างคอมมิตใหม่ที่ยกเลิกการเปลี่ยนแปลงก่อนหน้า ประวัติยังคงเป็นเส้นตรงและคอมมิตเก่าทั้งหมดยังคงอยู่ นี่เป็นทางเลือกที่ถูกต้องเท่านั้นสำหรับการยกเลิกในสาขาที่ใช้ร่วมกันซึ่งนักพัฒนาหลายคนทำงาน Git revert ไม่ได้ลบประวัติ — มันเพิ่มข้อเท็จจริงของการโรลแบ็กเป็นการเปลี่ยนแปลงใหม่

Git reset เลื่อนตัวชี้สาขาปัจจุบันไปยังคอมมิตที่ระบุ ละทิ้งการเปลี่ยนแปลงที่ตามมาทั้งหมด ขึ้นอยู่กับแฟล็ก — soft, mixed หรือ hard — reset จัดการไดเรกทอรีทำงานและดัชนีแตกต่างกัน โหมด hard จะลบการเปลี่ยนแปลงออกจากประวัติอย่างสมบูรณ์ ทำให้เป็นอันตรายสำหรับสาขาที่ใช้ร่วมกันและเหมาะสำหรับงานในเครื่องเท่านั้น

เมื่อใดควรใช้ revert

Revert ใช้ในสาขาที่ใช้ร่วมกัน: main, develop, release มันรักษาประวัติและช่วยให้นักพัฒนาคนอื่นเข้าใจว่าการเปลี่ยนแปลงถูกยกเลิก หลังจาก revert คุณสามารถทำ git pull ได้อย่างปลอดภัย — ระบบจะไม่สร้างความขัดแย้งที่เกี่ยวข้องกับประวัติที่ถูกเขียนใหม่ ในการทำงานเป็นทีม revert เป็นมาตรฐานเริ่มต้น

# ยกเลิกคอมมิตล่าสุดโดยสร้างคอมมิตใหม่
git revert HEAD

# ยกเลิกคอมมิตเฉพาะด้วยแฮช
git revert a1b2c3d

เมื่อใดควรใช้ reset

Reset เหมาะสมในสาขาในเครื่องที่คุณยังไม่ได้เผยแพร่การเปลี่ยนแปลง หากคุณกำลังทดลองและต้องการล้างประวัติทั้งหมด — reset hard จะทำเช่นนั้น ในสาขาในเครื่อง คุณสามารถใช้ reset mixed เพื่อยกเลิกคอมมิตแต่คงการเปลี่ยนแปลงไว้ในไดเรกทอรีทำงานเพื่อคอมมิตใหม่

# ยกเลิกคอมมิตล่าสุด คงการเปลี่ยนแปลงในไดเรกทอรีทำงาน
git reset HEAD~1

# ยกเลิกทั้งหมด — การเปลี่ยนแปลงจะถูกลบอย่างถาวร
git reset --hard HEAD~2

โรลแบ็กในฐานข้อมูล: ธุรกรรมและ ACID

การโรลแบ็กธุรกรรม — การดำเนินการที่ยกเลิกการเปลี่ยนแปลงทั้งหมดที่ทำภายในธุรกรรมปัจจุบันและส่งคืนฐานข้อมูลสู่สถานะเมื่อเริ่มต้นธุรกรรม สิ่งนี้รับประกันความเป็นอะตอม — หนึ่งในสี่หลักการของ ACID (Atomicity, Consistency, Isolation, Durability) หากเกิดข้อผิดพลาดในขั้นตอนใดก็ตามของธุรกรรม จะดำเนินการโรลแบ็กและข้อมูลกลับสู่สถานะเดิม

กลไกการโรลแบ็กถูกนำไปใช้ผ่านบันทึกการเขียนล่วงหน้า (WAL) ก่อนที่จะแก้ไขหน้าข้อมูล DBMS จะเขียนค่าเก่าและใหม่ลงในบันทึก ระหว่างการโรลแบ็ก ระบบจะอ่านบันทึกและกู้คืนค่าเดิมสำหรับหน้าข้อมูลที่ถูกแก้ไขทั้งหมด สิ่งนี้รับประกันว่าแม้ในกรณีที่ไฟฟ้าดับ ธุรกรรมก็สามารถยกเลิกได้อย่างถูกต้อง

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint: การโรลแบ็กบางส่วน

ในธุรกรรมที่ยาวนาน สะดวกที่จะใช้ savepoint — จุดบันทึกชั่วคราวที่คุณสามารถย้อนกลับไปได้โดยไม่ต้องทำให้ธุรกรรมทั้งหมดเสร็จสมบูรณ์ ช่วยให้จัดการข้อผิดพลาดภายในดำเนินการที่ซับซ้อนโดยไม่สูญเสียความคืบหน้าในส่วนอื่น ๆ Savepoint รองรับโดย DBMS เชิงสัมพันธ์ส่วนใหญ่: PostgreSQL, MySQL, Oracle

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

โรลแบ็กในการปรับใช้: กลยุทธ์และเครื่องมือ

การโรลแบ็กการปรับใช้ — การส่งคืนแอปพลิเคชันที่กำลังทำงานไปยังเวอร์ชันก่อนหน้าหลังจากการปรับใช้ที่ไม่สำเร็จ นี่คือความสามารถที่สำคัญสำหรับสภาพแวดล้อมการผลิต: เวลากู้คืน (MTTR) ส่งผลโดยตรงต่อ SLA และประสบการณ์ผู้ใช้ แพลตฟอร์มสมัยใหม่มีกลยุทธ์การโรลแบ็กหลายแบบขึ้นอยู่กับสถาปัตยกรรมและข้อกำหนดด้านความพร้อมใช้งาน

การปรับใช้ Blue-green

Blue-green — กลยุทธ์ที่สภาพแวดล้อมที่เหมือนกันสองสภาพแวดล้อมทำงานพร้อมกัน: blue (เวอร์ชันปัจจุบัน) และ green (เวอร์ชันใหม่) ทราฟฟิกจะสลับไปที่ green หลังจากการปรับใช้สำเร็จ หากเวอร์ชันใหม่ทำงานไม่ถูกต้อง สวิตช์ทราฟฟิกจะกลับไปที่ blue การโรลแบ็กดำเนินการทันที โดยไม่ต้องปรับใช้ใหม่ — เพียงเปลี่ยนเส้นทาง

Canary release พร้อมการโรลแบ็กอัตโนมัติ

การปรับใช้ Canary ส่งทราฟฟิกส่วนเล็กไปยังเวอร์ชันใหม่และตรวจสอบเมตริก: อัตราข้อผิดพลาด เวลาตอบสนอง เปอร์เซ็นต์ของคำขอที่สำเร็จ หากเมตริกแย่ลง ระบบจะโรลแบ็ก canary โดยอัตโนมัติและส่งทราฟฟิกทั้งหมดไปยังเวอร์ชันเสถียร Kubernetes และ service mesh (Istio, Linkerd) รองรับกลยุทธ์นี้ในตัว

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

ตัวอย่างเชิงปฏิบัติของโรลแบ็กในการพัฒนา

มาดูสามสถานการณ์ทั่วไปที่นักพัฒนาจำเป็นต้องโรลแบ็กการเปลี่ยนแปลง แต่ละสถานการณ์ต้องใช้แนวทางของตนเอง — จากคำสั่งง่าย ๆ ในเทอร์มินัลไปจนถึงขั้นตอนหลายขั้นตอนที่เกี่ยวข้องกับ CI/CD

สถานการณ์ที่ 1: คอมมิตโดยไม่ตั้งใจใน main

คุณเผลอ push คอมมิตที่มีบั๊กไปที่ main งานของคุณคือโรลแบ็กการเปลี่ยนแปลงโดยไม่สูญเสียประวัติสำหรับทีม ใช้ git revert เพื่อสร้างคอมมิตที่ยกเลิก แล้ว git push สมาชิกทุกคนในทีมจะเห็นการโรลแบ็กและสามารถทำงานต่อได้โดยไม่มีความขัดแย้ง นี่เป็นวิธีที่ปลอดภัยและโปร่งใสที่สุด

git checkout main
git pull origin main
git revert HEAD
git push origin main

สถานการณ์ที่ 2: การย้ายฐานข้อมูลล้มเหลว

การย้ายฐานข้อมูลล้มเหลวและข้อมูลบางส่วนเสียหาย ใช้ การโรลแบ็กธุรกรรมในสคริปต์การย้ายและกู้คืนจากข้อมูลสำรองสำหรับการเปลี่ยนแปลงที่ใช้ไปแล้ว ในระบบที่ออกแบบมาอย่างดี การย้ายแต่ละครั้งจะถูกห่อหุ้มในธุรกรรม — เมื่อเกิดข้อผิดพลาด DBMS จะดำเนินการโรลแบ็กโดยอัตโนมัติ

สถานการณ์ที่ 3: การปรับใช้ที่มีบั๊กร้ายแรง

หลังจากปรับใช้เวอร์ชันใหม่ คุณพบว่าการรับรองความถูกต้องไม่ทำงาน หากคุณใช้ blue-green การโรลแบ็กคือการสลับเราเตอร์กลับ หากเป็นการอัปเดตแบบต่อเนื่อง — คำสั่ง kubectl rollout undo จะกลับไปยังเวอร์ชันก่อนหน้า ตามอุดมคติแล้ว กระบวนการโรลแบ็กควรเป็นอัตโนมัติและใช้เวลาไม่เกินหนึ่งนาที