Déploiement des bases de données avec Visual Studio 2010

Dans notre précédent article, Cycle de vie des bases de données dans Visual Studio 2010 nous vous avions présenté l’initialisation d’une base de données à partir de Visual Studio.
Nous avions abordé la méthodologie à suivre pour maintenir le code SQL de votre base de données, afin d’en assurer la qualité.

Nous allons aujourd’hui aborder la question du déploiement des modifications sur les bases de données.

Les différentes techniques de déploiement de bases de données

Les projets Visual Studio proposent différentes techniques pour déployer vos modifications :

  • Exécuter « command »
    Cette option est assez inutile car tous les scripts sont sauvegardés en CREATE [Object], donc l’exécution d’une mise à jour est impossible car l’objet existe déjà en base
  • Déployer
    Vous pouvez utiliser la commande Déployer sur votre projet de base de données. Si votre projet compile, il est possible de le déployer automatiquement. Cependant il est intéressant de garder la main sur la livraison pour être sûr ce qui est correctement livré. Cette méthode est donc déconseillée…
  • Comparateur de schéma
    C’est la solution idéale pour livrer vos mises à jour et c’est sur cette technique que nous allons nous concentrer durant cet article
    La solution que nous retenons est donc le déploiement à l’aide de l’outil de comparaison de schéma présent dans la solution Visual Studio.

Présentation du comparateur de schéma

Le comparateur de schéma est disponible dans la liste des items exploitables dans la solution.
Ainsi comme tout autre item, il faut le créer dans le bon répertoire dans l’arborescence :

Une fois l’item crée, ouvrez-le pour regarder les options qu’il vous propose :

Vous pouvez comparer 2 schémas, une source et une cible, parmi ces 3 types :

  • Projets de base de données
  • Bases de données
  • Fichiers de base de données

Pour ma part, je ne manipule que les 2 premiers types de schéma, et ceci permet déjà de faire tout ce que je souhaite.
Nous voulons aujourd’hui mettre à jour une base de données, donc il faut prendre comme source votre projet et comme cible votre base de données.
Avant de lancer la comparaison, il est conseillé de mettre à jour les options pour éliminer les objets que vous ne souhaitez pas comparer. Pour éviter tout problème, il vaut mieux être trop restictif au départ pour éviter une erreur de manipulation qui pourrait supprimer des utilisateurs par exemple.
Par expérience, je peux vous confirmer qu’il est problèmatique de supprimer l’accès d’un développeur qui est en train de travailler sur la base de données…

Génération du script

Vous avez séléctionné votre projet, votre base, et limité la comparaison, il ne vous reste plus qu’à valider votre choix et le comparateur va effectuer sa comparation.
Une fois celle-ci terminée, le résultat s’affiche dans une grille.

« L’ update action » permet de rapidement identifier si l’objet est identique, à mettre à jour, à supprimer ou à créer.
Vous pouvez observer les différences entre l’ancienne et la nouvelle version, en sélectionnant la ligne de l’objet à comparer puis en parcourant l’object definitions.
Si vous ne souhaitez pas déployer certaines différences, vous pouvez très simplement les «skipper » en choisissant « Skip » dans le menu déroulant qui apparait lorsque vous appuyez sur la colonne « update action ».
La barre d’outils offre la possibilité de filtrer sur les types de modification qui vous intéressent. Attention, ce filtre n’est que visuel : Lorsque vous générez le script, il prendra en compte l’ensemble des différences
Une fois confirmée la liste des modifications que vous souhaitez appliquer, il ne vous reste plus qu’à générer le script en utilisant le bouton d’export.
Je vous déconseille très fortement d’utiliser l’écriture directe, à moins que votre modification ne soit réellement mineure.
De plus, il est intéressant de noter qu’il est possible d’ajouter automatiquement dans ce script le code SQL pre et post-déploiement, dans lequel vous pouvez saisir les données de référence à insérer dans les tables. Personnellement, je préfère gérer cela manuellement dans un autre fichier pour ne pas tout mettre dans un seul et même fichier.
Votre script est généré. Vous pouvez à présent le coller dans SQL Server afin de pouvoir l’exécuter sur votre base de données.

Nous allons donc pouvoir aborder son exploitation, afin d’en découvrir toutes les subtilités.

Exploitation du script

Le script étant présent, regardons son contenu.
Le squelette général est le suivant :

    1. Initialisation des variables SQLCMD
    2. Suppression des triggers des tables modifiées
    3. Suppression des contraintes liées aux tables modifiées
    4. Suppression des éléments sélectionnés
    5. Modification/ création des tables
    6. Création des contraintes
    7. Création des triggers
    8. Modification / création des vues
    9. Modification / création des procédures stockées

Il n’y a aucune encapsulation générale par des transactions. N’hésitez donc pas à en ajouter une au cas où…

Passons en revue les points importants à contrôler dans le script avant de le lancer par un « F5 »

Initialisation des variables SQLCMD

Ces variables ne sont utiles que si vous manipulez des variables SQLCMD dans votre code :
Par exemple, vous pouvez en utiliser lorsque vous faites appel à des bases voisines comme il a été évoqué dans le précédent article.
Pour rendre exploitable les scripts SQLCMD, il faut activer le SQLCMD mode dans l’onglet «Query » sinon vous pouvez supprimer cette partie du script.

Suppression des éléments sélectionnés

Cette partie est importante à contrôler afin de vérifier qu’il ne supprime pas des éléments que vous souhaiteriez conserver.

Modification/ création des tables

Cette partie est la plus délicate. Il faut être très vigilent et vous allez sans nul doute être amené à devoir faire des modifications.
Si vous n’avez fait qu’ajouter des colonnes NULLABLE, ou que vous ne faites que créer de nouvelles tables, tout va bien. Il n’a pas grand-chose à faire à part vérifier par précaution.
Cependant en cas d’ajout de nouvelles colonnes NOT NULLABLE, et que la table est déjà peuplée, vous allez devoir compléter le code généré.

Comme le commentaire l’indique, le système de création n’est pas complet car il faut alimenter la nouvelle colonne NOT NULLABLE, et que le générateur ne peut pas déterminer sa valeur.
Une solution de contournement, si le contenu de la colonne le permet, est d’ajouter une contrainte de valeur par défaut lors de sa création, qu’on supprimerait par la suite pour permettre l’initialisation de la colonne facilement.

Vous connaissez à présent le plus important sur la génération. Les conseils que l’on pourrait ajouter pour son utilisation sont :

  • Ajouter une encapsulation transactionnelle par sécurité
  • Découper en plusieurs fichiers pour plus de lisibilité
  • Gérer l’alimentation des données de référence de manière isolée

Les autres possibilités du comparateur de données

Nous avons vu ensemble comment exploiter l’outil de comparaison d’un projet vers une base de données, mais ce n’est pas son seul usage.

Voici quelques autres exemples d’exploitations :

  • De base de données vers base de données
    Pour comparer votre base de production et votre base de développement ou intégration.
  • De base de données vers un projet
    Pour effectuer un rattrapage du projet suite à une modification « sauvage », directement en base de données
  • De projet vers un projet
    Pour comparer la version actuelle du projet avec une ancienne version de ce même projet

Conclusions

Nous avons vu aujourd’hui comment déployer des modifications à l’aide d’un outil très intéressant qui fait partie du projet de base de données Visual Studio 2010.
Personnellement, c’est l’outil qui m’a le plus intéressé dans la gestion de la base de données par le biais de Visual Studio dans sa version 2010.

Il ne nous reste donc plus qu’à voir une dernière option très intéressante qui a pris tout son sens dans Visual Studio 2010 : la génération de données afin d’améliorer ses tests automatisés.

Nous arriverons donc à la conclusion de cette série sur le sujet des bases de données dans notre prochain article, qui aura pour but de vous présenter les deux systèmes disponibles dans Visual Studio 2010 pour la génération de données.

Un commentaire. Laisser un commentaire

[…] fait suite aux deux articles précédents d’Arnaud Villenave sur le cycle de vie et le déploiement de bases de données SQL Server. Nous allons aborder le problème sur un angle légèrement […]

Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *