2009-12-22 4 views
19

Le système logiciel sur lequel je travaille est un système de facturation médicale, de grandes quantités de données et de tables de données, ainsi que des procédures stockées. Je lisais l'article "12 Steps to Better Code" et dans le The Joel Test # 2 états: Pouvez-vous faire une construction en une seule étape?Quel est un moyen facile de déployer les modifications de base de données à l'aide de SQL Server?

Maintenant, je me demandais, cela signifie-t-il la construction de déploiement (de sorte qu'un client peut mettre à jour leur déploiement). Maintenant, le principal problème que je rencontre est de savoir comment faire une mise à jour de base de données en une étape? À l'heure actuelle, lorsque nous apportons des modifications à une base de données, toutes les modifications sont enregistrées et ajoutées à un script de mise à jour de base de données auquel est associé un numéro de version lors de la création d'un déploiement sur le client.

Existe-t-il une façon plus simple de faire cela? Quel script ou application là-bas qui prend un "avant et après" regarder un schéma de base de données et crée un script de mise à jour comme je l'ai mentionné?

Ou est-ce juste comme tout le monde le fait, ce que je trouverais difficile à croire, mais plausible. Un système automatisé réduirait les erreurs et accélérerait considérablement les temps de construction du déploiement, et je serais intéressé de savoir comment le faire.

Répondre

14

Il y a différents niveaux de complexité que vous pouvez passer par:

  • si vous avez des scripts de mise à jour que vous créez manuellement, et sont à la recherche d'un moyen d'appliquer facilement les divers serveurs, consultez la SSW SQL Deploy par SSW Consulting. Il peut gérer ce scénario très bien

  • Si vous avez tendance à faire plus d'une approche de base de données diff, alors SQL Compare de Red Gate (déjà mentionné) et SQL Packager font un excellent combo. Vous pouvez comparer la base de données entre l'ancien et le nouveau, puis appliquer les modifications dans un joli paquet - comme un EXE ou un projet C#

  • si vous voulez une approche réelle, de bout en bout, bien pensée (avec un peu d'une courbe d'apprentissage), consultez Innovartis' DBGhost approche. C'est une méthodologie/technique entière pour gérer le développement de la base de données et les mises à jour incrémentales. Il est très puissant et semble très prometteur - mais il est un peu une approche tout ou rien: soit vous achetez en elle et l'utiliser de bout en bout, ou vous ne

Hope this helps un peu!

+2

J'ai utilisé DbGhost pendant 10 ans et ça fonctionne toujours. Le soutien qu'ils fournissent est sans pareil. – penderi

+0

Nous sommes en 2013 maintenant. Toute mise à jour sur ce champ? – ysrb

+1

@ysrb: bien, il y a les [Outils de données SQL Server] (http://msdn.microsoft.com/en-us/data/tools.aspx) à l'intérieur de Visual Studio 2012/2013 qui semblent automatiser beaucoup de ces tâches prêtes à l'emploi (si vous utilisez Visual Studio, c'est-à-dire) –

2

Jetez un oeil à cet article de blog. J'ai utilisé ce type de script de mise à jour unique à partir de n'importe quelle version DB sur un couple de projets et cela fonctionne très bien.

http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx

Vous devrez peut-être modifier le flux de travail un peu pour l'adapter à votre flux de travail et/ou mettre à jour le modèle fichier sql, mais dans l'ensemble j'ai trouvé l'idée d'être une approche assez solide pour les déploiements DB.

EDIT: Juste pour expliquer comment j'ai utilisé cette technique. Fondamentalement, tous mes scripts de révision DB sont placés dans le contrôle de la source. Ensuite, en tant qu'étape de génération de message sur la boîte de construction, cet outil Mambo est exécuté sur le répertoire des scripts pour faire rouler les scripts dans un script unique englobé par une transaction pour permettre le retour en arrière si quelque chose tourne mal. Ensuite, le programme d'installation est assez intelligent pour rechercher le script .sql à exécuter sur la base de données existante. La raison pour laquelle cela fonctionne est que le script déroulé vérifie que chaque pièce qui était un script individuel a déjà été exécutée sur la base de données souhaitée. Par conséquent, seuls les derniers scripts sont exécutés. Une mise en garde à cela est qu'une fois qu'un script est vérifié dans le contrôle de la source et qu'il a été déployé, vous ne pouvez pas le modifier car la table de suivi pense déjà que le script a été exécuté. C'est bien pour les projets sur lesquels j'ai travaillé parce que nous ajoutons simplement un autre script dans le dossier des scripts.

J'espère que j'explique le processus assez bien pour comprendre. Ce n'est vraiment pas si complexe et peut être très utile si l'approche est applicable à votre projet.

1

Réponse à la première question de "Maintenant je me demandais, cela signifie-t-il la construction de déploiement (de sorte qu'un client peut mettre à jour leur déploiement)?"

Je crois que le test Joel n ° 2 n'est pas destiné au déploiement, mais à l'intégration continue pendant le développement. En ce qui concerne les changements de base de données dans prod, ils doivent tous être effectués via un script dans le cadre d'un transfert de transaction ou après la sauvegarde de la base de données.Vous voulez toujours pouvoir revenir en arrière si quelque chose échoue dans le déploiement.

+0

(+1) bonne réponse. Pour l'implémenter, vous avez besoin de numéros de version pour votre état de base de données, d'un état de base et de scripts pour effectuer et annuler les modifications apportées aux objets de base de données. –

+0

Bien qu'ils ne soient pas parfaits, les migrations de rails le font plutôt bien. –

0

Il existe des applications qui synchronisent les bases de données, mais je pense que vous feriez mieux de faire ce que vous faites. L'écriture d'un script pour mettre à jour une base de données vous permet de gérer les erreurs et d'exécuter des transactions. Ceci est considéré comme la meilleure pratique. Redgate a un outil SQL Compare pour comparer les bases de données et générer un script à synchroniser.

2

Nous avions l'habitude de l'utiliser mais plus récemment nous sommes passés à des scripts manuels en utilisant le même processus que celui que vous décrivez. L'utilisation de scripts manuels à grain fin avec un numéro de version unique a bien fonctionné. Nous avons intégré nos scripts de mise à niveau dans les tests unitaires afin qu'ils soient testés avec le code dans le cadre de l'intégration continue. Je pense que c'est un élément important pour «faire une construction en une seule étape».

1

Développez votre base de données en tant que jeu de correctifs dépendant les uns des autres. Ensuite, utilisez un outil comme https://github.com/LuvDaSun/sqlpatch (par moi) pour créer un fichier SQL pour le déploiement. Sqlpatch va trier les patchs dans le bon ordre et s'assurer que chaque patch est exécuté exactement une fois, même si le même script est exécuté deux fois.

Cette stratégie peut être utilisée pour le déploiement de votre base de données dans un environnement ci/cd. Cela rend le déploiement aussi facile que de pousser vers une succursale.

0

Microsoft a lui-même introduit Data-tier applications dans SQL 2012 comme une option gratuite pour le déploiement et la mise à niveau des bases de données. J'utilise et aime cet outil, y compris pour les déploiements de production.

Questions connexes