Quelle est la bonne façon de migrer les modifications de base de données du développement vers le contrôle qualité vers les environnements de production? Actuellement, nous:

1. Scriptez la modification dans un fichier SQL et associez-la à un élément de travail TFS.
2. Le travail est évalué par des pairs
3. Lorsque le travail est prêt pour les tests, le SQL est exécuté sur QA.
4. Le travail est testé QA
5. Lorsque le travail est prêt pour la production, le SQL est exécuté sur les bases de données de production.

Le problème est que c'est très manuel. Il repose sur le développeur qui se souvient de joindre le sql ou le peer-reviewer le rattrapant si le développeur oublie. Parfois, il finit par être le testeur ou le déployeur d'AQ qui découvre le problème.

Un problème secondaire est que vous finissez parfois par devoir coordonner manuellement les modifications si deux tâches distinctes modifient le même objet de base de données. C'est peut-être juste ainsi, mais il semble toujours qu'il devrait y avoir un moyen automatisé de «signaler» ces problèmes ou quelque chose.

Notre configuration: Notre boutique de développement est pleine de développeurs avec beaucoup d'expérience DB. Nos projets sont très orientés DB. Nous sommes principalement une boutique .NET et MS SQL. Actuellement, nous utilisons des éléments de travail MS TFS pour suivre notre travail. Ceci est pratique pour les modifications de code car il relie les ensembles de modifications aux éléments de travail afin que je puisse savoir exactement quelles modifications je dois inclure lors de la migration vers les environnements QA et Production. Nous n'utilisons pas actuellement un projet de base de données, mais nous pourrions y basculer à l'avenir (cela fait peut-être partie de la réponse).

Je suis très habitué à ce que mon système de contrôle de source s'occupe de ce genre de choses pour moi et j'aimerais avoir la même chose pour mon SQL.

Dans un environnement VS, j'ai toujours utilisé des projets de base de données pour implémenter les scripts de mise à jour. J'ai tendance à utiliser des noms peu imaginatifs comme "DatabaseUpdate17.sql" ou "PriceUpdateF February2010.sql" pour mes scripts. Les avoir comme projets de base de données me permet de les lier aux tâches de Team Server, aux bogues (et si nous avons fait des révisions de code, à eux aussi). J'inclus également dans chaque base de données (sur laquelle j'ai autorité) une table spécifiquement pour la collecte des modifications du schéma.

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

Eh bien, qui prend soin de 3 des 6 Ws .

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

J'inclus une instruction d'insertion pour enregistrer le début d'un correctif ainsi que la fin d'un correctif. Les événements qui se produisent en dehors des correctifs sont des éléments à examiner.

Par exemple, un insert "begin patch" pour "patch 17" ressemblerait à:

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

Puisqu'il se déclenche également lorsque les indices sont reconstruits, vous devrez exécuter les éléments suivants tous les mois environ pour effacer ces événements:

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

Version antérieure précédemment publiée sur Server Fault .

Dans un environnement compatible SOX et PCI-DSS, vous n'aurez jamais accès aux serveurs de production. Par conséquent, les scripts doivent être clairs et exercés au préalable. Les commentaires en haut des scripts de mise à jour incluent des listes de nouvelles tables, procs stockés, fonctions, etc. ainsi que des listes de tables modifiées, procs stockés, fonctions, etc. Si les données sont modifiées, expliquez ce qui est modifié et pourquoi.

Un problème secondaire est que vous finissez parfois par devoir coordonner manuellement les modifications si deux tâches distinctes modifient le même objet de base de données. C'est peut-être juste ainsi, mais il semble toujours qu'il devrait y avoir un moyen automatisé de «signaler» ces problèmes ou quelque chose.

Je n'ai jamais rencontré d'outil qui nous permette de suivre cela automatiquement. Les employeurs précédents utilisaient le principe du "propriétaire de la base de données" - une et une seule personne qui est personnellement responsable de la base de données. Cette personne ne sera pas le seul développeur à travailler sur cette base de données, mais toutes les modifications doivent plutôt les traverser. Cela a fonctionné assez bien pour empêcher les changements d'entrer en collision et de s'endommager.

Avez-vous regardé le contrôle de code source SQL? Vous pouvez l'utiliser pour connecter votre serveur SQL à TFS / SVN / Vault ou VSS - http://www.red-gate.com/products/sql-development/sql-source-control/

Une autre solution consiste à utiliser quelque chose comme PowerAMC, ERWin, etc. pour concevoir et gérer les modifications apportées à votre base de données.

Nous commençons à passer à une politique où les bases de données sont modélisées dans PowerAMC. Toutes les modifications apportées à la structure / au code de la base de données sont effectuées dans le modèle, archivées dans le contrôle de code source, puis des scripts de modification sont générés à partir des modèles pour implémenter les modifications dans la base de données. Ces scripts de modification sont également archivés dans le contrôle de code source. Les modifications importantes sont examinées par des pairs et PowerAMC ​​facilite grandement l'utilisation des fonctionnalités intégrées.

PowerAMC ​​est un outil de modélisation générique prenant en charge plus que de simples bases de données. Nous commençons donc à l'utiliser pour gérer les exigences, créer des diagrammes conceptuels, physiques et architecturaux (MOO aussi), etc. Fondamentalement, nous l'utilisons pour fournir l'épine dorsale à notre processus de génie logiciel.

(Je ne suis en aucun cas affilié à Sybase, qui a développé PowerAMC ​​- je pensais juste que j'y mettrais ça).

DB Ghost

DB Ghost est mon outil préféré pour gérer les bases de données.

Avantages

1. Tous les objets de votre base de données sont stockés sous forme de scripts dans le contrôle de code source.
2. Vous pouvez également écrire des «données statiques» (données de la table de recherche).
3. Vous pouvez mettre à jour le contrôle de code source manuellement ou en scriptant une base de données de développement «modèle».
4. Vous pouvez créer une base de données (rapidement) à partir des scripts dans le contrôle de code source (y compris les données statiques).
5. Vous pouvez déployer des modifications sur des instances de la base de données, y compris toutes les instances de production:
   • Vous pouvez comparer une «base de données de construction» (créée à partir des scripts) à une base de données existante et générer un script de changement.
   • Vous pouvez demander à DB Ghost de synchroniser automatiquement les modifications entre deux instances de la base de données, par exemple une base de données de génération et votre base de données de production.

[4] est particulièrement pratique pour effectuer des modifications locales ou créer des instances distinctes pour différents environnements. En fait, c'est si facile que je crée une base de données distincte pour chaque fonctionnalité ou bug sur lequel je travaille et qui affecte une base de données.

Détails

Le principal avantage de l' utiliser sur le maintien de changement explicite ou migration des scripts est que vous la plupart du temps ne pas besoin de maintenir le changement explicite ou migration scripts - vous pouvez maintenir la plupart du temps que la « version actuelle » de votre base de données. Un aspect ennuyeux de la gestion des scripts de migration est qu'il n'y a pas de moyen facile de voir, par exemple une liste de colonnes dans une table (basée sur les scripts de migration). Bien sûr, certaines modifications doivent être apportées sous forme de migrations explicites, mais elles sont assez faciles à gérer en tant que scripts distincts.

Une conséquence particulièrement agréable de pouvoir gérer des bases de données en tant que (un ensemble) de scripts et également de pouvoir créer rapidement de nouvelles instances est que le test unitaire du code de base de données important est très facile (et assez amusant aussi). J'utilise tSQLt pour les tests unitaires.

Je souhaite seulement qu'il y ait un outil similaire pour les autres SGBD.

Je sais que cela semble exagéré pour la plupart des administrateurs de base de données:

Avez-vous envisagé d'utiliser Ruby on Rails pour suivre les modifications de la base de données (et uniquement les modifications de la base de données). Vous n'avez pas besoin d'exécuter une application ou du code rubis etc. Mais j'ai trouvé le style des migrations (c'est la façon dont ils l' appellent) est très utile: http://guides.rubyonrails.org/migrations.html

Sql Server est également pris en charge, vous devrez peut-être utiliser JRuby + JDBC.