Une checklist de promotion des objets JD Edwards EnterpriseOne pour les environnements DV, PY et PD est le document de processus qui distingue les installations où la production reste calme de celles où chaque mardi matin ressemble à une intervention d’urgence. La différence ne vient presque jamais du talent des développeurs. Elle vient du fait que tout le monde sait ce qui doit être vrai avant qu’un objet puisse passer d’un environnement au suivant, et que quelqu’un vérifie chaque point avant que le statut OMW ne change.

J’ai vu des environnements JDE où le processus de promotion se résumait à « demande à Marco si c’est prêt », et d’autres où une checklist de trente points était affichée au mur au-dessus du bureau du CNC. Le deuxième type d’organisation connaît moins d’incidents, récupère plus vite et dispose de développeurs qui ne redoutent pas les déploiements du lundi. La checklist elle-même n’a rien de magique. Sa valeur vient du fait que tout le monde — développeur, lead, équipe CNC et responsable métier — sait ce qui sera vérifié avant que le changement n’atteigne PD.

À quoi servent réellement DV, PY et PD

Le modèle à trois environnements dans JDE E1 se ressemble dans toutes les installations, mais il signifie quelque chose de légèrement différent dans chacune d’elles. DV, pour Development, est l’endroit où vit le code instable — un code qui peut ne pas compiler, casser le formulaire qu’il touche ou corrompre des données de test. Le seul engagement de DV est que tout ce qui s’y trouve appartient à un développeur capable de le corriger. PYEnvironnement Prototype ou Pristine — le niveau de test JDE où le code promu est exécuté sur une copie de données proche de la production avant d’être transféré vers PD. Le « Y » vient de l’ancien path code Pristine/Pristine-Yes. est l’endroit où vit le code stable qui a passé une revue par les pairs, testé sur des données suffisamment proches de la production pour révéler les anomalies que DV ne montrera jamais. PD, c’est la production : l’environnement où l’activité fonctionne, avec une exigence de disponibilité et d’exactitude.

L’erreur que je vois le plus souvent consiste à traiter PY comme « DV avec de meilleures données ». Ce n’est pas le cas. PY est un environnement de release candidate, et le code qui s’y trouve a déjà franchi une barrière de contrôle. Si trois développeurs y déposent du travail inachevé parce que « ce n’est que l’environnement de test », alors le véritable contrôle a été déplacé entre PY et PD, et PY ne remplit plus son rôle. L’équipe de test fonctionnel commence à trouver des anomalies qui auraient dû être détectées en DV, les cycles de régression s’allongent, et le rythme de promotion vers PD passe d’hebdomadaire à mensuel.

Chaque environnement vit dans son propre path code — DV920, PY920, PD920 dans une installation 9.2, avec les tables de données métier correspondantes dans des environnements comme DV920FA, PY920FA et PD920FA. La checklist ci-dessous suppose cette correspondance. Si votre installation utilise des noms non standard, remplacez-les, mais les barrières de contrôle et leur ordre restent les mêmes.

La barrière DV-vers-PY : ce qui doit être vrai avant que le code quitte les mains du développeur

La première barrière de promotion est celle où se concentre l’essentiel de la valeur, car les erreurs détectées ici coûtent quelques minutes, alors que les mêmes erreurs détectées à la barrière PY-vers-PD peuvent coûter plusieurs jours. Avant qu’un objet ne passe de DV à PY via un changement de statut OMWObject Management Workbench — l’outil JDE qui gère le check-in, le check-out, l’appartenance aux projets et les transitions de statut entre les path codes DV, PY et PD., la checklist de cette étape comprend généralement six points.

L’objet doit compiler proprement en DV. Pour les BSFN et les conversions de tables, ce point n’est pas négociable, et le journal de build doit afficher zéro erreur et zéro avertissement. Les avertissements comptent : dans les BSFN en C, ils se transforment en plantages à l’exécution bien plus souvent que les développeurs ne veulent l’admettre. Le spec merge avec la dernière baseline ESU standard doit être revu, en particulier pour les objets de retrofit, où le standard peut avoir évolué depuis le dernier rafraîchissement du développeur. La data structure utilisée par la fonction ou l’application doit être vérifiée par rapport aux points d’appel. Un nouveau champ ajouté à une DS peut casser chaque appelant qui n’a pas été recompilé, et l’ordre de recompilation fait partie du plan de promotion, ce n’est pas une réflexion de dernière minute.

Le projet OMW doit contenir tous les objets touchés, pas seulement l’objet principal : le formulaire qui appelle la nouvelle BSFN, la data structure utilisée par la BSFN, la table UDC lue par le nouveau code, ainsi que les lignes F7900 ajoutées pour les nouveaux codes d’erreur. Un projet qui promeut la BSFN mais oublie la nouvelle ligne F7900 échouera à l’exécution en PY avec un message d’erreur vide, que l’ingénieur d’astreinte mettra une heure à remonter.

La revue par les pairs est la barrière humaine qui détecte ce que les outils ne peuvent pas voir. Un second développeur qui lit le changement, même pendant dix minutes, trouve souvent l’hypothèse que le développeur initial n’avait pas remarquée : le numéro de société codé en dur, la comparaison de dates qui casse au changement d’année, ou la recherche qui retourne la première ligne alors qu’elle devrait agréger. Le statut 25 dans OMW est la convention habituelle pour « revu par les pairs et prêt à être promu ». Cette convention ne fonctionne que si chaque développeur la respecte.

La barrière PY-vers-PD : là où le risque métier est réellement maîtrisé

La deuxième barrière est celle où la checklist de promotion justifie pleinement son existence. Le code qui a franchi DV-vers-PY est techniquement correct isolément. Pour franchir PY-vers-PD, il doit fonctionner aux côtés de tout ce qui existe déjà en production, et le déploiement lui-même ne doit pas mettre l’activité en danger.

Le premier point de cette barrière est la validation des tests. La personne responsable du processus métier concerné — saisie des commandes, facturation, paie ou réapprovisionnement des stocks — doit avoir confirmé personnellement que le comportement en PY correspond à ce qui est attendu. Pas « l’équipe de développement pense que cela fonctionne », mais bien le responsable métier qui recevra les tickets de support si quelque chose tourne mal. Sans cette validation, le développeur reste la seule personne à avoir réellement touché le code, et aussi la seule personne à qui l’on reprochera l’incident si quelque chose casse.

Le plan de build du package doit être explicite avant l’ouverture de la barrière. Update package, foundation package ou full package ? Un update suffit pour les changements ER et les modifications de formulaires. Un foundation package est obligatoire dès que du code C BSFN compilé a changé — et « obligatoire » signifie redémarrage serveur, donc fenêtre d’indisponibilité coordonnée. Un full package doit rester réservé aux changements de Tools Release et aux déploiements cumulatifs trimestriels. Choisir le mauvais type de package soit ne livre pas réellement le changement — update sans foundation alors que du C a changé — soit impose à l’entreprise une interruption inutile lorsque qu’un update aurait suffi.

Le plan de rollback doit être écrit avant que le changement ne soit promu, pas après le déclenchement de l’alarme. Pour les changements ER, le rollback consiste à restaurer la version précédente de l’objet via OMW. Pour les changements C BSFN, il consiste à republier le foundation package précédent, ce qui peut prendre les mêmes 30 à 60 minutes que l’installation initiale. Pour les changements de Data Dictionary qui affectent de nombreux formulaires, il peut ne pas exister de rollback propre. Ce type d’information doit figurer dans la checklist de la barrière, et non être découvert à 02:00 lorsqu’un problème survient.

Contrôles de coexistence : quand le nouvel objet rencontre le reste de PD

Le risque caché d’une promotion se trouve rarement dans le nouvel objet lui-même. Il se trouve dans l’interaction entre ce nouvel objet et les dizaines d’objets standard et custom déjà présents en PD. La checklist doit prévoir un contrôle explicite de ces interactions, car rien d’autre ne les détectera de manière fiable.

L’état du spec merge est le premier contrôle de coexistence. Si le nouvel objet hérite d’un objet standard qui a changé entre le début du développement et la promotion planifiée, le spec merge doit être relancé, le diff revu et chaque conflit résolu. Ignorer cette étape, c’est ainsi qu’une modification custom de P4210 fonctionnant parfaitement en 9.2.6 cesse de fonctionner lorsque l’installation applique le cumulatif 9.2.8 — parce que le formulaire standard a changé sous la personnalisation.

Les dépendances d’appel BSFN constituent le deuxième contrôle. Une nouvelle BSFN qui appelle des BSFN existantes exige que ces fonctions appelées soient vérifiées en PD dans la version contre laquelle le nouveau code a été testé. Un nouveau champ ajouté à une data structure existante signifie que chaque appelant présent dans le projet OMW doit être inclus dans la même promotion — et que tout appelant externe au projet doit être identifié, testé en régression, puis soit intégré au package, soit explicitement déclaré non affecté.

Les ajouts UDC et Data Dictionary constituent le troisième contrôle. Les nouvelles valeurs UDC pour un type UDC existant sont généralement sûres. Les nouveaux types UDC référencés par du code ne le sont pas, car le type doit exister dans F0004 en PD avant que le code qui le lit ne s’exécute. Le point de checklist est donc : « vérifier que chaque nouvelle ligne F0004 et F0005 requise par le package existe en PD avant que le code qui en dépend ne soit promu ». Deux minutes de contrôle préalable peuvent éviter des heures de support.

Ce qui se passe au moment de la promotion vers PD

L’acte de promotion lui-même est l’étape la plus procédurale de toute la séquence, et c’est précisément pourquoi les décisions improvisées y causent le plus de dégâts. Une promotion vers PD est un événement planifié, pas une opération de type « faisons-le maintenant pendant que c’est calme ».

La fenêtre est annoncée à l’avance — à l’équipe d’exploitation, aux responsables métier et à toute personne dont les jobs batch s’exécutent pendant cette période. L’équipe CNC possède le transfert OMW et le build du package. Dans une installation correctement gouvernée, les développeurs ne promeuvent pas eux-mêmes leur propre code vers PD, à la fois pour des raisons d’audit et parce que la personne qui a écrit le code est la moins bien placée pour vérifier qu’il fonctionne dans un environnement propre.

La vérification post-promotion est le dernier point de la checklist, et celui qui est le plus souvent oublié. Pendant la même fenêtre de maintenance, un smoke test est exécuté sur le changement promu — une transaction de forme réaliste, de bout en bout, sur le chemin concerné, contre des données PD avec un compte de test identifié. Cette vérification prouve que le package a été construit, déployé et qu’il est appelable. Sans cette étape, le nouveau code s’exécute pour la première fois en PD lorsqu’un utilisateur réel l’utilise le matin ouvré suivant, et tout problème de déploiement devient un incident de production au lieu d’un rollback interne à la fenêtre de maintenance.

Pour approfondir l’aspect opérationnel du travail JDE, les articles connexes sur la stratégie de mise à niveau Tools Release, le retrofit des copies de standard et les harnais de test BSFN couvrent le contexte environnant. Le portfolio technique de ce site documente deux déploiements en production qui ont produit les modèles de checklist décrits ici.