Récemment, OCTO a publié deux bons billets sur les implémentations de services REST et sur leur testabilité. Je vais donc laisser ce sujet de côté pour le moment et différer le billet que je comptais écrire sur le sujet.

Depuis déjà pas mal de temps, je m’intéresse aux « forges logicielles », en particulier autour de des technologies Java. Dans ce cadre, j’ai testé plusieurs outils de suivi d’anomalies/évolutions : Mantis, JIRA, Redmine, etc.

D’après ce que j’ai pu voir, de nombreux clients utilisent Mantis pour le suivi des anomalies. Dans la forge mise en place en interne, nous utilisons plutôt Redmine (la suite des produits Altassian est également excellente, mais nécessite d’avoir le budget), en particulier pour son excellente intégration avec git :

  • possibilité de lier des commits aux fiches Redmine
  • pilotage automatique de la résolution et du « time-tracking » des fiches en extrayant automatiquement ces informations des commits git
  • visualisation dans l’interface Redmine des diffs
  • calcul et affichage de statistiques sur le dépôt du projet

Afin de pouvoir utiliser simultanément ces différents produits (Mantis du client et Redmine ou JIRA interne), j’ai pensé créer un projet Open Source permettant de synchroniser les données entre ces différents produits, en utilisant Talend Open Studio. Pour cela, il fallait donc réussir à partager ce projet en utilisant git (afin de le rendre accessible sur GitHub).

Préambule

Ce qui suit n’a absolument aucun intérêt pour les personnes disposant déjà d’un environnement Talend Integration Suite. La suite professionnelle gère nativement les projets partagés, et de manière beaucoup plus efficace que ce qu’il est possible de mettre en place avec un gestionnaire de configuration externe :

  • la gestion du partage de données est directement intégrée à l’outil
  • elle permet de visualiser graphiquement dans l’outil les différences entre versions et les impacts des changements

La solution dégradée que je propose ici n’est donc destinée qu’à permettre le travail collaboratif sur un projet Open Source basé sur Talend Open Studio.

Structure d’un projet Talend Open Studio

Talend Open Studio étant basé sur Eclipse RCP :

  • il utilise la même notion de Workspace et de projets.
  • Au sein d’un projet, nous avons le fichier talend.project (équivalent du .project d’Eclipse)
  • un répertoire .settings contenant la configuration spécifique du projet
  • plusieurs répertoires, correspondants aux différents types de données du projet (routines, méta-données, jobs, etc.)

Au passage, on remarquera que dans la dernière version stable (4.1.2), Talend a fait de nombreux efforts non visibles pour l’utilisateur final, mais qui vont faciliter la gestion de configuration des fichiers source, en les simplifiant considérablement (suppression d’identifiants XML). C’est pourquoi je recommande grandement d’être au moins en version 4.1.2 pour appliquer ce qui suit.

Voici par exemple, la source correspondant à la déclaration d’un subjob de fermeture d’une connexion PostgreSQL en version 4.1.1 :

1
2
3
4
5
<subjob xmi:id="_0rPlKUmcEeCSbcfkBi-qrA">
    <elementParameter xmi:id="_0rPlKkmcEeCSbcfkBi-qrA" field="TEXT" name="UNIQUE_NAME" value="tPostgresqlClose_1"/>
    <elementParameter xmi:id="_0rPlK0mcEeCSbcfkBi-qrA" field="COLOR" name="SUBJOB_TITLE_COLOR" value="160;190;240"/>
    <elementParameter xmi:id="_0rPlLEmcEeCSbcfkBi-qrA" field="COLOR" name="SUBJOB_COLOR" value="220;220;250"/>
</subjob>

Le même, après migration en version 4.1.2, qui me plaît beaucoup plus (disparition des id parasites) :

1
2
3
4
5
<subjob>
    <elementParameter field="TEXT" name="UNIQUE_NAME" value="tPostgresqlClose_1"/>
    <elementParameter field="COLOR" name="SUBJOB_TITLE_COLOR" value="160;190;240"/>
    <elementParameter field="COLOR" name="SUBJOB_COLOR" value="220;220;250"/>
</subjob>

Plusieurs façons d’envisager la gestion de configuration

A partir d’ici, nous avons plusieurs façons d’envisager la gestion de configuration :

  • effectuer la gestion de configuration à la racine du workspace, incluant ainsi l’ensemble des projets du workspace dans un seul dépôt
  • effectuer la gestion de configuration à la racine de chaque projet d’un workspace : chaque projet a alors son dépôt dédié
  • combiner les deux approches précédentes, en utilisant des submodules git, en adaptant la procédure décrite dans cet article

Comme j’aime avoir des dépôts atomiques, j’ai opté dans cet article pour la deuxième solution.

Mise en place

Après avoir créé son projet, on se déplace en ligne de commande dans le répertoire correspondant, et on initialise le dépôt git.

Il suffit ensuite de configurer les fichiers/répertoires qui seront ignorés dans le .gitignore :

1
2
3
4
5
6
# Le répertoire temp ne nous intéresse pas en gestion de configuration
/temp
# Les routines systèmes sont régénérées à chaque ouverture du projet dans TOS. On les ignore donc pour qu'elles ne parasitent pas les diffs.
/code/routines/system/
# Les patterns SQL sont régénérées à chaque ouverture du projet dans TOS. On les ignore donc pour qu'ils ne parasitent pas les diffs.
/sqlPatterns

Une fois cette configuration effectuée, il est possible de commiter puis de partager son travail sur un dépôt distant.

Note : lorsqu’on ouvre un élément dans Talend, son XML est modifié afin de rajouter un lock sur l’élément. Ces locks n’ayant aucune raison de remonter en gestion de configuration, je préconise de fermer dans TOS tous les éléments avant de les commiter (quitte à les réouvrir ensuite pour continuer à travailler dessus).

Un certain nombre de répertoires sont vides et ne seront donc pas mis en gestion de configuration par git. Cela ne gène pas le bon fonctionnement de l’ensemble.

Il est en revanche important de commiter le fichier talend.project, afin de permettre l’import du projet par d’autres développeurs.

Importer et travailler le projet

Plaçons-nous maintenant du point de vue d’un développeur qui compte travailler sur le projet. Il faut tout d’abord cloner le projet dans un répertoire temporaire :

1
2
cd /tmp
git clone git://gitdistantrepository/talendproject.git

Ensuite, dans l’écran d’accueil de Talend, il faut choisir Importer le ou les projet(s) existant en local à partir d’un répertoire temporaire que l’on vient de créer (/tmp/talendproject).

Import d'un projet Talend Open Studio

Import d'un projet Talend Open Studio

Attention : il est important que l’ensemble des développeurs nomment leur projet exactement de la même façon. En effet, lors de l’export des scripts de traitement, le nom du projet est utilisé dans le nom du package java du traitement. Aussi, si les développeurs n’ont pas le même nom de projet, les binaires qu’ils génèreront ne pourrons pas être combinés. En cas de livraison différentiele et de dépendances entre les traitements (tRunJob), on obtient des surprises du genre ClassNotFoundException

Une fois le projet importé, le répertoire temporaire peut être supprimé. En effet, l’import du projet copie l’intégralité de son contenu, y compris le dépôt git. Dès que le projet est importé, on peut donc travailler directement avec git dans le véritable répertoire du projet.

Il n’y plus qu’à…

Maintenant que vous savez comment contribuer à un projet TOS partager, je vous attends pour donner un coup de main si le projet vous intéresse ! Je ne manquerai bien sûr pas de vous prévenir dès qu’il sera créé !