Boostez vos équipes IBM i : l’extraordinaire potentiel de Git

3. Qu’en est-il d’IBM i ?

Pourquoi stocker vos sources RPG ou COBOL dans Git/GitHub ? Quels sont les avantages par rapport aux outils de gestion du changement que l’on trouve traditionnellement dans les environnements IBM i ? Cela est-il même imaginable pour les nombreuses applications IBM i « Legacy » qui font encore tourner les opérations business les plus critiques du monde aujourd’hui ?

OUI ! Sans l’ombre d’un doute.

Dans mon travail de modernisation des processus et des environnements de développement IBM i, j’ai rencontré de nombreux professionnels de l’informatique qui sont encore sceptiques aujourd’hui. Les développeurs IBM i sont bizarrement, à bien des égards, à la fois considérés comme les inventeurs de DevOps (avec leurs processus structurés de gestion du changement et de déploiement, conçus pour un risque minimal, certains diraient que les développeurs de RPG ont inventé DevOps), et pourtant ils peuvent encore être les plus réticents au changement. Pour certains, la culture Git peut sembler à une génération (ou deux) de la leur. À ces sceptiques, je dirais : « Les applications IBM i ne sont-elles pas précisément conçues pour servir le business ? Leurs utilisateurs n’ont-ils pas des exigences de plus en plus pressantes ? Pourquoi donc les laisser de côté ? ». Git est d’autant plus pertinent pour les applications IBM i que ces applications précieuses et fiables encapsulent généralement les parties les plus critiques du système d’information et représentent souvent l’avantage concurrentiel unique sur lequel les entreprises IBM i ont construit leurs modèles de réussite business.

4. Les mythes Git à dissiper – les mythes techniques

Dans le cadre de votre mission visant à faire bénéficier l’IBM i des avantages de Git, vous rencontrerez sans doute des questions techniques qu’il vous faudra contrer. Quelques exemples classiques :

Q1. « Mais les applications IBM i – avec leur système de fichiers « propriétaire » – peuvent-elles réellement s’intégrer dans un outil standard comme Git ? »

Oui, elles le peuvent ! IBM a grandement contribué à la modernisation de la plate-forme IBM i au fil des ans. Et le reste du travail d’intégration pour rendre Git prêt à l’emploi sur IBM i a été développé par ARCAD Software. Avec l’intégration Git d’ARCAD, vous pouvez gérer 100% des composants de vos applications IBM i en tant que « sources » dans Git (et oui, même les objets dits « sans source »).

Q2. « Les applications IBM i sont trop volumineuses pour être gérées dans Git« .

Bien au contraire ! Parce que Git fonctionne par changements « delta », il est particulièrement bien adapté aux applications de grand volume comme celles sur IBM i.

Q3. « OK, peut-être qu’il n’y a pas d’obstacles techniques à Git sur IBM i – mais qu’est-ce que mon équipe y gagne ?

Le retour sur investissement (ROI) d’une approche DevOps est bien documenté et universellement compris. Mais au-delà du retour sur investissement, Git et Jenkins apportent tous deux des avantages mesurables à l’équipe de développement elle-même :

1. Plus de temps disponible « à valeur ajoutée » pour les développeurs

Lorsqu’ils sont utilisés ensemble, les outils d’automatisation DevOps Jenkins et ARCAD Builder permettent d’automatiser à 100% le processus de « build » (recompilation). Cela libère les développeurs de tâches fastidieuses, répétitives et souvent manuelles, telles que les contrôles d’intégrité et la maintenance des scripts. Les développeurs peuvent ainsi se concentrer sur leur véritable travail de création et de valeur ajoutée pour innover et soutenir le business !

2. Comprendre le code des autres

Quel développeur de la planète ne s’est pas creusé la tête pour comprendre pourquoi ce morceau de code a été écrit de cette façon ? Et a regardé autour de lui pour trouver quelqu’un qui puisse lui expliquer pourquoi ? (Seulement pour découvrir que l’auteur est parti il y a un moment et n’a jamais pensé qu’une documentation complète serait nécessaire !)

Ce genre de situation est courante et constitue un « gaspillage de temps » potentiel énorme et un goulot d’étranglement dans l’accélération de vos processus de développement. C’est également un domaine où les outils de collaboration comme GitHub offrent le plus grand avantage.

GitHub et d’autres vous permettent de remonter dans le temps, dans les moindres détails, pour comprendre les raisons qui se cachent derrière ce code et pourquoi il a été écrit de cette façon. En comprenant mieux la logique, vos modifications de code sont certainement plus rapides et beaucoup moins susceptibles d’introduire des défauts cachés.

De plus, avec GitHub, les mécanismes de la revue de code sont intégrés au processus standard. La revue par les pairs devient une partie intégrante du développement. Tous les échanges entre les développeurs et les explications qu’ils partagent sont stockés en toute sécurité pour une consultation ultérieure. Cet historique est une mine d’or de « renseignements » sur le code pour tout futur développeur…

Pour le prouver, considérons simplement la façon dont les développeurs de logiciels libres travaillent. Sans même se connaître, et souvent répartis géographiquement aux quatre coins du globe, ils développent et collaborent sur des projets très complexes de manière totalement décentralisée. Git rend tout cela possible. Ce n’est pas un hasard s’il existe littéralement des millions de référentiels d’applications open source sur GitHub !

3. « Pull Request » : un flux de validation pour la fusion de codes

L’autre grande contribution de GitHub à DevOps est le flux de validation pour la fusion des branches de code : le « pull request ». DevOps vise à automatiser les parties non créatives du développement de logiciels. Cela signifie tout sauf l’art du codage lui-même !

Plus l’automatisation est importante, plus le risque d’erreur est faible et plus votre système est sécurisé. Un processus entièrement contrôlable facilite les tâches liées au respect des réglementations en vigueur.

5. Comment l’équipe d’ARCAD peut-elle vous aider ?

Avec tous ces avantages – j’espère avoir réussi à dissiper certains des mythes sur Git, et vous avoir aidé à faire un pas de plus vers l’adoption de Git sur IBM i. Les clients d’ARCAD considèrent notre collaboration comme un élément essentiel dans le succès de leur projet DevOps sur IBM i. Les intégrations avancées de Git et la méthodologie spécifique de Git sur IBM i qui sont fournies par défaut avec ARCAD for DevOps rendent ces outils dîts « standards » enfin utilisables sur IBM i – avec un environnement de développement Git personnalisé suffisamment convivial pour embarquer les plus réticents des puristes IBM i… Le modèle hybride d’ARCAD permet même à vos développeurs 5250 de travailler aux côtés de vos développeurs RDi, tous partageant les mêmes puissantes fonctionnalités de versioning de Git !

Un autre avantage évident d’ARCAD lors de l’implémentation de Git et Jenkins sur IBM i est sans aucun doute l’architecture unique du référentiel de métadonnées d’ARCAD : ARCAD Metadata Repository. Chaque développeur, opérateur, testeur et responsable informatique tire profit de ce référentiel car il est mis à jour en temps réel au fur et à mesure que les développeurs codent. La connaissance des dépendances contenue dans ARCAD Metadata Repository offre un potentiel d’automatisation massif pour minimiser les risques et les coûts tout au long du cycle de vie du développement logiciel :

• Détection précoce des défauts grâce à l’automatisation des tests basée sur les dépendances, éliminant ainsi tout effort répétitif dans le processus d’assurance qualité
• Efforts de débogage / re-work / re-test / redéploiement rapides grâce à une connaissance détaillée des références croisées
• Revue par les pairs automatisé / contrôle de la qualité des codes pour détecter les failles de qualité et de sécurité au moment même où elles sont introduites
• Intégrations stables, transparentes et éprouvées avec les outils d’entreprise standard et multi-technologiques de l’industrie, notamment Git, Jenkins, Azure DevOps, Jira et ServiceNow.

Donnez du pouvoir à vos équipes IBM i – et constatez par vous-même le potentiel débridé de Git sur IBM i, consultez notre webinaire « Git Ahead »…