To Git or not to Git ?

Êtes-vous prêt pour Git ?

Posez la question autour de vous : « Quel outil pour gérer nos sources ? » La réponse tombe avant même la fin de la phrase : « Git, bien sûr ! » Plus personne ne se demande si c'est pertinent. Git est devenu une évidence, un standard, presque un réflexe.

Sur IBM i, pourtant, la question mérite d'être posée. Non pas parce que Git serait un mauvais outil, c'est un excellent outil, mais parce qu'il repose sur des hypothèses que notre patrimoine applicatif ne respecte pas toujours. Ayant pratiqué un gestionnaire de sources essentiel pendant plus de 10 ans en mode natif IBM i, puis interfacé avec Git, voici mon retour d'expérience.

Ce que Git sait faire… et ce qu'il ignore

Git gère des sources, c'est-à-dire du texte. Il le fait remarquablement bien : historique, branches, fusions, comparaisons.

Mais sur IBM i, un source n'est que la moitié de l'histoire. Ce qui s'exécute, ce sont des objets : programmes, programmes de service, fichiers physiques et logiques, écrans. Et entre ces objets existe un réseau de dépendances. Modifiez un fichier physique, et c'est une cascade de recompilations qu'il faut orchestrer dans le bon ordre.

Git n'en a pas la moindre idée. Pour lui, un DDS est un fichier texte comme un autre.

Un ALM natif, lui, gère conjointement les sources, les objets et les références croisées. C'est tout son intérêt.

Le mariage de la carpe et du lapin

Il est aujourd'hui possible d'interfacer certains ALM natifs avec Git. Le partage des rôles est le suivant :

• Git prend la main sur les sources ;

• Un ALM natif (surtout celui que je connais 👏) gère les objets compilés ;

• une branche Git est associée à une version ALM, qui contient une copie des sources de la branche et les objets issus de leur compilation ;

• à la mise en production, la branche est fusionnée dans la branche principale, et sources et objets rejoignent le référentiel natif ALM.

Le référentiel objets ALM reste la référence. Le référentiel sources ALM devient subordonné à Git, mais cette phase de réintégration reste indispensable : c'est elle qui met à jour les références croisées de l’ALM.

Ça fonctionne. Mais on vit désormais avec deux référentiels, des sources dupliqués et une synchronisation à maîtriser. Chaque couche ajoutée est un point de défaillance potentiel et un sujet de formation supplémentaire.

Là où Git brille vraiment

Soyons honnêtes : Git apporte des choses que l'ALM natif ne sait pas faire.

La recomposition des livraisons. Avec Git, une release est le résultat de la fusion de plusieurs features. Si le contenu de la release est remis en cause en cours de route, on peut recomposer un autre ensemble de features. En ALM natif, ce n'est pas possible.

Attention toutefois : la recomposition n'est gratuite que côté sources. Côté objets, un nouvel assemblage implique de recompiler et de retester l'ensemble.

Et surtout, ce besoin est rare. En une longue carrière de consultant, je ne l'ai rencontré que chez un seul client.

La revue de code. C'est pour moi le véritable atout de Git, et une pratique quasi inconnue du monde IBM i. Avant d'intégrer une modification, un collègue consulte les écarts, les commente et valide. C'est un formidable levier de qualité et de transmission de connaissances. Nous aurions tout intérêt à l'adopter, avec ou sans Git.

L'intégration continue. On me répondra : « Mais il n'y a pas de tests automatisés sur IBM i ! » C'est vrai. Les tests unitaires se font encore manuellement, et même en démarrant aujourd'hui avec un outil comme RPGUnit, il faudra des années pour constituer un patrimoine de tests suffisant. Mais l'intégration continue ne se résume pas aux tests : compilation automatique de la branche, analyse statique, contrôle des règles de codage, rapport d'impact. Tout cela est accessible dès le premier jour.

L'outillage et l'attractivité. VS Code (surtout), RDi (de moins en moins) : les outils modernes sont conçus autour de Git. Et un jeune développeur connaît Git, rarement les ALM natifs.

Quant à l'argument des équipes mixtes, où IBM i, Java et web partageraient le même outil, je le trouve plus théorique que réel. Sur le terrain, je n'ai vu que des équipes centrées sur leur technologie, dont les déploiements se coordonnent par concertation. Si le besoin est d'orchestrer des livraisons multi-plateformes, y en a pas des masses, faut aller chercher un éditeur en Savoie pour en avoir un.

Le coût caché : le Release Manager

Git a un prix organisationnel. Qui décide de ce qui entre dans une release ? Qui fusionne ? Qui arbitre les conflits ?

Dans la plupart des organisations, la réponse s'appelle le gestionnaire de livraisons, le Release Manager. Un poste qui n'existait pas avec les ALM natifs, où le chef de projet et les développeurs géraient eux-mêmes leurs versions.

Nuançons : ce besoin dépend largement du modèle de branches. Un Git Flow complet, avec ses branches develop, release et hotfix, demande un chef d'orchestre. Un modèle plus léger, à branches courtes fusionnées fréquemment, peut s'en passer. Mais les sites IBM i qui adoptent Git choisissent souvent le modèle le plus lourd, sans en avoir le besoin.

Le vrai sujet : pessimiste ou optimiste

Voici à mon sens le point le plus important, et le moins discuté.

Les ALM natifs d'IBM i et des grands systèmes IBM fonctionnent en mode pessimiste : dès qu'un source est mis en maintenance, il est verrouillé. Le développeur qui arrive ensuite est immédiatement prévenu qu'une fusion sera nécessaire. Le problème est connu dès le départ.

Git fonctionne en mode optimiste : chacun travaille de son côté, et l'on réconciliera à la fin. On ne découvre le conflit qu'au moment de fusionner la branche dans la branche principale, parfois des semaines plus tard, quand plus personne n'a le contexte en tête.

Ce pari optimiste fonctionne très bien sur des sources courts, comme c'est la bonne pratique en C, C++ ou Java. La probabilité que deux développeurs touchent la même zone est faible.

Mais sur un programme RPG de plusieurs milliers de lignes ? Tout le monde passe par la même boucle principale, ajoute des zones dans les mêmes déclarations, modifie la même sous-routine de contrôle. Le conflit n'est plus une exception, c'est la règle.

Des parades existent : branches courtes, réintégration régulière de la branche principale dans la branche de travail, voire verrouillage de fichiers. Mais ce sont des disciplines d'équipe, pas des garanties. Précisément la rigueur que le mode pessimiste imposait par construction.

Le mode pessimiste n'est pas parfait non plus : chacun a connu le correctif urgent bloqué par un source verrouillé. Mais au moins, la fusion à venir est connue et tracée.

Autrement dit : le mode pessimiste est une protection adaptée au code monolithique ; le mode optimiste est une récompense accordée au code modulaire. Adopter Git sans modularité, c'est retirer la protection sans toucher la récompense.

Les monstres dans le placard

Je ne défends pas les sources monstrueux. Je n'ai jamais réussi à m'en sortir avec. On m'a enseigné la programmation modulaire à la fac à la fin des années 80, et elle n'a rien perdu de sa pertinence.

Mais ces monstres sont une réalité. Une horrible réalité, présente dans la plupart des patrimoines IBM i.

Git ne crée pas ce problème. Il le révèle, brutalement, là où le mode pessimiste permettait de vivre avec depuis trente ans.

Êtes-vous prêt pour Git ?

Au fond, la question n'est pas « Git ou pas Git ». C'est « votre code et votre organisation sont-ils prêts pour Git ? ». Quelques questions pour vous situer :

1. Vos sources font-ils majoritairement moins de quelques centaines de lignes ?

2. Vos traitements sont-ils découpés en procédures et en programmes de service ?

3. Avez-vous déjà une pratique de revue de code, même informelle ?

4. Vos releases sont-elles susceptibles d'être recomposées en cours de route ?

5. Savez-vous qui fera les fusions et qui arbitrera les conflits ?

Trois « non » ou plus ? La réponse honnête est : pas encore.

Ce qui ne veut pas dire jamais. Il ne faut jamais dire “jamais”.

Une migration vers Git peut être l'occasion de lancer la modularisation de votre patrimoine, à condition de l'assumer comme un projet à part entière et non comme un effet de bord. Et rien ne vous empêche, dès demain, d'adopter la revue de code avec vos outils actuels.

To Git ? Oui, si… Et ce « si » mérite qu'on s'y arrête.