เปลี่ยนระบบเดิมอย่างปลอดภัย

ระบุข้อตกลงการทำงานรอบการเปลี่ยนแปลง

ซอฟต์แวร์เดิมมีส่วนที่เรียกใช้ ข้อมูลที่เก็บไว้ งานตามกำหนดเวลา และขั้นตอนเดินระบบ บางสิ่งที่ต้องพึ่งพามองไม่เห็นในไฟล์ที่ต้องการแก้ Agent อาจสร้างการเปลี่ยนแปลงที่ถูกต้องเฉพาะจุด แต่ทำให้ข้อตกลงการทำงานข้อใดข้อหนึ่งเสีย

ก่อนพัฒนา ให้ระบุส่วนที่อ่านและเขียนข้อมูลที่ได้รับผลกระทบ ตรวจดู route งานเบื้องหลัง รายงาน และการเชื่อมต่อภายนอก ตรวจว่าทีมอื่นหรือ client เวอร์ชันเก่าพึ่งพาพฤติกรรมปัจจุบันหรือไม่

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

ทำให้พฤติกรรมปัจจุบันสังเกตได้

สำหรับ module ที่มีเอกสารไม่เพียงพอ ให้เพิ่มการตรวจสอบเฉพาะพฤติกรรมที่ต้องคงเดิม การตรวจสอบเหล่านี้อธิบายข้อตกลงปัจจุบัน แต่ไม่ได้พิสูจน์ว่าทุกพฤติกรรมที่มีอยู่เป็นสิ่งที่ต้องการ

หากพฤติกรรมปัจจุบันขัดกับข้อกำหนด ให้บันทึกข้อขัดแย้ง อย่ารักษาข้อบกพร่องความปลอดภัยเพียงเพราะ test บันทึกพฤติกรรมนั้นไว้ ขอการตัดสินใจที่จำเป็นเพื่อแยกพฤติกรรมที่ตั้งใจออกจากข้อบกพร่อง

ใช้ fixture ที่สมจริงและไม่มีข้อมูลอ่อนไหว รวมรูปแบบข้อมูลเก่าและระเบียนไม่ครบในกรณีที่อาจเกิดขึ้นได้ Schema ใหม่ที่ทดสอบด้วยข้อมูลสร้างใหม่เท่านั้นอาจซ่อนปัญหา migration

ตรวจทานช่วงเปลี่ยนระหว่างเวอร์ชัน

พิจารณาการเปลี่ยนชื่อสมมติจาก customer_name เป็น display_name การเปลี่ยนชื่อทันทีอาจทำให้ instance แอปเก่าทำงานไม่ได้ระหว่าง deployment การอัปเดตทั้งสองไฟล์ใน pull request เดียวไม่ได้ทำให้ deployment เป็น atomic

การแบ่งเป็นขั้นอาจรักษา compatibility ได้

1. เพิ่ม field ใหม่โดยไม่ลบ field เก่า
2. กำหนดว่าการเขียนข้อมูลใหม่จะรักษาค่าที่ต้องการให้สอดคล้องกันอย่างไร
3. เติมข้อมูลให้ระเบียนเดิมด้วยกระบวนการ backfill ที่เริ่มต่อได้
4. ตรวจสอบความครบถ้วนและพฤติกรรมของส่วนที่อ่านข้อมูล
5. ย้ายส่วนที่อ่านข้อมูลไปใช้ field ใหม่
6. ลบ field เก่าหลังจากไม่มีส่วนใดใช้มันแล้วเท่านั้น

วิธีที่แน่นอนขึ้นอยู่กับฐานข้อมูลและรูปแบบการเขียน การเขียนสองที่อาจทำให้ข้อมูลไม่สอดคล้องกันหากที่หนึ่งเขียนไม่สำเร็จ อาจต้องใช้ database transaction หรือวิธี synchronization อื่นที่กำหนดชัดเจน อย่าใช้ตัวอย่างนี้โดยไม่ตรวจสอบสิ่งที่ระบบรับประกัน

Martin Fowler อธิบายการเปลี่ยนผ่านทั่วไปนี้ว่า parallel change หรือ expand-and-contract แนวคิดหลักคือทำช่วงเปลี่ยนผ่านให้เข้ากันได้ก่อนลบของเดิม

วางแผนกู้คืนแยกจาก rollback

การ rollback โค้ดนำแอปเวอร์ชันก่อนหน้ากลับมา ไม่ได้ย้อน data migration โดยอัตโนมัติ เวอร์ชันเก่าอาจไม่เข้าใจข้อมูลใหม่ Migration ที่ทำลายข้อมูลอาจลบข้อมูลที่ rollback โค้ดกู้กลับไม่ได้

ระบุวิธีกู้คืนแต่ละขั้น Backfill ที่เริ่มต่อได้อาจดำเนินต่ออย่างปลอดภัย การแปลงผิดอาจต้องแก้จากข้อมูลต้นทางที่เก็บรักษาไว้ การดำเนินการที่ทำลายข้อมูลอาจต้องใช้ขั้นตอน restore ที่ตรวจสอบแล้ว

ถามว่าใครรับผิดชอบการตัดสินใจกู้คืนและอาจใช้เวลานานเท่าใด อย่าถือว่า “เรามี backup” เป็นหลักฐานว่าการกู้คืนตรงตามข้อกำหนดบริการ

รักษาการเปลี่ยนแปลงให้ตรวจทานได้

แยกการเก็บกวาดโค้ดที่ไม่เกี่ยวข้องออกจากการเปลี่ยนฟังก์ชัน ระบุแผน compatibility ผลการตรวจสอบ และเงื่อนไขการลบใน pull request ทำเครื่องหมายจุดที่หลังจากนั้น rollback จะต้องมีงานเพิ่ม

Agent ช่วยตรวจดูระบบที่ใช้ข้อมูลและเตรียมโค้ด migration ได้ แต่ผู้รับผิดชอบยังต้องยอมรับแผนเปลี่ยนผ่านและกู้คืน แบบสุดท้ายเป็นเพียงส่วนหนึ่งของการเปลี่ยนแปลงที่ปลอดภัย