{"id":36991,"date":"2020-03-11T18:07:16","date_gmt":"2020-03-11T16:07:16","guid":{"rendered":"http:\/\/arcadsoftware.com\/?p=36991"},"modified":"2025-05-19T17:04:24","modified_gmt":"2025-05-19T15:04:24","slug":"boostez-vos-equipes-ibm-i-lextraordinaire-potentiel-de-git","status":"publish","type":"post","link":"https:\/\/www.arcadsoftware.fr\/arcad\/infos-et-evenements\/blog-fr\/boostez-vos-equipes-ibm-i-lextraordinaire-potentiel-de-git\/","title":{"rendered":"Boostez vos \u00e9quipes IBM i : l’extraordinaire potentiel de Git"},"content":{"rendered":"

Par Michel Mouchon <\/h3>\n<\/div><\/div><\/div>

Le mouvement DevOps a cr\u00e9\u00e9 un “vent de changement” nouveau dans la mani\u00e8re de g\u00e9rer le d\u00e9veloppement d’applications, atteignant les coins les plus recul\u00e9s de l’industrie et notamment notre cher IBM i.<\/p>\n

DevOps a vu le jour en tant que prolongement des m\u00e9thodologies de d\u00e9veloppement Agiles, avec l’ambition d’\u00e9tendre les m\u00eames principes \u00e0 l’ensemble du cycle de vie des applications, depuis les besoins initiaux jusqu’\u00e0 la disponibilit\u00e9 op\u00e9rationnelle de la nouvelle fonctionnalit\u00e9 pour les utilisateurs.<\/p>\n

En substance, l’objectif premier de DevOps est de “servir le business” en fournissant des logiciels de meilleure qualit\u00e9 aussi rapidement que possible – en supprimant tous les obstacles potentiels \u00e0 n’importe quel stade du cycle et en automatisant tout ce qui peut l’\u00eatre<\/strong>.\u00a0 Ayant l\u2019avantage d\u2019\u00eatre open source, Git et Jenkins sont devenus les acteurs principaux (bien que d’autres existent et gagnent r\u00e9guli\u00e8rement du terrain).<\/p>\n

Pour \u00eatre accept\u00e9e sur IBM i, la domination absolue de Git exige une explication.\u00a0 Dans cet article, nous allons d\u00e9mystifier Git et examiner sa pertinence sur la plate-forme IBM i<\/strong> en particulier.\u00a0 Un certain nombre d’outils de collaboration sont \u00e9troitement li\u00e9s \u00e0 Git, GitHub \u00e9tant le leader dans ce domaine.\u00a0 Mais qu’est-ce que GitHub apporte exactement en plus de Git ?\u00a0 Et dans quelle mesure un outil standard de l’industrie comme GitHub est-il adapt\u00e9 \u00e0 un environnement de d\u00e9veloppement traditionnel sur IBM i ?<\/p>\n<\/div>

Sommaire<\/h2>\n
    \n
  1. Se familiariser avec Git<\/a><\/li>\n
  2. GitHub : le pouvoir au d\u00e9veloppeur<\/a><\/li>\n
  3. Qu’en est-il d’IBM i ?<\/a><\/li>\n
  4. Les mythes Git \u00e0 dissiper – les mythes techniques<\/a><\/li>\n
  5. Comment l’\u00e9quipe d’ARCAD peut-elle vous aider ?<\/a><\/li>\n<\/ol>\n<\/div>
    <\/div>\n

    1. Se familiariser avec Git<\/strong><\/h2>\n

    Git est un gestionnaire de code source distribu\u00e9 qui suit les changements d’application via un m\u00e9canisme de validation \u00ab optimiste \u00bb pour les changements (les “commits”). Le travail des d\u00e9veloppeurs est s\u00e9curis\u00e9 et la tra\u00e7abilit\u00e9 de toutes les modifications du code source est totale. Ce m\u00e9canisme lib\u00e8re la cr\u00e9ativit\u00e9 illimit\u00e9e du d\u00e9veloppeur, car il peut revenir tr\u00e8s facilement aux versions pr\u00e9c\u00e9dentes, comparer les diff\u00e9rents niveaux de commit et consulter l’historique de toutes les modifications apport\u00e9es, m\u00eame mineures. Le fait que Git soit enti\u00e8rement d\u00e9centralis\u00e9 ne fait que renforcer l’autonomie et la libert\u00e9 des d\u00e9veloppeurs.<\/p>\n<\/p>\n

    <\/div>\n

    2. GitHub : le pouvoir au d\u00e9veloppeur<\/strong><\/h2>\n

    GitHub<\/a> est l’outil de collaboration de choix pour de nombreuses entreprises cherchant une plateforme d’h\u00e9bergement de r\u00e9f\u00e9rentiels sur le web via Git. Il peut \u00eatre utilis\u00e9 aussi bien dans le Cloud que sur site. Avant tout, il organise et g\u00e8re le travail d’\u00e9quipe, mais il fournit \u00e9galement une interface graphique Web \u00e0 Git ainsi que des fonctionnalit\u00e9s suppl\u00e9mentaires, notamment un workflow complet de validation du code.<\/p>\n<\/div><\/div><\/div><\/div><\/div>

    <\/div>\n

    3. Qu’en est-il d’IBM i ?<\/strong><\/h2>\n

    Pourquoi stocker vos sources RPG ou COBOL dans Git\/GitHub ?<\/b> 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\u00eame imaginable pour les nombreuses applications IBM i “Legacy” qui font encore tourner les op\u00e9rations business les plus critiques du monde aujourd’hui ?<\/p>\n

    OUI ! Sans l’ombre d’un doute.<\/p>\n

    Dans mon travail de modernisation des processus et des environnements de d\u00e9veloppement IBM i, j’ai rencontr\u00e9 de nombreux professionnels de l’informatique qui sont encore sceptiques aujourd’hui. Les d\u00e9veloppeurs IBM i sont bizarrement, \u00e0 bien des \u00e9gards, \u00e0 la fois consid\u00e9r\u00e9s comme les inventeurs de DevOps (avec leurs processus structur\u00e9s de gestion du changement et de d\u00e9ploiement, con\u00e7us pour un risque minimal, certains diraient que les d\u00e9veloppeurs de RPG ont invent\u00e9 DevOps), et pourtant ils peuvent encore \u00eatre les plus r\u00e9ticents au changement. Pour certains, la culture Git peut sembler \u00e0 une g\u00e9n\u00e9ration (ou deux) de la leur. \u00c0 ces sceptiques, je dirais : “Les applications IBM i ne sont-elles pas pr\u00e9cis\u00e9ment con\u00e7ues pour servir le business ? Leurs utilisateurs n’ont-ils pas des exigences de plus en plus pressantes ? Pourquoi donc les laisser de c\u00f4t\u00e9 ?”. Git est d’autant plus pertinent pour les applications IBM i que ces applications pr\u00e9cieuses et fiables encapsulent g\u00e9n\u00e9ralement les parties les plus critiques du syst\u00e8me d’information et repr\u00e9sentent souvent l’avantage concurrentiel unique<\/strong> sur lequel les entreprises IBM i ont construit leurs mod\u00e8les de r\u00e9ussite business.<\/p>\n<\/p>\n

    <\/div>\n

    4. Les mythes Git \u00e0 dissiper – les mythes techniques<\/strong><\/h2>\n

    Dans le cadre de votre mission visant \u00e0 faire b\u00e9n\u00e9ficier l’IBM i des avantages de Git, vous rencontrerez sans doute des questions techniques qu’il vous faudra contrer. Quelques exemples classiques :<\/p>\n

    Q1. “Mais les applications IBM i – avec leur syst\u00e8me de fichiers “propri\u00e9taire” – peuvent-elles r\u00e9ellement s’int\u00e9grer dans un outil standard comme Git<\/em> ?”<\/strong><\/p>\n

    Oui, elles le peuvent ! IBM a grandement contribu\u00e9 \u00e0 la modernisation de la plate-forme IBM i au fil des ans. Et le reste du travail d’int\u00e9gration pour rendre Git pr\u00eat \u00e0 l’emploi sur IBM i a \u00e9t\u00e9 d\u00e9velopp\u00e9 par ARCAD Software. Avec l’int\u00e9gration Git d’ARCAD, vous pouvez g\u00e9rer 100% des composants de vos applications IBM i en tant que “sources” dans Git (et oui, m\u00eame les objets dits “sans source”).<\/p>\n

    Q2. “Les applications IBM i sont trop volumineuses pour \u00eatre g\u00e9r\u00e9es dans Git<\/em>“.<\/strong><\/p>\n

    Bien au contraire ! Parce que Git fonctionne par changements “delta”, il est particuli\u00e8rement bien adapt\u00e9 aux applications de grand volume comme celles sur IBM i.<\/p>\n

    Q3. “OK, peut-\u00eatre qu’il n’y a pas d’obstacles techniques \u00e0 Git sur IBM i – mais qu’est-ce que mon \u00e9quipe y gagne<\/em> ?<\/strong><\/p>\n

    Le retour sur investissement (ROI) d’une approche DevOps est bien document\u00e9 et universellement compris. Mais au-del\u00e0 du retour sur investissement, Git et Jenkins apportent tous deux des avantages mesurables \u00e0 l’\u00e9quipe de d\u00e9veloppement elle-m\u00eame :<\/p>\n

      \n
    1. Plus de temps disponible “\u00e0 valeur ajout\u00e9e” pour les d\u00e9veloppeurs<\/strong><\/li>\n<\/ol>\n

      Lorsqu’ils sont utilis\u00e9s ensemble, les outils d’automatisation DevOps Jenkins et ARCAD Builder<\/a> permettent d’automatiser \u00e0 100% le processus de \u00ab build \u00bb (recompilation). Cela lib\u00e8re les d\u00e9veloppeurs de t\u00e2ches fastidieuses, r\u00e9p\u00e9titives et souvent manuelles, telles que les contr\u00f4les d’int\u00e9grit\u00e9 et la maintenance des scripts. Les d\u00e9veloppeurs peuvent ainsi se concentrer sur leur v\u00e9ritable travail de cr\u00e9ation et de valeur ajout\u00e9e pour innover et soutenir le business !<\/p>\n

        \n
      1. Comprendre le code des autres<\/strong><\/li>\n<\/ol>\n

        Quel d\u00e9veloppeur de la plan\u00e8te ne s’est pas creus\u00e9 la t\u00eate pour comprendre pourquoi ce morceau de code a \u00e9t\u00e9 \u00e9crit de cette fa\u00e7on ? Et a regard\u00e9 autour de lui pour trouver quelqu’un qui puisse lui expliquer pourquoi ? (Seulement pour d\u00e9couvrir que l’auteur est parti il y a un moment et n’a jamais pens\u00e9 qu’une documentation compl\u00e8te serait n\u00e9cessaire !)<\/p>\n

        Ce genre de situation est courante et constitue un “gaspillage de temps” potentiel \u00e9norme et un goulot d’\u00e9tranglement dans l’acc\u00e9l\u00e9ration de vos processus de d\u00e9veloppement. C’est \u00e9galement un domaine o\u00f9 les outils de collaboration comme GitHub offrent le plus grand avantage.<\/p>\n

        GitHub et d’autres vous permettent de remonter dans le temps<\/strong>, dans les moindres d\u00e9tails, pour comprendre les raisons qui se cachent derri\u00e8re ce code et pourquoi il a \u00e9t\u00e9 \u00e9crit de cette fa\u00e7on. En comprenant mieux la logique, vos modifications de code sont certainement plus rapides et beaucoup moins susceptibles d’introduire des d\u00e9fauts cach\u00e9s.<\/p>\n

        De plus, avec GitHub, les m\u00e9canismes de la revue de code sont int\u00e9gr\u00e9s au processus standard<\/strong>. La revue par les pairs devient une partie int\u00e9grante du d\u00e9veloppement. Tous les \u00e9changes entre les d\u00e9veloppeurs et les explications qu’ils partagent sont stock\u00e9s en toute s\u00e9curit\u00e9 pour une consultation ult\u00e9rieure. Cet historique est une mine d’or de “renseignements” sur le code pour tout futur d\u00e9veloppeur…<\/p>\n

        Pour le prouver, consid\u00e9rons simplement la fa\u00e7on dont les d\u00e9veloppeurs de logiciels libres travaillent. Sans m\u00eame se conna\u00eetre, et souvent r\u00e9partis g\u00e9ographiquement aux quatre coins du globe, ils d\u00e9veloppent et collaborent sur des projets tr\u00e8s complexes de mani\u00e8re totalement d\u00e9centralis\u00e9e. Git rend tout cela possible. Ce n’est pas un hasard s’il existe litt\u00e9ralement des millions de r\u00e9f\u00e9rentiels d’applications open source sur GitHub !<\/p>\n

          \n
        1. “Pull Request” : un flux de validation pour la fusion de codes<\/strong><\/li>\n<\/ol>\n

          L’autre grande contribution de GitHub \u00e0 DevOps est le flux de validation pour la fusion des branches de code : le “pull request”. DevOps vise \u00e0 automatiser les parties non cr\u00e9atives du d\u00e9veloppement de logiciels. Cela signifie tout sauf l’art du codage lui-m\u00eame !<\/p>\n

          Plus l’automatisation est importante, plus le risque d’erreur est faible et plus votre syst\u00e8me est s\u00e9curis\u00e9. Un processus enti\u00e8rement contr\u00f4lable facilite les t\u00e2ches li\u00e9es au respect des r\u00e9glementations en vigueur.<\/p>\n<\/p>\n

          <\/div>\n

          5. Comment l’\u00e9quipe d’ARCAD peut-elle vous aider ?<\/strong><\/h2>\n

          Avec tous ces avantages – j’esp\u00e8re avoir r\u00e9ussi \u00e0 dissiper certains des mythes sur Git, et vous avoir aid\u00e9 \u00e0 faire un pas de plus vers l’adoption de Git sur IBM i<\/strong>. Les clients d’ARCAD consid\u00e8rent notre collaboration comme un \u00e9l\u00e9ment essentiel dans le succ\u00e8s de leur projet DevOps sur IBM i. Les int\u00e9grations avanc\u00e9es de Git et la m\u00e9thodologie sp\u00e9cifique de Git sur IBM i qui sont fournies par d\u00e9faut avec ARCAD for DevOps<\/a> rendent ces outils d\u00eets \u00ab standards \u00bb enfin utilisables sur IBM i – avec un environnement de d\u00e9veloppement Git personnalis\u00e9 suffisamment convivial pour embarquer les plus r\u00e9ticents des puristes IBM i… Le mod\u00e8le hybride d’ARCAD permet m\u00eame \u00e0 vos d\u00e9veloppeurs 5250 de travailler aux c\u00f4t\u00e9s de vos d\u00e9veloppeurs RDi, tous partageant les m\u00eames puissantes fonctionnalit\u00e9s de versioning de Git !<\/p>\n

          Un autre avantage \u00e9vident d’ARCAD lors de l’impl\u00e9mentation de Git et Jenkins sur IBM i est sans aucun doute l’architecture unique du r\u00e9f\u00e9rentiel de m\u00e9tadonn\u00e9es <\/strong>d’ARCAD : ARCAD Metadata Repository. Chaque d\u00e9veloppeur, op\u00e9rateur, testeur et responsable informatique tire profit de ce r\u00e9f\u00e9rentiel car il est mis \u00e0 jour en temps r\u00e9el au fur et \u00e0 mesure que les d\u00e9veloppeurs codent. La connaissance des d\u00e9pendances contenue dans ARCAD Metadata Repository offre un potentiel d’automatisation massif pour minimiser les risques et les co\u00fbts tout au long du cycle de vie du d\u00e9veloppement logiciel :<\/p>\n