La semaine passée, durant un petit échange avec Jackson Derock, il est apparu que la gestion des versions dans Boomi pouvait s’avérer assez acrobatique chez certains clients, notamment ceux qui utilisent des numéros de version personnalisés. Il est donc opportun de faire le point sur cette fonctionnalité.
La gestion des versions est cruciale dans le développement logiciel et l’intégration, car elle permet de suivre les évolutions et d’assurer la compatibilité. La comprendre et avoir les idées claires sur son utilisation dans Boomi permet d’apprécier pleinement la plateforme.
Les Fondamentaux de la Sémantique des Versions
La numérotation des versions suit généralement le format MAJEUR.MINEUR.CORRECTIF (MAJOR.MINOR.PATCH) :
- Majeur : Incrémenté pour des changements majeurs non rétro-compatibles.
- Mineur : Incrémenté pour l’ajout de fonctionnalités rétro-compatibles.
- Correctif : Utilisé pour les corrections de bugs et les mises à jour de sécurité.
Des suffixes comme Alpha, Bêta, RC (Release Candidate) ou des versions 0.y.z indiquent l’état de développement (instable, pré-finale, etc.) avant la version Stable/GA (General Availability).
La Gestion des Versions dans Boomi
Boomi, en tant qu’iPaaS, propose ses propres mécanismes pour gérer les versions de ses composants et processus d’intégration. Bien que son approche puisse différer des systèmes de contrôle de version distribués comme Git, elle vise également à assurer la traçabilité et la stabilité des intégrations.
Historique des Révisions et Composants
Dans Boomi, les “processus” et les “composants” (tels que les maps, les profils de données, les connecteurs) sont les éléments fondamentaux. Boomi maintient un historique des révisions pour ces composants, permettant de revenir à des états antérieurs si nécessaire. Chaque modification d’un composant est enregistrée, offrant de larges possibilités de retour en arrière et un puissant utilitaire d’audit.
Les Composants Packagés : Numérotation Personnalisée
Un concept clé du versioning Boomi est le “composant packagé”. Une fois qu’un processus ou un ensemble de composants est validé (souvent après des tests en mode “Build”), il peut être encapsulé dans un “composant packagé”. Ce package représente une “photographie” ou un “snapshot” du processus et de toutes ses dépendances (maps, profils, connecteurs, etc.) à un moment précis.
Lors de la création d’un composant packagé, il est possible de lui attribuer un numéro de version alphanumérique personnalisé. Par exemple : [NomProjet]-[Majeur].[Mineur].[Correctif]-[Phase], tel que Vicat-1.0.14-Demo. Cette flexibilité permet aux équipes d’aligner les versions de leurs intégrations avec des conventions internes ou des cycles de publication externes.
Si aucun numéro n’est fourni, Boomi peut générer un ID de version incrémentale. L’ID de version reste associé au composant packagé, quel que soit l’environnement où il est déployé (développement, test, production).
Mais…
“Quelqu’un a dit une fois que tout ce que tu dis avant le mot ‘mais’ n’a vraiment aucune valeur.” — Jon Snow.
Une nuance importante doit être soulignée : si Boomi offre une flexibilité appréciable pour utiliser vos propres numéros de version pour les composants packagés, cette capacité s’accompagne de considérations clés :
Discipline Interne Essentielle : Boomi ne valide pas automatiquement la sémantique de vos versions personnalisées. La cohérence de la numérotation (respect des règles Majeur.Mineur.Correctif) repose entièrement sur la rigueur des équipes de développement.
Comparaisons Détaillées : Obtenir un “diff” précis et visuel entre deux versions packagées spécifiques peut nécessiter des étapes manuelles ou l’utilisation d’outils externes, là où d’autres systèmes de contrôle de version excellent nativement.
Compléments Externes pour les Besoins Avancés : La collaboration via la fonctionnalité “Branch & Merge” est native à Boomi. Cependant, pour des besoins de gestion de code plus complexes — stratégies de branchement sophistiquées ou “pull requests” typiques de Git — une orchestration via des outils externes reste nécessaire.
En somme, la “facilité” de gestion des versions personnalisées dans Boomi est optimisée par la mise en place de processus internes clairs et rigoureux, et, pour les scénarios les plus complexes, par une intégration réfléchie avec des outils externes (Jenkins, Azure DevOps…) de gestion du code source.
Pour ceux qui sont allés au bout de cette publication, j’espère les retrouver aussi motivés en septembre lors des petits ateliers de travail que nous préparons sur l’APIM (legacy), l’APIM Cloud et la révolution Agentique BOOMI.
Merci de votre attention.