DevOps sur IBM i (AS/400 – AS400)
Pourquoi et comment commencer ?

Le déploiement d’applications est la phase la plus importante dans le cycle de vie du développement logiciel. Beaucoup moins fréquents il y a 10 ans, les déploiements nécessitaient un effort manuel complexe. Étant donné l’ampleur des modifications impliquées, une mise à jour de logiciel créait des discordances entre les équipes de développement et d’opérations. A l’époque, le développement s’était organisé avec l’arrivée de méthodes agiles, alors que l’opérationnel représentait un goulot d’étranglement. Le déploiement était perçu comme risqué, source d’indisponibilités prévisibles pour les utilisateurs. Pour que le cycle soit fluide, il fallait donc absolument intégrer les opérations.

DevOps est alors devenu une pratique courante dans de nombreuses organisations pour répondre plus facilement à ces problèmes et plus efficacement à leurs enjeux business. La transformation numérique d’aujourd’hui requiert un délai de commercialisation rapide, promesse tenue par DevOps. D’ailleurs, les organisations qui ont mis en place tout ou une partie de DevOps ont depuis longtemps identifié et validé qu’une telle démarche garantissait un retour sur investissement.

Aujourd’hui la question n’est plus de savoir si les organisations doivent adopter DevOps, mais comment le mettre en œuvre correctement et l’étendre à toute l’entreprise. La notion d’Enterprise DevOps permet de positionner DevOps comme une stratégie d’entreprise, un processus qui apporte de la plus-value à l’organisation, et pas uniquement dans les services informatiques.

Pour en savoir plus sur son évolution, vous pouvez lire nos articles Quelles évolutions pour le DevOps ? et Pourquoi DevOps ? ou même télécharger notre White Paper Enterprise DevOps.

L’apparition de nouveaux termes relatifs au DevOps représente simplement une extension de la posture de communication à l’ensemble des services, une progression dans la mutation des entreprises. Par exemple, le DevSecOps a pour objectif de renforcer la sécurité en l’intégrant dès le début du processus de développement des applications. Nous allons voir justement ci-dessous comment réaliser un pipeline DevSecOps unique et partagé sur toutes les technologies et comment automatiser de bout en bout le cycle DevSecOps – et y intégrer l’open source et le cloud.

DevOps aide les entreprises à répondre rapidement aux changements du marché, en fournissant plus rapidement aux utilisateurs des mises à jour logicielles de meilleure qualité. Mais le passage au “full DevOps” peut s’avérer difficile pour les équipes IBM i confrontées à des échéances de projets, ne disposant pas de la fenêtre de temps nécessaire pour passer intégralement à un nouveau modèle CI/CD.

ARCAD vous apporte l’aide nécessaire dans cette transition afin de passer des outils traditionnels à un changement radical en matière de DevOps et de modernisation.

• Construisez un pipeline CI/CT/CD d’entreprise sur l’ensemble de vos technologies, en intégrant à la fois les outils des fournisseurs et les outils open source. Ouvertes et modulaires, nos solutions ARCAD s’intègrent parfaitement à tous les outils DevOps standard – GitLab, GitHub, BitBucket, Jenkins, Jira, CloudBees, Azure Pipelines et SonarQube – pour fournir un pipeline DevSecOps commun à l’ensemble de votre entreprise et de vos équipes. Vous pouvez également regarder la démonstration d’une chaîne d’outils CI/CD simplifiée grâce à notre webinaire “DevOps lite” : passez votre développement IBM i au CI/CD.

• Optimisez votre pipeline DevOps pour éliminer les goulots d’étranglement dans votre chaîne de valeur. Le référentiel de métadonnées unique d’ARCAD – une véritable base de connaissances construite à partir de vos propres applications IBM i – alimente les principaux leaders de la gestion de la chaîne de valeur d’aujourd’hui – GitLab, HCL, TaskTop, Atlassian, … fournissant des informations uniques sur l’agilité de votre flux DevSecOps sur IBM i.

Découvrez le parcours d’un de nos collaborateurs en tant que responsable mondial des outils DevOps et des services d’ingénierie chez HSBC, qui a contribué à la transition d’une “équipe de développement AS/400” vers un Pod IBM i Agile avec un pipeline DevOps CI/CT/CD entièrement automatisé et une méthodologie Agile sur l’IBM i en lisant notre article Transformation d’une équipe traditionnelle “green screen” en un Pod Agile pour IBM i.

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. Avec toutes ses différences – et ses avantages – IBM i appartient aussi à ce monde DevOps open-source. Mais comment faire pour ne pas rester sur ses acquis et adopter enfin DevOps sur IBM i ? Consultez notre article Maturité DevOps sur IBM i : laissez le passé derrière vous pour vous aider à lâcher prise.

Vous souhaitez comprendre les étapes clés vers une maturité DevOps complète et comment concevoir une feuille de route qui convient à vos équipes ? Regardez notre webinaire Maturité DevSecOps sur IBM i – pourquoi est-ce important – et comment y parvenir ? afin de comprendre les tendances émergentes en matière de DevSecOps et d’appréhender les différents chemins vers la maturité.

Toutes les technologies de l’information passent par des stades de maturité. Il est donc important de savoir à quel stade vous vous trouvez actuellement afin de comprendre et de planifier la suite des événements. Les niveaux de maturité informatique ont un impact sur le degré de maturité de DevOps dans votre organisation. Bien que l’adoption de DevOps ne dépende en aucun cas de la technologie du cloud, les serveurs physiques et les centres de données internes peuvent ralentir la progression de DevOps. En revanche, la dépendance à l’égard de programmes monolithiques constitue un obstacle de taille.

Les modèles de maturité DevOps sont utilisés pour évaluer le niveau de maturité de DevOps au sein d’une entreprise. Il existe plusieurs variantes du modèle, mais chacune tente de répondre à la même question : quel est le degré de maturité de DevOps au sein de l’entreprise ? Pour en savoir plus sur les différents degrés de maturité et quels peuvent être les obstacles à la maturité DevOps, vous pouvez lire nos White paper Transformation DevOps : Mobilisez vos équipes IBM i et Améliorer la maturité DevOps sur IBM i.

Pour atteindre cette maturité DevOps, vous aurez le choix entre deux différentes approches :

• une approche transformative (la plus rapide) – cette voie implique un plan complet qui trace le chemin le plus rapide pour atteindre et maintenir la maturité de DevOps sur IBM i.
• une approche progressive (axée sur les outils) – cette voie est destinée aux entreprises dont la direction estime que l’approche transformative risque d’être trop perturbatrice.

Pour éviter des projets de migration coûteux et à haut risque à l’avenir, il est donc important d’agir le plus tôt possible et de commencer à franchir les étapes de la maturité d’IBM i DevOps. Vous avez besoin de quelques conseils pour optimiser votre propre implémentation DevOps et tirer parti de l’avantage avantage concurrentiel de votre IBM i ? Prenez connaissance de notre guide DevOps IBM i mature : nos 7 conseils gagnants.

“Coder pour le 21e siècle” ne signifie pas seulement changer la façon dont vous développez votre interface utilisateur – un développement “vraiment moderne” signifie adapter des techniques de codage éprouvées et la méthodologie DevOps à la façon dont vous travaillez avec vos applications. Apprenez avec notre webinaire Un développement CI/CT/CD vraiment moderne, du code au déploiement comment se libérer de l’emprise du 5250 et du développement de fichiers d’impression en utilisant des techniques de codage RPG modernes.

Si vous effectuez actuellement des tests manuels, regardez notre webinaire Les tests continus (TC) dans votre stratégie DevOps pour apprendre comment automatiser le processus de test continu, afin de détecter les erreurs le plus tôt possible dans le cycle.

Sur les systèmes modernes et distribués, les tests unitaires sont sans doute l’élément le plus efficace de votre stratégie de test. Une batterie de tests unitaires bien conçus « impose » la qualité de votre application au fur et à mesure de son développement – et idéalement même avant. Les éléments des tests unitaires sont ensuite réutilisés en continu pendant toute la durée de vie de l’application afin de détecter toute régression dans le système.

Mais comment les tests unitaires peuvent-ils profiter aux applications existantes sur IBM i – et en particulier à celles qui n’ont pas été conçues dans une optique « unitaire », et où le code monolithique a toujours été la norme ? Les tests unitaires sont un maillon indispensable et souvent manquant du développement logiciel sur IBM i. Les tests unitaires automatisés peuvent rendre un pipeline DevSecOps sur IBM i véritablement continu – avec des avantages mesurables en termes de qualité, de vitesse et de coût :

• Détection automatique des entrées et des sorties pour automatiser la création de tests réalistes/utiles
• Intégration des tests unitaires dans le processus de contrôle de version
• Auto-exécutions des tests en tant que partie continue du flux CI/CD
• Réutilisation des actifs des tests unitaires pour chaque changement de programme
• Maintenance/mise à jour des tests unitaires en fonction des dépendances

Vous souhaitez en savoir plus sur tests unitaires et comment peuvent-ils profiter aux applications existantes sur IBM i ? Lisez notre article Tests unitaires : Vaincre la dette technique.

Pour éviter les risques de régression et détecter les défauts afin qu’ils n’atteignent la production, il convient d’automatiser ces tests de régression pour IBM i en enregistrant les cas de tests fonctionnels et de les rejouer automatiquement à chaque version de l’application.

Regardez notre webinaire Tests automatisés : Comment accélérer et protéger votre pipeline IBM i DevOps pour apprendre comment préserver la disponibilité de vos applications IBM i, grâce à des tests de régression automatisés :

• Enregistrez des scénarios de test à l’aide d’un émulateur facile à utiliser
• Déclenchez la relecture des scénarios de test à chaque livraison
• Menez des campagnes de test intelligentes basées sur les dépendances
• Signalez les défauts à leur cause première

Chaque organisation informatique effectue des tests, qu’il s’agisse de tests unitaires effectués par les développeurs, de tests d’assurance qualité effectués par le personnel d’assurance qualité ou de tests de régression entièrement automatisés. Dans chacune de ces techniques, un aspect largement sous-estimé est le rôle des données de test. Pourtant, l’efficacité avec laquelle ces données sont gérées a un impact direct sur le temps consacré aux tests et sur la qualité des résultats. En lisant notre article Comment gérer les données de test pour des tests plus intelligents et plus rapides ?, vous pourrez comprendre pourquoi les données de test peuvent être difficiles à gérer, et découvrir quelles sont les meilleures pratiques basées sur notre expérience et quels avantages tangibles vous pouvez tirer d’un ensemble cohérent de données de test.

Le déploiement d’applications est indéniablement la phase la plus critique et la plus risquée de tout cycle de développement d’applications. En effet, elle a un impact direct sur la disponibilité des applications et, par conséquent, sur la continuité de l’activité.

Les applications IBM i et les mises à niveau des bases de données en synchronisation avec les systèmes distribués – sur site, hybrides et multi-cloud ont tout intérêt à être déployés à l’aide d’outils de Release management qui permet d’optimiser l’intégration et la livraison continues (CI/CD) des logiciels IBM i et des données et de gérer les interdépendances à partir d’un point de contrôle unique.

La mise à disposition officielle par IBM des outils open sources a rendu la plateforme IBM i « disponible » pour tous. Ce mouvement par la simplicité de la mise en œuvre d’une démarche DevOps sur IBM i offre la possibilité de casser les barrières entre les développements dit « traditionnels/natifs » et ceux dit « modernes » pour unifier tout cela et engager l’IT dans une réponse unifié aux besoins du marché. Il a permis également de tirer parti de ces nouveaux outils Open sources pour l’ensemble des développements, de partager par exemple Jira pour l’ensemble des gestion de projet, d’adopter donc des cycles de développement Agiles globaux, de partager les gestion des sources dans un seul et unique outil et donc d’améliorer la combinaison des projets multi-technologies, de partager la connaissance de façon simple et rapide, de partager les processus comme par exemple l’utilisation de Jenkins pour gérer les « Builds » et orchestrer des déploiements : Continuous Integration/Continuous deployement.

Découvrez comment l’utilisation d’outils Open Source peut faciliter grandement le développement sur IBM i en regardant nos webinaires DevOps sur IBM i avec Git, Jenkins et Jira et Intégration continue (CI) : Construire une stratégie pour IBM i en utilisant Git, Jenkins et JIRA et comment ils permettent à l’IBM i de devenir plus populaire et de s’ouvrir plus facilement aux jeunes générations de développeurs en lisant notre article Partager la Plateforme IBM i grâce aux outils Open-Sources.

Jenkins est conçu pour être distribué et fonctionne au mieux avec non pas une, mais plusieurs instances. Cependant, la maintenance de cette infrastructure est coûteuse et peut faire perdre du temps non seulement à votre service informatique, mais aussi aux développeurs. Le centre d’opérations CloudBees facilite la gestion de plusieurs instances Jenkins grâce à une interface unifiée et conviviale. Il est construit sur Kubernetes, ce qui permet une évolutivité et une élasticité bien supérieures à ce qui est possible avec Jenkins seul, et il est prêt à l’emploi. Il est donc facile d’abandonner votre pipeline monolithique au profit d’un modèle distribué élastique. Si vous débutez avec Jenkins, vous pouvez être rassuré en sachant que la solution s’adaptera à vos besoins au fil du temps. Les goulets d’étranglement dans votre pipeline sont coûteux et peuvent avoir des effets durables. CloudBees est conçu pour éliminer cette possibilité.

Vous utilisez peut-être actuellement Jenkins et vous vous demandez quels avantages CloudBees pourrait vous offrir ? Ou bien, vous avez peut-être envisagé d’utiliser Jenkins, mais avez quelques inquiétudes d’ordre commercial ? Pour en savoir plus, lisez notre article CI pour RPG/COBOL avec ARCAD et CloudBees.

Passer par ARCAD for DevOps vous garantie une livraison plus rapide et permet d’éliminer la complexité DevOps. L’intégration des outils d’entreprise tels que Git, Jenkins et Jira avec la couche technologique IBM i d’ARCAD vous donne la possibilité également d’automatiser un cycle complet de bout en bout de CI/CT/CD pour IBM i.

Atteignez vos objectifs DevOps grâce à l’automatisation des flux de travail de bout en bout, alimentée par des logiciels open-source.

Nos différents outils pour votre processus DevOps : “classique” modules de base IBM i CI/CD, avec un ‘Shift Defects left’ pour des tests et des contrôles de qualité automatisés, ou même avec une intégration Git et Open-source.

Découvrez comment assurer la qualité et la sécurité du code avec ARCAD CodeChecker en regardant le webinaire “Améliorez la qualité et la sécurité du code de vos applications IBM i” et Qualité continue (CQ) : Vérifiez la qualité du code source de votre RPG, automatiquement.

Retrouvez une démonstration d’ARCAD iUnit dans notre webinaire consacré aux tests unitaires “Automatisation des tests unitaires : Sécuriser la qualité des applications sur IBM i.”

Regardez ces deux webinaires pour en apprendre plus sur les tests de régressions automatisés avec ARCAD Verifier “Tests automatisés : Comment accélérer et protéger votre pipeline IBM i DevOps.” et découvrir comment notre produit s’associe parfaitement à Selenium pour des tests de régression Associer Verifier à Selenium pour tous vos besoins de régression.