Par Jeff Tickner
Sommaire
1. Le contrôle de source – avant et maintenant
Tous ceux d’entre nous qui travaillent dans le domaine du développement d’applications IBM i utilisent depuis des années une forme de “contrôle de source” pour la gestion des versions de leur code RPG et COBOL. Jusqu’à présent, les outils actuels de gestion de changement (CM) ont dominé le marché de l’IBM i en fournissant un versionnage élémentaire des livraisons d’applications, seulement une version de la source par livraison. Mais aujourd’hui, le terme “contrôle de source” (SCM) a pris une toute nouvelle signification.
La plus grande contribution est venue au monde de l’open source. L’émergence de Git en tant qu’outil de contrôle de source a de facto radicalement changé notre façon de travailler – pour le mieux, en permettant le versionnement incrémental des changements, une plus grande visibilité et un merge facile. Alors pourquoi tant d’entreprises IBM i ont-elles du mal à réaliser les avantages que le contrôle continu et distribué des changements par Git peut apporter ? La réponse se résume à une sorte de collision entre deux mondes très différents. Dans cet article, nous allons révéler comment combler ce fossé et définir ce qui constitue une “véritable approche Git” qui apporte des avantages mesurables à la fois aux équipes traditionnelles et distribuées.
2. Git sur IBM i – la « friction » et les défis
Alors que de plus en plus d’entreprises cherchent à adopter Git comme outil de contrôle de source pour leurs systèmes Legacy, il y a souvent des “frictions” et des réticences de la part des développeurs IBM i plus traditionnels. C’est d’autant plus ironique que l’intention de DevOps est de réduire les frictions avec son processus. Alors, où ces frictions se produisent-elles et que peut-on faire pour les résoudre ?
Il existe deux grandes zones de friction : les outils utilisés dans le processus DevOps et les personnes qui s’adaptent à ces outils et au nouveau processus.
La cause première de cette friction est le passage des outils traditionnels et du processus Waterfall généralement utilisés sur les systèmes Legacy aux outils “DevOps-friendly” et au processus Agile couramment utilisés sur d’autres plateformes.
Je parle souvent de cette différence comme de la méthode “pessimiste” par rapport à la méthode “optimiste”. Pessimiste parce que le processus traditionnel verrouille le code de sorte qu’un seul développeur puisse travailler dessus à la fois (pessimiste = on ne peut pas faire confiance aux développeurs pour ne pas modifier le code des autres) ; optimiste parce que le processus DevOps permet une édition collaborative (concurrente) et que les outils modernes facilitent cela (optimiste = tout finira par s’arranger parce que le processus est conçu pour cela).
Cette méthodologie “optimiste” constitue déjà un énorme changement culturel pour de nombreuses entreprises IBM i.
En principe, il y a deux obstacles principaux qui empêchent la clientèle d’IBM i d’adopter les techniques modernes de contrôle de source.
1) les outils “modernes” des autres plateformes ne peuvent pas fonctionner immédiatement sur la plateforme IBM i, car ils ne traitent pas ou ne comprennent pas les exigences uniques de la technologie IBM i ; et
2) les développeurs IBM i traditionnels doivent apprendre et s’adapter à un nouveau processus et à de nouveaux outils.
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.
