คุณควรสร้างฐานข้อมูลจากการควบคุมแหล่งที่มาอย่างไร

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

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

ฉันต้องการรับฟังความคิดเห็นจากชุมชน SO เกี่ยวกับแนวทางปฏิบัติที่ได้ผลในโลกแห่งความเป็นจริง

ฉันตระหนักดีว่าการปฏิบัตินั้นค่อนข้างเป็นอัตวิสัยที่ดีที่สุด แต่ฉันคิดว่าบทสนทนาที่ดีเกี่ยวกับงานที่อาจเป็นประโยชน์กับคนจำนวนมาก

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

1. ควรสร้างทั้งสภาพแวดล้อมการทดสอบและการผลิตจากการควบคุมแหล่งที่มาหรือไม่
   
   • ทั้งสองควรสร้างขึ้นโดยใช้ระบบอัตโนมัติ - หรือควรผลิตโดยสร้างโดยการคัดลอกวัตถุจากสภาพแวดล้อมการทดสอบที่เสถียรและสรุปแล้ว?
   • คุณจัดการกับความแตกต่างที่อาจเกิดขึ้นระหว่างสภาพแวดล้อมการทดสอบและการใช้งานจริงในสคริปต์การปรับใช้อย่างไร
   • คุณจะทดสอบได้อย่างไรว่าสคริปต์การปรับใช้จะทำงานได้อย่างมีประสิทธิภาพเมื่อเทียบกับการใช้งานจริงเช่นเดียวกับที่ทำในการทดสอบ
2. ชนิดของวัตถุที่ควรควบคุมเวอร์ชัน?
   • เพียงแค่รหัส (โพรซีเดอร์แพ็คเกจทริกเกอร์ java ฯลฯ )?
   • ดัชนี?
   • ข้อ จำกัด ?
   • นิยามตาราง?
   • สคริปต์เปลี่ยนตาราง? (เช่นแก้ไขสคริปต์)
   • ทุกอย่าง?
3. ออบเจ็กต์ประเภทใดที่ไม่ควรควบคุมเวอร์ชัน
   • ลำดับ?
   • เงินช่วยเหลือ?
   • บัญชีผู้ใช้?
4. ควรจัดระเบียบวัตถุฐานข้อมูลในที่เก็บ SCM ของคุณอย่างไร
   • คุณจัดการกับสิ่งที่เกิดขึ้นเพียงครั้งเดียวเช่นสคริปต์การแปลงหรือแก้ไขสคริปต์อย่างไร
   • คุณจัดการกับการเลิกใช้วัตถุจากฐานข้อมูลอย่างไร?
   • ใครควรรับผิดชอบส่งเสริมวัตถุตั้งแต่ระดับการพัฒนาจนถึงระดับทดสอบ?
   • คุณประสานการเปลี่ยนแปลงจากนักพัฒนาหลายคนได้อย่างไร?
   • คุณจัดการกับการแยกย่อยสำหรับอ็อบเจ็กต์ฐานข้อมูลที่ระบบหลายระบบใช้อย่างไร
5. มีข้อยกเว้นใดบ้างที่สมเหตุสมผลกับกระบวนการนี้
   • ปัญหาด้านความปลอดภัย?
   • ข้อมูลที่มีข้อกังวลเกี่ยวกับการยกเลิกการระบุตัวตน?
   • สคริปต์ที่ไม่สามารถทำงานอัตโนมัติได้ทั้งหมด?
6. คุณจะทำให้กระบวนการยืดหยุ่นและบังคับใช้ได้อย่างไร
   • ถึงข้อผิดพลาดของนักพัฒนา?
   • ถึงปัญหาสิ่งแวดล้อมที่ไม่คาดคิด?
   • สำหรับการกู้คืนระบบ?
7. คุณจะโน้มน้าวผู้มีอำนาจในการตัดสินใจได้อย่างไรว่าประโยชน์ของ DB-SCM ทำให้ต้นทุนเหมาะสมอย่างแท้จริง
   • หลักฐาน?
   • การวิจัยอุตสาหกรรม?
   • คำแนะนำแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรม?
   • การอุทธรณ์ต่อหน่วยงานที่ได้รับการยอมรับ?
   • การวิเคราะห์ผลประโยชน์ค่าใช้จ่าย?
8. ใครควร "เป็นเจ้าของ" วัตถุฐานข้อมูลในโมเดลนี้
   • นักพัฒนา?
   • DBA?
   • นักวิเคราะห์ข้อมูล?
   • มากกว่าหนึ่ง?

คำตอบบางส่วนสำหรับคำถามของคุณมีดังนี้

1. ควรสร้างทั้งสภาพแวดล้อมการทดสอบและการผลิตจากการควบคุมแหล่งที่มาหรือไม่ ใช่
   • ทั้งสองควรสร้างขึ้นโดยใช้ระบบอัตโนมัติ - หรือควรผลิตโดยสร้างโดยการคัดลอกวัตถุจากสภาพแวดล้อมการทดสอบที่เสถียรและสรุปแล้ว?
   • ระบบอัตโนมัติสำหรับทั้งสองอย่าง อย่าคัดลอกข้อมูลระหว่างสภาพแวดล้อม
   • คุณจัดการกับความแตกต่างที่อาจเกิดขึ้นระหว่างสภาพแวดล้อมการทดสอบและการใช้งานจริงในสคริปต์การปรับใช้อย่างไร
   • ใช้เทมเพลตดังนั้นคุณจะสร้างชุดของสคริปต์ที่แตกต่างกันสำหรับแต่ละสภาพแวดล้อม (เช่นการอ้างอิงไปยังระบบภายนอกฐานข้อมูลที่เชื่อมโยง ฯลฯ )
   • คุณจะทดสอบได้อย่างไรว่าสคริปต์การปรับใช้จะทำงานได้อย่างมีประสิทธิภาพเมื่อเทียบกับการใช้งานจริงเช่นเดียวกับที่ทำในการทดสอบ
   • คุณทดสอบในสภาพแวดล้อมก่อนการผลิต: ทดสอบการปรับใช้กับสำเนาของสภาพแวดล้อมการผลิตที่ถูกต้อง (ฐานข้อมูลและระบบอื่น ๆ ที่อาจเกิดขึ้น)
2. ชนิดของวัตถุที่ควรควบคุมเวอร์ชัน?
   • เพียงแค่รหัส (โพรซีเดอร์แพ็คเกจทริกเกอร์ java ฯลฯ )?
   • ดัชนี?
   • ข้อ จำกัด ?
   • นิยามตาราง?
   • สคริปต์เปลี่ยนตาราง? (เช่นแก้ไขสคริปต์)
   • ทุกอย่าง?
   • ทุกอย่างและ:
     • อย่าลืมข้อมูลคงที่ (รายการค้นหา ฯลฯ ) ดังนั้นคุณไม่จำเป็นต้องคัดลอกข้อมูลใด ๆ ระหว่างสภาพแวดล้อม
     • เก็บเฉพาะเวอร์ชันปัจจุบันของสคริปต์ฐานข้อมูล (เวอร์ชันที่ควบคุมแน่นอน) และ
     • จัดเก็บสคริปต์การเปลี่ยนแปลง: 1 สคริปต์ขนาดใหญ่ (หรือไดเรกทอรีของสคริปต์ที่ชื่อชอบ 001_AlterXXX.sql เพื่อให้การเรียกใช้ตามลำดับการจัดเรียงตามธรรมชาติจะอัปเกรดจากเวอร์ชัน A เป็น B)
3. ออบเจ็กต์ประเภทใดที่ไม่ควรควบคุมเวอร์ชัน
   • ลำดับ?
   • เงินช่วยเหลือ?
   • บัญชีผู้ใช้?
   • ดู 2. หากผู้ใช้ / บทบาทของคุณ (หรือชื่อผู้ใช้ทางเทคนิค) แตกต่างกันระหว่างสภาพแวดล้อมคุณยังคงสามารถเขียนสคริปต์ได้โดยใช้เทมเพลต (ดู 1. )
4. ควรจัดระเบียบวัตถุฐานข้อมูลในที่เก็บ SCM ของคุณอย่างไร
   • คุณจัดการกับสิ่งที่เกิดขึ้นเพียงครั้งเดียวเช่นสคริปต์การแปลงหรือแก้ไขสคริปต์อย่างไร
   • ดู 2.
   • คุณจัดการกับการเลิกใช้วัตถุจากฐานข้อมูลอย่างไร?
   • ลบออกจากฐานข้อมูลถูกลบออกจากลำตัวควบคุมแหล่งที่มา / คำแนะนำ
   • ใครควรเป็นผู้รับผิดชอบในการส่งเสริมวัตถุตั้งแต่ระดับการพัฒนาจนถึงระดับทดสอบ?
   • กำหนดการพัฒนา / ทดสอบ / เผยแพร่
   • คุณประสานการเปลี่ยนแปลงจากนักพัฒนาหลายคนได้อย่างไร?
   • พยายามอย่าสร้างฐานข้อมูลแยกกันสำหรับนักพัฒนาแต่ละคน คุณใช้การควบคุมแหล่งที่มาใช่ไหม ในกรณีนี้นักพัฒนาเปลี่ยนฐานข้อมูลและเช็คอินสคริปต์ เพื่อความปลอดภัยอย่างสมบูรณ์สร้างฐานข้อมูลใหม่จากสคริปต์ในระหว่างการสร้างทุกคืน
   • คุณจัดการกับการแยกย่อยสำหรับอ็อบเจ็กต์ฐานข้อมูลที่ระบบหลายระบบใช้อย่างไร
   • สิ่งที่ยาก: พยายามหลีกเลี่ยงค่าใช้จ่ายทั้งหมด
5. มีข้อยกเว้นใดบ้างที่สมเหตุสมผลกับกระบวนการนี้
   • ปัญหาด้านความปลอดภัย?
   • อย่าเก็บรหัสผ่านสำหรับการทดสอบ / ผลิตภัณฑ์ คุณอาจอนุญาตสำหรับ dev โดยเฉพาะอย่างยิ่งถ้าคุณสร้าง DB ใหม่อัตโนมัติทุกวัน / ทุกคืน
   • ข้อมูลที่มีข้อกังวลเกี่ยวกับการยกเลิกการระบุตัวตน?
   • สคริปต์ที่ไม่สามารถทำงานอัตโนมัติได้ทั้งหมด?
   • เอกสารและจัดเก็บด้วยข้อมูลรุ่น / สคริปต์แก้ไข
6. คุณจะทำให้กระบวนการยืดหยุ่นและบังคับใช้ได้อย่างไร
   • ถึงข้อผิดพลาดของนักพัฒนา?
   • ทดสอบด้วยการสร้างรายวันตั้งแต่เริ่มต้นและเปรียบเทียบผลลัพธ์กับการอัปเกรดแบบเพิ่มหน่วย (จากเวอร์ชัน A ถึง B โดยใช้ ALTER) เปรียบเทียบทั้งสคีมาที่เป็นผลลัพธ์และข้อมูลคงที่
   • ถึงปัญหาสิ่งแวดล้อมที่ไม่คาดคิด?
   • ใช้การควบคุมเวอร์ชันและการสำรองข้อมูล
   • เปรียบเทียบสคีมาฐานข้อมูล PROD กับสิ่งที่คุณคิดโดยเฉพาะก่อนการปรับใช้ SuperDuperCool DBA อาจแก้ไขข้อผิดพลาดที่ไม่เคยมีในระบบตั๋วของคุณ :)
   • สำหรับการกู้คืนระบบ?
7. คุณจะโน้มน้าวผู้มีอำนาจในการตัดสินใจได้อย่างไรว่าประโยชน์ของ DB-SCM ทำให้ต้นทุนเหมาะสมอย่างแท้จริง
   • หลักฐาน?
   • การวิจัยอุตสาหกรรม?
   • คำแนะนำแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรม?
   • การอุทธรณ์ต่อหน่วยงานที่ได้รับการยอมรับ?
   • การวิเคราะห์ผลประโยชน์ค่าใช้จ่าย?
   • หากนักพัฒนาและ DBA เห็นด้วยคุณไม่จำเป็นต้องโน้มน้าวใครฉันคิดว่า (เว้นแต่คุณต้องการเงินเพื่อซื้อซอฟต์แวร์เช่นdbGhostสำหรับ MSSQL)
8. ใครควร "เป็นเจ้าของ" วัตถุฐานข้อมูลในโมเดลนี้
   • นักพัฒนา?
   • DBA?
   • นักวิเคราะห์ข้อมูล?
   • มากกว่าหนึ่ง?
   • โดยปกติ DBA จะอนุมัติโมเดล (ก่อนเช็คอินหรือหลังเป็นส่วนหนึ่งของการตรวจสอบโค้ด) พวกเขาเป็นเจ้าของออบเจ็กต์ที่เกี่ยวข้องกับประสิทธิภาพอย่างแน่นอน แต่โดยทั่วไปทีมงานเป็นเจ้าของ [และนายจ้างแน่นอน :)]

ฉันถือว่า SQL เป็นซอร์สโค้ดเมื่อเป็นไปได้

ถ้าฉันสามารถเขียนในSQL ที่เป็นไปตามมาตรฐานได้โดยทั่วไปแล้วมันจะไปอยู่ในไฟล์ในตัวควบคุมแหล่งที่มาของฉัน ไฟล์จะกำหนดให้มากที่สุดเช่นคำสั่ง SPs, Table CREATE

ฉันยังรวมข้อมูลจำลองสำหรับการทดสอบในการควบคุมแหล่งที่มา:

1. proj / sql / setup_db.sql
2. proj / sql / dummy_data.sql
3. proj / sql / mssql_specific.sql
4. proj / sql / mysql_specific.sql

จากนั้นฉันก็สรุปการสืบค้น SQL ทั้งหมดของฉันเพื่อที่ฉันจะสามารถสร้างโครงการทั้งหมดสำหรับ MySQL, Oracle, MSSQL หรืออย่างอื่นได้

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

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

แต่ละบิลด์มีคอลเลกชันของสคริปต์ SQL ของตัวเองที่เก็บไว้ในไดเร็กทอรี $ project \ SQL \ ในคอนโทรลซอร์สกำหนดคำนำหน้าเป็นตัวเลขและดำเนินการตามลำดับ ด้วยวิธีนี้เรากำลังฝึกฝนขั้นตอนการปรับใช้ของเราในทุกบิลด์

ทั้งนี้ขึ้นอยู่กับตารางการค้นหาค่าการค้นหาส่วนใหญ่ของเราจะถูกเก็บไว้ในสคริปต์และเรียกใช้เพื่อให้แน่ใจว่าข้อมูลการกำหนดค่าเป็นไปตามที่เราคาดหวังเช่น "เหตุผล _ รหัส" หรือ "รหัสประเทศ" ด้วยวิธีนี้เราสามารถทำการเปลี่ยนแปลงข้อมูลการค้นหาใน dev ทดสอบและจากนั้น "โปรโมต" ผ่าน QA และการผลิตแทนที่จะใช้เครื่องมือในการแก้ไขค่าการค้นหาในการผลิตซึ่งอาจเป็นอันตรายสำหรับความพร้อมในการทำงาน

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

+1 สำหรับLiquibase : LiquiBaseเป็นโอเพ่นซอร์ส (LGPL) ไลบรารีที่ไม่ขึ้นกับฐานข้อมูลสำหรับการติดตามจัดการและใช้การเปลี่ยนแปลงฐานข้อมูล สร้างขึ้นจากหลักฐานที่เรียบง่าย: การเปลี่ยนแปลงฐานข้อมูลทั้งหมด (โครงสร้างและข้อมูล) จะถูกจัดเก็บในลักษณะอธิบายตาม XML และตรวจสอบในการควบคุมแหล่งที่มา จุดดีคือการเปลี่ยนแปลง DML จะถูกจัดเก็บตามความหมายไม่ใช่แค่ความแตกต่างเพื่อให้คุณสามารถติดตามวัตถุประสงค์ของการเปลี่ยนแปลงได้

สามารถใช้ร่วมกับการควบคุมเวอร์ชันGITเพื่อการโต้ตอบที่ดีขึ้น ฉันจะกำหนดค่าสภาพแวดล้อม dev-prod ของเราเพื่อทดลองใช้

นอกจากนี้คุณยังสามารถใช้Mavenระบบสร้างAntสำหรับสร้างรหัสการผลิตจากสคริปต์

ท่าลบคือ LiquiBase ไม่ได้รวมเข้ากับ SQL IDE ที่แพร่หลายและคุณควรดำเนินการขั้นพื้นฐานด้วยตัวเอง

นอกจากนี้คุณสามารถใช้DBUnitสำหรับการทดสอบ DB - เครื่องมือนี้อนุญาตให้ใช้สคริปต์การสร้างข้อมูลสำหรับการทดสอบ env การผลิตของคุณด้วยการล้างข้อมูลหลัง

IMHO:

1. จัดเก็บ DML ในไฟล์เพื่อให้คุณสามารถกำหนดเวอร์ชันได้
2. ทำให้กระบวนการสร้างสคีมาโดยอัตโนมัติจากการควบคุมต้นทาง
3. สำหรับวัตถุประสงค์ในการทดสอบนักพัฒนาสามารถใช้ฐานข้อมูลภายในที่สร้างขึ้นจากการควบคุมต้นทางผ่านระบบบิลด์ + โหลดข้อมูลการทดสอบด้วยสคริปต์หรือสคริปต์ DBUnit (จาก Source Control)
4. LiquiBase ช่วยให้คุณสามารถจัดเตรียมสคริปต์ "รันลำดับ" เพื่อเคารพการพึ่งพา
5. ควรมีทีม DBA ที่ตรวจสอบ Master Brunch พร้อมการเปลี่ยนแปลงทั้งหมดก่อนใช้งานจริง ฉันหมายถึงพวกเขาตรวจสอบ trunk / branch จาก DBA อื่น ๆ ก่อนที่จะเข้าสู่ MASTER trunk เพื่อให้ต้นแบบนั้นมีความสม่ำเสมอและพร้อมในการผลิตเสมอ

เราประสบปัญหาที่กล่าวมาทั้งหมดเกี่ยวกับการเปลี่ยนแปลงรหัสการรวมการเขียนใหม่ในฐานข้อมูลการผลิตการเรียกเก็บเงินของเรา หัวข้อนี้เหมาะสำหรับการค้นพบสิ่งต่างๆ

การถาม "คำถามทีเซอร์" ดูเหมือนว่าคุณจะสนใจการสนทนามากกว่าความคิดเห็นของใครบางคนเกี่ยวกับคำตอบสุดท้าย รายชื่อผู้รับจดหมายagileDatabases ที่ใช้งานอยู่ (> 2500 คน) ได้ตอบคำถามเหล่านี้มากมายและจากประสบการณ์ของฉันเป็นฟอรัมที่ซับซ้อนและเป็นที่ยอมรับสำหรับการสนทนาประเภทนี้

ฉันเป็นพื้นเห็นด้วยกับคำตอบที่ได้รับจากทุกตู้ สำหรับข้อมูลเชิงลึกที่มากขึ้นพื้นฐานของฉันสำหรับการจัดการฐานข้อมูลคือชุดของ K. Scott Allen (ต้องอ่าน IMHO และดูเหมือนว่าความคิดเห็นของเจฟฟ์ด้วย)

• ออบเจ็กต์ฐานข้อมูลสามารถสร้างขึ้นใหม่ได้ตลอดเวลาโดยการเรียกใช้ไฟล์ SQL ไฟล์เดียว (ซึ่งสามารถเรียกไฟล์ SQL อื่นได้): Create.sqlSQL): ซึ่งอาจรวมถึงการแทรกข้อมูลแบบคงที่ (รายการ ... )
• สคริปต์ SQL ถูกกำหนดพารามิเตอร์เพื่อให้ไม่มีข้อมูลที่ขึ้นอยู่กับสภาพแวดล้อมและ / หรือข้อมูลที่ละเอียดอ่อนถูกเก็บไว้ในไฟล์ธรรมดา
• ฉันใช้ไฟล์แบตช์ที่กำหนดเองเพื่อเปิดCreate.sql: Create.cmd. เป้าหมายหลักคือการตรวจสอบข้อกำหนดเบื้องต้น (เครื่องมือตัวแปรสภาพแวดล้อม ... ) และส่งพารามิเตอร์ไปยังสคริปต์ SQL นอกจากนี้ยังสามารถโหลดข้อมูลคงที่จำนวนมากจากไฟล์ CSV สำหรับปัญหาด้านประสิทธิภาพ
• โดยทั่วไปข้อมูลรับรองผู้ใช้ระบบจะถูกส่งเป็นพารามิเตอร์ไปยังCreate.cmdไฟล์

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

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

• ต้องมีวิธีการดึงเวอร์ชันจากฐานข้อมูล (ฉันใช้กระบวนงานที่เก็บไว้ แต่ตารางก็ทำได้เช่นกัน)
• ก่อนปล่อยเวอร์ชันใหม่ฉันสร้างUpgrade.sqlไฟล์ (ที่สามารถเรียกไฟล์อื่นได้) ที่อนุญาตให้อัปเกรดเวอร์ชัน N-1 เป็นเวอร์ชัน N (N ซึ่งเป็นเวอร์ชันที่ออก) ฉันเก็บสคริปต์นี้ไว้ในโฟลเดอร์ชื่อN-1ฉันเก็บสคริปต์นี้ภายใต้โฟลเดอร์ชื่อ
• ฉันมีไฟล์แบตช์ที่อัปเกรด: Upgrade.cmd. สามารถดึงข้อมูลเวอร์ชันปัจจุบัน (CV) ของฐานข้อมูลผ่านคำสั่ง SELECT แบบธรรมดาเรียกใช้Upgrade.sqlสคริปต์ที่เก็บไว้ในCVโฟลเดอร์และวนซ้ำจนกว่าจะไม่พบโฟลเดอร์ ด้วยวิธีนี้คุณสามารถอัปเกรดจากพูด N-3 เป็น N ได้โดยอัตโนมัติ

ปัญหานี้คือ:

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

คุณต้องการให้วัตถุฐานข้อมูลประเภทใดอยู่ภายใต้การควบคุมแหล่งที่มา ฉันจะพูดให้มากที่สุด แต่ไม่มาก ;-) หากคุณต้องการสร้างผู้ใช้ด้วยรหัสผ่านให้รับรหัสผ่านเริ่มต้น (เข้าสู่ระบบ / เข้าสู่ระบบซึ่งเป็นประโยชน์สำหรับวัตถุประสงค์ในการทดสอบหน่วย) และเปลี่ยนรหัสผ่านเป็นการดำเนินการด้วยตนเอง . สิ่งนี้เกิดขึ้นมากมายกับ Oracle โดยที่ schemas ยังเป็นผู้ใช้ ...

เรามีโครงการ Silverlight พร้อมฐานข้อมูล MSSQL ในการควบคุมเวอร์ชัน Git วิธีที่ง่ายที่สุดคือตรวจสอบให้แน่ใจว่าคุณมีฐานข้อมูลที่บางลง (เนื้อหาที่ชาญฉลาด) และทำการถ่ายโอนข้อมูลทั้งหมดจาก fe Visual Studio จากนั้นคุณสามารถทำ 'sqlcmd' จากบิลด์สคริปต์ของคุณเพื่อสร้างฐานข้อมูลใหม่ในเครื่อง dev แต่ละเครื่อง

สำหรับการปรับใช้นี้เป็นไปไม่ได้เนื่องจากฐานข้อมูลมีขนาดใหญ่เกินไปนั่นเป็นเหตุผลหลักที่ทำให้มีฐานข้อมูลอยู่ในฐานข้อมูลตั้งแต่แรก

ฉันเชื่ออย่างยิ่งว่า DB ควรเป็นส่วนหนึ่งของการควบคุมแหล่งที่มาและเป็นส่วนหนึ่งของกระบวนการสร้าง ถ้ามันอยู่ในการควบคุมแหล่งที่มาฉันก็มีเซฟการ์ดเข้ารหัสเหมือนกันเมื่อเขียนโพรซีเดอร์ที่เก็บไว้ใน SQL เหมือนกับที่ฉันทำเมื่อเขียนคลาสใน C # ฉันทำได้โดยรวมไดเร็กทอรีสคริปต์ DB ไว้ใต้แผนผังซอร์สของฉัน ไดเร็กทอรีสคริปต์นี้ไม่จำเป็นต้องมีไฟล์เดียวสำหรับอ็อบเจ็กต์เดียวในฐานข้อมูล ที่จะปวดก้น! ฉันพัฒนาในฐานข้อมูลของฉันเพียงแค่ในโครงการรหัสของฉัน จากนั้นเมื่อฉันพร้อมที่จะเช็คอินฉันจะสร้างความแตกต่างระหว่างเวอร์ชันล่าสุดของฐานข้อมูลของฉันกับเวอร์ชันปัจจุบันที่ฉันกำลังทำงานอยู่ ฉันใช้ SQL Compare สำหรับสิ่งนี้และสร้างสคริปต์ของการเปลี่ยนแปลงทั้งหมด จากนั้นสคริปต์นี้จะถูกบันทึกลงในไดเร็กทอรี db_update ของฉันด้วยหลักการตั้งชื่อเฉพาะ 1234_TasksCompletedInThisIteration โดยที่ตัวเลขนี้เป็นตัวเลขถัดไปในชุดของสคริปต์ที่มีอยู่แล้วและชื่อจะอธิบายถึงสิ่งที่กำลังทำในการเช็คอินนี้ฉันทำแบบนี้เพราะเป็น ส่วนหนึ่งของกระบวนการสร้างของฉันฉันเริ่มต้นด้วยฐานข้อมูลใหม่ที่สร้างขึ้นโดยใช้โปรแกรมโดยใช้สคริปต์ในไดเร็กทอรีนี้ ฉันเขียนงาน NAnt ที่กำหนดเองซึ่งวนซ้ำผ่านแต่ละสคริปต์ที่เรียกใช้เนื้อหาบนฐานข้อมูลเปล่า เห็นได้ชัดว่าถ้าฉันต้องการข้อมูลเพื่อเข้าสู่ฐานข้อมูลฉันก็มีสคริปต์แทรกข้อมูลด้วย ซึ่งก็มีประโยชน์มากมายเช่นกันค่ะ หนึ่งข้อมูลทั้งหมดของฉันเป็นเวอร์ชัน สองแต่ละบิลด์เป็นงานสร้างใหม่ซึ่งหมายความว่าจะไม่มีสิ่งที่แอบแฝงเข้ามาในกระบวนการพัฒนาของฉัน (เช่นข้อมูลสกปรกที่ทำให้เกิดความผิดปกติในระบบ) สามเมื่อมีการเพิ่มคนใหม่ในทีม dev พวกเขาเพียงแค่ต้องได้รับข้อมูลล่าสุดและนักพัฒนาในพื้นที่ของพวกเขาถูกสร้างขึ้นสำหรับพวกเขาทันที สี่ฉันสามารถเรียกใช้กรณีทดสอบ (ฉันไม่ได้เรียกว่า "การทดสอบหน่วย"!) บนฐานข้อมูลของฉันเนื่องจากสถานะของฐานข้อมูลถูกรีเซ็ตในแต่ละบิลด์ (หมายความว่าฉันสามารถทดสอบที่เก็บของฉันได้โดยไม่ต้องกังวลเกี่ยวกับการเพิ่มข้อมูลทดสอบลงใน db)

นี่ไม่ใช่สำหรับทุกคน

นี่ไม่ใช่สำหรับทุกโครงการ ฉันมักจะทำงานในโครงการสนามสีเขียวซึ่งช่วยให้ฉันสะดวก!

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

การสร้างฐานข้อมูลตั้งแต่เริ่มต้นสามารถสรุปได้เป็นการจัดการสคริปต์ sql

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

จากนั้นจะรวบรวมสคริปต์ที่จำเป็นทั้งหมดเข้าด้วยกันและเรียกใช้ จากนั้นจะบันทึกว่าสคริปต์ใดถูกเรียกใช้

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

ดูคำแนะนำที่ดีที่นี่:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

คุณอาจพบว่าLiquibase สามารถจัดการกับสิ่งที่คุณกำลังมองหาได้มากมาย

นักพัฒนาทุกคนควรมีฐานข้อมูลในเครื่องของตนเองและใช้การควบคุมซอร์สโค้ดเพื่อเผยแพร่ไปยังทีม ทางออกของฉันอยู่ที่นี่: http://dbsourcetools.codeplex.com/ ขอให้สนุก - นาธาน