La méthode " Transport Case " pour les déploiements Automic fait toute la différence entre une mise en production qui prend une heure et une autre qui ne prend que deux minutes. Dans des environnements comptant des dizaines ou des centaines de milliers d’objets, ce n’est pas simplement une question de commodité : c’est la différence entre des déploiements qui tiennent dans une fenêtre de maintenance et ceux qui ne le peuvent pas. La partie 7 du 3C Release Manager pour les Automic et Enablement Serie examine le chemin de déploiement alternatif proposé par le produit, les modifications à apporter à la configuration de l'environnement pour l'utiliser, et pourquoi cela est important pour toute organisation exécutant Automic à une échelle d'entreprise réelle.
Précédemment dans cette série
Cet article poursuit le3C Release Managerpour les Automic Enablement Serie. Si vous avez manqué les parties précédentes, voici où vous rattraper :
- Partie 1 — Fonction de cliché : capture de l'état complet d'un client Automic comme référence horodatée.
- Partie 2 — Fonction Diff : comparaison des instantanés pour détecter les changements d'objets et vérifier la transparence des versions.
- Partie 3 — Création d’environnements : définition des connexions techniques aux clients Automic qui rendent possibles les snapshots, les diffs et les déploiements.
- Partie 4 — Déploiements contrôlés : transport d'objets entre clients avec sauvegardes automatiques et chemin de retour arrière défini.
- Partie 5 — Ajouter des éléments associés : recenser les dépendances imbriquées des flux de travail jusqu'au niveau des scripts en une seule opération.
- Partie 6 — Principe du double contrôle : mise en œuvre technique de la double validation au sein du processus de déploiement.
Une fois que des versions gérées et sans dépendances sont en place, le prochain goulot d'étranglement auquel la plupart des équipes sont confrontées est le débit pur. Les clients Automic matures contiennent des dizaines de milliers d'objets, voire parfois des centaines de milliers. À cette échelle, c'est la méthode de déploiement elle-même qui devient le facteur limitant.
Pourquoi la méthode « Transport Case » est-elle importante pour les déploiements à grande échelle du Automic ?
Le chemin de déploiement par défaut dans la plupart des outils Automic repose sur le format XML : chaque objet est sérialisé en XML, transféré, puis réimporté côté cible. Cela fonctionne parfaitement bien pour un petit nombre d'objets. Mais l'évolutivité laisse à désirer dès que le nombre d'objets atteint plusieurs milliers. Une mise en production de 10 000 objets prenant une heure n'est pas rare avec l'approche XML — et une mise en production de plus de 100 000 objets commence à bouleverser complètement les fenêtres de maintenance.
Il ne s'agit pas d'un problème théorique. C'est l'une des raisons les plus courantes pour lesquelles les équipes Automic en entreprise regroupent leurs mises en production dans un nombre réduit de fenêtres plus longues, acceptent des temps d'arrêt prolongés ou évitent tout simplement certains transports jusqu'à ce qu'elles y soient absolument contraintes. La méthode Transport Case s'attaque à la racine du problème de débit en adoptant un mécanisme de transfert fondamentalement plus rapide.
Fonctionnement de la méthode « Transport Case » dans le 3C Release Manager
Dans la version 3C Release Manager pour Automic, chaque environnement peut être configuré pour utiliser l'un des deux chemins de déploiement. La différence réside dans la définition de l'environnement. Un environnement standard — par exemple, celui nommé AE24X0105XML pointant vers le client 105 — utilise le chemin classique basé sur XML. Un deuxième environnement peut pointer vers le même client mais être configuré avec les paramètres de cas de transport activés ; il est généralement nommé avec un suffixe TC, tel que AE24X0105TC.
Les paramètres système en haut de la configuration sont pratiquement identiques pour les deux. Ce qui change, c'est l'exigence de connexion supplémentaire : lorsque « Transport Case » est activé, l'environnement nécessite un point de terminaison REST en plus de la connexion JCP, car la méthode « Transport Case » fonctionne via l'API REST de Automic. La vérification des connexions dans la vue de l'environnement permet de s'assurer que les deux points de terminaison sont accessibles avant que l'environnement ne soit utilisé.
À partir de ce moment, la différence est invisible dans l'interface utilisateur. Les instantanés pris à partir d'un environnement Transport Case sont identiques aux instantanés XML : les objets sont toujours affichés dans une structure XML, la navigation est la même, et les mêmes flux de travail de diff et de déploiement s'appliquent. L'accélération se produit en arrière-plan, pas dans la façon dont le responsable des versions est opéré.
À quoi ressemblent réellement les nombres
La vidéo ci-dessous présente deux comparaisons côte à côte du même client 105, déployant 10 000 objets dans le client 106 :
- Aperçu (XML) : un peu plus de deux minutes.
- Instantané (boîte de transport) : légèrement plus long, car les structures XML sont toujours enregistrées et une boîte de transport est en outre générée pour chaque objet.
- Déploiement (XML) : 4 098 secondes, soit environ 66 minutes.
- Déploiement (valise de transport) : un peu plus de deux minutes.
Côté instantané, c'est à peu près comparable. C'est côté déploiement que la méthode Transport Case prend tout son sens : une réduction de 30 fois du temps de déploiement sur une charge de travail de 10 000 objets. Extrapolez cela à 400 000 objets ou plus – le type d'étendue de publication qui n'est tout simplement pas réaliste avec l'approche XML dans une fenêtre de changement normale.
Quels sont les changements concrets dans les opérations Automic ?
Passer à la voie plus rapide modifie quatre éléments importants pour toute personne gérant des calendriers de publication réels :
- Les fenêtres de maintenance redeviennent réalistes. Un déploiement de 60 minutes qui se réduit à deux minutes ne permet pas seulement de gagner du temps : il modifie les versions pouvant s'inscrire dans la fenêtre opérationnelle effectivement convenue avec l'entreprise. Cela élimine une raison courante de reporter ou de regrouper les transports.
- Les migrations de clients à grande échelle deviennent réalisables. Les déploiements portant sur plus de 100 000 objets — transferts complets de clients, refontes d'environnements, consolidations à grande échelle — passent du stade de “ théoriquement possible ” à celui de routine opérationnelle. La méthode XML ne s'adapte pas à de tels volumes ; l'approche REST, elle, le fait.
- Les fenêtres de risque se réduisent. Chaque minute pendant laquelle une mise à jour est en cours d'exécution est une minute pendant laquelle le client cible se trouve dans un état transitoire. Réduire ce délai d'un ordre de grandeur réduit directement la fenêtre d'exposition durant laquelle un problème peut survenir au cours du transfert.
- La fréquence des mises à jour peut augmenter. Lorsque les déploiements ne prennent pas trop de temps, les équipes cessent d'accumuler les modifications en attendant la prochaine grande fenêtre de mise à jour. Des déploiements plus modestes et plus fréquents deviennent alors possibles — ce qui correspond exactement à l'orientation préconisée par la gouvernance moderne des mises à jour.
Quand utiliser quelle méthode
L'approche basée sur XML n'est pas obsolète. Pour un petit nombre d'objets, des corrections ponctuelles ou des environnements où l'API REST n'est pas disponible, elle reste la solution par défaut la plus simple – moins de prérequis, pas de configuration d'endpoint supplémentaire. La voie la plus rapide est le bon choix lorsque le nombre d'objets est important, lorsque le temps de déploiement fait partie de la contrainte opérationnelle, ou lorsque la même version sera exécutée à plusieurs reprises sur plusieurs cibles.
Une approche pragmatique qui fonctionne bien en pratique : définir les deux environnements côte à côte, pointant vers le même client cible, et choisir le chemin par version. Les modifications de maintenance courantes passent par l'environnement XML ; les grands transports et les migrations complètes passent par l'environnement Transport Case. L'outil gère les deux de manière transparente.
Où cela s'insère-t-il dans le cadre de publication plus large
Le chemin le plus rapide ne remplace pas le reste du cadre de publication — il est un accélérateur en dessous. Les instantanés capturent toujours l'état. Les différences mettent toujours en évidence les changements. Les déploiements contrôlés écrivent toujours des sauvegardes et offrent un retour arrière. La collecte récursive d'objets connexes résout toujours les dépendances. La double validation impose toujours l'approbation. La méthode Transport Case rend tout cela suffisamment rapide pour être appliqué à l'échelle de l'entreprise.
En d'autres termes, la gouvernance et la performance cessent d'être un compromis. Les équipes n'ont plus à choisir entre un processus de mise en production correctement contrôlé et un processus qui se termine dans la fenêtre de changement — elles obtiennent les deux.
Points clés à retenir
- La méthode « Transport Case » est une voie de déploiement alternative qui utilise l'API REST de Automic à la place d'un transfert basé sur XML.
- L'activation est par environnement : activez les paramètres de transport dans la définition de l'environnement et ajoutez un point de terminaison REST en plus de la connexion JCP.
- Sur un benchmark de 10 000 objets, le temps de déploiement est passé d'environ 66 minutes (XML) à un peu plus de 2 minutes — même charge de travail, même cible, un chemin fondamentalement plus rapide.
- L'accélération est décisive à l'échelle de l'entreprise : les migrations de clients à grande échelle, les reconstructions complètes de l'environnement et les transports de plus de 100 000 objets deviennent réalistes au lieu d'être irréalistes.
- Les environnements XML et de transport peuvent coexister, pointant vers le même client cible, permettant de choisir le bon chemin par version.
Pour les organisations qui exploitent Automic à grande échelle, c'est l'une des fonctionnalités qui fait passer 3C Release Manager du statut d'outil utile à celui d'infrastructure opérationnelle.
Vous souhaitez évaluer les performances du produit par rapport à vos propres volumes de charge de travail Automic ? Prenez rendez-vous pour une consultation gratuite afin de discuter de vos besoins en matière de performances de déploiement — ou découvrez l'ensemble du parcours de formation Automic sur Tricise University pour développer les compétences de votre équipe en matière de déploiement à grande échelle.
