Qual è un buon modo per migrare le modifiche al DB dallo sviluppo al QA in ambienti di produzione? Attualmente noi:

1. Script la modifica in un file SQL e allegarlo a un elemento di lavoro TFS.
2. Il lavoro è sottoposto a revisione paritaria
3. Quando il lavoro è pronto per il test, l'SQL viene eseguito sul QA.
4. Il lavoro è testato per il controllo qualità
5. Quando il lavoro è pronto per la produzione, l'SQL viene eseguito sui database di produzione.

Il problema è che è molto manuale. Fa affidamento sul fatto che lo sviluppatore si ricordi di allegare sql o il peer-reviewer che lo prende se lo sviluppatore dimentica. A volte, finisce per essere il tester o il responsabile del QA che scopre il problema.

Un problema secondario è che a volte si finisce per dover coordinare manualmente le modifiche se due attività separate cambiano lo stesso oggetto di database. Potrebbe essere così, ma sembra che ci dovrebbe essere un modo automatizzato di "segnalare" questi problemi o qualcosa del genere.

La nostra configurazione: il nostro negozio di sviluppo è pieno di sviluppatori con molta esperienza DB. I nostri progetti sono molto orientati al DB. Siamo principalmente un negozio .NET e MS SQL. Attualmente stiamo utilizzando MS TFS Work Items per tracciare il nostro lavoro. Questo è utile per le modifiche al codice perché collega i changeset agli elementi di lavoro in modo che io possa scoprire esattamente quali cambiamenti devo includere durante la migrazione agli ambienti QA e Production. Al momento non stiamo usando un progetto DB ma potremmo passare a quello in futuro (forse questo fa parte della risposta).

Sono molto abituato al mio sistema di controllo del codice sorgente a occuparmi di cose del genere per me e vorrei avere la stessa cosa per il mio SQL.

In un ambiente VS, ho sempre usato progetti di database per implementare gli script di aggiornamento. Tendo a usare nomi privi di fantasia come "DatabaseUpdate17.sql" o "PriceUpdateFebruary2010.sql" per i miei script. Avendoli come progetti di database mi consente di collegarli alle attività di Team Server, ai bug (e se abbiamo fatto anche delle revisioni del codice). Includo anche in ogni database (di cui ho autorità) una tabella specifica per la raccolta di modifiche allo schema.

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

Beh, che si occupa di 3 dei 6 Ws .

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

Includo un'istruzione insert per registrare l'inizio di una patch e la fine di una patch. Gli eventi che si verificano al di fuori delle patch sono elementi da esaminare.

Ad esempio, un inserto "inizio patch" per "patch 17" dovrebbe apparire come:

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

Dal momento che rileva anche quando gli indici vengono ricostruiti, dovrai eseguire ogni mese circa per eliminare quegli eventi:

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

Versione precedente precedentemente pubblicata su Server Fault .

In un ambiente conforme a SOX e PCI-DSS, non si avrà mai accesso ai server di produzione. Pertanto gli script devono essere chiari ed esercitati in anticipo. I commenti nella parte superiore degli script di aggiornamento includono elenchi di nuove tabelle, processi memorizzati, funzioni, ecc. Nonché elenchi di tabelle modificate, processi memorizzati, funzioni, ecc. Se i dati vengono modificati, spiegare cosa viene modificato e perché.

Un problema secondario è che a volte si finisce per dover coordinare manualmente le modifiche se due attività separate cambiano lo stesso oggetto di database. Potrebbe essere così, ma sembra che ci dovrebbe essere un modo automatizzato di "segnalare" questi problemi o qualcosa del genere.

Non ho mai trovato uno strumento che ci permetta di rintracciarlo automaticamente. I precedenti datori di lavoro utilizzavano un principio di "proprietario del database" - una e una sola persona che è personalmente responsabile del database. Questa persona non sarà l'unico sviluppatore che lavora contro quel database, ma piuttosto tutte le modifiche devono passare attraverso di loro. Questo ha funzionato ragionevolmente bene per evitare che i cambiamenti si scontrino e si danneggino.

Hai visto il controllo del codice sorgente SQL? Puoi usarlo per connettere il tuo SQL Server a TFS / SVN / Vault o VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Un'altra soluzione è utilizzare qualcosa come PowerDesigner, ERWin, ecc. Per progettare e gestire le modifiche al database.

Stiamo iniziando a passare a una politica in cui i database sono modellati in PowerDesigner. Tutte le modifiche alla struttura / al codice del database vengono eseguite nel modello, controllate nel controllo del codice sorgente e quindi gli script di modifica vengono generati dai modelli per implementare le modifiche nel database. Anche questi script di modifica vengono archiviati nel controllo del codice sorgente. Grandi cambiamenti sono sottoposti a peer review e PowerDesigner lo rende molto semplice grazie alle funzionalità integrate.

PowerDesigner è uno strumento di modellazione generico che supporta più di semplici database, quindi stiamo iniziando a usarlo per gestire i requisiti, creare diagrammi concettuali, fisici e di architettura (anche quelli di OOM), ecc. Fondamentalmente, lo stiamo usando per fornire la struttura portante al nostro processo di ingegneria del software.

(Non sono in alcun modo affiliato con Sybase, che ha sviluppato PowerDesigner - ho pensato di buttarlo lì).

DB Ghost

DB Ghost è il mio strumento preferito per la gestione di database.

Benefici

1. Tutti gli oggetti nel database sono memorizzati come script nel controllo del codice sorgente.
2. Puoi anche scrivere "dati statici" (dati della tabella di ricerca).
3. È possibile aggiornare il controllo del codice sorgente manualmente o tramite script di un database di sviluppo "modello".
4. È possibile creare un database (rapidamente) dagli script nel controllo del codice sorgente (inclusi i dati statici).
5. È possibile distribuire le modifiche alle istanze del database, comprese tutte le istanze di produzione:
   • È possibile confrontare un "database di build" (creato dagli script) con un database esistente e generare uno script di modifica.
   • È possibile indirizzare DB Ghost per sincronizzare automaticamente le modifiche tra due istanze del database, ad esempio un database di build e il database di produzione.

[4] è particolarmente utile per apportare modifiche locali o creare istanze separate per ambienti diversi. In effetti è così facile che creo un database separato per ogni funzione o bug su cui lavoro che abbia un impatto su un database.

Dettagli

Il vantaggio principale di usarlo rispetto al mantenimento di script di migrazione o modifica espliciti è che per lo più non è necessario mantenere script di migrazione o modifica espliciti - si può principalmente mantenere solo la "versione corrente" del database. Un aspetto fastidioso della gestione degli script di migrazione è che non esiste un modo semplice per visualizzare, ad esempio un elenco di colonne in una tabella (basato sugli script di migrazione). Naturalmente alcune modifiche devono essere apportate come migrazioni esplicite, ma sono abbastanza facili da gestire come script separati.

Una conseguenza particolarmente piacevole di essere in grado di gestire i database come (un insieme) di script e anche di poter creare rapidamente nuove istanze è che test di unità di codice di database importante è molto semplice (e anche abbastanza divertente). Uso tSQLt per test unitari.

Vorrei solo che esistesse uno strumento simile per altri DBMS.

So che sembra eccessivo per la maggior parte dei DBA:

Hai preso in considerazione l'utilizzo di Ruby on Rails per tenere traccia delle modifiche al database (e solo delle modifiche al database). Non è necessario eseguire alcuna app o scrivere alcun codice ruby ​​ecc. Ma ho trovato che lo stile delle migrazioni (è così che lo chiamano) è abbastanza utile: http://guides.rubyonrails.org/migrations.html

Sql Server è anche supportato, potrebbe essere necessario utilizzare JRuby + JDBC però.