---
robots : noindex , nofollow
---
# Organisation des développements sur Eno

## Problématique générale de gestion du git flow sur Eno

Gérer plusieurs développements en parallèle, avec des rythmes d'avancement différents et potentiellement des mises en production séparées et dans un ordre inconnu au moment des développements (Eno complexe, des retours de recettes qui peuvent être longs, des besoins urgents qui peuvent apparaître, etc)...

## Gestion des branches Github

Les branches sur github sont : une branche master et des features branchs uniquement (plus d'acceptance ou de develop)

Une branche par feature (=fonctionnalité) c'est-à-dire l'équivalent d'un ticket trello (mettre le nom de la branche où les devs sont effectués dans le ticket)

### Normes pour les features branchs

- Nommage de la branche : un nom parlant, de la forme : `dev-{format(s)_de_sortie_eno}-{feature}`
avec :
- `{format(s)_de_sortie_eno}` : les formats de sorties Eno concernés (valeurs : "xforms", "ddi", "fo", "lunaticXml", "ddi2out" et "all" dans le cas où tous les formats sont concernés)
- `{feature}` : un libellé parlant du dév effectué
- Nom de version (dans le fichier pom.xml, balise "version") : mettre le nom de la branche tant qu'elle est en cours de dev (ex : `<Version>2.0.5-ddi-loopRefactor</Version>`.

## Déroulement d'un développement

### Généralité

Il est nécessaire d'avoir dans la carte
- les fichiers entrants et sortants pour implémenter les tests
- les échéances

Tous les échanges doivent passer par le trello (conversation, fichier, etc)

### Déroulement

- Création de la feature branch à partir de master (ou d'une autre feature branch dans le cas d'un dév dépendant. Dans ce cas, la première peut être recetter avant la deuxième)
- Le développeur peut "pusher" directement ses devs sur la branche (pas besoin de passer par une PR de son compte vers celui d'InseeFr).
- Lorsqu'un dev est terminé : appeler dans le ticket Trello @XXX un relecteur technique (car pas de branche entre master et celle de dev pour faire une PR dans notre cas, pour gérer des développements "concurrents" et la mise en prod d'une avant l'autre)
- Lorsque la relecture est fini et lorsque les dev sont validés : recette MOA
*(Dans le cas d'une relecture longue ou d'un développement urgent avec un relecteur non disponible sur le moment, les deux en parallèle)*
- Lorsque la recette est OK : PR sur master avec l'incrément du numéro de version par rapport à master

### Règles pour le versionnement pour la mise en prod (PR sur master)

Alignement sur les bonnes pratiques (https://semver.org/lang/fr/) : X.Y.Z avec
- incrément sur X dans le cas d'une montée de version majeure, c'est-à-dire non compatibilité ascendante
- incrément sur Y dans le cas d'une nouvelle fonctionnalité (avec compatibilité ascendante)
- incrément sur Z dans le cas d'un patch (bug, etc)

Mais qu'entend-on derrière la notion de fonctionnalité (et de non rétro-compatibilité) pour Eno ?

> Est-ce qu'une nouvelle fonctionnalité au sein d'un format (au hasard, la mise à dispo des boucles pour Xforms) est une fonctionnalité ? Ce n'est apparemment pas la logique qui a été utilisé jusque là. Et si je comprends bien, l'ajout d'une nouvelle fonctionnalité au sein d'un format ou la correction d'un bug est au même niveau (incrément de X que ce soit la correction d'une faute d'orthographe dans la page de garde des courriers ou un développement importants comme les boucles) ?
>
> Et que se passe-t-il pour tout développement au sein d'un format de sortie qui présente une non-compatibilité ascendante ? Ce qui va d'ailleurs se passer prochainement avec la mise en prod de la version comportant la génération XML Lunatic correspondant à la V2 Lunatic…
> J'aurais tendance à vouloir dire du coup qu'un est quand même sur une version majeure 3.0 pour Eno puisque les clients ont dû adapter leur appli pour l'utiliser… Mais ainsi, on n'est pas sur la logique qu'on avait adopter jusque là puisque, pour le passage à DDI3.3, on aurait déjà dû être un 2.0.X (il n'y avait pas de rétro-compatibilité).
>
> Bref : c'est quoi une fonctionnalité d'Eno ? Est-ce qu'on descend au niveau de la fonctionnalité au sein d'un format ou pas ? Quand augmente-t-on le Y et qu'est-ce qu'une version majeure ?
>
> Finalement, je pencherai pour descendre pour la fonctionnalité d'Eno au niveau fonctionnalité du format (exemple : l'ajout du rond point dans le format web serait une nouvelle fonctionnalité d'Eno dans ce cas).
>
>

> Avis d'Eric :
> Mon avis : Eno 3.0 ça peut pas être "on a ajouté le support Lunatic V2".
> Après le soucis de comptatibilité ascendante est tricky, pour bien faire, il faudrait séparer pré-proc de post-proc et formats par formats... Et consolider le tout...
> Bref, je retiendrais les choses comme ça :
>
> X : Evolution d'ENO-Core. Ex : Ajout du paramétrage.
> Y : Evolutions fonctionnelles : Nouvelles fonctionnalités. On est un peu orthogonale car la compatibilité ascendante d'un format n'est pas assurée. On peut imaginer un mécanisme pour signaler les versions de ce type (du genre celle de Lunatic V2.0 ou de DDI 3.3).
> Z : Les bugs.
>
> Voilà en très synthétique.

## Pour les livraisons (TodoList) :
- Exploiter la piste dépôt de plusieurs war sur le tomcat du CEI our plusieurs version d'Eno en dev et qf
- Sinon : faire "popper" des environnements (avec toujours en tête la dépendance Eno/Pogues…)
- Sinon : merger les branches à recetter (branche de déploiement "artificiel") pour mettre en QF
Dans tous les cas :
- variabliser les branches github à déployer et les environnements
- gestion dans le CI du pom.xml d'Eno-WS de la version d'Eno à récupérer (pour éviter de faire autant de branches que de celle d'Eno), uniquement pour les branches de dev (on doit garder la cohérence master Eno/master EnoWS pour la prod)
(une description plus complète des deux derniers points me fera surement du bien à la comprenette)

> En faisant directement :
>
> `mvn clean install -DmaVariable=maValeur`
> Ça sucharge les variables d'environnement (et ceux du pom.xml aussi)
>
> Donc il suffit de faire :
>
> ```
> LUNATIC_VERSION=...
> ENO_VERSION=...
> mvn clean install -Deno.version=${ENO_VERSION} -Dlunatic-model.version=${LUNATIC_VERSION} -Dfinal.war.name=${ENO_VERSION}
> ```
>
> Et tu auras ton livrable comme tu veux :)
>
> PS: pour choper la version d'Eno qui dans le pom tu fais :
> ENO_VERSION=${mvn org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate -Dexpression=project.version}
>
> (dans le projet Eno ou alors tu lui specifie le chemin vers le fichier pom.xm (via -f ./Eno/pom.xml) par exemple (mvn -f ... puis le reste de la commande)
>