Les complexités cachées du déploiement de nouvelles versions sur IBM^® i

Nouvelle version de Rocket disponible^® Le DevOps est toujours une étape importante. Il représente des mois (voire des années) d'efforts de la part des équipes de développement, de test, de documentation et de support. Mais pour nous, chez IBM, c'est différent.^® Dans un écosystème, le processus de libération est rarement simple.

Intéressons-nous aux aspects moins visibles des lancements de produits: les défis liés à la compatibilité, aux mises à niveau et au support à long terme. Si chaque fournisseur et chaque équipe produit sont confrontés à des obstacles qui leur sont propres, ces trois thèmes récurrents sont ceux que j'ai souvent observés lors des cycles de lancement. Mais comment les entreprises peuvent-elles les surmonter ?

1. Suivre le rythme des mises à jour du système d'exploitation IBM i

IBM^® i continue d'évoluer grâce à des mises à jour technologiques fréquentes et des versions majeures périodiques. Chaque changement apporte des améliorations, mais aussi des risques potentiels pour les éditeurs de logiciels.

• Risques de compatibilité: Même de petits changements apportés à IBM i peuvent modifier le comportement de nos produits. Les API peuvent être obsolètes, les modèles de sécurité améliorés ou les outils système remplacés.
• Exigences en matière de tests: Avant chaque sortie, nous investissons massivement dans des tests sur plusieurs versions d'IBM i afin de garantir la stabilité. Cela nécessite non seulement des efforts techniques, mais aussi l'accès à des environnements de test exécutant chaque version prise en charge.

Ce que vous pouvez faire:

• Maintenir un laboratoire dédié d’environnements couvrant les versions IBM i prises en charge.
• Collaborer avec IBM dès le début du cycle de renouvellement technologique pour anticiper les changements radicaux.
• Fournir aux clients des matrices claires de support des versions IBM i.

2. Interdépendances avec des outils tiers

Les applications IBM i modernes sont rarement isolées. Notre produit s'intègre au contrôle de source ^Git®, aux plateformes CI/CD, aux systèmes de gestion des tickets et même aux solutions de sécurité. Le défi réside dans l'évolution indépendante de ces outils tiers.

• Dérive de version: Une nouvelle version d’un outil tiers peut soudainement interrompre notre intégration.
• Coordination des fournisseurs: Nous dépendons souvent des feuilles de route et des priorités d’autres fournisseurs, qui peuvent ne pas correspondre aux nôtres.

Ce que vous pouvez faire

• Créez des intégrations robustes et basées sur des normes dans la mesure du possible.
• Maintenez des pipelines de tests automatisés qui exercent des intégrations avec les dernières versions d'outils tiers.
• Offrir des conseils aux clients sur les versions tierces « certifiées » que nous avons testées.

3. Mise à niveau des clients à partir d'anciennes versions de notre logiciel

Tous nos clients n'effectuent pas régulièrement des mises à jour. Certains utilisent peut-être des versions de notre produit vieilles de cinq, dix, voire quinze ans, ce qui représente une stratégie risquée. Mettre à jour ses produits vers la dernière version se fait rarement en un seul clic.

• Plusieurs sauts requis: Parfois, l'architecture du produit a tellement évolué qu'une mise à niveau directe est impossible. Les clients peuvent être amenés à parcourir plusieurs versions intermédiaires.
• Conversion des données: les modifications de schéma et les transformations de configuration doivent être soigneusement gérées pour éviter toute perturbation.
• Aversion au risque: les clients s’inquiètent naturellement de l’impact sur les applications critiques.

Ce que vous pouvez faire

• Fournissez des chemins de mise à niveau clairs et une documentation décrivant les étapes requises.
• Dans la mesure du possible, fournissez des utilitaires de migration pour automatiser les transitions de données et de configuration.
• Proposez des services professionnels ou un support partenaire pour des mises à niveau complexes.

4. Prise en charge des anciennes versions lorsque les dépendances changent

Même après la sortie d'une nouvelle version, les anciennes versions restent utilisées. Leur prise en charge peut s'avérer complexe, notamment en cas de dépendances tierces comme Java.^® ou les compilateurs évoluent.

Terrain mouvant: Par exemple, lorsque Oracle^® ou si IBM modifie les politiques de support Java, les anciennes versions de notre produit peuvent ne plus fonctionner de manière fiable.
Attentes des clients: Certains clients s’attendent à ce que les anciennes versions restent entièrement prises en charge, même lorsque la plate-forme sous-jacente ne coopère plus.

Ce que vous pouvez faire

• Définir et communiquer une politique claire de cycle de vie du support (par exemple, versions N-2).
• Informez les clients à l’avance lorsque des modifications apportées par des tiers affectent des versions plus anciennes.
• Encouragez les mises à niveau proactives plutôt que la résolution réactive des problèmes.

5. Autres défis à mentionner

Les problèmes mentionnés ci-dessus sont courants, mais ils ne constituent en aucun cas les seules difficultés rencontrées lors de la livraison d'une nouvelle version. Par exemple:

• Localisation et support multilingue.
• Différences matérielles entre les sites clients.
• Exigences de conformité en matière de sécurité (par exemple, normes de cryptage).
• Personnalisations spécifiques au client qui compliquent les mises à niveau.
   

Réflexions finales

Le déploiement d'une nouvelle version logicielle sur IBM i ne se résume jamais à l'ajout de fonctionnalités. Chaque version est un exercice d'équilibre délicat entre priorités, compromis et gestion des risques. Pour Rocket Software, il s'agit de garantir la compatibilité, la continuité et la confiance des clients qui dépendent de notre produit pour leurs applications critiques.

Il existe rarement une approche unique et parfaite pour la publication de logiciels, surtout dans des environnements complexes comme IBM i. La réussite repose sur un mélange judicieux de tests et de validation rigoureux, d'une communication claire et cohérente, et de politiques bien définies qui guident le support et la planification du cycle de vie. Lorsque ces éléments sont en place, les organisations réduisent les risques, améliorent la fiabilité et renforcent leur crédibilité. En étant transparents sur les implications, les évolutions et les attentes, nous favorisons la confiance et consolidons les bases d'un partenariat et d'une performance à long terme.

IBM est une marque déposée d'International Machines Corporation

Oracle, Java, MySQL et NetSuite sont des marques déposées d'Oracle et/ou de ses filiales. Les autres noms peuvent être des marques commerciales de leurs détenteurs respectifs.

Git et le logo Git sont des marques déposées ou des marques commerciales de Software Freedom Conservancy, Inc., aux États-Unis et/ou dans d'autres pays.