Projets et environnements Apache Hop : du dev à la prod sans dupliquer vos pipelines

Vous avez construit votre premier pipeline, il tourne, tout va bien. Puis vient le moment de le passer en recette, et là : le chemin du fichier source est écrit en dur, la connexion pointe encore sur la base de développement, et vous vous retrouvez à dupliquer le pipeline « juste pour la prod ». C’est exactement le problème que les projets et les environnements d’Apache Hop viennent résoudre.

Ce mécanisme est l’une des différences les plus nettes avec Pentaho Data Integration, où l’on bricolait souvent la même chose à coups de fichiers kettle.properties et de scripts maison. Dans Hop, c’est un concept de premier ordre, intégré à l’interface comme à la ligne de commande.

Prérequis

Apache Hop 2.19.0 (sortie le 17 août 2026) ou une version récente
Java 21 installé sur la machine
Un pipeline fonctionnel, même trivial, pour servir de cobaye

1. Projet et environnement : qui fait quoi

La distinction est simple à énoncer et c’est elle qui structure tout le reste :

Le projet porte la logique : vos pipelines, vos workflows, vos métadonnées, votre documentation. C’est ce que vous versionnez dans Git.
L’environnement porte l’infrastructure : l’adresse du serveur de base de données, les identifiants, les répertoires d’entrée et de sortie. C’est ce qui change entre votre poste, la recette et la production.

La règle qui découle de tout ça, et que la documentation officielle formule clairement : n’utilisez les variables de projet que pour ce qui est réellement propre au projet. Tout ce qui prend une valeur différente selon la machine — connexions bases de données, serveurs mail, chemins — appartient à l’environnement.

2. Créer un projet dans Hop GUI

Dans la barre d’outils de Hop GUI, cliquez sur le bouton Add a new project. La boîte de dialogue demande :

Name — le nom du projet, par exemple facturation
Home folder — le dossier racine, typiquement votre dépôt Git
Configuration file (relative path) — laissez project-config.json
Metadata base folder — par défaut ${PROJECT_HOME}/metadata
Data Sets CSV Folder — par défaut ${PROJECT_HOME}/datasets
Unit test base path — par défaut ${PROJECT_HOME}
Parent project to inherit from — default sauf besoin particulier

Notez que les valeurs par défaut sont déjà exprimées avec ${PROJECT_HOME}. Ce n’est pas cosmétique : cette variable est posée automatiquement par Hop et pointe sur le Home folder que vous venez de saisir. Tant que vous l’utilisez, votre projet reste déplaçable d’une machine à l’autre.

Hop crée alors un fichier project-config.json dans le dossier du projet, et enregistre la référence au projet dans le hop-config.json global (situé dans le dossier config de votre installation Hop, ou ailleurs si vous avez défini la variable d’environnement HOP_CONFIG_FOLDER).

Bon réflexe dès maintenant : définissez HOP_CONFIG_FOLDER en dehors du dossier d’installation de Hop. Vos configurations survivront ainsi à une mise à jour de version.

3. Le réflexe `${PROJECT_HOME}`

Ouvrez un pipeline existant et regardez vos transforms de lecture de fichier. Si vous y trouvez C:\donnees\clients.csv ou /home/philippe/input/clients.csv, remplacez par :

${PROJECT_HOME}/input/clients.csv

Hop vous aide sur ce point : lorsque vous sélectionnez un fichier via le sélecteur, il réécrit automatiquement le chemin en utilisant les variables applicables. Quand plusieurs variables pourraient convenir, c’est le chemin le plus long — donc le plus spécifique — qui l’emporte.

4. Créer un environnement

Après la création du projet, Hop propose spontanément de créer un environnement. Vous pouvez aussi passer par le bouton Add a new environment. Les champs :

Name — facturation-dev
Purpose — à choisir parmi Development, Testing, Acceptance, Production, Continuous integration, Common build
Project — le projet associé, ici facturation
Configuration files — un ou plusieurs fichiers JSON contenant vos variables

Point important, et c’est une recommandation explicite de la documentation : stockez les fichiers de configuration d’environnement en dehors du dossier du projet. Typiquement dans un dépôt Git distinct, à droits restreints. Votre code métier se partage largement ; les identifiants de la base de production, non.

Une arborescence qui fonctionne bien :

~/projets/
├── facturation/              ← dépôt Git du projet
│   ├── project-config.json
│   ├── metadata/
│   ├── pipelines/
│   └── workflows/
└── config-environnements/    ← dépôt Git séparé, accès restreint
    ├── facturation-dev.json
    ├── facturation-recette.json
    └── facturation-prod.json

5. Externaliser les variables de connexion

Dans l’éditeur d’environnement, le bouton d’édition ouvre le fichier de configuration et vous permet d’y saisir des couples clé-valeur. Définissez par exemple :

DWH_HOST      = localhost
DWH_PORT      = 5432
DWH_DATABASE  = facturation_dev
DWH_USER      = hop_dev
DWH_PASSWORD  = motdepasse_dev
INPUT_FOLDER  = /data/dev/input

Puis, dans votre connexion de base de données Hop, remplacez chaque valeur en dur par la variable correspondante : ${DWH_HOST}, ${DWH_PORT}, etc. La connexion, elle, reste dans les métadonnées du projet et se versionne sans risque, puisqu’elle ne contient plus aucun secret.

Si votre projet contient déjà beaucoup de variables disséminées, ne les recopiez pas à la main : la fonction Import variables parcourt le projet à la recherche des expressions ${NOM_VARIABLE} et pré-remplit le fichier d’environnement avec ce qu’elle trouve.

6. Basculer d’un environnement à l’autre

Dupliquez le fichier facturation-dev.json en facturation-prod.json, ajustez les valeurs, créez un second environnement pointant dessus. Dans Hop GUI, il vous suffit désormais de sélectionner l’environnement dans la barre d’outils pour que l’ensemble de vos pipelines change de cible. Aucune modification dans les pipelines eux-mêmes.

C’est le moment de vérité de tout l’exercice : si un pipeline échoue après bascule, c’est qu’il reste une valeur en dur quelque part.

7. La même chose en ligne de commande

Tout ce qui précède se scripte, ce qui est indispensable pour une chaîne CI/CD. Création du projet :

hop-conf.sh --project-create \
  --project facturation \
  --project-home /opt/projets/facturation

Création de l’environnement :

hop-conf.sh --environment-create \
  --environment facturation-prod \
  --environment-project facturation \
  --environment-purpose Production \
  --environment-config-files /opt/config/facturation-prod.json

Et pour alimenter un fichier de variables sans ouvrir l’interface :

hop-conf.sh --config-file /opt/config/facturation-prod.json \
  --config-file-set-variables DWH_HOST=dwh.interne,DWH_PORT=5432

Enfin, l’exécution d’un pipeline dans un environnement donné :

hop-run.sh \
  -j facturation \
  -e facturation-prod \
  -r local \
  -f ${PROJECT_HOME}/pipelines/chargement-clients.hpl \
  -l BASIC

Les options principales de hop-run :

Option	Forme longue	Rôle
`-j`	`--project`	Nom du projet
`-e`	`--environment`	Nom de l’environnement
`-f`	`--file`	Fichier `.hpl` ou `.hwf` à exécuter
`-r`	`--runconfig`	Configuration d’exécution
`-p`	`--parameters`	Paramètres, format `NOM=VALEUR` séparés par des virgules
`-s`	`--system-properties`	Propriétés système, même format
`-l`	`--level`	Niveau de log : `NOTHING`, `ERROR`, `MINIMAL`, `BASIC`, `DETAILED`, `DEBUG`, `ROWLEVEL`
`-lf`	`--logfile`	Fichier de sortie des logs

Sous Windows, remplacez hop-run.sh par hop-run.bat et hop-conf.sh par hop-conf.bat.

8. Comprendre la portée des variables

Hop ne raisonne pas en « liste de priorités » mais en portées imbriquées : une variable est locale à l’endroit où elle est définie, et héritée à partir de là. Du plus large au plus local :

Propriétés système — héritées par la JVM et par tout le reste
Environnement — hérité par les configurations d’exécution
Configurations d’exécution — héritées par le pipeline ou le workflow
Pipeline / workflow
Objets de métadonnées — hérités à l’endroit où ils sont chargés

En pratique : une variable définie dans l’environnement est visible partout en aval, et un paramètre passé à l’exécution d’un pipeline précis ne contamine pas le reste.

Deux syntaxes complémentaires méritent d’être connues : $[valeur] pour les valeurs hexadécimales — pratique pour un séparateur non imprimable —, et #{nom:clé:élément} pour les résolveurs de variables basés sur les métadonnées, qui permettent d’aller chercher un secret dans un coffre plutôt que dans un fichier JSON.

Ce que vous avez gagné

Un seul jeu de pipelines pour tous vos environnements. Un dépôt Git qui ne contient aucun mot de passe. Une bascule dev/recette/prod qui tient dans un menu déroulant ou dans une option -e. Et, accessoirement, la possibilité de confier votre projet à un collègue sans passer une heure à lui expliquer quels chemins modifier.

Le prochain sujet naturel, une fois ce socle en place : automatiser l’exécution avec Hop Server et intégrer hop-run dans une chaîne CI/CD.

Pour aller plus loin

Projects and Environments — documentation officielle
Hop Conf — l’outil de configuration en ligne de commande
Hop Run — toutes les options d’exécution
Variables — portée et syntaxes

Projets et environnements Apache Hop : du dev à la prod sans dupliquer vos pipelines

Prérequis

1. Projet et environnement : qui fait quoi

2. Créer un projet dans Hop GUI

3. Le réflexe ${PROJECT_HOME}

4. Créer un environnement

5. Externaliser les variables de connexion

6. Basculer d’un environnement à l’autre

7. La même chose en ligne de commande

8. Comprendre la portée des variables

Ce que vous avez gagné

Pour aller plus loin

Se former à Apache Hop

Apache Hop — Fondamentaux

Apache Hop — Perfectionnement et industrialisation

Migrer de Pentaho Data Integration vers Apache Hop

Un projet Apache Hop ? Parlons-en.

3. Le réflexe `${PROJECT_HOME}`