Par Michel Mouchon | 11 mars 2020

Empower your IBM i teams: the extraordinary potential of Git

Le mouvement DevOps a créé un « vent de changement » nouveau dans la manière de gérer le développement d’applications, atteignant les coins les plus reculés de l’industrie et notamment notre cher IBM i.

DevOps a vu le jour en tant que prolongement des méthodologies de développement Agiles, avec l’ambition d’étendre les mêmes principes à l’ensemble du cycle de vie des applications, depuis les besoins initiaux jusqu’à la disponibilité opérationnelle de la nouvelle fonctionnalité pour les utilisateurs.

En substance, l’objectif premier de DevOps est de « servir le business » en fournissant des logiciels de meilleure qualité aussi rapidement que possible – en supprimant tous les obstacles potentiels à n’importe quel stade du cycle et en automatisant tout ce qui peut l’être.  Ayant l’avantage d’être open source, Git et Jenkins sont devenus les acteurs principaux (bien que d’autres existent et gagnent régulièrement du terrain).

Pour être acceptée sur IBM i, la domination absolue de Git exige une explication.  Dans cet article, nous allons démystifier Git et examiner sa pertinence sur la plate-forme IBM i en particulier.  Un certain nombre d’outils de collaboration sont étroitement liés à Git, GitHub étant le leader dans ce domaine.  Mais qu’est-ce que GitHub apporte exactement en plus de Git ?  Et dans quelle mesure un outil standard de l’industrie comme GitHub est-il adapté à un environnement de développement traditionnel sur IBM i ?

1. Se familiariser avec Git

Git est un gestionnaire de code source distribué qui suit les changements d’application via un mécanisme de validation « optimiste » pour les changements (les « commits »).  Le travail des développeurs est sécurisé et la traçabilité de toutes les modifications du code source est totale.  Ce mécanisme libère la créativité illimitée du développeur, car il peut revenir très facilement aux versions précédentes, comparer les différents niveaux de commit et consulter l’historique de toutes les modifications apportées, même mineures.  Le fait que Git soit entièrement décentralisé ne fait que renforcer l’autonomie et la liberté des développeurs.

2. GitHub : le pouvoir au développeur

GitHub est l’outil de collaboration de choix pour de nombreuses entreprises cherchant une plateforme d’hébergement de référentiels sur le web via Git. Il peut être utilisé aussi bien dans le Cloud que sur site. Avant tout, il organise et gère le travail d’équipe, mais il fournit également une interface graphique Web à Git ainsi que des fonctionnalités supplémentaires, notamment un workflow complet de validation du code.

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 !

  1. 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 !

  1. « 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 Open 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 Open 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 »

Webinar Git Ahead - from IBM i change mangement to Git

Boostez vos équipes IBM i !

Webinar

Constatez par vous-même le potentiel débridé de Git sur IBM i, consultez notre webinaire « Git Ahead »

A propos de l’auteur

Michel Mouchon

Michel Mouchon

CTO and VP of Strategy

Michel Mouchon occupe le poste de directeur technique chez ARCAD Software depuis 2000, jouant un rôle majeur dans la définition de la stratégie technique et la coordination des services de R&D, d’ingénierie et de conseil. Il joue un rôle majeur au sein de la société en tant que leader technologique autour du concept DevOps, en mettant l’accent sur la modernisation des applications, des méthodes et des outils.

Michel a développé des compétences hautement transversales en IT, en commençant sa carrière avec un double diplôme en électronique et ingénierie logicielle.
Le don de Michel pour la communication et son expertise sont reconnus par la communauté d’utilisateurs IBM i à l’international.

Contact us
Contact us .........................................
Book a demo