web-dev-qa-db-fra.com

Existe-t-il un processus de type "Meilleures pratiques" pour les développeurs à suivre pour les modifications de la base de données?

Qu'est-ce qu'un bon moyen de migrer les changements de DB du développement au QA aux environnements de production? Actuellement nous:

  1. Script le changement dans un fichier SQL et attachez-le à un élément de travail TFS.
  2. Le travail est évalué par des pairs
  3. Lorsque le travail est prêt pour le test, 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 avec c'est que c'est très manuel. Il s'appuie sur le développeur se souvenir de joindre le SQL ou le réviseur de pair la capturer si le développeur oublie. Parfois, cela finit par être le testeur ou le déploiement QA qui découvre le problème.

Un problème secondaire est que vous avez parfois besoin de coordonner manuellement les modifications si deux tâches distinctes modifient le même objet de base de données. Cela peut être comme la façon dont il est, mais il semble toujours qu'il y ait une manière automatisée de "signaler" ces problèmes ou quelque chose comme ça.

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

Je suis très habitué à mon système de contrôle source prenant soin de choses comme ceci pour moi et aimerais avoir la même chose pour mon SQL.

sql-server-2008processsource-control
31
Beth Whitezel

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 inimaginatifs tels que "base de donnéesUpdate17.sql" ou "PriceUpdatefebRubera2010.sql" pour mes scripts. Les avoir en tant que projets de base de données me permettent de les attacher aux tâches de serveur d'équipe, à des bugs (et si nous avons fait des critiques de codes, à eux aussi). J'inclus également dans chaque base de données (que j'ai autorité sur) une table spécifiquement pour la collecte des modifications apportées au 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, cela prend soin de 3 du 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 insertion pour enregistrer le début d'un patch ainsi que la fin d'un patch. Les événements se produisent en dehors des patchs sont des choses à examiner.

Par exemple, un insert "Begn 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 attrape également lorsque des indices sont reconstruits, vous devrez exécuter ce qui suit chaque mois ou 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 affichée sur défaut de serveur .

Dans un environnement conforme au 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 au sommet des scripts de mise à jour incluent des listes de nouvelles tables, des Procs stockés, des fonctions, etc. ainsi que des listes de tableaux modifiés, des PROC stockés, des fonctions, etc. Si les données sont modifiées, expliquent ce qui est modifié et pourquoi.

Un problème secondaire est que vous avez parfois besoin de coordonner manuellement les modifications si deux tâches distinctes modifient le même objet de base de données. Cela peut être comme la façon dont c'est, mais il semble toujours qu'il y ait une manière automatisée de "signaler" ces problèmes ou quelque chose.

Je n'ai jamais rencontré un outil qui nous permet de la suivre automatiquement. Les employeurs précédents ont utilisé un principe de "propriétaire de la base de données" - une seule personne qui est personnellement responsable de la base de données. Cette personne ne sera pas le seul développeur qui travaille contre cette base de données, mais tous les changements doivent les passer à travers. Cela a bien fonctionné pour maintenir les changements de collision et d'endommagement des autres.

17
Tangurena

Avez-vous regardé SQL Source Control? 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/

7
Michael Francis

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

Nous commençons à transmettre vers une stratégie où les bases de données sont modélisées dans PowerDesigner. Toutes les modifications apportées à la structure/code de base de données sont effectuées dans le modèle, vérifiée dans le contrôle de la source, puis modifier les scripts sont générés à partir des modèles pour implémenter les modifications de la base de données. Ces scripts de changement sont également vérifiés pour contrôler la source. Les gros changements sont examinés par des pairs et PowerDesigner rend cette très facile à utiliser des fonctionnalités intégrées.

PowerDesigner est un outil de modélisation générique qui supporte plus que des bases de données, nous commençons donc à l'utiliser pour gérer les exigences, créer des diagrammes conceptuels, physiques et d'architecture (OUM'S TOO), etc. Fondamentalement, nous l'utilisons pour fournir à la colonne vertébrale Processus d'ingénierie logicielle.

(Je ne suis en aucun cas affilié à Sybase, qui a développé PowerDesigner - il suffit de penser que je jetais ça là).

4
ScottCher

Ghost de DB

DB Ghost est mon outil préféré pour la gestion de bases de données.

Avantages

  1. Tous les objets de votre base de données sont stockés en tant que scripts dans le contrôle de la source.
  2. Vous pouvez également faire un script 'Données statiques' (données de la table de recherche).
  3. Vous pouvez mettre à jour le contrôle de la source manuellement ou en script d'une base de données de développement de modèle.
  4. Vous pouvez Construire une base de données (rapidement) à partir des scripts du contrôle de la source (y compris les données statiques).
  5. Vous pouvez déployer des modifications à 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) dans une base de données existante et générer un script de changement.
    • Vous pouvez diriger DB Ghost pour synchroniser automatiquement les modifications entre deux instances de la base de données, par exemple. une base de données de construction et votre base de données de production.

[4] est particulièrement pratique pour faire des changements locaux ou créer des instances séparées pour différents environnements. En fait, il est si facile que je crée une base de données séparée pour chaque fonctionnalité ou bogue que je travaille sur cet impact sur une base de données.

Détails

Le principal avantage de l'utiliser sur la maintenance des changements explicites ou des scripts de migration est que vous surtout Vous n'avez pas besoin de maintenir des changements explicites ou des scripts de migration - vous pouvez surtout entretenir la "version actuelle" de votre base de données. Un aspect gênant 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, certains changements doivent être faits sous forme de migrations explicites, mais ils sont suffisamment faciles à gérer comme scripts distincts.

Une conséquence particulièrement agréable de pouvoir gérer des bases de données comme (un ensemble) de scripts et de pouvoir créer rapidement de nouvelles instances est que le test de base de données important est très facile (et assez amusant). J'utilise TSQLT pour tester unitaire.

Je souhaite seulement qu'il y ait un outil similaire pour les autres DBMS-S.

2
Kenny Evitt

Je sais que cela semble survenir à la plupart des DBA:

Avez-vous envisagé d'utiliser Ruby sur Rails pour suivre les modifications de la base de données (et uniquement les modifications de base de données). Vous n'avez pas besoin d'exécuter une application ou d'écrire Ruby code, etc. Mais j'ai trouvé le style des migrations (c'est comme ça qu'ils l'appellent) est assez utile: http://guides.rubyonrails.org/migrations.html Englisons

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

1
Sebastian Roth