Procédures stockées / schéma de base de données dans le contrôle de code source
Faites-vous le suivi des procédures stockées et du schéma de base de données dans le système de contrôle de source de votre choix?
Lorsque vous effectuez une modification (ajoutez une table, mettez à jour un processus stocké, comment obtenir les modifications dans le contrôle de code source?)
Nous utilisons SQL Server au travail et j'ai commencé à utiliser darcs pour la gestion des versions, mais je serais curieux de connaître les stratégies générales ainsi que les outils pratiques.
Edit : Wow, merci pour toutes les bonnes suggestions, les gars! Je souhaite pouvoir sélectionner plus d'une "Réponse acceptée"!
Nous choisissons de tout scripter, et cela inclut toutes les procédures stockées et les changements de schéma. Aucun outil wysiwyg et aucun programme sophistiqué de "synchronisation" n'est nécessaire.
Les changements de schéma sont faciles, tout ce que vous avez à faire est de créer et de maintenir un seul fichier pour cette version, y compris tous les changements de schéma et de données. Cela devient votre script de conversion de la version x à x + 1. Vous pouvez ensuite l'exécuter sur une sauvegarde de production et l'intégrer dans votre "build quotidien" pour vérifier qu'il fonctionne sans erreur. Notez qu'il est important de ne pas modifier ou supprimer le schéma déjà écrit/chargement de données sql car vous pouvez finir par casser tout SQL écrit plus tard.
-- change #1234
ALTER TABLE asdf ADD COLUMN MyNewID INT
GO
-- change #5678
ALTER TABLE asdf DROP COLUMN SomeOtherID
GO
Pour les procédures stockées, nous choisissons un seul fichier par sproc, et il utilise le formulaire drop/create. Toutes les procédures stockées sont recréées lors du déploiement. L'inconvénient est que si une modification a été effectuée en dehors du contrôle de la source, la modification est perdue. En même temps, c'est vrai pour n'importe quel code, mais votre DBA'a doit en être conscient. Cela empêche vraiment les personnes extérieures à l'équipe de se mêler de vos procédures stockées, car leurs modifications sont perdues lors d'une mise à niveau.
En utilisant Sql Server, la syntaxe ressemble à ceci:
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [usp_MyProc]
GO
CREATE PROCEDURE [usp_MyProc]
(
@UserID INT
)
AS
SET NOCOUNT ON
-- stored procedure logic.
SET NOCOUNT OFF
GO
La seule chose à faire est d'écrire un programme utilitaire qui rassemble tous les fichiers individuels et crée un nouveau fichier avec l'ensemble des mises à jour (sous la forme d'un seul script). Pour ce faire, commencez par ajouter les modifications de schéma, puis en répétant la structure de répertoires et en incluant tous les fichiers de procédure stockée.
En tant qu'avantage de tout script, vous deviendrez bien meilleur en lecture et en écriture SQL. Vous pouvez également rendre tout ce processus plus élaboré, mais c'est le format de base pour contrôler à la source tout SQL sans aucun logiciel spécial.
addendum: Rick a raison de dire que vous perdrez les autorisations sur les procédures stockées avec DROP/CREATE, vous devrez donc peut-être écrire un autre script pour réactiver des autorisations spécifiques. Ce script d'autorisation serait le dernier à s'exécuter. Notre expérience a révélé plus de problèmes avec la sémantique ALTER verses DROP/CREATE. YMMV
créer un "projet de base de données" dans Visual Studio pour écrire et gérer votre code sQL et garder le projet sous contrôle de version avec le reste de votre solution.
La solution que nous avons utilisée lors de mon dernier travail était de numéroter les scripts au fur et à mesure qu'ils étaient ajoutés au contrôle de code source:
01.CreateUserTable.sql
02.PopulateUserTable
03.AlterUserTable.sql
04.CreateOrderTable.sql
L'idée était que nous savions toujours dans quel ordre exécuter les scripts, et nous pourrions éviter d'avoir à gérer les problèmes d'intégrité des données qui pourraient survenir si vous essayiez de modifier le script n ° 1 (ce qui entraînerait vraisemblablement l'échec des INSERTs du n ° 2).
Je suis d'accord (et j'approuve) la pratique de Robert Paulson. Cela suppose que vous contrôlez une équipe de développement avec la responsabilité et la discipline nécessaires pour adhérer à une telle pratique.
Pour "forcer" cela à mes équipes, nos solutions maintiennent au moins un projet de base de données de Visual Studio Team Edition for Database Professionals . Comme pour les autres projets de la solution, le projet de base de données obtient un contrôle versionné. Cela en fait un processus de développement naturel de diviser le tout dans la base de données en morceaux maintenables, "disciplinant" mon équipe en cours de route.
Bien sûr, étant un projet Visual Studio, il est loin d'être parfait. Vous rencontrerez de nombreuses bizarreries qui peuvent vous frustrer ou vous embrouiller. Il faut un peu de compréhension du fonctionnement du projet avant de le faire accomplir vos tâches. Les exemples comprennent
- déploiement de données à partir de fichiers CSV .
- déploiement sélectif des données de test en fonction du type de construction .
- Visual Studio se bloque lors de la comparaison avec des bases de données avec un certain type d'assembly CLR intégré dans .
- aucun moyen de différenciation entre les bases de données de test/production qui implémentent différents schémas d'authentification - utilisateurs SQL vs utilisateurs Active Directory.
Mais pour les équipes qui n'ont pas l'habitude de gérer les versions de leurs objets de base de données, c'est un bon début. L'autre alternative célèbre est bien sûr, la suite de produits SQL Server de Red Gate , que la plupart des utilisateurs considèrent comme supérieure à l'offre de Microsoft.
Une chose à garder à l'esprit avec vos scripts de suppression/création dans SQL Server est que les autorisations au niveau de l'objet seront perdues. Nous avons changé notre norme pour utiliser à la place des scripts ALTER, qui maintiennent ces autorisations.
Il existe quelques autres mises en garde, comme le fait que la suppression d'un objet supprime les enregistrements de dépendance utilisés par sp_depends et que la création de l'objet ne crée que les dépendances pour cet objet. Donc, si vous déposez/créez une vue, sp_depends ne connaîtra plus aucun objet référençant cette vue.
Morale de l'histoire, utilisez des scripts ALTER.
Je pense que vous devriez écrire un script qui configure automatiquement votre base de données, y compris toutes les procédures stockées. Ce script doit ensuite être placé dans le contrôle de code source.
Couple différentes perspectives de mon expérience. Dans le monde Oracle, tout était géré par des scripts DDL "create". Comme ahockley l'a mentionné, un script pour chaque objet. Si l'objet doit changer, son script DDL est modifié. Il existe un script wrapper qui appelle tous les scripts d'objet afin que vous puissiez déployer la version actuelle de la base de données dans l'environnement de votre choix. Ceci est pour le noyau principal create.
De toute évidence, dans une application en direct, chaque fois que vous poussez une nouvelle construction qui nécessite, par exemple, une nouvelle colonne, vous n'allez pas supprimer la table et la créer à nouveau. Vous allez faire un script ALTER et ajouter la colonne. Ainsi, chaque fois que ce type de changement doit se produire, il y a toujours deux choses à faire: 1) écrire l'alter DDL et 2) mettre à jour le core create DDL pour refléter le changement. Les deux vont dans le contrôle de code source, mais le script de modification unique est plus un changement momentané dans le temps puisqu'il ne sera utilisé que pour appliquer un delta.
Vous pouvez également utiliser un outil comme ERWin pour mettre à jour le modèle et générer ultérieurement le DDL, mais la plupart des DBA que je connais ne font pas confiance à un outil de modélisation pour générer le script exactement comme ils le souhaitent. Vous pouvez également utiliser ERWin pour faire de l'ingénierie inverse de votre script DDL de base dans un modèle périodiquement, mais c'est très compliqué de lui donner une apparence correcte (à chaque fois que vous le faites).
Dans le monde Microsoft, nous avons utilisé une tactique similaire, mais nous avons utilisé le produit Red Gate pour aider à gérer les scripts et les deltas. Mettez toujours les scripts dans le contrôle de code source. Encore un script par objet (table, sproc, peu importe). Au début, certains DBA préféraient vraiment utiliser l'interface graphique de SQL Server pour gérer les objets plutôt que d'utiliser des scripts. Mais cela a rendu très difficile la gestion cohérente de l'entreprise au fur et à mesure de sa croissance.
Si le DDL est dans le contrôle de code source, il est simple d'utiliser n'importe quel outil de construction (généralement ant) pour écrire un script de déploiement.
J'ai trouvé que de loin, le moyen le plus simple, le plus rapide et le plus sûr de le faire est de simplement mordre la balle et d'utiliser SQL Source Control de RedGate. Scripté et stocké dans le référentiel en quelques minutes. Je souhaite juste que RedGate considère le produit comme un leader de la perte afin qu'il puisse être utilisé plus largement.
Dans le passé, j'ai gardé la source des modifications de base de données contrôlées de telle sorte que pour chaque version du produit, toutes les modifications de base de données étaient toujours scriptées et stockées dans la version sur laquelle nous travaillons. Le processus de construction en place amènerait automatiquement la base de données à la version actuelle basée sur une table dans la base de données qui stockait la version actuelle pour chaque "application". Une application utilitaire .net personnalisée que nous avons écrite s'exécuterait alors et déterminerait la version actuelle de la base de données, et exécuterait tous les nouveaux scripts sur elle dans l'ordre des numéros de préfixe des scripts. Ensuite, nous exécutions des tests unitaires pour nous assurer que tout allait bien.
Nous stockons les scripts dans le contrôle de code source comme suit (structure de dossiers ci-dessous):
Je suis un peu rouillé sur les conventions de dénomination actuelles sur les tables et les procédures stockées si nues avec mon exemple ...
[racine]
[Application]
[version]
[Script]
\ scripts
Mon application\
1.2.1 \
001.MyTable.Create.sql
002.MyOtherTable.Create.sql
100.dbo.usp.MyTable.GetAllNewStuff.sql
Avec l'utilisation d'une table Versions qui prendrait en compte l'application et la version, l'application restaurerait la sauvegarde de production hebdomadaire et exécuterait tous les scripts nécessaires sur la base de données depuis la version actuelle. En utilisant .net, nous pouvions facilement intégrer cela dans une transaction et si quelque chose échouait, nous annulions et envoyions des e-mails, donc nous savions que cette version contenait de mauvais scripts.
Ainsi, tous les développeurs veilleraient à conserver cela dans le contrôle de code source afin que la version coordonnée s'assure que tous les scripts que nous prévoyons d'exécuter sur la base de données fonctionneraient correctement.
C'est probablement plus d'informations que ce que vous recherchiez, mais cela a très bien fonctionné pour nous et compte tenu de la structure, il était facile de faire participer tous les développeurs.
Lorsque le jour de la publication arrivait, l'équipe des opérations suivait les notes de publication et récupérait les scripts du contrôle de code source et exécutait le package sur la base de données avec l'application .net que nous avons utilisée pendant le processus de construction nocturne qui regrouperait automatiquement les scripts dans les transactions, donc si quelque chose a échoué, il reviendrait automatiquement et aucun impact sur la base de données n'a été effectué.
Semblable à Robert Paulson, ci-dessus, notre organisation maintient la base de données sous contrôle de source. Cependant, notre différence est que nous essayons de limiter le nombre de scripts que nous avons.
Pour tout nouveau projet, il existe une procédure définie. Nous avons un script de création de schéma à la version 1, un script de création de proc stocké et éventuellement un script de création de chargement de données initial. Tous les processus sont conservés dans un seul fichier, certes massif. Si nous utilisons Enterprise Library, nous incluons une copie du script de création pour la journalisation; s'il s'agit d'un projet ASP.NET utilisant le framework d'application ASP.NET (authentification, personnalisation, etc.), nous incluons également ce script. (Nous l'avons généré à partir des outils de Microsoft, puis nous l'avons peaufiné jusqu'à ce qu'il fonctionne de manière reproductible sur différents sites. Pas amusant, mais un investissement en temps précieux.)
Nous utilisons la magie CTRL + F pour trouver le proc que nous aimons. :) (Nous serions ravis si SQL Management Studio avait une navigation dans le code comme VS le fait. Soupir!)
Pour les versions ultérieures, nous avons généralement des scripts upgradeSchema, upgradeProc et/ou updateDate. Pour les mises à jour de schéma, nous ALTERONS les tables autant que possible, en en créant de nouvelles si nécessaire. Pour les mises à jour de proc, nous DROP et CREATE.
Une ride apparaît avec cette approche. Il est facile de générer une base de données, et il est facile d'en obtenir une nouvelle à jour sur la version actuelle de la base de données. Cependant, il faut faire attention avec la génération DAL (ce que nous faisons actuellement - généralement - avec SubSonic), pour s'assurer que les changements DB/schema/proc sont synchronisés proprement avec le code utilisé pour y accéder. Cependant, dans nos chemins de construction se trouve un fichier batch qui génère le SubSonic DAL, donc c'est notre SOP pour extraire le code DAL, réexécutez ce fichier batch, puis revérifiez tout à tout moment le changement de schéma et/ou de processus (ceci, bien sûr, déclenche une construction source, la mise à jour des dépendances partagées vers les DLL appropriées ...)
Dans mon entreprise, nous avons tendance à stocker tous les éléments de la base de données dans le contrôle de code source sous forme de scripts individuels, comme vous le feriez pour des fichiers de code individuels. Toutes les mises à jour sont d'abord effectuées dans la base de données, puis migrées vers le référentiel de code source afin de conserver un historique des modifications.
Dans un deuxième temps, toutes les modifications apportées à la base de données sont migrées vers une base de données d'intégration. Cette base de données d'intégration représente exactement à quoi devrait ressembler la base de données de production après le déploiement. Nous avons également une base de données QA qui représente l'état actuel de la production (ou le dernier déploiement). Une fois que toutes les modifications sont apportées dans la base de données d'intégration, nous utilisons un outil de différence de schéma (SQL Diff de Red Gate pour SQL Server) pour générer un script qui migrera toutes les modifications d'une base de données à l'autre.
Nous avons trouvé cela assez efficace car il génère un seul script que nous pouvons intégrer facilement à nos installateurs. Le plus gros problème que nous rencontrons souvent est que les développeurs oublient de migrer leurs modifications vers l'intégration.
Les procédures stockées obtiennent 1 fichier par sp avec le standard s'il existe des instructions drop/create en haut. Les vues et les fonctions obtiennent également leurs propres fichiers, ce qui facilite leur version et leur réutilisation.
Le schéma est tout un script pour commencer, puis nous effectuerons des changements de version.
Tout cela est stocké dans un projet de base de données Visual Studio connecté à TFS (@ work ou VisualSVN Server @ home pour les affaires personnelles) avec une structure de dossiers comme suit:
- projet
-- les fonctions
- schéma
-- procédures stockées
- vues
Nous avons utilisé une approche alternative dans mon projet actuel - nous n'avons pas la base de données sous contrôle de code source, mais à la place, nous avons utilisé un outil de diff de base de données pour écrire les modifications lorsque nous arrivons à chaque version.
Cela fonctionne très bien jusqu'à présent.
Nous conservons les procédures stockées sous contrôle de code source.
Nous stockons tout ce qui concerne une application dans notre SCM. Les scripts DB sont généralement stockés dans leur propre projet, mais sont traités comme n'importe quel autre code ... concevoir, implémenter, tester, valider.
Script tout (création d'objets, etc.) et stockez ces scripts dans le contrôle de code source. Comment les changements y parviennent-ils? Cela fait partie de la pratique standard de la façon dont les choses sont faites. Besoin d'ajouter une table? Écrivez un script CREATE TABLE. Mettre à jour un sproc? Modifiez le script de procédure stockée.
Je préfère un script par objet.
Pour procs, écrivez les procs avec les wrappers de script dans des fichiers simples et appliquez les modifications de ces fichiers. S'il s'applique correctement, vous pouvez archiver ce fichier et vous pourrez également le reproduire à partir de ce fichier.
Pour les modifications de schéma, vous devrez peut-être archiver des scripts pour effectuer de manière incrémentielle les modifications que vous avez apportées. Écrivez le script, appliquez-le, puis archivez-le. Vous pouvez ensuite créer un processus pour appliquer automatiquement chaque script de schéma en série.
Nous conservons les procédures stockées sous contrôle de code source. La façon dont nous (ou du moins moi) le faisons est d'ajouter un dossier à mon projet, d'ajouter un fichier pour chaque SP et copiez manuellement, collez-y le code. Donc, lorsque je change le SP , Je dois modifier manuellement le fichier du contrôle de source.
Je serais intéressé de savoir si les gens peuvent le faire automatiquement.