Industrialiser un projet Talend : Git, projets de référence, tests et CI/CD

Deux cycles de vie : le code et les bases

Dale Anderson rappelle qu’un projet réussi repose sur trois pieds : un cas d’usage bien défini, une technologie, et une méthode partagée par l’équipe. Pour le code, cette méthode est le cycle de vie du développement logiciel (SDLC) : comment on développe, teste, livre et déploie. Talend publie un guide de bonnes pratiques sur ce sujet ; il mérite d’être repris dans le guide de développement de l’équipe.

Il ajoute un second cycle, souvent oublié : celui des bases de données (DDLC). Les modèles de données évoluent eux aussi, et chaque environnement doit savoir :

• installer une base neuve, dans la version courante du modèle ;
• mettre à niveau une base existante d’une version à la suivante (création, modification, suppression d’objets) ;
• migrer les données quand la mise à niveau les bouscule, par exemple quand une table est scindée en deux.

Versionner le modèle de données, le documenter et tenir un dictionnaire des données évite que les jobs découvrent un changement de structure en production.

Le workspace, à sa place

Studio range les copies locales des projets dans un workspace. Dale Anderson constatait qu’il se trouve souvent, par défaut, dans le dossier du logiciel, et conseillait de le placer ailleurs, dans un dossier facile à identifier et à sauvegarder, selon une règle commune à toute l’équipe : une mise à jour de Studio ne doit pas toucher aux projets. La documentation actuelle ajoute deux consignes : pas d’espace ni de caractère spécial dans le chemin, et un workspace propre à chaque connexion distante.

Un projet de référence pour le code commun

Copier un joblet d’un projet à l’autre, ou exporter puis importer une routine, fonctionne… jusqu’à la première correction, qu’il faut reporter partout. La bonne réponse est le projet de référence : un projet dont les objets (joblets, routines, groupes de contextes, métadonnées) sont visibles dans les projets qui le référencent, en lecture seule selon Dale Anderson. Depuis Talend 7.0, la référence se déclare dans Studio, sur un projet distant : nœud Referenced project du référentiel, Reference Projects Setting.

Le code commun vit à un seul endroit ; une correction profite à tous les projets.

L’auteur recommande un seul projet de référence, deux ou trois dans des cas discutables : trop de références brouillent les dépendances. Leur usage et leurs règles s’écrivent dans le guide de développement.

Git plutôt que les versions de jobs

Chaque job porte, dans ses propriétés, un numéro de version (majeure et mineure) et un statut. Dale Anderson met en garde : ces versions servent au développeur seul, sans gestion de sources. Chaque incrément crée une copie complète du job dans le workspace, synchronisée avec le dépôt ; après une douzaine d’incréments, le projet s’alourdit et met longtemps à s’ouvrir.

La bonne pratique est de laisser la gestion de versions au dépôt : des branches pour les développements et les corrections, des tags pour les livraisons. Le dépôt ne stocke que les différences, et l’historique de chaque job reste lisible. Le schéma de numérotation des livraisons s’écrit, lui aussi, dans le guide.

Des tests de composants

Studio permet de créer un test de composant (test case) : clic droit sur un composant, Create Test Case. Le framework de test s’installe au besoin par le Feature Manager de Studio. Studio génère un job de test qui lit un fichier d’entrée, le passe au composant testé, écrit le résultat et le compare à un fichier de référence. Le test réussit si les deux fichiers sont identiques.

Studio génère ces tests en JUnit. Ce ne sont pas des tests unitaires au sens strict, mais ils sont précieux pour un tMap complexe ou un tJavaRow. Le test reste lié au composant : si son schéma change dans le job, le test en hérite. Un même test accepte plusieurs couples de fichiers d’entrée et de référence, pour essayer des données correctes, erronées, volumineuses ou limites.

Construire et déployer sans clic

Ces tests prennent tout leur sens dans une intégration continue. Talend CI Builder, un plugin Maven, compile les jobs depuis le dépôt Git, exécute leurs tests et publie les artefacts. Un profil Maven choisit la destination : nexus pour un dépôt Nexus ou Artifactory, cloud-publisher pour Talend Management Console, docker pour une image. Un orchestrateur comme Jenkins, GitLab CI ou Azure DevOps enchaîne ces étapes à chaque commit.

Un commit déclenche la construction et les tests ; le même artefact passe ensuite de DEV à PROD.

Le principe à retenir : on ne reconstruit pas un job pour chaque environnement. On construit un artefact, et on le promeut de DEV à TEST puis à PROD, en ne changeant que le contexte.

Composants personnalisés et Job Scripts

Avec plus d’un millier de composants, la palette couvre l’essentiel. Il reste des cas où une fonction spécialisée gagne à devenir un composant réutilisable. En 2016, Dale Anderson renvoyait vers Talend Exchange, la place de marché communautaire, et vers la perspective Component Designer de Studio, qui produit des composants en JavaJet.

Il terminait sa série sur les Job Scripts : la description d’un job sous forme de texte, à partir de laquelle Studio génère le job. Couplés à des métadonnées décrivant les jobs à produire, ils permettent de générer des familles de jobs semblables. Nous en donnons un exemple complet, avec la procédure de déploiement, dans l’article sur la structure d’un job.

Ce qui a changé depuis 2016

• Git a remplacé SVN : c’est la seule option sur Qlik Talend Cloud. La documentation décrit les flux de branches courants (feature branch, Gitflow).
• Les références entre projets se déclarent dans Studio depuis Talend 7.0, et non plus dans Talend Administration Center.
• Talend Exchange a été retiré de Studio en 2023 ; son contenu a été déplacé sur GitHub. Pour développer un composant, la documentation renvoie désormais au Talend Component Kit, un framework Java.

À retenir

• Deux cycles de vie. Le code (SDLC) et les bases de données (DDLC) se versionnent tous deux.
• Un workspace hors du dossier d’installation. Facile à trouver, à l’abri des mises à jour.
• Un projet de référence. Le code commun en un seul endroit, en lecture seule ailleurs.
• Git, pas les versions de jobs. Des branches pour développer, des tags pour livrer.
• Des tests de composants. Un fichier d’entrée, un fichier de référence, un verdict.
• Un artefact promu. Construit une fois par la CI, déployé de DEV à PROD.

Essayer dans Talend Studio

Pour créer un premier test de composant :

1. Si le menu Create Test Case n’apparaît pas, installez le framework de test par le Feature Manager. Créez un fichier noms.csv contenant dupont et martin, un nom par ligne, et un fichier attendu.csv contenant DUPONT et MARTIN.
2. Créez un job : un tFileInputDelimited (une colonne nom) relié à un tMap, qui produit nom avec l’expression row1.nom.toUpperCase(), relié à un tFileOutputDelimited.
3. Clic droit sur le tMap, Create Test Case, en gardant l’option Create a Test Skeleton. Studio crée et ouvre le job de test.
4. Dans la vue Test Cases du job, indiquez noms.csv comme fichier d’entrée et attendu.csv comme fichier de référence.
5. Lancez le test : il réussit. Modifiez l’expression en row1.nom.toLowerCase() dans le job, relancez : il échoue.

Sources

• Dale Anderson, Talend Job Design Patterns and Best Practices, partie 2, partie 3 et partie 4, Talend (version archivée).
• Aide Qlik Talend : références de projet, versions de jobs, bonnes pratiques Git, créer un test case, tests en intégration continue, options de construction de CI Builder et composants personnalisés.

Tout le mérite du contenu original revient à Dale Anderson ; l’adaptation à Talend Studio 8 et ses éventuelles erreurs sont de HeyData. Cet article fait partie de notre série sur les bonnes pratiques de conception de jobs Talend : découvrir la série.