Automatisation des migrations d'objets de base de données à partir du contrôle de code source

Question

Je suis à la recherche de «meilleures pratiques» pour automatiser le déploiement de procédures stockées/vues/fonctions/modifications de table à partir du contrôle de source. J'utilise StarTeam & ANT afin que l'étiquetage est pris en charge; Ce que je cherche, c'est comment certains d'entre vous ont approché l'automatisation de la traction de ces objets de la source - pas nécessairement StarTeam.

Je voudrais finir avec un script qui peut ensuite être exécuté, enregistré et étiqueté.

Je ne demande à personne d'écrire cela - juste quelques idées ou approches qui ont (ou n'ont pas) fonctionné dans le passé. J'essaye de nettoyer un désordre et veux m'assurer que je reçois ceci aussi près que possible de «droite».

Nous stockons les tables/vues/fonctions etc. dans des fichiers individuels dans StarTeam et notre base de données est SQL 2K5.

Answer 1

Nous utilisons SQL Compare from redgate (http://www.red-gate.com/).

Nous avons une base de données de production, une base de développement et chaque développeur a sa propre base de données.

La base de données de développement est synchronisée avec les modifications qu'un développeur a apportées à sa base de données lorsqu'il vérifie ses modifications.

Le développeur vérifie également dans un script de synchronisation et un rapport de comparaison généré par SQL Compare. Lorsque nous déployons notre application, nous synchronisons simplement la base de données de développement avec la base de données de production à l'aide de SQL Compare.

Cela fonctionne pour nous parce que notre application est pour l'usage interne seulement. Si ce n'est pas votre scénario alors je regarderais SQL Packager (également de Redgate).

Answer 2

Je préfère séparer les vues, les procédures et les triggers (objets qui peuvent être recréés à volonté) des tables. Pour les vues, les procédures et les déclencheurs, écrivez simplement un travail qui va les vérifier et recréer les derniers. Pour les tables, je préfère avoir une table de version de base de données avec une rangée. Utilisez cette table pour déterminer quelles nouvelles mises à jour n'ont pas été appliquées. Ensuite, chaque mise à jour est appliquée et le numéro de version est mis à jour. Si une mise à jour échoue, vous n'avez que cette mise à jour à vérifier et vous pouvez relancer savoir que les mises à jour précédentes ne se reproduiront plus.

Answer 3

dans Migrations Check (souligné dans Andrew Petersanother post)

Answer 4

Comme Carl a souligné, vous pouvez utiliser un utilitaire diff pour créer vos scripts de mise à jour. RedGate est un bon produit, mais SQL Server 2k5 est livré avec TableDiff qui devrait également faire le travail.