OpCon Deploy :
industrialiser le déploiement de vos chaînes.

Qu'est-ce qu'OpCon Deploy ?

OpCon Deploy est l'outil de gestion des mises en production des chaînes OpCon. Il fait passer les définitions de schedules d'un environnement à l'autre, de la DEV vers la qualification puis la production, en gardant la trace de chaque version et de chaque action.

Son principe directeur tient en une ligne : on ne modifie jamais une chaîne directement en production. On la déploie en DEV, on la modifie, on la teste, on l'importe dans le référentiel sous une nouvelle version, puis on déploie cette version vers les environnements suivants.

Trois piliers

• Une application distincte. OpCon Deploy s'installe à part, avec sa propre base de données et son propre service. Il dialogue avec chaque environnement OpCon déclaré comme serveur.
• Un mécanisme de déploiement. À partir du référentiel, il pousse chaînes et scripts d'un environnement vers un autre, en une seule opération contrôlée.
• Un référentiel central. Il stocke les chaînes, les règles de transformation et l'ensemble des paramètres nécessaires aux déploiements.

Chaque version importée est figée : une définition n'est jamais réécrite dans le référentiel, ce qui permet de redéployer à tout moment une version antérieure. Chaque utilisateur OpCon Deploy est rattaché à un utilisateur OpCon, et toutes les actions sont auditées. On sait qui a déployé quoi, où et quand.

Point de vigilance

Le piège classique au démarrage : importer les chaînes dans le référentiel, puis laisser certaines équipes continuer à corriger directement en production. En quelques semaines, le référentiel ne reflète plus la réalité et le déploiement suivant écrase une correction faite à la main. Le jour où l'outil arrive, l'accès en modification à la production doit se refermer.

Comment fonctionne OpCon Deploy ?

Le référentiel, souvent appelé REF, occupe le centre du dispositif. Autour de lui gravitent les environnements OpCon : développement (DEV), qualification (QUA) et production (PRD). La production se contente de recevoir des versions et n'alimente jamais le référentiel.

Le circuit en quatre temps

Le circuit recommandé suit quatre mouvements :

1. le référentiel alimente la DEV OpCon avec la version courante de la chaîne ;
2. une fois la modification développée et testée, la chaîne remonte de la DEV vers le référentiel, où elle devient une nouvelle version ;
3. le référentiel déploie cette version en QUA, en appliquant les règles de transformation propres à cet environnement ;
4. après validation, la même version part du référentiel vers la PRD.

La DEV est le seul environnement qui renvoie des définitions vers le référentiel. Cette asymétrie fait la robustesse du modèle : tant que le circuit est respecté, ce qui arrive en production a transité par la qualification, sous le même numéro de version.

Import, simulation, déploiement, rollback

Quatre opérations structurent le quotidien :

• L'import extrait une définition d'un environnement source et la range dans le référentiel sous un nouveau numéro de version.
• La simulation déroule toutes les vérifications d'un déploiement sans rien modifier sur la cible. Elle est recommandée avant chaque mise en production.
• Le déploiement associe une version, un environnement cible, d'éventuelles règles de transformation et une description, puis applique le tout dans une transaction unique, en mode tout ou rien : en cas d'erreur, la définition existante reste intacte.
• Le rollback redéploie une version précédente et stable, ce qui ramène rapidement une chaîne à un état connu.

OpCon Deploy propose aussi un mode batch : des déploiements planifiés à une date et une heure données, ainsi que des fonctions d'import, de simulation et de déploiement appelables en ligne de commande. C'est la porte d'entrée vers une démarche CI/CD, où la promotion des chaînes s'enchaîne avec le reste de la livraison applicative.

Les règles de transformation

Selon l'environnement, une même chaîne tourne sur d'autres machines et avec d'autres comptes. Les règles de transformation adaptent la définition au moment du déploiement, sans dupliquer la chaîne. Elles interviennent à trois niveaux, dans cet ordre : le serveur, avec les règles par défaut de l'environnement cible appliquées automatiquement, puis le package, puis le déploiement lui-même pour un ajustement ponctuel.

Voici un exemple de transformation vers la qualification, avec des valeurs illustratives :

Point de vigilance

Piège fréquent : multiplier les règles ponctuelles, ajoutées au moment du déploiement. Elles dépannent une fois, puis plus personne ne sait pourquoi telle machine est remplacée lors de telle livraison. Une règle utile deux fois mérite de remonter au niveau du serveur.

Pourquoi le référentiel porte-t-il des valeurs de production ? La réponse se trouve dans les bonnes pratiques détaillées plus bas.

OpCon Deploy, DDI, ImpEx : pourquoi changer de méthode ?

Avant OpCon Deploy, deux méthodes servaient à promouvoir des chaînes : DDI et ImpEx. Beaucoup de plans de production en portent encore la trace, et leurs limites expliquent l'intérêt de l'outil.

DDI : trois étapes et beaucoup de manuel

SMADDI, pour SMA Dynamic Data Input, met à jour la base OpCon à partir de fichiers XML déposés dans des répertoires surveillés. Promouvoir une chaîne avec DDI suit trois étapes :

1. Extraire la chaîne avec l'utilitaire Schedule Extract, qui produit un fichier XML par chaîne.
2. Transformer à la main chaque champ qui change d'un environnement à l'autre, comme la machine d'exécution ou l'utilisateur de lancement, en éditant les balises XML.
3. Déposer le fichier dans le répertoire d'injection DDI de l'environnement cible.

Le procédé fonctionne, au prix de plusieurs fragilités :

• Une erreur d'injection se diagnostique difficilement, car les informations sont réparties entre plusieurs logs. Si la configuration d'un job pose problème, la chaîne est tout de même créée en cible, mais vide.
• Réinjecter une chaîne impose de la supprimer d'abord dans l'environnement cible, faute de quoi l'injection bute sur une chaîne déjà existante.
• Les chaînes interconnectées ou contenant des containers doivent être injectées dans un ordre précis : les sous-chaînes d'abord, la chaîne principale ensuite.
• Toutes les actions sont tracées sous le compte d'installation générique d'OpCon, opconsam. Retrouver l'auteur d'une modification après un incident relève alors de l'enquête.

ImpEx : un utilitaire en fin de vie

ImpEx, l'utilitaire Schedule Import Export, automatise davantage la démarche, avec ses propres limites :

• Une base Access annexe sert de base de transport entre les environnements.
• La compatibilité des connecteurs reste partielle : certains connecteurs de l'éditeur ou certains types de jobs échappent à l'outil.
• La maintenance s'est arrêtée, et l'utilitaire figure comme déprécié dans la documentation de l'éditeur au profit de solutions plus récentes.
• La cohérence des identifiants pose problème avec les scripts embarqués : le même script toto.exe peut porter l'ID 1 en QUA et l'ID 4 en PRD.
• Les transformations se limitent aux machines.
• Les dépendances externes entre deux chaînes OpCon distinctes demandent un traitement manuel.

Versioning et rollback : le point aveugle commun

Ni DDI ni ImpEx ne versionnent les objets, qu'il s'agisse des chaînes, des scripts ou des règles de transformation. Le versioning se gère à la main, dans un plan de maintenance dédié. Le rollback suit le même sort : comme les sauvegardes, il repose entièrement sur la discipline des équipes.

Combien de temps faut-il pour reconstruire la version de la veille d'une chaîne de cinquante jobs, quand la seule sauvegarde est un fichier XML dont personne ne connaît l'origine ?

Le bilan d'OpCon Deploy

Le premier inconvénient correspond en réalité au but recherché. Une correction d'une ligne qui contourne le cycle de livraison reste une source classique de régressions en production.

Point de vigilance

Piège à éviter : profiter du premier incident urgent pour rouvrir les modifications directes en production. La correction passe, la version du référentiel devient fausse, et le déploiement suivant réintroduit le bug. Pour les urgences, la bonne réponse consiste à accélérer le cycle : simulation, déploiement, validation rapide.

Bonnes pratiques Ntico pour OpCon Deploy

Neuf règles issues du terrain complètent le circuit en quatre temps. Elles se regroupent en trois familles.

Tracer chaque action

• Des comptes nominatifs. Chaque intervenant se connecte avec son propre compte, et le compte administrateur reste réservé à l'administration. L'audit d'OpCon Deploy n'a de valeur que si les noms qu'il enregistre désignent des personnes.
• Des actions commentées. Comme dans tout outil de versioning, une note courte accompagne chaque import ou déploiement. Six mois plus tard, c'est elle qui permet de distinguer la version 14 de la version 15.

Maîtriser les transformations

• Des transformations simples. Machines et utilisateurs batch couvrent l'essentiel des besoins. Les cas plus complexes justifient une règle dédiée, au cas par cas, parce que chaque règle ajoutée est une règle à maintenir.
• Des transformations hors production uniquement. Les règles visent les environnements de développement et de qualification. La production reçoit la définition telle qu'elle est stockée dans le référentiel.
• Des fichiers de transformation liés aux environnements. Rattachées directement à l'environnement cible, comme règles par défaut du serveur, les règles s'appliquent automatiquement à chaque déploiement, sans risque d'oubli.
• Des global properties gérées dans chaque environnement. Les variables OpCon se définissent directement sur chaque environnement, ce qui évite de les faire transiter par des règles de transformation.

Structurer environnements et livraisons

• Trois environnements au minimum. DEV, QUA et PRD permettent de tester chaque déploiement avant la production, en suivant le chemin DEV, puis QUA, puis PRD.
• Des objets de production recréés en DEV. Les machines, utilisateurs et autres objets OpCon de la production sont déclarés en DEV sous les mêmes noms. Ces objets fictifs existent pour faciliter les transformations et les déploiements.
• Des packages pour les livraisons groupées. Dès que plusieurs chaînes ou scripts partent ensemble, le package les déploie comme un tout et prend en charge les dépendances externes entre chaînes.