Was ist ein guter Weg, um DB-Änderungen von der Entwicklung über die Qualitätssicherung in Produktionsumgebungen zu migrieren? Derzeit sind wir:

1. Schreiben Sie die Änderung per Skript in eine SQL-Datei und hängen Sie sie an ein TFS-Arbeitselement an.
2. Die Arbeit wird von Fachleuten begutachtet
3. Wenn die Arbeit zum Testen bereit ist, wird SQL auf QA ausgeführt.
4. Die Arbeit ist QS-geprüft
5. Wenn die Arbeit produktionsbereit ist, wird SQL auf den Produktionsdatenbanken ausgeführt.

Das Problem dabei ist, dass es sehr manuell ist. Der Entwickler muss daran denken, den SQL-Code beizufügen, oder der Peer-Reviewer muss ihn abfangen, wenn der Entwickler dies vergisst. Manchmal ist es der Tester oder QS-Bereitsteller, der das Problem entdeckt.

Ein sekundäres Problem ist, dass Sie manchmal Änderungen manuell koordinieren müssen, wenn zwei separate Aufgaben dasselbe Datenbankobjekt ändern. Dies mag einfach so sein, aber es scheint immer noch so, als ob es eine automatisierte Möglichkeit geben sollte, diese Probleme zu "markieren" oder so.

Unser Setup: Unser Development-Shop ist voll von Entwicklern mit viel DB-Erfahrung. Unsere Projekte sind sehr DB-orientiert. Wir sind hauptsächlich ein .NET und MS SQL Shop. Derzeit verwenden wir MS TFS Work Items, um unsere Arbeit zu verfolgen. Dies ist praktisch für Codeänderungen, da hiermit die Änderungssätze mit den Arbeitselementen verknüpft werden, sodass ich genau herausfinden kann, welche Änderungen ich bei der Migration zu QS- und Produktionsumgebungen berücksichtigen muss. Wir verwenden derzeit kein DB-Projekt, werden aber möglicherweise in Zukunft darauf umsteigen (vielleicht ist das ein Teil der Antwort).

Ich bin sehr daran gewöhnt, dass mein Quellcodeverwaltungssystem solche Dinge für mich erledigt, und möchte dasselbe für mein SQL haben.

In einer VS-Umgebung habe ich immer Datenbankprojekte verwendet, um die Aktualisierungsskripten zu implementieren. Ich neige dazu, einfallslose Namen wie "DatabaseUpdate17.sql" oder "PriceUpdateFebruary2010.sql" für meine Skripte zu verwenden. Wenn ich sie als Datenbankprojekte habe, kann ich sie mit Team Server-Aufgaben und -Bugs verknüpfen (und, wenn wir Codeprüfungen durchgeführt haben, auch mit ihnen). Außerdem füge ich in jede Datenbank (für die ich die Berechtigung habe) eine Tabelle ein, die speziell für die Sammlung von Änderungen am Schema vorgesehen ist.

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

Nun, das kümmert sich um 3 der 6 Ws .

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

Ich füge eine insert-Anweisung ein, um den Beginn eines Patches sowie das Ende eines Patches zu protokollieren. Ereignisse, die außerhalb von Patches stattfinden, müssen untersucht werden.

Zum Beispiel würde eine "Start Patch" -Einfügung für "Patch 17" so aussehen:

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

Da es auch bei der Neuerstellung von Indizes auffällt, müssen Sie etwa jeden Monat die folgenden Aktionen ausführen, um diese Ereignisse zu löschen:

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

Frühere Version, die zuvor bei Server Fault veröffentlicht wurde .

In einer SOX- und PCI-DSS-kompatiblen Umgebung haben Sie niemals Zugriff auf die Produktionsserver. Daher müssen die Skripte vorher klar sein und geübt werden. Die Kommentare oben in den Aktualisierungsskripten enthalten Listen mit neuen Tabellen, gespeicherten Prozessen, Funktionen usw. sowie Listen mit geänderten Tabellen, gespeicherten Prozessen, Funktionen usw. Wenn Daten geändert werden, erläutern Sie, was und warum geändert wird.

Ein sekundäres Problem ist, dass Sie manchmal Änderungen manuell koordinieren müssen, wenn zwei separate Aufgaben dasselbe Datenbankobjekt ändern. Dies mag einfach so sein, aber es scheint immer noch so, als ob es eine automatisierte Möglichkeit geben sollte, diese Probleme zu "markieren" oder so.

Ich bin noch nie auf ein Tool gestoßen, mit dem wir dies automatisch verfolgen können. Vorherige Arbeitgeber verwendeten den Grundsatz des "Datenbankbesitzers" - eine und nur eine Person, die persönlich für die Datenbank verantwortlich ist. Diese Person wird nicht der einzige Entwickler sein, der mit dieser Datenbank arbeitet, sondern alle Änderungen müssen sie durchlaufen. Dies hat einigermaßen gut funktioniert, um zu verhindern, dass Änderungen kollidieren und sich gegenseitig beschädigen.

Haben Sie sich die SQL-Quellcodeverwaltung angesehen? Sie können damit Ihren SQL Server mit TFS / SVN / Vault oder VSS verbinden - http://www.red-gate.com/products/sql-development/sql-source-control/

Eine andere Lösung ist die Verwendung von PowerDesigner, ERWin usw. zum Entwerfen und Verwalten von Änderungen an Ihrer Datenbank.

Wir beginnen mit dem Übergang zu einer Richtlinie, bei der Datenbanken in PowerDesigner modelliert werden. Alle Änderungen an der Datenbankstruktur / am Code werden im Modell vorgenommen, in die Quellcodeverwaltung eingecheckt und anschließend werden Änderungsskripten aus den Modellen generiert, um die Änderungen in der Datenbank zu implementieren. Diese Änderungsskripte werden auch in die Quellcodeverwaltung eingecheckt. Große Änderungen werden von Fachleuten überprüft, und PowerDesigner vereinfacht dies mithilfe integrierter Funktionen.

PowerDesigner ist ein generisches Modellierungstool, das mehr als nur Datenbanken unterstützt. Wir beginnen, es zum Verwalten von Anforderungen, Erstellen von konzeptuellen, physischen und Architekturdiagrammen (auch OOMs) usw. zu verwenden Software-Engineering-Prozess.

(Ich bin in keiner Weise mit Sybase verbunden, der PowerDesigner entwickelt hat - dachte nur, ich würde das da reinwerfen).

DB Ghost

DB Ghost ist mein Lieblingswerkzeug für die Verwaltung von Datenbanken.

Leistungen

1. Alle Objekte in Ihrer Datenbank werden als Skripte in der Quellcodeverwaltung gespeichert.
2. Sie können auch 'statische Daten' (Nachschlagetabellendaten) skripten.
3. Sie können die Quellcodeverwaltung manuell aktualisieren oder ein Skript für eine Modellentwicklungsdatenbank erstellen.
4. Sie können bauen eine Datenbank (schnell) aus den Skripten in der Quellcodeverwaltung (einschließlich statischen Daten).
5. Sie können Änderungen an Instanzen der Datenbank bereitstellen , einschließlich Produktionsinstanzen:
   • Sie können eine (aus den Skripten erstellte) 'Build-Datenbank' mit einer vorhandenen Datenbank vergleichen und ein Änderungsskript generieren.
   • Sie können DB Ghost anweisen, Änderungen zwischen zwei Instanzen der Datenbank, z. B. einer Build-Datenbank und Ihrer Produktionsdatenbank, automatisch zu synchronisieren.

[4] ist besonders praktisch, um lokale Änderungen vorzunehmen oder separate Instanzen für verschiedene Umgebungen zu erstellen. Tatsächlich ist es so einfach, dass ich für jede Funktion oder jeden Fehler, an dem ich arbeite und der sich auf eine Datenbank auswirkt, eine separate Datenbank erstelle.

Einzelheiten

Der Hauptvorteil gegenüber der Verwaltung expliziter Änderungs- oder Migrationsskripten besteht darin, dass Sie meist keine expliziten Änderungs- oder Migrationsskripten verwalten müssen - Sie können meist nur die 'aktuelle' Version Ihrer Datenbank verwalten. Ein ärgerlicher Aspekt beim Verwalten von Migrationsskripten ist, dass es keine einfache Möglichkeit gibt, diese anzuzeigen, z. B. eine Liste von Spalten in einer Tabelle (basierend auf den Migrationsskripten). Natürlich müssen einige Änderungen als explizite Migrationen vorgenommen werden, aber sie sind einfach genug, um als separate Skripte behandelt zu werden.

Eine besonders schöne Folge der Möglichkeit, Datenbanken als (eine Reihe von) Skripten zu verwalten und auch neue Instanzen schnell zu erstellen, ist, dass das Testen wichtiger Datenbankcodes durch das Testen von Einheiten sehr einfach ist (und auch ziemlich viel Spaß macht). Ich benutze tSQLt für Unit-Tests.

Ich wünschte nur, es gäbe ein ähnliches Tool für andere DBMS.

Ich weiß, dass es für die meisten DBAs übertrieben klingt:

Haben Sie darüber nachgedacht, Ruby on Rails zu verwenden, um die Datenbankänderungen (und nur die DB-Änderungen) zu verfolgen? Sie müssen keine App ausführen oder Ruby-Code schreiben usw. Aber ich fand den Migrationsstil (so nennen sie ihn) sehr nützlich: http://guides.rubyonrails.org/migrations.html

SQL Server wird ebenfalls unterstützt, möglicherweise müssen Sie jedoch JRuby + JDBC verwenden.