วิธีใดที่มีประสิทธิภาพในการจัดการกับสกีมาฐานข้อมูลที่ใช้ร่วมกันระหว่างสาขาโค้ด

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

ฐานข้อมูลซึ่งเป็น MS SQL Server มีสคีมาที่ใช้ร่วมกันอย่างไรก็ตามแต่ละสาขาทำการเปลี่ยนแปลงสคีมาในขณะที่มันดำเนินไป

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

ฉันใช้วิธีการต่อไปนี้สำเร็จแล้วได้อธิบายไว้ในการควบคุมเวอร์ชันและฐานข้อมูลของคุณ :

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

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

มันทำงานอย่างไรกับการแยกกิ่ง:

• เมื่อสาขาถูกสร้างขึ้นมันจะยึดเวอร์ชั่นสกีมาปัจจุบันกล่าวว่าเวอร์ชัน 1.6
• เมื่อทีมเริ่มทำงานในสาขาจะเพิ่มเวอร์ชันใหม่ 1.7 แล้วเริ่มเข้ารหัสขั้นตอนการอัปเกรดจาก 1.6 เป็น 1.7
• ขั้นตอนการอัพเกรดได้รับการเปลี่ยนแปลงเมื่อทำการแก้ไขในสาขา มันจะเรียกใช้สคริปต์ที่อัปเกรดจาก v 1.6 เป็น 1.7 เสมอ แต่สิ่งที่สคริปต์เหล่านั้นทำนั้นอยู่ภายใต้การวนซ้ำของรหัสปกติและการเช็คอินในสาขา
• สาขาเสร็จสิ้นการพัฒนามันเป็นการเตรียมการสำหรับการรวมระบบย้อนกลับ
  • มันจะบูรณาการไปข้างหน้าใหม่จากพื้นฐานไปยังสาขา หากการรวมกันไม่นำการเปลี่ยนแปลงใด ๆ กับเวอร์ชันของสคีมาสิ่งต่าง ๆ ดีสาขาสามารถย้อนกลับการรวมตามที่เป็น รุ่น 1.7 กลายเป็นรุ่นพื้นฐานใหม่
  • สิ่งที่น่าสนใจคือเมื่อสาขาอื่นกลับรวมเข้ากับฐานในระหว่างนี้และตอนนี้เวอร์ชันสกีมาฐานได้เปลี่ยนเป็น 1.7 ในกรณีนี้สาขาของเราต้องทำการชนมันคือสกีมาเป้าหมายการปรับใช้เป็น 1.8 และทำการตรวจสอบขั้นตอนการอัพเกรดที่เดิมจาก 1.6 เป็น 1.7 เพื่อดูว่ามันทำงานอย่างไรในสภาพแวดล้อมใหม่อัพเกรดจาก 1.7 เป็น 1.8 ความขัดแย้งของสคีมาแบบลอจิคัลต้องได้รับการแก้ไขสคริปต์อาจต้องมีการเปลี่ยนแปลงและต้องทำการทดสอบ เมื่อเสร็จแล้วสาขาสามารถรวมกลับเป็นฐาน เวอร์ชันเป้าหมายที่ปรับใช้ของผลิตภัณฑ์ตอนนี้กลายเป็น 1.8
  • เมื่อสาขาอื่นที่แยกส่วนที่ schema เวอร์ชัน 1.6 ต้องการรวมกลับเข้าด้วยกันจะต้องมีการชนรุ่นของ schema เป็น 1.9 ทดสอบสคริปต์อัปเกรดจาก 1.8 เป็น 1.9 จากนั้นสามารถรวมกลับเข้าไปในฐานได้

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

BTW, การแตกแขนง / การรวมเกิดขึ้นจริงแตกต่างกันอย่างไรระหว่างผลิตภัณฑ์ควบคุมซอร์สฉันใช้คำศัพท์ที่คุ้นเคยจากโหมดการทำงานแบบรวมกำลัง

ในขณะที่คำตอบของฉันอาจไม่ยาวเท่ากับรีมัส แต่ฉันคิดว่านี่เป็นทางออกที่ดีจริงๆ ฉันยังไม่ได้ตั้งค่าในการผลิตดังนั้น YMMV *

Liquibase

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

<createTable tableName="department">
            <column name="id" type="int">
                <constraints primaryKey="true" nullable="false"/>
            </column>

มีไวยากรณ์ที่ครบถ้วนสมบูรณ์ดังนั้นคุณสามารถทำสิ่งใดก็ได้ที่คุณต้องการในฐานข้อมูลของคุณ

คุณยังระบุในการติดตั้ง Liquibase ฐานข้อมูลที่คุณต้องการให้เป็นเวอร์ชัน จากนั้นคุณ "เรียกใช้" .xml ด้วย Java executable ที่รวมอยู่ (ไฟล์ jar) สิ่งนี้จะสร้างการเปลี่ยนแปลงที่ระบุใน XML ไปยังฐานข้อมูลของคุณอีกครั้ง

ตัว kicker ที่แท้จริงคือคุณเก็บไฟล์ XML นี้ไว้ในโฟลเดอร์ versioned เดียวกับรหัสของคุณ ดังนั้นในกรณีของฉันนั่นคือ Git ฉันมีไฟล์ XML นี้ในโฟลเดอร์โครงการ (ระดับเดียวกับ /.git) จากนั้นเมื่อใดก็ตามที่ฉันสลับสาขาไฟล์ XML จะเปลี่ยนเป็นเวอร์ชันสาขานั้นและฉันจะเรียกใช้ไฟล์. jar และฐานข้อมูลของฉันจะสะท้อนสาขานั้น

* หมายเหตุ: ฉันยังไม่ได้ติดตั้งให้เสร็จเพราะฉันมีปัญหาในการเชื่อมต่อ Java กับ SQL Server ต้องการไดรเวอร์ jdbc บางตัวและฉันไม่ได้อยู่ในอารมณ์ ดังนั้นไมล์สะสมของคุณอาจแตกต่างกันไป

ที่ Red Gate ในไม่ช้าเราจะปล่อยโซลูชันการกำหนดเวอร์ชันฐานข้อมูลที่ใช้ประโยชน์จากทั้งการเปรียบเทียบ SQL และการควบคุมแหล่งที่มาของ SQL สิ่งนี้ใช้วิธีการอัปเกรดสคริปต์การย้ายข้อมูลและประทับฐานข้อมูลด้วยคุณสมบัติเพิ่มเติมที่สอดคล้องกับการแก้ไขการควบคุมแหล่งที่มา

เราหวังว่าจะเปิดตัวในกลางเดือนธันวาคม มีตัวเลือกการเปิดตัวพร้อมใช้งานในขณะนี้ สำหรับข้อมูลเพิ่มเติมโปรดไปที่:

http://www.red-gate.com/products/sql-development/sql-source-control/entrypage/migration

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

หากคุณและการจัดการ schema ของคุณเปลี่ยนแปลงโดยการสร้างสคริปต์และทำให้สคริปต์เหล่านั้นอยู่ภายใต้การควบคุมแหล่งที่มาจากนั้นคุณควรจะสามารถรักษาการเปลี่ยนแปลงตามที่คุณต้องการผสานรหัสอื่น ๆ คุณสามารถเลือกที่จะรวมอัตโนมัติหรือทำการแทรกแซงด้วยตนเองเพิ่มเติม

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

ฉันแก้ไขมันด้วยการเขียนการลงรายการบัญชีเช็คเอาต์และเบ็ดการโพสต์ผสานที่สามารถใช้ได้ดีกับคอมไพล์ ฉันจัดเก็บการย้ายข้อมูลทั้งหมดของฉันในรูปแบบของไฟล์ SQL ในไดเรกทอรีแยกต่างหากและส่งข้อมูลไปพร้อมกับโค้ด PHP ที่เปลี่ยนแปลง ทุกครั้งที่ฉันแสดง

git checkout

หรือ

git merge

git จะเรียกการโยกย้ายขึ้นและลงที่เหมาะสมโดยอัตโนมัติ ดูการดำเนินงานของฉันบนGithub