คุณจัดการกับการปรับใช้การเปลี่ยนแปลงฐานข้อมูลอย่างไร

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

ในอีกด้านหนึ่งมีการปรับใช้รูปแบบการโยกย้ายที่คุณมีคำสั่งแบบขึ้น - ลงและการเรียนการสอนแบบลง - ลง (ไม่ว่าจะเขียนใน SQL หรือในภาษาแอปพลิเคชันของคุณ) และแอปของคุณรู้รุ่นที่มันต้องการ

สิ่งเหล่านี้เรียบง่ายและเราจะไม่ย้อนกลับบ่อยนักพัฒนามีความกระตือรือร้น อย่างไรก็ตามมีความเสี่ยงเมื่อคุณเพิ่มเขตข้อมูล / ตารางและเขตข้อมูลนั้นจะถูกเติมก่อนที่คุณจะย้อนกลับ หรือแย่กว่านั้นคือคุณทิ้งข้อมูลที่เกี่ยวข้องกับเวอร์ชันก่อนหน้า

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

สิ่งนี้จะเก็บข้อมูล แต่มีความซับซ้อนทั้งในการเขียนโค้ดและเพื่อทดสอบ (น่าเศร้าที่การทดสอบการรวมอัตโนมัติของเรานั้นไม่ค่อยมีอยู่จริงและในขณะที่เรากำลังแก้ไขนั้นเรามีปัญหาในขณะเดียวกัน)

มีวิธีที่ปลอดภัยในการลดปัญหาเหล่านี้หรือไม่? มีตัวเลือกอื่น ๆ ที่ฉันควรพิจารณาหรือไม่ คุณเคยมีประสบการณ์ที่ไม่ดีที่คุณต้องการแบ่งปันซึ่งสามารถช่วยฉันเจ็บปวดในภายหลัง

การจัดการฐานข้อมูลควรได้รับการจัดการเช่นเดียวกับการเปลี่ยนแปลงอื่น ๆ ทั้งหมดและปรับใช้เป็นสคริปต์ซึ่งเป็นส่วนหนึ่งของการปรับใช้ (และแน่นอนว่าบันทึกไว้ในการควบคุมแหล่งที่มา) เนื่องจากมีการปรับใช้กับรหัสสำหรับแอปพลิเคชันรุ่นเดียวกันคุณจึงรู้ว่าต้องย้อนกลับไปที่ใด คุณสามารถจินตนาการและเขียนสคริปต์เพื่อยกเลิกการเปลี่ยนแปลงแต่ละครั้งในขณะที่คุณเขียนสคริปต์ฐานข้อมูล แต่ถ้าการย้อนกลับไม่ใช่เรื่องปกติคุณอาจไม่ต้องการทำเช่นนั้น หากคอลัมน์ใหม่ถูกเติมข้อมูลคุณจะสูญเสียข้อมูลหากคุณกลับไปที่ฐานข้อมูลเดิม

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

การเปลี่ยนแปลงโครงสร้างฐานข้อมูลควรเป็นแบบอัตโนมัติ / สคริปต์และทดสอบโดยใช้สภาพแวดล้อมการทดสอบ การเปลี่ยนแปลงด้วยตนเองมีความเสี่ยงเกินไปในสภาพแวดล้อมการผลิต

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

การเปลี่ยนแปลงสามารถทำได้แบบเพิ่มขึ้น (เช่นการเพิ่มฟิลด์) และการทดสอบสดที่มีความเสี่ยงน้อยกว่าเมื่อทำการเปลี่ยนแปลงทั้งหมดในครั้งเดียว

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

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

ต่อต้านการกระตุ้นให้แก้ไขปัญหาด้วยตนเอง ใช้กลยุทธ์ฉุกเฉินของคุณ (ย้อนกลับสแนปชอต) จากนั้นคิดว่าเหตุใดจึงเกิดความผิดพลาดก่อนลองอัปเกรดอีกครั้ง