Par Alan Ashley
Que vous soyez un client actuel d’ARCAD que vous n’ayez pas encore de processus de contrôle de code source ou que vous vouliez passer de votre processus actuel à un qui utilise Git, vous êtes au bon endroit ! ARCAD Software est le seul distributeur à offrir une transition plus fluide pour vos équipes de développement avec une mise en œuvre facile et un passage rapide au processus de contrôle de code source Git. Je ne peux pas en dire trop pour le moment, mais il est question de « Build ». Et c’est là qu’ARCAD entre en jeu.
Pour commencer, il convient de déterminer votre processus actuel et vos besoins futurs :
- Disposez-vous d’un contrôle des sources, qu’il s’agisse d’une tierce personne ou d’un contrôle « manuel » ?
- Votre gestion de durée de vie des applications ressemble-t-elle davantage à une sorte de Far West où tout est permis ?
- En êtes-vous encore à une version à la fois ?
- Avez-vous un dépôt Git dans votre entreprise vers lequel votre équipe peut être transférée ?
- Voulez-vous un développement simultané simple et plus fonctionnel ?
- Voulez-vous passer à des normes modernes ?
- Voulez-vous sortir l’IBM i de son silo et l’intégrer à l’entreprise ?
Ce ne sont là que quelques-unes des questions qui peuvent définir votre environnement ALM actuel et futur. Mais lorsqu’il est temps de passer à une méthodologie plus moderne, telle que l’utilisation de Git, il n’y a qu’une seule vraie solution, celle d’ARCAD Software. De nombreux fournisseurs prétendent prendre en charge Git, mais ils n’utilisent pas ses fonctionnalités lorsqu’il s’agit d’utiliser des branches et des fusions, des push/pulls ou des webhooks. Ne vous préoccupez pas des termes, car ARCAD se chargera de la plupart des tâches lourdes dans ces domaines. Vous remarquerez que j’ai omis volontairement le terme « build ».
1. Pourquoi donc de nombreuses personnes se tournent-elles vers l’utilisation d’un dépôt de sources centralisé ?
Cette évolution découle de l’aspect « Open-Source » du monde de la technologie. Les systèmes open-source ont ouvert la voie au codage et à la vérification en commun. Maintenant que nous avons une génération entière qui grandit avec ce processus, il est logique que le monde IBM i évolue également dans ce sens. Beaucoup s’inquiètent de la transition, mais n’ayez crainte, ARCAD a l’expertise et les outils pour gérer cela et pour vous soulager des difficultés que vous pourriez rencontrer dans cette transition.
2. Quel est donc le rôle d’ARCAD ?
Nous allons le détailler en quelques points. Migration des sources, construction/compilation, développement simultané.
Pour commencer, nous effectuons un nettoyage/audit et construisons un référentiel dans ARCAD. Si vous utilisez actuellement nos outils DevOps comme Audit/Observer/Skipper, c’est chose faite. Si ce n’est pas le cas, ARCAD dispose des outils nécessaires pour vous aider dans ce processus. Pendant ce temps, en second plan, nous configurons quelques paramètres pour passer à Git.
Pour les tâches annexes, nous devons connecter votre dépôt Git à l’application ARCAD via des webhooks. Il faut ensuite connecter notre application Builder à Git et à l’application ARCAD. Comme vous le savez peut-être, Git ne parle pas IBM i. Git ne sait même pas ce qu’est l’IBM i. C’est à ce moment-là qu’ARCAD commence à se démarquer de la concurrence. Pour passer de Git à la production, il faut compiler, et bien sûr, Git ne peut pas compiler le code source IBM i. Comme l’application ARCAD contient les exigences pour le Build, le processus de compilation passe par la solution Builder pour s’assurer que toutes les parties sont intégrées en conséquence, puis il est transféré à l’IBM i pour le traitement et la compilation.
Maintenant, évoquons le passage à Git :
Une fois les connexions en place, il est temps de passer du Source Control IBM i sous ARCAD, avec le plugin Skipper RDi, à Git. Si vous utilisez GitLab, GitHub, Azure, BitBucket ou d’autres, ARCAD a les outils nécessaires pour supporter ce changement. Du point de vue du skipper ou même de l’écran vert, il suffit d’une commande pour lancer le déplacement. Il suffit de charger le SCM. En fonction de la taille du référentiel, de son emplacement et du chemin de communication, le processus peut être relativement rapide.
Une fois le chargement terminé, le référentiel ressemblera à quelque chose comme ceci. La gestion du code source a donc commencé. C’est la vue du dépôt dans GitLab.
La version d’après :
Vous êtes désormais sous Git, et maintenant que faire ? Pour rester simple, nous allons laisser de côté toutes les connexions possibles et les déclencheurs vers des outils comme Jira ou Jenkins. Nous nous en tiendrons à l’intégration du SCM et d’ARCAD. Gardez à l’esprit que ce flux est de haut niveau et qu’il peut être fortement personnalisé pour répondre à vos besoins.
- Vous créez une nouvelle branche à partir de la branche master dans Git.
- Cela déclenche une connexion webhook à builder pour créer la version sur votre IBM i.
- Vous ouvrez alors votre IDE, vous pouvez commencer à extraire des composants dans cette bibliothèque de versions qui a été créée à partir du déclencheur ci-dessus, vous éditez un peu de code et vous avez terminé.
- Vous avez peut-être effectué des tests ici, comme des tests de qualité du code ou des tests unitaires.
- Vous êtes maintenant prêt à l’envoyer à Git et à la mettre en production. Exporter votre version vers SCM ou nous pouvons l’avoir sous forme de macro pour l’intégrer dans votre processus de travail.
- Dans Git, vous soumettez une demande de fusion, ce qui déclenche une révision entre la branche master ou release et votre branche de fonctionnalité.
- Il est plus que probable que vous ayez plusieurs branches de fonctionnalités qui seront fusionnées avec une branche de publication, avant d’être fusionnées avec la branche principale. Rappelez-vous, la branche master est la branche de production.
- Mais cette demande de fusion peut déclencher la construction réelle de la version, tous les composants nécessaires, comme les tables, les zones de données, les files d’attente de données, les programmes, etc.
- À ce stade, vous disposez d’un artefact prêt à être déployé ou mis en production. Ou, en fonction de votre flux, prêt pour le QA.
Je sais, c’est beaucoup à assimiler, cela semble compliqué, mais ce n’est qu’une apparence, en pratique cela se passe bien. Voilà à quoi ça pourrait ressembler quand vous êtes en plein processus d’utilisation de Git en tant que contrôle de source.
En résumé, avec l’approche centralisée d’ARCAD :
- C’est l’option la moins perturbante pour le développeur IBM i. Un « pull » se produit dans les coulisses avec un checkout. Un « push » se produit lorsque le développeur prend une option de menu ou fait un clic droit pour exporter vers SCM.
- Les développeurs IBM i continuent à travailler avec 5250 ou avec RDi.
- Les développeurs IBM i bénéficient d’un véritable développement simultané avec les puissantes fonctionnalités de fusion de Git ainsi que l’historique d’un changement au niveau de la ligne et l’identité de l’auteur du changement.
- C’est un développement moderne qui s’accompagne de nombreux avantages, de l’intégration à une approche flexible et progressive pour passer de la gestion classique des changements.
Maintenant, repensez à ce que j’ai dit : « ARCAD Software est le seul éditeur à proposer une transition novatrice pour vos équipes de développement, avec une mise en œuvre facile et un passage rapide au processus de contrôle de la source Git ». C’est là qu’ARCAD va exceller, il suffit de patienter et de laisser la magie opérer.
Alan Ashley
Solution Architect, ARCAD Software
Alan travaille depuis plus de 30 ans dans le domaine du support et de la promotion de la plateforme IBM i. Il est consultant avant-vente pour le rôle DevOps sur IBM i chez ARCAD Software. Avant de rejoindre ARCAD Software, il a occupé pendant de nombreuses années de multiples fonctions au sein d’IBM, de l’assistance aux clients par le biais de HA (Haute Disponibilité) à DR (Reprise après Sinistre) à la promotion des applications et aux migrations de l’IBM i vers le cloud. Dans le cadre de ces fonctions, il a pu constater de visu les difficultés rencontrées par de nombreux clients en matière de gestion du cycle de vie des applications, de modernisation et de protection des données. Sa passion dans ces domaines s’inscrit parfaitement dans la suite de produits ARCAD.
