Transition vers Git Source Control : Les avantages d’une approche progressive

Par Ray Bernardi

Dans le monde de l’IBM i, les systèmes de contrôle de version pour le développement de logiciels sont utilisés pour le suivi des modifications du code, l’historique du projet et bien d’autres choses encore. Les systèmes traditionnels de Source Control Management (SCM) utilisent des bibliothèques sur IBM i pour stocker les versions précédentes et effectuer ce tracking. D’autres options sont désormais disponibles, mais Git se distingue comme étant le plus populaire et le plus facile à utiliser. La plupart des équipes open source utilisent déjà Git. C’est devenu un standard dans le monde de l’informatique. Cependant, la transition vers Git peut s’avérer être une tâche fastidieuse.

Le facteur déterminant est votre base de code et sa complexité. La taille et la complexité de vos projets sont également des facteurs qui vont influencer la difficulté du passage à Git. C’est pourquoi la meilleure approche consiste à procéder par étapes, en apportant progressivement de petites modifications au processus de développement et en permettant aux développeurs de s’adapter.

Une transition en douceur avec une approche progressive

Chez ARCAD, nous aimons dire : rampez, marchez, courez, puis volez. Ce que nous voulons dire par là, c’est qu’il faut décomposer la transition vers Git en plusieurs étapes. Ne commencez pas par l’application la plus importante et la plus critique du système et ne visez pas une transition à 100% en un mois. Ne dites pas à votre équipe IBM i qu’elle doit apprendre toutes les spécificités de Git pour rester productive. En bref, faites de votre mieux pour minimiser les perturbations du flux de travail lors de cette transition.

ARCAD propose plusieurs « types » d’implémentation de Git, et il est possible de les combiner entre elles. Prenons un exemple quelconque d’une entreprise IBM i et voyons comment nous pourrions passer à Git. Cette entreprise compte 5 développeurs IBM i. Trois d’entre eux travaillent dans l’entreprise depuis longtemps et utilisent 5250 pour la plupart de leurs développements. L’un d’entre eux est nouvellement embauché et utilise RDi pour effectuer ses tâches de développement. Le dernier est un nouvel employé tout juste sorti de l’école, qui connaît Git, utilise VS Code et a vu RDi.

Dans une approche progressive, l’un des principaux objectifs est de réduire les risques. Commençons par là. En travaillant en équipe, choisissez d’abord une application qui sera la première à passer à Git. Comme je l’ai dit précédemment, choisissez une application facile à comprendre et dont le flux de travail est clairement défini. Dans l’exemple ci-dessus, le regroupement de différents développeurs semble justifier l’utilisation de la version centralisée de Git d’ARCAD pour commencer. Cette version évite aux développeurs IBM i, les complexités de Git, tout en leur permettant d’utiliser Git pour le SCM.

Dans cet exemple, nous transférons une petite partie de la base de code vers Git. En utilisant ce sous-ensemble, nous pouvons identifier et résoudre tous les problèmes potentiels sans impacter ou perturber le flux de travail existant. Cela vous permet de corriger les problèmes tout en restant productif pendant le processus.

Notre prochain objectif est l’éducation. Une fois que nous avons identifié le code avec lequel nous allons commencer, la configuration du logiciel commence. Nous créons des définitions d’application ; nous les connectons à votre dépôt Git. Nous nous assurons que la communication entre Git, ARCAD et vos outils d’automatisation fonctionne. Nous vous formons tout au long du processus afin que vous ayez une meilleure compréhension de Git, des concepts de Git et des pratiques de Git en relation avec le monde IBM i.

Un autre objectif est d’éliminer les silos de développement. Dans de nombreux cas, les entreprises avec lesquelles nous traitons utilisent déjà DevOps du côté ouvert du développement. Notre objectif est d’intégrer l’IBM i dans ce flux de travail existant, s’il est présent. L’idée est d’utiliser la même suite d’outils pour le « change control », quelle que soit la plateforme sur laquelle le changement se produit.

Une réelle collaboration entre l’équipe IBM i et l’équipe open source commence à se mettre en place. L’équipe IBM i peut se joindre au flux de travail agile déjà utilisé, sans avoir besoin d’apprendre une toute nouvelle façon de développer. Dans cet exemple, les développeurs 5250 peuvent accéder à l’application ARCAD aussi facilement que les développeurs RDi et VS Code. L’application communique avec Git. Lorsque les développeurs ouvrent une version d’ARCAD pour y apporter des modifications, une branche correspondante est ouverte dans le référentiel Git, ils développent sur cette branche « fonctionnalité ».

Lorsqu’ils font un checkout, la source provient de la branche associée. Elle est livrée dans un fichier physique source IBM i dans une bibliothèque IBM i. Ils utilisent l’éditeur de leur choix. Lorsqu’ils ont terminé, une option de menu ou un clic droit envoie leurs modifications au répertoire Git. Ils n’interagissent pratiquement pas avec celui-ci, mais leurs modifications se trouvent désormais sur une branche de fonctionnalités qui peut être fusionnée avec une branche de version et qui peut déclencher votre logiciel d’automatisation pour la distribuer là où elle doit aller. C’est le concept DevOps avec les composants IBM i.

Le but de cet article est de proposer une approche par étapes. Dans cet exemple, nous sommes passés d’une gestion classique des changements à l’aide des bibliothèques sur l’IBM i à l’utilisation de Git pour le contrôle des sources et nous l’avons connecté à ce qui se passe sur l’IBM i. Nous avons pris une base de code et un flux de travail gérables et nous avons adopté le nouveau processus. Nous avons également trouvé et corrigé des problèmes en cours de route.

Nous sommes maintenant entrés dans la phase suivante de notre projet. La phase d’apprentissage ne s’arrête jamais, mais maintenant, nous surveillons nos résultats. Nous recevons les commentaires des développeurs et nous améliorons le plan de migration si nécessaire pour éviter les mêmes problèmes lorsque nous nous attaquons à la prochaine base de code que nous voulons migrer.

Nous pouvons maintenant commencer à étendre la portée de notre migration vers Git. Nous pouvons ajouter des lignes de code plus complexes et étendre le flux de travail existant pour gérer des projets plus complexes. Les développeurs IBM i pourront comprendre le nouveau flux de travail, ils auront une bonne idée des branches de fonctionnalités et des branches de versions, et ils auront une bonne compréhension des concepts de Git.

Cette approche vous permet de minimiser les perturbations, de favoriser la collaboration, d’améliorer l’apprentissage et de permettre à vos équipes de réussir cette transition. ARCAD et Git travaillent ensemble et complètent leurs forces de manière réciproque. ARCAD connaît l’IBM i et Git est l’outil Open Source le plus populaire de l’industrie.

L’utilisation conjointe d’ARCAD et de Git améliorera la productivité, l’efficacité et la précision de l’équipe de développement IBM i. Vous réduirez le risque d’erreurs et de problèmes dans le cycle de développement. Vous moderniserez vos outils et votre personnel en même temps, progressivement. Vous pouvez ajouter de nouvelles fonctionnalités et de nouveaux outils à la pile d’outils DevOps au fur et à mesure que vous êtes prêt à les utiliser. Vous contrôlez le rythme.

En conclusion, une approche progressive est typiquement la meilleure approche pour une entreprise IBM i ayant “peu de visibilité sur Git” ? C’est le point de départ d’une évolution ultérieure. Le niveau de maturité de votre organisation dans le domaine de Git aura une grande influence sur la façon dont vous procéderez. ARCAD et Git sont une combinaison puissante qui peut vous aider quelle que soit l’approche que vous choisissez.