sql-server - relationnelle - sql to nosql converter




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

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 les 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?


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.


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 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 exécutez-les par rapport à 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 d' excellents 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.


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.


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. Est-ce que la base de données existe? 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 inviter l'utilisateur à 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


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.


Je travaille actuellement la même chose pour vous. Non seulement déployer des bases de données SQL Server de test à vivre, mais aussi inclure l'ensemble du processus de Local -> Intégration -> Test -> Production. Donc, ce qui peut me rendre facilement tous les jours est que je fais la tâche NAnt avec Red-Gate SQL Compare . Je ne travaille pas pour RedGate mais je dois dire que c'est un bon choix.


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.


Pour mes projets, j'alterne entre SQL Compare de REd Gate et l'Assistant de Publication de Base de Données de Microsoft que vous pouvez télécharger gratuitement ici .

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.


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.


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.





release-management