Déploiement de bases de données SQL Server de test à Live

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 (batch 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.

Voulez-vous simplement copier le fichier .mdf et l'attacher? 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 fonctionner avec la même version du serveur à tout moment).

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

Et enfin - étant donné que la base de données 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 structure et ALTER TABLE les live, qui peuvent aussi nécessiter une vérification / conversion des données.

Maintenant, j'entends beaucoup de bonnes choses sur les produits Red Gate , mais pour projets de passe-temps, le prix est un peu raide.

Alors, qu'utilisez-vous pour déployer automatiquement les bases de données SQL Server de Test à Live?

0
ajouté édité
Vues: 2

14 Réponses

J'utilise le mécanisme de migrations de Subsonic, donc j'ai juste un dll avec des classes en ordre squental qui ont 2 méthodes, de haut en bas. Il y a un hook d'intégration / construction continue dans nant, de sorte que je puisse automatiser la mise à niveau de ma base de données.

Ce n'est pas le meilleur thème du monde, mais il bat l'écriture DDL.

0
ajouté

Comme Rob Allen, j'utilise SQL Compare / Data Compare par Redgate. J'utilise également l'assistant de publication de base de données de Microsoft. J'ai aussi une application de 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 avec des commandes 'GO' à partir d'une ligne de commande ou dans un script batch.

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

0
ajouté

Si vous avez une entreprise qui 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 ont des éditions pour la plupart des bases de données populaires, y compris bien sûr Sql Server.

0
ajouté

Je travaille de la même manière que Karl, en gardant tous mes scripts SQL pour créer et modifier des tables dans un fichier texte que je garde dans le contrôle de la source. En fait, pour éviter le problème d'avoir un script à examiner la base de données en direct pour déterminer ce que ALTERs à exécuter, je travaille habituellement comme ceci:

  • Sur la première version, je place tout ce qui est en cours de test dans un script SQL, et traite toutes les tables comme un CREATE. Cela signifie que je finis par perdre et lire beaucoup de tables pendant les tests, mais ce n'est pas un gros problème au début du projet (puisque je suis généralement en train de pirater les données que j'utilise à ce moment-là).
  • 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 ALTERs pour cette version. Et je fais les changements à l'original, créer 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 parvenir.
  • Selon la manière dont je déploie les modifications de la base de données, je placerai également 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 sur les scripts à exécuter, quel que soit le code que j'exécute, les scripts create / upgrade utilisent la version pour déterminer ce qu'il faut exécuter.

La seule chose que cela ne va pas faire, c'est aider si vous passez de test à production, mais si vous voulez gérer la structure et ne pas payer pour un package de gestion de BD agréable, mais coûteux, ce n'est vraiment pas très difficile. J'ai également trouvé que c'est un très bon moyen de garder une trace mentale de votre DB.

0
ajouté

For my projects I alternate between SQL Compare from REd Gate and the Database Publishing Wizard from Microsoft which you can download free here.

L'assistant n'est pas aussi lisse que SQL Compare ou SQL Data Compare, mais il fait l'affaire. Un problème est que les scripts qu'il génère peuvent avoir besoin d'être réarrangés et / ou édités pour être diffusés en une fois.

Sur le plan positif, il peut déplacer votre schéma et vos données, ce qui n'est pas mauvais pour un outil gratuit.

0
ajouté

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 faisables.

En général, je prends l'approche "Script It", mais vous pouvez envisager quelque chose comme suit:

  • Distinguer entre Développement et Staging, de sorte que vous puissiez développer avec un sous-ensemble de données ... ceci je créerais un outil pour simplement abaisser quelques données de production, ou pour générer de fausses données là où la sécurité est concernée.
  • Pour le développement de l'équipe, chaque modification de 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 entremêlées, mais un seul script doit activer une fonctionnalité donnée. Une fois que toutes vos fonctionnalités sont prêtes, regroupez-les dans un seul fichier SQL et lancez-le contre une restauration de production.
  • Une fois que votre transfert a été accepté, vous réexécutez le fichier SQL unique sur l'ordinateur de production.

J'ai utilisé les outils Red Gate et ce sont de grands outils, mais si vous ne pouvez pas vous le permettre, construire les outils et travailler de cette manière n'est pas trop loin de l'idéal.

0
ajouté

Je suis d'accord que tout script est la meilleure voie à suivre et est ce que je préconise au travail. Vous devez tout écrire à partir de la base de données et de la création d'objets pour remplir vos tables de recherche.

Tout ce que vous faites dans l'interface utilisateur ne se traduira pas (surtout pour les changements ... pas tellement pour les premiers déploiements) et finira par nécessiter des outils comme ceux offerts par Redgate.

0
ajouté

J'ai pris le codage manuel de toutes mes instructions DDL (create / alt / delete), les ajoutant à mon .sln en tant que fichiers texte, et en utilisant un versionnage normal (en utilisant subversion, mais tout contrôle de révision devrait fonctionner). De cette façon, je n'ai pas seulement l'avantage de la version, mais la mise à jour en direct de dev / stage est la même chose pour le code et la base de données - les balises, les branches, etc. fonctionnent tout de même.

Sinon, je suis d'accord que Redgate est cher si vous n'avez pas une entreprise qui l'achète pour vous. Si vous pouvez obtenir une entreprise pour l'acheter pour vous, ça vaut vraiment le coup!

0
ajouté
+1 J'apporte des modifications à l'aide de Design GUI dans SSMS (ou Enterprise Manager dans SQL2000), mais j'utilise l'icône «Générer un script de modification» pour générer un script, que je stocke pour créer le script de modification pour la prochaine version. Il y a une case à cocher "Automatically make change script" au cas où vous oublieriez un jour!
ajouté l'auteur Kristen, source

Je suis d'accord avec garder tout dans le contrôle de la source et écrire manuellement tous les changements. Les modifications apportées au schéma d'une version unique vont dans un fichier de script créé spécifiquement pour cette version. Tous les procs, vues, etc. stockés devraient aller dans des dossiers individuels et être traités juste comme .cs ou .aspx aussi loin que le contrôle de source va. J'utilise un script powershell pour générer un gros fichier .sql pour la mise à jour de la programmation.

Je n'aime pas automatiser l'application des changements de schéma, comme les nouvelles tables, les nouvelles colonnes, etc. Lorsque je fais une version de production, j'aime passer la commande change script par commande pour m'assurer que chacun fonctionne comme prévu. Il n'y a rien de pire que de lancer un gros script de changement sur la production et d'obtenir des erreurs parce que vous avez oublié un petit détail qui ne s'est pas présenté en développement.

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

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

0
ajouté

RedGate SqlCompare is a way to go in my opinion. We do DB deployment on a regular basis and since I started using that tool I have never looked back. Very intuitive interface and saves a lot of time in the end.

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

0
ajouté

Je fais toute ma création de base de données en tant que DDL, puis j'encapsule ce DDL dans une classe de maintenance de schéma. Je peux faire plusieurs choses pour créer le DDL en premier lieu mais fondamentalement je fais tout le schéma maint dans le code. Cela signifie également que si vous avez besoin de 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 dbs ont alors une table qui définit la version actuelle afin que l'on puisse coder un ensemble relativement simple de tests:

  1. La base de données existe-t-elle? Si ce n'est pas le cas, créez-le.
  2. La DB est-elle la version actuelle? Si ce n'est pas le cas, exécutez les méthodes, en séquence, qui mettent le schéma à jour (vous pouvez demander à l'utilisateur de confirmer et, idéalement, faire des sauvegardes à ce stade).

Pour une application mono-utilisateur, je la mets juste en place, pour une application web, nous devons actuellement verrouiller l'utilisateur si les versions ne correspondent pas et que nous avons une application stand-alone schema maint. Pour les utilisateurs multiples, cela dépendra de l'environnement particulier.

L'avantage? Eh bien, j'ai un très haut niveau de confiance que le schéma pour les 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 quand même plus ou moins donné!

Murph

0
ajouté

Ne pas oublier la solution de Microsoft au problème: Visual Studio 2008 Database Edition . Inclut des outils pour déployer des changements aux bases de données, produisant un diff entre les bases de données pour le schéma et / ou les changements de données, les tests unitaires, 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é que c'était génial. Il rend la base de données aussi facile à utiliser que n'importe quel autre morceau de code.

0
ajouté

I'm currently working the same thing to you. Not only deploying SQL Server databases from test to live but also include the whole process from Local -> Integration -> Test -> Production. So what can make me easily everyday is I do NAnt task with Red-Gate SQL Compare. I'm not working for RedGate but I have to say it is good choice.

0
ajouté
Le lien en réponse est mort.
ajouté l'auteur Pang, source

Je gère é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 tout le lot au sein d'une transaction.

0
ajouté