image_thumb.png

Intégration Continue de BDD avec SQLCompare de RedGate

Nous utilisons SQL Source Control de RedGate pour le gérer le versionning de nos bases de données ainsi que SQLCompare afin de générer les scripts de mise à jour d’une version à une autre. Cette solution est en effet peu coûteuse et à mon sens plus simple à utiliser que les outils proposés par Microsoft.

L’objectif de la mise en place d’intégration continue est d’arriver à déployer de manière automatique toutes les modifications sur une base de données destinée aux tests.

Pour notre scénario exemple, j’ai donc une base de données DBTest liée au source control, et une base de données DBTest_CI non liée au source control et qui sera automatiquement mise à jour par le serveur de builds (celle-ci peut évidemment être sur un autre serveur) :

image

Pour arriver à impacter la base DBTest_CI à chaque checkin d’une modification sur la base versionnée, il est donc nécessaire de créer un processus de build en intégration continue :

image

Une fois le processus de build défini, il est nécessaire de rajouter une tâche au processus de build : cette tâche permettra d’appeler SQL Compare selon le principe suivant :

image

SQL Compare ne va pas effectuer un compare entre le source control et la base de données d’intégration mais entre le dossier de scripts présent sur le source control et cette même base.

Pour cela nous allons utiliser le fait que le processus de build par défaut un getlatest pour directement récupérer la dernière version des scripts SQL.

Pour avoir de souplesse dans les modifications du processus de builds je préfère souvent externaliser les commandes à réaliser via un fichier .bat ou un fichier powershell. L’intêret est que le développement en est beaucoup plus simple (plus besoin de fait un checkin/checkout de la définition de la build à chaque modification), l’inconvénient est que cette définition n’est donc pas versionnée.

Vous pouvez donc utiliser cette technique dans vos phases de définition/personnalisation de de builds et ensuite pousser vos modifications sur le source control une fois que vous avez terminé pour garder les avantages des deux solutions.

Pour lancer la commande vous pouvez utiliser l’activité InvokeProcess et spécifier en argument de la commande à lancer les informations souhaitées :

image

De plus comme vous pouvez le voir, afin d’avoir un retour dans le log de la build, j’ai placé une activité WriteBuildMessage au niveau de la gestion de l’output ce qui permettra d’avoir une tracabilité au niveau des actions effectuées.

Concernant mon .bat donc, la commande est assez simple :

SNAGHTML61b1df96

J’indique à SQL Compare d’utiliser le dossier de scripts SQL qui a été getlatesté par le processus de build, j’indique ensuite les informations de connexion au second serveur. A noter que j’utilise l’authentification SQL afin de me simplifier la vie. Le paramètre /sync indique enfin à SQL Compare de directement exécuter le résultat du compare pour synchroniser les deux sources de données.

Le résultat est que lorsque l’on checkin un ajout d’un nouveau champ dans une table de la base DBTest :

image

Une nouvelle build se déclenche automatiquement :

image

Build qui a pour effet d’automatiquement intégrer les modifications sur la base d’intégration continue :

imageimage

3 réflexions au sujet de « Intégration Continue de BDD avec SQLCompare de RedGate »

  1. Limozin Lionel

    Si j’ai bien compris, les dev modifient un/des fichier(s) sql qui permettrai de créer l’intégralité de la base ‘from scratch’ et le sql compare peux comparer ce script avec une instance ‘live’ d’une base ?
    Autre question, ça marche si on compare 2 bases (et qu’on passe pas par script sql) ?
    Dernière remarque : ds le 1er screenshot de ton workflow de def de build on ne vois pas l’etape « updateCiBdd » et on la voie ds le second screenshot mais sans voir où elle est placée par rapport aux autres étapes… bref c’est pas très parlant…
    Bon sinon ds l’ensemble continue à démystifier les sujet d’intégration continue , je kiff et on en fait pas assez souvent !!!

    Répondre
    1. Patrice Lamarche

      Bonne question, je pourrais faire un post dédié sur le sujet. La plupart des outils de versionning de BDD (RedGate SQL Source Control, les database project dans Visual Studio, et consors) gèrent les versions des « objets » de ta base (tables, procédures stockées, etc.) en générant un script de création de l’objet en question et en stockant ce script dans le source control.
      Pour versionner la table Toto, un script de création de la table sera généré à chaque modification de la table, et c’est ce script (et uniquement ce script) qui est versionné dans le source control.
      Après les outils se débrouillent pour générer le bon script de diff pour mettre à jour les schémas à partir de ce script de création.

      Tu as raison concernant la remarque sur le screenshot pour indiquer où placer l’activité, j’essaierai de faire mieux les prochaines fois. Dans le cas de l’exemple on peut la placer après la compilation de tous les projets.

      Répondre

Laisser un commentaire

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