เป็นวิธีที่ดีในการโยกย้ายการเปลี่ยนแปลงฐานข้อมูลจากการพัฒนาเพื่อ QA ไปยังสภาพแวดล้อมการผลิตคืออะไร? ขณะนี้เรา:

1. สคริปต์การเปลี่ยนแปลงในไฟล์ SQL และแนบกับไอเท็มงาน TFS
2. การทำงานคือการตรวจสอบโดยเพื่อน
3. เมื่องานพร้อมสำหรับการทดสอบ SQL จะทำงานบน QA
4. งานทดสอบ QA
5. เมื่องานพร้อมสำหรับการผลิตแล้ว SQL จะทำงานบนฐานข้อมูลการผลิต

ปัญหาของเรื่องนี้คือมันเป็นคู่มือมาก มันขึ้นอยู่กับนักพัฒนาที่จำได้ว่าจะแนบ sql หรือผู้ตรวจทานเพื่อนจับมันถ้านักพัฒนาลืม บางครั้งมันก็กลายเป็นผู้ทดสอบหรือปรับใช้ QA ที่พบปัญหา

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

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

ฉันคุ้นเคยกับระบบควบคุมซอร์สของฉันมากที่ดูแลเรื่องนี้ให้ฉันและอยากให้ SQL ของฉันเหมือนกัน

ในสภาพแวดล้อมแบบ VS ฉันมักใช้โครงการฐานข้อมูลเพื่อใช้สคริปต์การอัปเดต ฉันมักจะใช้ชื่อ unimaginative เช่น "DatabaseUpdate17.sql" หรือ "PriceUpdateFonne2010.sql" สำหรับสคริปต์ของฉัน มีพวกเขาเป็นโครงการฐานข้อมูลให้ฉันผูกพวกเขาไปที่ทีมงานเซิร์ฟเวอร์ข้อบกพร่อง (และถ้าเราได้ตรวจสอบรหัสเพื่อพวกเขาเช่นกัน) ฉันยังรวมอยู่ในแต่ละฐานข้อมูล (ที่ฉันมีสิทธิ์) ตารางโดยเฉพาะสำหรับการรวบรวมการเปลี่ยนแปลงสคีมา

CREATE TABLE [dbo].[AuditDDL](
    [EventID] [int] IDENTITY(1,1) PRIMARY KEY NOT NULL,
    [EventData] [xml] NULL,                    -- what did they do
    [EventUser] varchar(100) NOT NULL,         -- who did it
    [EventTime] [datetime] DEFAULT (getdate()) -- when did they do it
    )
GO

ดีที่จะดูแลใน 3 ของ6 Ws

CREATE TRIGGER [trgAuditDDL]
ON DATABASE 
FOR DDL_DATABASE_LEVEL_EVENTS 
AS
INSERT INTO AuditDDL(EventData, EventUser)
SELECT EVENTDATA(), original_login()
GO

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

ตัวอย่างเช่นการแทรก "start patch" สำหรับ "patch 17" จะมีลักษณะดังนี้:

INSERT INTO [dbo].[AuditDDL]
           ([EventData]
           ,[EventUser])
     VALUES
           ('<EVENT_INSTANCE><EventType>BEGIN PATCH 17</EventType></EVENT_INSTANCE>'
           ,ORIGINAL_LOGIN())
GO

เนื่องจากมันยังจับได้เมื่อสร้างดัชนีใหม่คุณจะต้องเรียกใช้สิ่งต่อไปนี้ทุกเดือนเพื่อล้างกิจกรรมเหล่านั้น:

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"ALTER_INDEX")]') =1
GO

DELETE FROM AuditDDL
WHERE [EventData].exist('/EVENT_INSTANCE/EventType/text()[fn:contains(.,"UPDATE_STATISTICS")]') =1
GO

รุ่นก่อนหน้านี้โพสต์ก่อนหน้านี้บนเซิร์ฟเวอร์ผิดพลาด

ในสภาพแวดล้อมที่สอดคล้องกับ SOX และ PCI-DSS คุณจะไม่สามารถเข้าถึงเซิร์ฟเวอร์ที่ใช้งานจริงได้ ดังนั้นสคริปต์จะต้องชัดเจนและฝึกซ้อมล่วงหน้า ความคิดเห็นที่ด้านบนของสคริปต์อัปเดตประกอบด้วยรายการของตารางใหม่ procs ที่เก็บไว้ฟังก์ชั่น ฯลฯ รวมถึงรายการของตารางที่ถูกปรับเปลี่ยน procs ที่เก็บไว้ฟังก์ชั่น ฯลฯ หากข้อมูลได้รับการแก้ไขให้อธิบายสิ่งที่กำลังแก้ไข

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

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

คุณเคยดูที่การควบคุมแหล่งที่มาของ SQL? คุณสามารถใช้มันเพื่อเชื่อมต่อ SQL Server ของคุณกับ TFS / SVN / Vault หรือ VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

อีกวิธีคือใช้ PowerDesigner, ERWin และอื่น ๆ เพื่อออกแบบและจัดการการเปลี่ยนแปลงฐานข้อมูลของคุณ

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

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

(ฉันไม่มีส่วนเกี่ยวข้องกับ Sybase ซึ่งเป็นผู้พัฒนา PowerDesigner - แค่คิดว่าฉันจะทิ้งเรื่องนี้ไว้)

DB Ghost

DB Ghostเป็นเครื่องมือที่ฉันโปรดปรานสำหรับการจัดการฐานข้อมูล

ประโยชน์ที่ได้รับ

1. วัตถุทั้งหมดในฐานข้อมูลของคุณจะถูกเก็บไว้เป็นสคริปต์ในการควบคุมแหล่งที่มา
2. คุณสามารถสคริปต์ 'ข้อมูลคงที่' (ข้อมูลตารางการค้นหา) ได้เช่นกัน
3. คุณสามารถอัปเดตการควบคุมแหล่งข้อมูลด้วยตนเองหรือโดยการเขียนสคริปต์ฐานข้อมูลการพัฒนา 'รุ่น'
4. คุณสามารถสร้างฐานข้อมูล (อย่างรวดเร็ว) จากสคริปต์ในการควบคุมแหล่งที่มา (รวมถึงข้อมูลคงที่)
5. คุณสามารถปรับใช้การเปลี่ยนแปลงกับอินสแตนซ์ของฐานข้อมูลรวมถึงอินสแตนซ์ที่ใช้งานจริง:
   • คุณสามารถเปรียบเทียบ 'สร้างฐานข้อมูล' (สร้างจากสคริปต์) กับฐานข้อมูลที่มีอยู่และสร้างสคริปต์การเปลี่ยนแปลง
   • คุณสามารถสั่งให้ DB Ghost ทำการซิงค์การเปลี่ยนแปลงโดยอัตโนมัติระหว่างสองอินสแตนซ์ของฐานข้อมูลเช่นฐานข้อมูลการสร้างและฐานข้อมูลการผลิตของคุณ

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

รายละเอียด

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

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

ฉันแค่หวังว่าจะมีเครื่องมือที่คล้ายกันสำหรับ DBMS อื่น ๆ

ฉันรู้ว่ามันฟังดูเกินจริงกับ DBA ส่วนใหญ่:

คุณได้พิจารณาใช้ Ruby on Rails เพื่อติดตามการเปลี่ยนแปลงฐานข้อมูล (และเฉพาะการเปลี่ยนแปลงฐานข้อมูล) คุณไม่จำเป็นต้องเรียกใช้แอพใด ๆ หรือเขียนรหัสทับทิมเป็นต้น แต่ฉันพบว่ารูปแบบการย้ายข้อมูล (นั่นคือวิธีที่พวกเขาเรียกมันว่า) มีประโยชน์มาก: http://guides.rubyonrails.org/migrations.html

รองรับ sql Server คุณอาจต้องใช้ JRuby + JDBC