‘True Git’ – les bonnes et mauvaises approches de Git sur IBM i

3. Les outils open-source ne peuvent pas gérer le « Build » d’IBM i

Le « Build” ou processus de recompilation constitue le plus grand défi en termes d’outil, car il n’existe aucun outil de construction open-source capable de “construire” un projet legacy sans que quelqu’un écrive toute une série de scripts pour fournir les règles legacy. Pour de nombreux développeurs IBM i traditionnels, le fossé est trop grand et la plupart ne sont pas disposés à coder manuellement l’automatisation supplémentaire requise.

4. Nouveaux outils, nouveau processus

Sur le plan personnel, le changement culturel pour les développeurs traditionnels et les responsables du développement vers un contrôle de source de type Git peut-être écrasant pour une organisation. Cela fait maintenant 8 ans que je forme les développeurs traditionnels à ces nouveaux outils et processus, et j’ai pu constater de visu les difficultés qu’ils rencontrent pour effectuer cette transition. Les développeurs essaient parfois de travailler de la manière (pessimiste) comme ils l’ont toujours fait, puis tenter de “forcer” leurs modifications de code dans le nouveau processus en toute dernière étape. À ce stade, le processus DevOps représente en fait un surcroît de travail au lieu d’un développement simplifié.

5. Ne vous faites pas avoir: si ce n’est pas Git push et Git pull, ce n’est pas Git

Afin d’essayer de faciliter ce changement de culture, de nombreux éditeurs legacy de “gestion de changements” (CM) sur IBM i ont tenté de “raccourcir” le processus de contrôle de source Git – je l’appelle “Process Based Source Control” (contrôle de source basé sur le processus) sur la base de certaines des informations que j’ai vues là-bas.

Le contrôle de source basé sur le processus est lorsque l’interaction avec l’outil de contrôle de source n’est pas dirigée par le développeur traditionnel, mais plutôt par le processus de gestion de changement (CM) de l’éditeur lui-même. Cette solution partielle permet aux développeurs non traditionnels qui sont à l’aise avec les nouveaux outils ET les langages traditionnels de travailler directement avec le contrôle de source. Cependant, les développeurs traditionnels continuent à travailler avec le même processus de gestion de changement qu’ils connaissent bien, et ce n’est que plus tard dans le processus que leurs changements sont poussés vers le contrôle de code source (SCM). Nous pouvons dire que cela permet à l’outil de contrôle de code source de fournir un suivi de leurs changements et de réunir les deux types de développeurs à un moment donné. Normalement, lorsque les modifications sont apportées à la branche principale de contrôle de code source, elles sont également apportées à la “source de production” du système legacy.

En revanche, cette méthode ne permet pas d’exploiter les nombreux avantages de Git, tels que les modifications simultanées et les branchements. Le plus grand inconvénient de cette approche, et de loin, est que les modifications apportées par le développeur non traditionnel (directement dans Git) ne sont pas visibles par le développeur traditionnel (qui utilise le processus traditionnel de gestion de changements). Cela signifie qu’un conflit de merge doit être résolu en dehors de l’outil de gestion du changement basé sur le processus, directement dans Git (ligne de commande ou client), et le développeur IBM i traditionnel ne verra pas le résultat de cette résolution avant la mise en production. La plupart des entreprises seraient d’accord pour dire que c’est en fait pire que le développement 100% traditionnel.

6. Intégration True Git avec ARCAD

La meilleure méthode est celle où l’outil traditionnel de CM (gestion de changement) est si étroitement intégré à Git qu’il permet une interaction directe avec le SCM.

Avec ce niveau d’intégration, le développeur est en mesure de voir toutes les branches, la source sur laquelle il travaille dans ces branches, de commencer à partir d’un utilisateur spécifique et de voir toute l’activité passée et présente, de tirer la source actuelle lorsqu’il fait un “checkout”, de push ses changements vers le SCM, de pull des changements supplémentaires de SCM, etc. directement dans l’outil de gestion de changement. CECI est le véritable Git sur IBM i. À présent, le développeur a le confort d’un processus familier qui a été étendu avec des fonctionnalités supplémentaires au bout de ses doigts. Il n’a pas à apprendre la syntaxe de la ligne de commande pour résoudre un conflit de merge et, surtout, il a une visibilité sur les changements qui se produisent autour de lui. Voilà la véritable valeur du contrôle de code source dans le processus DevOps !

Choisir le bon chemin vers Git apporte des retours mesurables dans la vitesse et la qualité du développement d’applications IBM i. Voici quelques-uns des gains de “Git fait correctement” :

• Flexibilité du développement grâce à un véritable contrôle de version distribué
• Visibilité à 360 degrés des modifications apportées par les autres développeurs
• Merge facile des changements parallèles
• Livraison plus rapide de code et plus fiable
• Retour rapide vers un état stable du système

Si vous en êtes aux premières étapes de l’adoption de Git sur IBM i, vous êtes sur le point d’élever les capacités de votre équipe à un tout nouveau niveau de productivité et de précision. Ne vous contentez pas d’ajouter Git axé sur les processus pour pouvoir cocher la case indiquant que vous utilisez Git pour vos sources. Cela ne suffira pas, ni pour vos développeurs ni pour votre équipe de direction. Au contraire, adoptez le changement et UTILISEZ réellement Git pour en tirer de la valeur. Avec les bons outils, vos développeurs IBM i traditionnels apprendront les techniques SCM style Git et en verront les avantages, tant sur le plan conceptuel que dans leur travail quotidien. DevOps n’est pas seulement un mot à la mode, c’est un changement dans la façon de travailler qui permet aux développeurs de fournir du code de meilleure qualité plus rapidement. L’adoption d’une approche « true Git » sur IBM i avec des outils de gestion de code source qui s’intègrent étroitement au modèle Git est probablement l’étape la plus importante de votre voyage DevOps.