Maturité DevOps sur IBM i : laissez le passé derrière vous

Lorsqu’on parle de l’IBM i et du cycle de vie du développement d’applications, il serait facile de s’en tenir aux anciennes méthodes de travail. Mais dans le monde d’aujourd’hui, ces anciennes méthodes ne suffisent plus. Les entreprises avant-gardistes ont massivement adopté la philosophie Agile et DevOps. Le contrôle des sources est distribué et les outils issus du monde du logiciel libre apportent des changements en continu, ce qui permet de proposer plus rapidement de nouvelles fonctionnalités aux utilisateurs. Je soutiens qu’avec toutes ses différences – et ses avantages – IBM i appartient aussi à ce monde DevOps open-source. Le risque de ne pas bouger est tout simplement trop grand.

Aujourd’hui je vais aborder les points suivants :

1. Mon point de vue (maintenir les applications IBM i opérationnelles !)

Pour commencer, j’ai grandi sur écran vert tout en soutenant des clients de tous les secteurs pendant plus de 30 ans. J’ai connu la difficulté de contrôler le code source, de tester le code et de corriger les bugs en production. Je ne compte plus le nombre de fois où j’ai été appelé à 2 heures du matin pour corriger une erreur de « level check » en production. Alors que l’IBM i a beaucoup changé au fil des années, passant de l’AS/400 à l’iSeries pour arriver là où nous sommes aujourd’hui, une chose est restée constante pendant cette période. La difficulté de passer du processus de développement à la production.

Lorsque j’ai rejoint ARCAD Software, j’ai eu la chance de me plonger dans la suite d’outils disponibles. Ma 1ère réflexion a été que je peux penser à une douzaine d’anciens clients qui pourraient bénéficier d’une partie de cette suite. ARCAD commence par l’analyse et l’audit de votre code, et rien que cela change la donne. Combien de fois vous êtes-vous demandé si vous travailliez à partir de la bonne source ? Cette analyse permet de nettoyer votre environnement de développement, ce qui est particulièrement important à l’heure du DevOps et de l’utilisation d’outils open-source. Mais les outils ARCAD ne s’arrêtent pas là. La connaissance de l’application – ou métadonnées – qui découle de cette phase d’analyse initiale est réutilisée tout au long du cycle CI/CT/CD de bout en bout, ce qui rend chacun des outils ARCAD en aval plus intelligent et plus rapide. Plus d’informations à ce sujet plus tard…

Ma perspective sur le développement du code est un peu différente car je ne suis pas un développeur. J’ai été administrateur pendant la majeure partie de ma carrière, et mes compétences en matière de codage se sont concentrées sur le code qui me faciliterait la vie ou m’aiderait à débugger les erreurs à 2 heures. Dans mes fonctions, je devais généralement commencer par fouiller dans le code source. La commande DSPPGM était mon amie ainsi que DSPDBR. Ce que j’ai découvert avec les produits ARCAD, c’est qu’ils suppriment le besoin de faire ce niveau de recherche. Pourquoi ? Parce qu’ils ne laissent pas le développeur passer à la production sans quelques dizaines de vérifications en cours de route. Voici comment cela fonctionne…

2. Le flux de travail d’ARCAD : rien n’est gaspillé

Le cycle de vie et la gestion du code source sont au cœur de ce qu’ARCAD apporte. Vous pouvez voir dans le diagramme ci-dessous comment il peut toucher et aider dans chaque domaine du flux CI/CT/CD. ARCAD gère l’ensemble du processus de versionnement, soit avec Git, soit de manière native, selon vos préférences. Ensuite, lorsque vous extrayez, éditez et compilez votre code source directement à partir de LPEX, vous pouvez cliquer avec le bouton droit de la souris sur n’importe quel champ de texte, fichier, procédure, programme, zone de données, ou même sur des littéraux pour voir partout où cette construction est utilisée, ce qui est un grand gain de temps. Puis, ARCAD analysera votre code source pour mettre en évidence les zones qui enfreignent les règles qualité ou de sécurité. Une fois que vous avez terminé et que vous validez votre modification, un build est automatiquement lancé, compilant tout code dépendant impacté. Plus de séquencement manuel des compilations ! ARCAD optimise le build pour ne compiler que ce qui est nécessaire et dans le bon ordre. Après le build, les tests unitaires et les tests de régression fonctionnels sont exécutés pour vous en flux continu. Une fois la version validée, elle est déployée automatiquement en production, avec un retour en arrière automatisé en cas d’erreur.

Avec toute cette automatisation, le développeur n’a plus qu’à se préoccuper de l’écriture du code. Tous les points douloureux, tels que l’endroit où se trouve ma source, qui l’a testée et pourquoi le défaut n’a pas été trouvé, ainsi que le contrôle du déploiement du code dans votre environnement IBM i, mais aussi dans vos systèmes ouverts et distribués, sont pris en charge.

3. Automatisation et “shift left”

Attendez, suis-je en train de dire que le développeur devra passer par une check-list pour pousser le changement vers la production ou même simplement vers l’environnement UAT ? Non, c’est ce qui est génial avec ARCAD, tout est géré en coulisses. Si vous mettez à jour le format d’un fichier, il trouvera tous les programmes et objets qui doivent être recompilés. Donc, plus d’erreurs de « level check ». Si le fichier modifié implique une douzaine d’autres écrans, programmes, fichiers ou menus, ceux-ci sont tous connus grâce au référentiel créé lors de l’installation et ces objets sont recompilés si nécessaire. Désormais, le développeur peut se concentrer sur le code plutôt que sur les « et si ». Il s’agit d’un gain de temps considérable, voire d’un gain d’argent pour votre entreprise. Tout cela fait partie de la mentalité du “shift left ». Lorsque vous entendez shift left, la première chose à laquelle vous devez penser est le coût de la création du code et de sa mise en production. Plus les défauts sont proches de la production, plus la correction est coûteuse. Le « shifting left » (décalage vers la gauche) permet donc de réduire considérablement le coût de la correction d’un défaut.

4. Outils open-source sur IBM i

Vous entendrez donc maintenant des termes effrayants lorsque vous adopterez le DevOps sur IBM i, comme Jira, Git, Jenkins. Vous allez entendre des choses comme pipelines et branches. Mais ne vous inquiétez pas, j’ai découvert que la suite logicielle ARCAD rend la tâche facile. Comme je l’ai déjà dit, je ne suis pas développeur, mais apprendre les bases pour créer et promouvoir du code dans un environnement DevOps a été rendu facile avec ARCAD. Alors laissez tomber l’ancienne façon de penser avec SEU et PDM, adoptez RDi, l’Open Source, le SCM, Git, Jenkins et les pipelines, car ARCAD sera là pour vous guider dans le processus CI/CT/CD. ARCAD est au centre de cet univers et fait avancer le mouvement.

À ce stade, vous vous demandez ce que cela a à voir avec laisser le passé derrière soi. Cela ressemble plutôt à un surcroît de travail. Eh bien, comme vous le savez probablement maintenant, nous sommes tous plongés dans la philosophie DevOps/Agile qui s’applique aussi bien à IBM i qu’à toute autre plateforme technologique. Vous verrez dans les études de cas ci-dessous que nous avons rapidement déployé DevOps sur IBM i avec Git et des outils open-source dans certaines des équipes de développement IBM i les plus traditionnelles. Comme la couche ARCAD rend l’interface Git totalement transparente, même les développeurs IBM i les plus expérimentés sont heureux de se brancher sur le même référentiel Git et le même pipeline CI/CD que leurs collègues (probablement plus jeunes) qui développent sous Windows ou Linux !

5. Git sur IBM i – RDi ou écran vert !

Beaucoup craignent que les nouveaux paradigmes DevOps ne les remplacent en tant que développeurs au profit de ceux qui ont grandi avec l’open source. C’est là que le raisonnement est erroné. Ce que je peux dire, c’est que DevOps vous permet de faire votre travail plus efficacement et qu’avec les solutions ARCAD en arrière-plan, la mise en place d’une nouvelle amélioration dans les mains de vos utilisateurs sera beaucoup plus rapide et plus sûre.

D’autres traditionalistes diront « Je n’ai pas envie d’apprendre Git », et bien c’est ça qui est bien. Il y a des chances que quelqu’un du côté des systèmes distribués de votre organisation soit déjà le maître en la matière. Il s’occupera de la configuration initiale de votre environnement SCM. Ensuite, la couche technologique d’ARCAD vous évitera de devoir travailler directement avec Git lui-même. On vous donne simplement une version sur laquelle travailler et vous pouvez vous contenter de coder. Si vous ne voulez pas renoncer à l’écran vert, c’est également possible car vous pouvez coder dans ARCAD Skipper en utilisant soit RDi avec l’éditeur LPEX, soit 5250 comme ci-dessous :

C’est vraiment si simple, d’une certaine manière ? Il y a quelques nouvelles étapes à franchir pour commencer, mais l’automatisation permet un gain de temps considérable. En un rien de temps, vous serez un vieux briscard dans ce nouveau jeu.

5. Prochaines étapes

Alors, que faire maintenant que vous avez lâché prise ?

Adoptez l’automatisation. Adoptez l’open source. Si vous êtes comme moi, l’exploration de nouvelles idées et de nouveaux concepts est ce qui nous dynamise ainsi que la garantie que les applications IBM i continueront de profiter à l’entreprise dans les années à venir. Faites des recherches sur le paysage DevOps. Plus l’automatisation sera grande, plus vous disposerez de temps pour innover de nouvelles fonctionnalités et satisfaire vos utilisateurs et l’entreprise !