{"id":51252,"date":"2021-02-02T14:51:30","date_gmt":"2021-02-02T12:51:30","guid":{"rendered":"https:\/\/www.arcadsoftware.com\/?p=51252"},"modified":"2025-06-11T15:00:18","modified_gmt":"2025-06-11T13:00:18","slug":"true-git-les-bonnes-et-mauvaises-approches-de-git-sur-ibm-i","status":"publish","type":"post","link":"https:\/\/www.arcadsoftware.fr\/arcad\/infos-et-evenements\/blog-fr\/true-git-les-bonnes-et-mauvaises-approches-de-git-sur-ibm-i\/","title":{"rendered":"‘True Git’ – les bonnes et mauvaises approches de Git sur IBM i"},"content":{"rendered":"

Par Jeff Tickner <\/h3>\n<\/div><\/div><\/div>

Sommaire<\/h2>\n
    \n
  1. Le contr\u00f4le de source – avant et maintenant<\/a><\/li>\n
  2. Git sur IBM i \u2013 la friction et les d\u00e9fis<\/a><\/li>\n
  3. Les outils open-source ne peuvent pas g\u00e9rer le “Build” d’IBM i<\/a><\/li>\n
  4. Nouveaux outils, nouveau processus<\/a><\/li>\n
  5. Ne vous faites pas avoir<\/span><\/span>:<\/span><\/span> si ce n’est pas <\/span><\/span>G<\/span><\/span>it <\/span><\/span>push et <\/span><\/span>G<\/span><\/span>it <\/span><\/span>pull,<\/span><\/span> ce n’est pas Git<\/span><\/span><\/a><\/li>\n
  6. Int\u00e9gration ‘True Git’ avec ARCAD <\/a><\/li>\n<\/ol>\n<\/div>
    <\/div>\n

    1. Le contr\u00f4le de source – avant et maintenant<\/h2>\n

    Tous ceux d\u2019entre nous qui travaillent dans le domaine du d\u00e9veloppement d\u2019applications IBM i utilisent depuis des ann\u00e9es une forme de \u201ccontr\u00f4le de source\u201d<\/b> pour la gestion des versions de leur code RPG et COBOL. Jusqu\u2019\u00e0 pr\u00e9sent, les outils actuels de gestion de changement (CM) ont domin\u00e9 le march\u00e9 de l\u2019IBM i en fournissant un versionnage \u00e9l\u00e9mentaire des livraisons d\u2019applications, seulement une version de la source par livraison. Mais aujourd’hui, le terme \u201ccontr\u00f4le de source\u201d (SCM)<\/b> a pris une toute nouvelle signification.<\/p>\n

    La plus grande contribution est venue au monde de l\u2019open source. L\u2019\u00e9mergence de Git en tant qu\u2019outil de contr\u00f4le de source a de facto<\/span> radicalement chang\u00e9 notre fa\u00e7on de travailler <\/span><\/b>\u2013 pour le mieux, en permettant le versionnement incr\u00e9mental des changements, une plus grande visibilit\u00e9 et un merge facile. Alors pourquoi tant d\u2019entreprises IBM i ont-elles du mal \u00e0 r\u00e9aliser les avantages que le contr\u00f4le continu et distribu\u00e9 des changements par Git peut apporter ? La r\u00e9ponse se r\u00e9sume \u00e0 une sorte de collision entre deux mondes tr\u00e8s diff\u00e9rents. Dans cet article, nous allons r\u00e9v\u00e9ler comment combler ce foss\u00e9 et d\u00e9finir ce qui constitue une \u201cv\u00e9ritable approche Git\u201d qui apporte des avantages mesurables \u00e0 la fois aux \u00e9quipes traditionnelles et distribu\u00e9es.<\/span><\/p>\n<\/p>\n

    <\/div>\n

    2. Git sur IBM i \u2013 la “friction” et les d\u00e9fis<\/h2>\n

    Alors que de plus en plus d\u2019entreprises cherchent \u00e0 adopter Git comme outil de contr\u00f4le de source pour leurs syst\u00e8mes Legacy,<\/b> il y a souvent des \u201cfrictions\u201d et des r\u00e9ticences de la part des d\u00e9veloppeurs IBM i plus traditionnels. C\u2019est d\u2019autant plus ironique que l\u2019intention de DevOps est de r\u00e9duire les frictions avec son processus. Alors, o\u00f9 ces frictions se produisent-elles et que peut-on faire pour les r\u00e9soudre ?<\/p>\n

    Il existe deux grandes zones de friction : les outils utilis\u00e9s dans le processus DevOps et les personnes qui s\u2019adaptent \u00e0 ces outils et au nouveau processus.<\/p>\n

    La cause premi\u00e8re de cette friction est le passage des outils traditionnels et du processus Waterfall g\u00e9n\u00e9ralement utilis\u00e9s sur les syst\u00e8mes Legacy aux outils \u201cDevOps-friendly\u201d<\/b> et au processus Agile<\/b> couramment utilis\u00e9s sur d\u2019autres plateformes.<\/p>\n

    Je parle souvent de cette diff\u00e9rence comme de la m\u00e9thode \u201cpessimiste\u201d par rapport \u00e0 la m\u00e9thode \u201coptimiste\u201d. Pessimiste parce que le processus traditionnel verrouille le code de sorte qu\u2019un seul d\u00e9veloppeur puisse travailler dessus \u00e0 la fois (pessimiste = on ne peut pas faire confiance aux d\u00e9veloppeurs pour ne pas modifier le code des autres) ; optimiste parce que le processus DevOps permet une \u00e9dition collaborative (concurrente) et que les outils modernes facilitent cela (optimiste = tout finira par s\u2019arranger parce que le processus est con\u00e7u pour cela).<\/p>\n

    Cette m\u00e9thodologie \u201coptimiste\u201d constitue d\u00e9j\u00e0 un \u00e9norme changement culturel pour de nombreuses entreprises IBM i.<\/p>\n

    En principe, il y a deux obstacles principaux qui emp\u00eachent la client\u00e8le d\u2019IBM i d\u2019adopter les techniques modernes<\/b> de contr\u00f4le de source.<\/p>\n

    1) les outils \u201cmodernes<\/b>\u201d des autres plateformes ne peuvent pas fonctionner imm\u00e9diatement sur la plateforme IBM i, car ils ne traitent pas ou ne comprennent pas les exigences uniques de la technologie IBM i ; et<\/p>\n

    2) les d\u00e9veloppeurs IBM i traditionnels doivent apprendre et s\u2019adapter<\/b> \u00e0 un nouveau processus et \u00e0 de nouveaux outils.<\/p>\n<\/div><\/div><\/div>

    Git sur IBM i ? Les experts ARCAD r\u00e9pondent \u00e0 vos questions !<\/strong>
    \nEn direct et en face \u00e0 face sur le Web, nos experts r\u00e9pondent \u00e0 VOS questions sur Git et l\u2019open source.<\/strong><\/p>\n<\/div>

    Voir le webinar<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div>
    <\/div>\n

    3. Les outils open-source ne peuvent pas g\u00e9rer le “Build” d’IBM i<\/h2>\n

    Le “Build\u201d ou processus de recompilation constitue le plus grand d\u00e9fi en termes d\u2019outil<\/b>, car il n\u2019existe aucun outil de construction open-source capable de \u201cconstruire\u201d un projet legacy sans que quelqu\u2019un \u00e9crive toute une s\u00e9rie de scripts pour fournir les r\u00e8gles legacy. Pour de nombreux d\u00e9veloppeurs IBM i traditionnels, le foss\u00e9 est trop grand et la plupart ne sont pas dispos\u00e9s \u00e0 coder manuellement l\u2019automatisation suppl\u00e9mentaire requise.<\/p>\n<\/p>\n

    <\/div>\n

    4. Nouveaux outils, nouveau processus<\/h2>\n

    Sur le plan personnel, le changement culturel<\/b> pour les d\u00e9veloppeurs traditionnels et les responsables du d\u00e9veloppement vers un contr\u00f4le de source de type Git<\/b> peut-\u00eatre \u00e9crasant pour une organisation. Cela fait maintenant 8 ans que je forme les d\u00e9veloppeurs traditionnels \u00e0 ces nouveaux outils et processus, et j\u2019ai pu constater de visu les difficult\u00e9s qu\u2019ils rencontrent pour effectuer cette transition. Les d\u00e9veloppeurs essaient parfois de travailler de la mani\u00e8re (pessimiste) comme ils l\u2019ont toujours fait, puis tenter de \u201cforcer\u201d leurs modifications de code dans le nouveau processus en toute derni\u00e8re \u00e9tape. \u00c0 ce stade, le processus DevOps repr\u00e9sente en fait un surcro\u00eet de travail au lieu d’un d\u00e9veloppement simplifi\u00e9.<\/p>\n<\/div><\/div><\/div>

    <\/div>\n

    5. Ne vous faites pas avoir: si ce n’est pas Git push et Git pull, ce n’est pas Git<\/h2>\n

    Afin d\u2019essayer de faciliter ce changement de culture, de nombreux \u00e9diteurs legacy de \u201cgestion de changements\u201d (CM) sur IBM i ont tent\u00e9 de \u201craccourcir\u201d le processus de contr\u00f4le de source Git \u2013 je l\u2019appelle \u201cProcess Based Source Control\u201d (contr\u00f4le de source bas\u00e9 sur le processus) sur la base de certaines des informations que j\u2019ai vues l\u00e0-bas.<\/p>\n

    Le contr\u00f4le de source bas\u00e9 sur le processus est lorsque l\u2019interaction avec l\u2019outil de contr\u00f4le de source n\u2019est pas dirig\u00e9e par le d\u00e9veloppeur traditionnel, mais plut\u00f4t par le processus de gestion de changement (CM) de l\u2019\u00e9diteur lui-m\u00eame. Cette solution partielle permet aux d\u00e9veloppeurs non traditionnels qui sont \u00e0 l\u2019aise avec les nouveaux outils ET les langages traditionnels de travailler directement avec le contr\u00f4le de source. Cependant, les d\u00e9veloppeurs traditionnels continuent \u00e0 travailler avec le m\u00eame processus de gestion de changement qu\u2019ils connaissent bien, et ce n\u2019est que plus tard dans le processus que leurs changements sont pouss\u00e9s vers le contr\u00f4le de code source (SCM). Nous pouvons dire que cela permet \u00e0 l\u2019outil de contr\u00f4le de code source de fournir un suivi de leurs changements et de r\u00e9unir les deux types de d\u00e9veloppeurs \u00e0 un moment donn\u00e9. Normalement, lorsque les modifications sont apport\u00e9es \u00e0 la branche principale de contr\u00f4le de code source, elles sont \u00e9galement apport\u00e9es \u00e0 la \u201csource de production\u201d du syst\u00e8me legacy.<\/p>\n

    En revanche, cette m\u00e9thode ne permet pas d\u2019exploiter les nombreux avantages de Git, tels que les modifications simultan\u00e9es et les branchements. Le plus grand inconv\u00e9nient de cette approche, et de loin, est que les modifications apport\u00e9es par le d\u00e9veloppeur non traditionnel (directement dans Git) ne sont pas visibles par le d\u00e9veloppeur traditionnel (qui utilise le processus traditionnel de gestion de changements). Cela signifie qu\u2019un conflit de merge doit \u00eatre r\u00e9solu en dehors de l\u2019outil de gestion du changement bas\u00e9 sur le processus, directement dans Git (ligne de commande ou client), et le d\u00e9veloppeur IBM i traditionnel ne verra pas le r\u00e9sultat de cette r\u00e9solution avant la mise en production<\/u>. La plupart des entreprises seraient d\u2019accord pour dire que c\u2019est en fait pire<\/u> que le d\u00e9veloppement 100% traditionnel.<\/p>\n

    <\/div>\n

    6. Int\u00e9gration True Git avec ARCAD<\/h2>\n

    La meilleure m\u00e9thode est celle o\u00f9 l\u2019outil traditionnel de CM (gestion de changement) est si \u00e9troitement int\u00e9gr\u00e9 \u00e0 Git qu\u2019il permet une interaction directe avec le SCM.<\/b><\/p>\n

    Avec ce niveau d\u2019int\u00e9gration, le d\u00e9veloppeur est en mesure de voir toutes les branches, la source sur laquelle il travaille dans ces branches, de commencer \u00e0 partir d\u2019un utilisateur sp\u00e9cifique et de voir toute l\u2019activit\u00e9 pass\u00e9e et pr\u00e9sente<\/b>, de tirer la source actuelle lorsqu\u2019il fait un \u201ccheckout<\/b>\u201d, de push ses changements vers le SCM<\/b>, de pull des changements suppl\u00e9mentaires de SCM<\/b>, etc. directement dans l\u2019outil de gestion de changement. CECI est le v\u00e9ritable Git sur IBM i.<\/b> \u00c0 pr\u00e9sent, le d\u00e9veloppeur a le confort d\u2019un processus familier qui a \u00e9t\u00e9 \u00e9tendu avec des fonctionnalit\u00e9s suppl\u00e9mentaires au bout de ses doigts. Il n\u2019a pas \u00e0 apprendre la syntaxe de la ligne de commande pour r\u00e9soudre un conflit de merge et, surtout, il a une visibilit\u00e9 sur les changements qui se produisent autour de lui. Voil\u00e0 la v\u00e9ritable valeur du contr\u00f4le de code source dans le processus DevOps !<\/p>\n

    Choisir le bon chemin vers Git apporte des retours mesurables dans la vitesse et la qualit\u00e9 du d\u00e9veloppement d\u2019applications IBM i. Voici quelques-uns des gains de \u201cGit fait correctement\u201d :<\/b><\/p>\n