Procédures stockées sous contrôle de source, meilleures pratiques
J'utilise actuellement Tortoise SVN pour contrôler à la source une application Web .NET. Quelle serait la meilleure façon d'intégrer nos procédures stockées SQL Server dans le contrôle de code source? J'utilise actuellement VS 2010 comme environnement de développement et je me connecte à une base de données SQL Server 2008 R2 hors site à l'aide de SQL Server Data Tools (SSDT).
Ce que j'ai fait dans le passé, c'est d'enregistrer les procs dans un fichier .sql et de garder ces fichiers sous contrôle de source. Je suis sûr qu'il doit y avoir un moyen plus efficace que cela? Existe-t-il une extension que je peux installer sur VS2010, SSDT ou même SQL Server sur la machine de production?
Il existe des outils, tels que ceci de Redgate , mais j'ai toujours trouvé que le mieux était d'enregistrer en tant que fichiers SQL, peut-être même dans un projet de base de données (SSDT?) Dans votre solution.
Parallèlement à cela, je suggère les lignes directrices suivantes:
- Supposez toujours que la version SVN est "actuelle"/"dernière"
- Assurez-vous que chaque script que vous exécutez possède un "
if exists then drop" au début - N'oubliez pas d'écrire vos autorisations, le cas échéant
Vous pouvez initialement créer ces fichiers SQL en scriptant directement à partir de SSMS, et vous pouvez définir SSMS pour scripter tous vos "drop" et "create" ainsi que vos autorisations.
L'enregistrement des fichiers SQL dans le contrôle de code source permet de contrôler uniquement les fichiers SQL. Il ne contrôle pas les modifications des objets de base de données réels, ni n'empêche les modifications simultanées du même objet de base de données par plusieurs utilisateurs (et je suppose que vous aimeriez aussi avoir cela sous contrôle). Ce que nous utilisons est un outil tiers ( Version ApexSQL ), il s'intègre à la fois avec SSMS et VS, vous pouvez choisir de travailler avec une version de base de données de l'objet ou avec une version de contrôle de source. Si vous modifiez une version de base de données, elle est automatiquement extraite uniquement pour vous, donc personne d'autre ne peut la modifier (elle ne fusionne pas les modifications des différents utilisateurs). Ce n'est que lorsque vous le réenregistrez, que d'autres peuvent le modifier. Et vous pouvez avoir votre SC différente de la version d'un objet live (je l'utilise quand je pars pour la journée et je prévois de terminer les modifications et de la tester le lendemain)
Essayez Ankhsvn , hautement recommandé et gratuit.
Depuis la page d'accueil:
AnkhSVN est un fournisseur de contrôle de source Subversion pour Microsoft Visual Studio 2005, 2008, 2010 et 2012 .
AnkhSVN fournit une prise en charge de la gestion du code source Apache ™ Subversion® pour tous les types de projets pris en charge par Visual Studio et vous permet d'effectuer les opérations de contrôle de version les plus courantes directement à partir de l'intérieur de l'IDE Microsoft Visual Studio.
Le tableau de bord des modifications en attente vous donne un aperçu unique de votre processus de développement et offre un accès facile au code source et aux fonctionnalités de gestion des problèmes. L'intégration du contrôle de code source approfondi (SCC) vous permet de vous concentrer sur le développement, tandis que AnkhSVN garde une trace de toutes vos modifications et vous fournit les outils pour gérer efficacement vos besoins spécifiques.
J'ai essayé à la fois RedGate et le projet de base de données de Visual Studio et je préfère stocker la définition de base de données dans le projet de base de données. Dès que la base de données fait partie de la solution, vous pouvez utiliser votre fournisseur de contrôle de source préféré. La plupart ont une excellente intégration de Visual Studio.
Avec les outils SSDT, vous disposez de la "dernière version" de la définition de la base de données, ce qui vous permet de faire facilement des comparaisons de schéma et de générer des scripts de mise à niveau de schéma.
Cela dit, le schéma n'est généralement qu'une partie de l'équasion. Dans la vraie vie, il s'avère que les bases de données contiennent déjà beaucoup de données. Et mes utilisateurs ont tendance à être plutôt déçus lorsqu'ils le perdent.
Donc, dès que j'ai déployé la version 1.0, le besoin se fait sentir de maintenir les scripts de mise à niveau. Parfois, ceux-ci contiennent simplement des modifications de schéma, mais souvent, je dois créer des valeurs par défaut basées sur le contenu d'une autre table, je dois libérer une contrainte particulière jusqu'à ce que j'amorce les données, etc. Habituellement, la simple mise à niveau du schéma ne la coupe pas tout à fait. Ma préférence est d'avoir ces scripts de mise à niveau dans un dossier séparé dans le projet de base de données également. Celles-ci ressemblent généralement à une "mise à niveau de la version 1.0 vers la version 1.1".
Mes bases de données ont toujours une table de référence qui m'indique le numéro de version actuel, donc je peux bloquer les mises à niveau incompatibles. La première déclaration de mes scripts de mise à niveau vérifie la version actuelle et renfloue si elle est différente de ce qui est attendu.
Un autre avantage des projets de base de données est de pouvoir déployer différents ensembles de données basés sur le même schéma. J'ai différents jeux de données pour le développement, l'équipe QA, le test d'acceptation des utilisateurs et les tests d'intégration automatisés. Étant donné qu'un projet de base de données ne peut avoir qu'un seul script de post-déploiement, l'astuce consiste à créer un nouveau projet de base de données qui référence le projet `` maître '' et à intégrer l'ensemble de données personnalisé aux processus de post-déploiement de ce projet.
Ce sont mes 2 cents, quel que soit le processus que vous montez, il doit avant tout vous convenir à vous et à votre équipe et, espérons-le, vous soutenir dans la plupart des tâches courantes.
Utilisez RedGate Source Control pour le connecter à votre contrôle de source.
http://www.red-gate.com/products/sql-development/sql-source-control/
Il connectera votre SSMS directement à votre référentiel de contrôle de source et permet même de vérifier les données statiques.
Fonctionne comme un charme
J'ai fini par écrire un outil moi-même.
Il est disponible en téléchargement gratuit - http://www.gitsql.net
J'espère que cela aide d'autres personnes qui souhaitent atteindre le même objectif final.
Voici un article qui décrit comment contrôler la source SQL Server. http://gitsql.net/documentation-04_SQL_Server_and_GIT
J'ai essayé de le rendre aussi simple que possible. (3 écrans)
- Se connecter à SQL Server
- Sélectionnez des objets
- Choisissez le dossier vers lequel exporter/importer
J'ai également - accidentellement - ajouté la possibilité de choisir sélectivement des objets individuels à importer - ou à exporter. Ce qui facilite grandement le développement.
J'apportais généralement une modification à une procédure stockée et à une table, puis j'exportais ces deux objets dans un répertoire GIT.
Ensuite, j'utilise Source Tree pour voir visuellement les changements, puis je les valide dans bitbucket si je suis content.