Déploiement de bases de données SQL Server du test au live

08-06-2019
|

Question

Je me demande comment vous gérez le déploiement d'une base de données entre 2 serveurs SQL, en particulier SQL Server 2005.Maintenant, il y a un développement et un live.Comme cela devrait faire partie d'un buildscript (lot Windows standard, même avec la complexité actuelle de ces scripts, je pourrais passer à PowerShell ou plus tard), Enterprise Manager/Management Studio Express ne compte pas.

Voudriez-vous simplement copier le fichier .mdf et le joindre ?Je suis toujours un peu prudent lorsque je travaille avec des données binaires, car cela semble être un problème de compatibilité (même si le développement et le live doivent exécuter la même version du serveur à tout moment).

Ou - étant donné le manque de "EXPLAIN CREATE TABLE" dans T-SQL - faites-vous quelque chose qui exporte une base de données existante vers des scripts SQL que vous pouvez exécuter sur le serveur cible ?Si oui, existe-t-il un outil capable de vider automatiquement une base de données donnée dans des requêtes SQL et qui s'exécute à partir de la ligne de commande ?(Encore une fois, Enterprise Manager/Management Studio Express ne compte pas).

Et enfin - étant donné que la base de données active contient déjà des données, le déploiement peut ne pas impliquer la création de toutes les tables mais plutôt la vérification de la différence de structure et ALTER TABLE celles en direct, ce qui peut également nécessiter une vérification/conversion des données lorsque les champs existants changent.

Maintenant, j'entends beaucoup de bonnes choses sur le Porte Rouge produits, mais pour les projets de loisirs, le prix est un peu élevé.

Alors, qu'utilisez-vous pour déployer automatiquement les bases de données SQL Server du test au live ?

La solution

J'ai commencé à coder manuellement toutes mes instructions DDL (crée/modifier/supprimer), en les ajoutant à mon .sln en tant que fichiers texte et en utilisant la gestion de versions normale (en utilisant Subversion, mais tout contrôle de révision devrait fonctionner).De cette façon, je bénéficie non seulement du contrôle de version, mais la mise à jour en direct depuis le développement/l'étape est le même processus pour le code et la base de données - les balises, les branches, etc. fonctionnent de la même manière.

Sinon, je suis d’accord que Redgate coûte cher si aucune entreprise ne l’achète pour vous.Si vous parvenez à demander à une entreprise de l’acheter pour vous, cela en vaut vraiment la peine !

Autres conseils

Pour mes projets j'alterne entre SQL Compare de REd Gate et le Database Publishing Wizard de Microsoft que vous pouvez télécharger gratuitementici.

L'assistant n'est pas aussi simple que SQL Compare ou SQL Data Compare, mais il fait l'affaire.L'un des problèmes est que les scripts qu'il génère peuvent nécessiter une réorganisation et/ou une modification pour fonctionner d'un seul coup.

Du côté positif, il peut déplacer votre schéma et vos données, ce qui n'est pas mauvais pour un outil gratuit.

N'oubliez pas la solution de Microsoft au problème : Édition de base de données Visual Studio 2008.Comprend des outils pour déployer des modifications dans les bases de données, produisant une différence entre les bases de données pour les modifications de schéma et/ou de données, les tests unitaires et la génération de données de test.

C'est assez cher mais j'ai utilisé l'édition d'essai pendant un moment et j'ai trouvé qu'elle était géniale.Cela rend la base de données aussi facile à utiliser que n’importe quel autre morceau de code.

Comme Rob Allen, j'utilise SQL Compare / Data Compare de Redgate.J'utilise également l'assistant de publication de base de données de Microsoft.J'ai également une application console que j'ai écrite en C# qui prend un script SQL et l'exécute sur un serveur.De cette façon, vous pouvez exécuter des scripts volumineux contenant des commandes « GO » à partir d'une ligne de commande ou dans un script batch.

J'utilise les bibliothèques Microsoft.SqlServer.BatchParser.dll et Microsoft.SqlServer.ConnectionInfo.dll dans l'application console.

Je travaille de la même manière que Karl, en conservant tous mes scripts SQL pour créer et modifier des tables dans un fichier texte que je garde sous contrôle de code source.En fait, pour éviter le problème de devoir demander à un script d'examiner la base de données en direct pour déterminer quels ALTER exécuter, je travaille généralement comme ceci :

Sur la première version, je place tout pendant les tests dans un seul script SQL et je traite toutes les tables comme un CREATE.Cela signifie que je finis par supprimer et lire beaucoup de tableaux pendant les tests, mais ce n'est pas grave au début du projet (puisque je pirate généralement les données que j'utilise à ce stade de toute façon).
Sur toutes les versions suivantes, je fais deux choses :Je crée un nouveau fichier texte pour contenir les scripts SQL de mise à niveau, qui contiennent uniquement les ALTER pour cette version.Et j'apporte les modifications à l'original, je crée également un nouveau script de base de données.De cette façon, une mise à niveau exécute simplement le script de mise à niveau, mais si nous devons recréer la base de données, nous n'avons pas besoin d'exécuter 100 scripts pour y arriver.
En fonction de la manière dont je déploie les modifications de la base de données, je place également généralement une table de versions dans la base de données contenant la version de la base de données.Ensuite, plutôt que de prendre des décisions humaines sur les scripts à exécuter, quel que soit le code que j'ai exécutant les scripts de création/mise à niveau, il utilise la version pour déterminer ce qu'il faut exécuter.

La seule chose que cela ne fera pas est d'aider si une partie de ce que vous passez du test à la production est constituée de données, mais si vous souhaitez gérer la structure et ne pas payer pour un package de gestion de base de données intéressant mais coûteux, ce n'est vraiment pas très difficile.J'ai également trouvé que c'était un très bon moyen de garder une trace mentale de votre base de données.

Si une entreprise l'achète, Toad de Quest Software intègre ce type de fonctionnalité de gestion.Il s'agit essentiellement d'une opération en deux clics pour comparer deux schémas et générer un script de synchronisation de l'un à l'autre.

Ils proposent des éditions pour la plupart des bases de données populaires, y compris bien sûr SQL Server.

Je suis d’accord que tout scripter est la meilleure voie à suivre et c’est ce que je préconise au travail.Vous devez tout écrire, depuis la création de bases de données et d'objets jusqu'au remplissage de vos tables de recherche.

Tout ce que vous faites dans l'interface utilisateur uniquement ne sera pas traduit (en particulier pour les modifications...pas tellement pour les premiers déploiements) et finira par nécessiter des outils comme ceux proposés par Redgate.

En utilisant SMO/DMO, il n'est pas trop difficile de générer un script de votre schéma.Les données sont un peu plus amusantes, mais toujours réalisables.

En général, j'adopte l'approche "Script It", mais vous voudrez peut-être envisager quelque chose du genre :

Faites la distinction entre le développement et le staging, de sorte que vous puissiez développer avec un sous-ensemble de données...cela, je créerais un outil pour simplement extraire certaines données de production ou générer de fausses données en matière de sécurité.
Pour le développement d'équipe, chaque modification apportée à la base de données devra être coordonnée entre les membres de votre équipe.Les modifications de schéma et de données peuvent être mélangées, mais un seul script doit activer une fonctionnalité donnée.Une fois que toutes vos fonctionnalités sont prêtes, vous les regroupez dans un seul fichier SQL et vous les exécutez lors d'une restauration de la production.
Une fois que votre préparation a été acceptée, vous exécutez à nouveau le fichier SQL unique sur la machine de production.

J'ai utilisé les outils Red Gate et ils sont super outils, mais si vous ne pouvez pas vous le permettre, construire les outils et travailler de cette façon n'est pas très loin de l'idéal.

J'utilise le mécanisme de migration de Subsonic, j'ai donc juste une DLL avec des classes dans un ordre séquentiel qui ont 2 méthodes, haut et bas.Il existe un hook de script d'intégration/construction continue dans nant, afin que je puisse automatiser la mise à niveau de ma base de données.

Ce n'est pas la meilleure chose au monde, mais c'est mieux que d'écrire du DDL.

RedGate SqlCompare est une voie à suivre à mon avis.Nous effectuons régulièrement des déploiements de bases de données et depuis que j'ai commencé à utiliser cet outil, je n'ai jamais regardé en arrière.Interface très intuitive et fait gagner beaucoup de temps au final.

La version Pro prendra également en charge les scripts pour l'intégration du contrôle de code source.

Je maintiens également des scripts pour tous mes objets et données.Pour le déploiement, j'ai écrit cet utilitaire gratuit - http://www.sqldart.com.Il vous permettra de réorganiser vos fichiers de script et exécutera le tout dans une transaction.

Je suis d'accord pour que tout soit sous contrôle de code source et pour écrire manuellement toutes les modifications.Les modifications apportées au schéma pour une seule version sont transférées dans un fichier de script créé spécifiquement pour cette version.Tous les processus, vues, etc. stockés doivent être placés dans des fichiers individuels et traités comme .cs ou .aspx en ce qui concerne le contrôle de source.J'utilise un script PowerShell pour générer un gros fichier .sql pour mettre à jour les éléments de programmabilité.

Je n'aime pas automatiser l'application des modifications de schéma, comme les nouvelles tables, les nouvelles colonnes, etc.Lorsque je réalise une version de production, j'aime parcourir le script de modification commande par commande pour m'assurer que chacun fonctionne comme prévu.Il n'y a rien de pire que d'exécuter un script de changement important en production et d'obtenir des erreurs parce que vous avez oublié un petit détail qui ne s'est pas présenté lors du développement.

J'ai également appris que les index doivent être traités comme des fichiers de code et placés dans le contrôle de code source.

Et vous devriez certainement avoir plus de 2 bases de données – dev et live.Vous devriez disposer d'une base de données de développement que tout le monde utilise pour les tâches de développement quotidiennes.Ensuite, une base de données intermédiaire qui imite la production et est utilisée pour effectuer vos tests d'intégration.Ensuite, peut-être une copie récente et complète de la production (restaurée à partir d'une sauvegarde complète), si cela est faisable, afin que votre dernière série de tests d'installation aille à l'encontre de quelque chose d'aussi proche que possible de la réalité.

Je crée toute ma base de données en tant que DDL, puis j'enveloppe ce DDL dans une classe de maintenance de schéma.Je peux faire diverses choses pour créer le DDL en premier lieu, mais fondamentalement, je fais toute la maintenance du schéma dans le code.Cela signifie également que si l'on doit faire des choses non DDL qui ne correspondent pas bien à SQL, vous pouvez écrire une logique procédurale et l'exécuter entre des morceaux de DDL/DML.

Mes bases de données ont alors un tableau qui définit la version actuelle afin que l'on puisse coder un ensemble de tests relativement simples :

La base de données existe-t-elle ?Sinon, créez-le.
La base de données est-elle la version actuelle ?Sinon, exécutez les méthodes, dans l'ordre, qui mettent le schéma à jour (vous souhaiterez peut-être demander à l'utilisateur de confirmer et - idéalement - d'effectuer des sauvegardes à ce stade).

Pour une application mono-utilisateur, je viens de l'exécuter en place, pour une application Web, nous verrouillons actuellement l'utilisateur si les versions ne correspondent pas et disposons d'une application de maintenance de schéma autonome que nous exécutons.Pour le multi-utilisateur, cela dépendra de l’environnement particulier.

L'avantage?Eh bien, j'ai un très haut niveau de confiance dans le fait que le schéma des applications qui utilisent cette méthodologie est cohérent dans toutes les instances de ces applications.Ce n'est pas parfait, il y a des problèmes, mais ça marche...

Il y a quelques problèmes lors du développement dans un environnement d'équipe, mais c'est plus ou moins une évidence de toute façon !

Murph

Je travaille actuellement la même chose avec vous.Non seulement le déploiement des bases de données SQL Server du test au live, mais inclut également l'ensemble du processus depuis Local -> Intégration -> Test -> Production.Alors ce qui peut me rendre facile tous les jours, c'est que je le fais Tâche NAnt avec Red-Gate SQL Compare.Je ne travaille pas pour RedGate mais je dois dire que c'est un bon choix.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow