Stratégies de déploiement des bases de données (SQL Server)

Question

Je cherche un moyen d'effectuer des déploiements quotidiens et de maintenir les scripts de la base de données en phase avec les versions.

Actuellement, nous avons une façon assez décente de déployer nos sources, nous avons une couverture de code unitaire, une intégration continue et des procédures de retour en arrière.

Le problème est de garder les scripts de la base de données en ligne avec une version. Tout le monde semble essayer le script sur la base de données de test puis l'exécuter en direct, lorsque les mappages ORM sont mis à jour (c'est-à-dire que les changements sont mis en direct), alors il prend la nouvelle colonne.

Le premier problème est qu'aucun des scripts ne DOIT être écrit quelque part, généralement tout le monde "tente" de les mettre dans un dossier Subversion mais certaines personnes plus paresseuses exécutent simplement le script en direct et la plupart du temps personne ne sait qui a fait quoi à la base de données.

Le deuxième problème est que nous avons 4 bases de données de test et qu'elles sont TOUJOURS en décalage et que la seule façon de les remettre vraiment en ligne est de faire une restauration à partir de la base de données active.

Je suis convaincu qu'un processus comme celui-ci doit être simple, direct et facile à utiliser afin d'aider les développeurs et non de les gêner.

Ce que je recherche, ce sont des techniques/idées qui permettent au développeur d'enregistrer facilement ses scripts de base de données afin qu'ils puissent être exécutés dans le cadre d'une procédure de lancement. Un processus que le développeur voudrait suivre .

Toute histoire, tout cas d'utilisation ou même un lien serait utile.

Answer 1

Pour ce problème précis, j'ai choisi d'utiliser un outil de migration : Migratordotnet .

Avec les migrations (dans n'importe quel outil), vous avez une simple classe utilisée pour effectuer vos changements et les annuler. Voici un exemple :

[Migration(62)]
public class _62_add_date_created_column : Migration
{
    public void Up()
    {
       //add it nullable
       Database.AddColumn("Customers", new Column("DateCreated", DateTime) );

       //seed it with data
       Database.Execute("update Customers set DateCreated = getdate()");

       //add not-null constraint
       Database.AddNotNullConstraint("Customers", "DateCreated");
    }

    public void Down()
    {
       Database.RemoveColumn("Customers", "DateCreated");
    }
}

Cet exemple montre comment vous pouvez gérer les mises à jour volatiles, comme l'ajout d'une nouvelle colonne non nulle à une table contenant des données existantes. Cette opération peut être automatisée facilement, et vous pouvez facilement passer d'une version à l'autre.

Cela a été un ajout très précieux pour notre construction, et a simplifié le processus. immensément .

J'ai publié une comparaison des différents cadres de migration dans .NET ici : http://benscheirman.com/2008/06/net-database-migration-tool-roundup

Answer 2

Lire La série de billets de K.Scott Allen sur le versioning des bases de données .
Nous avons construit un outil permettant d'appliquer des scripts de base de données de manière contrôlée sur la base des techniques qu'il décrit et cela fonctionne bien.
Cela pourrait ensuite être utilisé dans le cadre du processus d'intégration continue, chaque base de données de test ayant des modifications déployées lorsqu'un commit est effectué sur l'URL dans laquelle vous conservez les scripts de mise à jour de la base de données. Je suggérerais d'avoir un script de base et des scripts de mise à niveau de sorte que vous puissiez toujours exécuter une séquence de scripts pour faire passer une base de données de sa version actuelle au nouvel état qui est nécessaire.
Cela nécessite néanmoins un certain processus et une certaine discipline de la part des développeurs (toutes les modifications doivent être intégrées dans une nouvelle version de l'installation de base script et un correctif script).

Answer 3

Nous utilisons SQL Compare de RedGate depuis quelques années maintenant :

http://www.red-gate.com/products/index.htm

La version pro dispose d'une interface en ligne de commande que vous pourriez probablement utiliser pour configurer vos procédures de déploiement.

Answer 4

Nous utilisons une version modifiée du versioning de la base de données décrit par K. Scott Allen . Nous utilisons le Assistant de publication de base de données pour créer la ligne de base originale script. Ensuite, un outil C# personnalisé basé sur SQL SMO pour vider les procédures stockées, les vues et les fonctions utilisateur. Les scripts de changement qui contiennent des modifications de schéma et de données sont générés par Porte Rouge outils. Nous nous retrouvons donc avec une structure du type

Database\
    ObjectScripts\ - contains stored procs, views and user funcs 1-per file
    \baseline.sql - database snapshot which includes tables and data
    \sc.01.00.0001.sql - incremental change scripts
    \sc.01.00.0002.sql
    \sc.01.00.0003.sql

L'outil personnalisé crée la base de données si nécessaire, applique le baseline.sql si nécessaire, ajoute un tableau SchemaChanges si nécessaire et applique les scripts de changement si nécessaire en fonction de ce qui se trouve dans le tableau SchemaChanges. Ce processus se produit dans le cadre d'une construction nant script chaque fois que nous faisons une construction de déploiement via cc.net.

Si quelqu'un veut le code source de l'application schemachanger, je peux le mettre sur codeplex/google ou autre.

Answer 5

Allez-y :

https://blog.codinghorror.com/get-your-database-under-version-control/

Faites défiler la page vers le bas jusqu'à la liste des 5 liens vers le site odetocode.com. Une série fantastique en cinq parties. Je m'en servirais comme point de départ pour trouver des idées et définir un processus qui convienne à votre équipe.