Connexion

Connexion à votre compte

Identifiant
Mot de passe
Maintenir la connexion active sur ce site

Blog

Nextep, un outil de gestion de version des bases de données - Tutoriel 1ère partie

Gestion de versions de base de données: le plus tôt sera le mieux! (NeXtep)

-- Traduction depuis l'anglais de l'article de Diethard Steiner Database Version Control: Sooner than later! (NeXtep)

Travailler en Business Intelligence amène inévitablement à créer des schémas au moins pour les data warehouse et les datamarts. Le DDL est généralement écrit à l'aide d'un éditeur de texte ou un quelconque GUI, svn, git ou apparenté sont utilisés pour la gestion de versions, mais une gestion de versions efficace de ce DDL n'est quasiment jamais mis en place. Dans le cas du développement de base de données vous avez besoin d'un outil qui puisse générer un DDL pour le delta entre deux versions, vous pourrez ainsi aisément actualiser votre base.

Si vous travaillez sur un projet qui implique de gérer proprement les environnements de développement, de test et de production, un outil de gestion de versions de base de données devrait être obligatoire. La bonne nouvelle est qu'il existe en effet des outils open-source qui peuvent vous aider dans votre tâche. La mauvaise nouvelle est qu'aucun ne peut être considéré comme étant en développement actif et qu'aucun n'a trouvé la reconnaissance et la notoriété que leurs développeurs de ces solutions auraient espérées.

Il y a environ un an j'ai essayé de trouver un projet open-source de gestion de versions de base de données, les deux que j'ai pu trouver à ce moment étaient dbmaintain et neXtep. A en juger par leur historique de release on pourrait penser que ces projets sont dormants. J'ai donc abandonné ce sujet. Cette année au Pentaho User Meeting à Amsterdam, Edwin Weber a mentionné neXtep lors de sa présentation et j'ai eu une brève discussion avec lui après coup à propos de son expérience avec cet outil. Il m'informa que malgré le fait qu'il y n'ait pas de nouvelles releases, il y avait encore des patchs proposés pour cet outil. J'ai donc pensé : essayons! J'ai donc décidé de jeter un œil à neXtep il y a à peine une semaine.

Après vous être enregistré, vous pouvez télécharger le neXtep Studio basé sur Eclipse. L'installation est relativement facile et l'interface est également assez intuitive. Je ne m'attendais vraiment pas à ce que la documentation soit de si bonne qualité. Les personnes derrière ce projet ont dû passer un temps considérable à créer ce que j'appellerais une excellente documentation, que vous pouvez trouver ici. Il y a également un forum sur lequel j'ai reçu quelques réponses à mes questions! Si quelqu'un a envie d'ajouter le support de base de données supplémentaires vous trouverez de la documentation ici et ici.

Le but de ce billet n'est pas de parcourir l'outil avec vous, leur Wiki étant le meilleur endroit pour trouver tout ce qu'il vous faut. Le message que je veux faire passer est plutôt : "Hey, cet outil de gestion de versions de base de donnée est vraiment impressionnant, utilisez le et aidez-les à se développer!". Je pense que, bien qu'il soit souvent négligé, la gestion de versions des bases de données est un sujet très important. Gestion de versions de base de données: le plus tôt sera le mieux!

Quelques notes sur l'installation :J'ai eu quelques problèmes lors de la configuration du repository NeXtep sur:

  • PostgreSQL 9.2 : deux colonnes n'ont pu être crées. Voir ici pour résoudre le problème
  • MySQL 5.5 : l'installeur s'est figé lors de l'upgrade finale sur le repository. J'ai dû forcer l'arrêt du processus et redémarrer NeXtep Studio après quoi l'upgrade s'est déroulé correctement. Ensuite je n'ai pas pu créer d'utilisateur, mais heureusement (dans ce cas au moins) le mot est passe est archivé en clair dans la db table. Exécutez SELECT * FROM nextep_repo.REP_USERS

Comment utiliser le système de gestion de versions neXtep

Partons d'un cas très simple : imaginons que nous ayons déjà la table suivante dans notre base PostgreSQL (pour les bases MySQL, MS SQL ou Oracle ajustez les scripts SQL).

CREATE DATABASE nextep; \connect nextep CREATE SCHEMA test; CREATE TABLE test.user (   firstname VARCHAR(50) , lastname VARCHAR(50) ) ;

Nous décidons de mettre en place une gestion de versions parce que les choses vont devenir beaucoup plus complexes lorsque le projet va démarrer. Sur le terminal (dans mon cas Ubuntu) naviguez jusqu'au dossier d'installation de neXtep et démarrez le Studio (cela suppose que vous ayez configuré l'utilisateur et le repository neXtep, explication ici): ./neXtep

Lorsque la fenêtre de sélection du Shared Workspace s'ouvre, choisissez New Workspace. Donnez un nom, une description et sélectionnez PostgreSQL comme database vendor. Assurez-vous ensuite de sélectionner Import structure from an existing database (reverse engineering).

Maintenant renseignez les informations de connexion à la base et testez la connexion :

Cliquez sur Next. Le mot de passe de la base de donnée vous sera demandé une nouvelle fois (assurez-vous de le sauvegarder cette fois-ci!). Maintenant, regardez attentivement le Version Navigator sur la gauche du Studio:

Faites un clic droit sur le module, le deuxième élément de la hiérarchie, Nextep Test, et choisissez commit:

Pour l'instant nous n'allons pas changer le numéro de version (nous le ferons dans le futur). Ajouter une bonne description et cliquez sur commit. Vous allez voir apparaître un petit cadenas sur le module ainsi que sur le nom de la table.

Sélectionnez ensuite le nom de la table et cliquez sur le bouton Check Out (vous pouvez également faire un clic droit sur la table et choisir Check Out)

Une nouvelle boite de dialogue, appelée Problem Solver Wizard s'ouvre. Cliquez simplement sur Finish. Ajoutez ensuite une description aux changements que vous êtes sur le point de faire. NeXtep va automatiquement incrémenter le numéro du patch, ce qui est exactement ce que nous voulons ici. Nous voulons également travailler sur la branche principale

Cliquez sur Ok. Le symbole de cadenas a maintenant disparu dans le Version Navigator et le numéro de version a été incrémenté.

Dans le Version Navigator double cliquez sur la table user. Une fenêtre Table Overview va s'ouvrir. Ajoutons une nouvelle colonne appelée user_id. Cliquez sur l'onglet Columns en bas de la fenêtre Table Overview, puis cliquez sur ajouter:

Ajoutez les colonnes suivantes :

  • userid : SERIAL
  • employeeno : VARCHAR(20); description : alpanumeric code

Puis remontez la colonne userid pour qu'elle soit la première de la liste. Cliquez sur l'onglet Primary Keys, ajoutez une nouvelle clé primaire appelée PK_userid et assignez-lui la colonne userid :

Regardons le message d'erreur remonté par neXtep: We forgot to define the userid column as NOT NULL. Il faut donc définir la colonne userid à NOT NULL. Revenez donc sur l'onglet Columns et faite la modification nécessaire :

Maintenant que nous avons fait tous les changements nécessaires, nous sommes prêts à les committer. Cliquez sur le bouton Commit and lock this version. Vous avez alors une dernière chance d'ajuster la description, puis cliquez sur Commit. Remarquez que le numéro de version a une nouvelle fois été incrémenté.

Cliquez ensuite sur le bouton Synchronize DB:

La perspective Synchronization s'ouvre, vous aurez alors une vue d'ensemble de toutes les modifications depuis la dernière version :

On voit alors que nous avons ajouté les colonnes employeeno et userid ainsi qu'une clé primaire appelée PK_userid. Dans la zone de travail principale vous pouvez voir le DDL neXtep généré pour passer de la version 1.0.0.0 à 1.0.0.1:

Comme tout paraît ok, cliquez sur le bouton Execute :

Tous les changements vont être appliqués à notre base cible. Gardez un œil sur la Console pour suivre la progression de l'exécution.

Il est conseillé de cliquer une nouvelle fois sur Synchronize afin de s'assurer que notre modèle est bien synchronisé avec notre base cible. Comme vous pouvez voir dans notre cas, quelque chose ne va pas :

En gros, l'explication de ce qui s'est passé est que PostgreSQL a créé sa propre séquence pour userid et a changé le type en Integer. Ces modifications nous conviennent, on peut donc simplement incorporer ces changements. Cliquer sur le bouton Repository reverse synchronization from database information et cliquez sur Execute :

Nous voulons maintenant nous assurer que tout est bien synchronisé, cliquez donc une nouvelle fois sur le bouton Synchronize database. Maintenant tout est en ordre (cliquez également sur le bouton Shows/Hides unchanged items) :

Retournez sur la perspective Database Design et remarquez que les changements ont bien été appliqué. On voit qu'une nouvelle séquence a été ajoutée (dans le Version Navigator) et que le détail de la colonne userid a changé :

Pour être honnête on aurait pu la configurer comme ça du premier coup, mais au moins maintenant vous avez pu être confronté un peu plus aux options de synchronisation.

Rechercher sur le blog