À propos des cookies sur ce site Pour fonctionner correctement, nos sites Internet nécessitent certains cookies (requis). En outre, d'autres cookies peuvent être utilisés avec votre consentement pour analyser l'utilisation d'un site, améliorer l'expérience des utilisateurs et à des fins publicitaires. Pour plus informations, passez en revue vos options de préférences en. En visitant notre site Web, vous acceptez que nous traitions les informations comme décrit dans ladéclaration de confidentialité d’IBM. Pour faciliter la navigation, vos préférences en matière de cookie seront partagées dans les domaines Web d'IBM énumérés ici.
Qu’est-ce que le DevOps ?
DevOps est une méthodologie de développement logiciel qui accélère la livraison d’applications et de services de meilleure qualité en combinant et en automatisant le travail des équipes de développement logiciel et d’exploitation informatique.
Grâce à des outils et des pratiques partagés, y compris des mises à jour petites mais fréquentes, le développement de logiciels devient plus efficace, plus rapide et plus fiable.
Par définition, le terme DevOps (opérations de développement) désigne à la fois un processus de développement de logiciels et un changement de culture organisationnelle qui favorise la coordination et la collaboration entre les équipes de développement et d’opérations informatiques, deux entités qui, traditionnellement, travaillent séparément ou en silos.
En pratique, les meilleurs processus et cultures DevOps vont au-delà du développement et des opérations pour intégrer les contributions de toutes les parties prenantes de l’application dans le cycle de vie du développement logiciel. Cela inclut l’ingénierie de plateforme et d’infrastructure, la sécurité, la conformité, la gouvernance, la gestion des risques et les équipes opérationnelles, les utilisateurs et les clients.
Les principes DevOps représentent l'état actuel de l'évolution du processus de livraison de logiciels au cours des 20 dernières années. Le processus de livraison est passé d'une mise à jour géante du code de l'application tous les mois, voire toutes les années, à des mises à jour itératives de caractéristiques ou de fonctionnalités plus petites, publiées aussi fréquemment que tous les jours ou plusieurs fois par jour.
En définitive, DevOps vise à répondre à la demande sans cesse croissante des utilisateurs de logiciels, qui exigent de nouvelles fonctionnalités fréquentes et innovantes, ainsi que des performances et une disponibilité ininterrompues.
Avant 2000, la plupart des logiciels étaient développés et mis à jour à l’aide de la méthodologie en cascade, une approche linéaire des projets de développement à grande échelle. Les équipes de développement de logiciels passaient des mois à développer de grands volumes de nouveaux codes qui avaient un impact sur la plupart ou la totalité du cycle de vie de l’application. En raison de l’ampleur des changements, elles consacraient plusieurs mois supplémentaires à l’intégration de ce nouveau code dans la base de code.
Ensuite, les équipes chargées de l’assurance qualité (QA), de la sécurité et des opérations passaient à nouveau des mois à tester le code. Au final, des mois, voire des années, s’écoulaient entre deux versions du logiciel et, souvent, plusieurs correctifs importants ou corrections de bogues s’intercalaient également entre les versions. Cette approche « Big Bang » de la livraison de fonctionnalités se caractérisait souvent par des plans de déploiement complexes et risqués, des verrouillages difficiles à planifier avec les systèmes en amont et en aval, et le grand espoir des services informatiques que les besoins métier n’avaient pas radicalement changé dans les mois précédant le lancement de la production ou de la version de disponibilité générale (GA).
Pour accélérer le développement et améliorer la qualité, les équipes de développement ont commencé à adopter des méthodologies de développement du logiciel Agile au début des années 2000. Ces méthodologies sont itératives plutôt que linéaires et se concentrent sur des mises à jour plus petites et plus fréquentes de la base de code de l'application. Parmi ces méthodologies DevOps, les plus importantes sont l’intégration continue et la distribution continue (CI/CD).
Dans la CI/CD, de plus petits fragments de nouveau code sont fusionnés dans la base de code à intervalles fréquents, puis automatiquement intégrés, testés et préparés pour le déploiement dans l’environnement de production. Agile a morcelé l’approche « Big Bang », ce qui a également permis de compartimenter les risques.
Plus ces pratiques de développement agile accéléraient le développement et la livraison de logiciels, plus elles exposaient les opérations informatiques, le provisionnement des systèmes, la configuration, les tests d’acceptation, la gestion et la surveillance en silos, par exemple, comme le prochain goulot d’étranglement dans le cycle de vie de la distribution des logiciels.
Ainsi, le DevOps est issu d'Agile. Il a ajouté de nouveaux processus et outils qui étendent l'itération continue et l'automatisation du CI/CD au reste du cycle de vie de la livraison du logiciel. Il a également mis en place une collaboration étroite entre le développement et les opérations à chaque étape du processus.
Comment fonctionne DevOps : le cycle de vie DevOps
Le cycle de vie DevOps (parfois appelé pipeline de distribution continue lorsqu’il est présenté de manière linéaire) est une série de processus de développement itératifs et automatisés, ou workflows, exécutés dans le cadre d’un cycle de développement plus large, automatisé et itératif, conçu pour optimiser la distribution rapide de logiciels de haute qualité. Les noms des workflows et leur nombre varient selon les personnes interrogées, mais ils incluent souvent les huit étapes suivantes.
Planification
Dans ce workflow, les équipes définissent les nouvelles fonctionnalités pour la prochaine version, en s'appuyant sur les commentaires des utilisateurs et les études de cas, ainsi que sur les entrées de toutes les parties prenantes internes. L'objectif de la phase de planification est de maximiser la valeur commerciale du produit en créant une liste de fonctionnalités qui améliorent la valeur du produit.
Codage
Il s’agit de l’étape de programmation, au cours de laquelle les développeurs codent et construisent des fonctionnalités nouvelles et améliorées à partir de commentaires d’utilisateurs et d’éléments de travail figurant dans le carnet de commandes. Un ensemble de pratiques telles que le développement axé sur les tests (TDD), la programmation en binôme et l’examen du code par les pairs sont courantes. Les développeurs utilisent souvent leur poste de travail local pour réaliser la boucle interne d’écriture et de test du code avant de l’envoyer dans le pipeline de distribution continue.
Création de l’intégration continue et distribution continue
Dans ce workflow, le nouveau code est intégré dans la base de code existante, puis testé et conditionné en vue de sa publication et de son déploiement. Les activités d’automatisation les plus fréquentes comprennent la fusion des modifications du code dans une copie principale, la vérification de ce code à partir d’un référentiel de code source et l’automatisation de la compilation, du test unitaire et de l’emballage dans un fichier exécutable. La bonne pratique consiste à stocker le résultat de la phase d’intégration continue dans un référentiel binaire pour la phase suivante.
Tests
Les équipes utilisent des tests, souvent automatisés, pour s’assurer que l’application répond aux normes et aux exigences. L’approche DevOps classique prévoit une phase de test discrète entre la création et la publication.
Cependant, DevOps a progressé de telle sorte que certains éléments de test peuvent intervenir dans la planification (développement axé sur le comportement), le développement (tests unitaires, tests sous contrat), l’intégration (analyses statiques du code, analyses CVE, linting), le déploiement (tests de fumée, tests d’intrusion, tests de configuration), les opérations (tests du chaos, tests de conformité) et l’apprentissage (tests A/B).
Les tests continus constituent une excellente méthode d’identification des risques et des vulnérabilités et permettent aux services informatiques d’accepter les risques, de les atténuer ou d’y remédier. En outre, les tests « shift-left » sont une approche du développement de logiciels qui met l’accent sur le transfert des activités de test plus tôt dans le processus de développement. Cela permet d’améliorer la qualité des produits, la couverture des tests, la continuité des boucles de rétroaction et la rapidité de mise sur le marché.
Publication
La première des étapes de l'opération, la phase de lancement est la dernière avant que les utilisateurs n'accèdent à l'application. Dans ce workflow, la production de la compilation en cours d'exécution (à partir de l'intégration) est déployée dans un environnement d'exécution, généralement un environnement de développement où les tests d'exécution sont réalisés à des fins de qualité, de conformité et de de sécurité.
Si des erreurs ou des défauts sont détectés, les développeurs ont la possibilité d’intercepter et de résoudre les problèmes avant que les utilisateurs ne les remarquent. Il existe généralement des environnements de développement, de test et de production, chaque environnement exigeant des critères de qualité de plus en plus strictes. Lorsque les développeurs ont résolu tous les problèmes identifiés et que l'application répond à toutes les exigences, l'équipe chargée des opérations confirme qu'elle est prête à être déployée et la met en place dans l'environnement de production.
Déployer
Le déploiement est le moment où le projet passe à un environnement de production où les utilisateurs peuvent accéder aux changements apportés à l’application. L’infrastructure est mise en place et configurée (souvent en utilisant l’infrastructure en tant que code) et le code de l’application est déployé. Une bonne pratique pour le déploiement dans un environnement de production consiste à déployer d’abord à un sous-ensemble d’utilisateurs finaux, puis par la suite à tous les utilisateurs une fois la stabilité établie.
Opérer
Si la mise à disposition des fonctionnalités dans un environnement de production se qualifie de « Jour 1 », les opérations de « Jour 2 » commencent une fois que les fonctionnalités sont opérationnelles dans l’environnement de production. Le suivi des performances, du comportement et de la disponibilité des fonctionnalités permet de s’assurer qu’elles apportent une valeur ajoutée aux utilisateurs.
Les équipes vérifient que les fonctionnalités s’exécutent correctement et qu’il n’y a pas d’interruption de service, en s’assurant que les postures en matière de réseau, de stockage, de plateforme, de calcul et de sécurité sont toutes adaptées. En cas de problème, les équipes chargées des opérations identifient l’incident, alertent le personnel approprié, résolvent les problèmes et appliquent des correctifs.
Contrôler
Cela passe par la collecte des commentaires des utilisateurs et des clients sur les fonctionnalités, les fonctions, les performances et la valeur commerciale, afin de préparer les améliorations et les fonctionnalités de la prochaine version. Cela inclut également tous les éléments d’apprentissage et de retard issus des activités opérationnelles qui peuvent aider les développeurs à prévenir de manière proactive la réapparition d’incidents connus. C’est à ce stade que se produit le retour à la phase de planification qui favorise l’amélioration continue.
Il existe deux autres workflows continus importants dans le cycle de vie :
Alors que les méthodologies en cascade et les implémentations agiles « ajoutent » des workflows de sécurité après la distribution ou le déploiement, le DevOps s’efforce d’intégrer la sécurité dès le début (planification), lorsque les problèmes de sécurité sont les plus faciles et les moins coûteux à traiter, et de l’exécuter en continu tout au long du cycle de développement. Cette approche de la sécurité s’appelle le « shift left ». Certaines organisations ont eu moins de succès que d’autres, ce qui a conduit à l’essor du DevSecOps (développement, sécurité et opérations).
Il est également préférable de se pencher sur la réglementation de gouvernance, de gestion des risques et de conformité (GRC) dès le début et tout au long du cycle de développement. Les secteurs réglementés sont souvent tenus de fournir un certain niveau d’observabilité, de traçabilité et d’accès à la manière dont les fonctionnalités sont fournies et gérées dans leur environnement opérationnel d’exécution.
Cela implique de planifier, de développer, de tester et d’appliquer des politiques dans la Delivery Pipeline continue et dans l’environnement d’exécution. L’auditabilité des mesures de conformité est importante pour prouver la conformité avec les auditeurs tiers.
Les dirigeants s’accordent généralement à dire que les méthodes DevOps ne fonctionnent pas sans un engagement en faveur de la culture DevOps, c’est-à-dire une approche organisationnelle et technique différente du développement logiciel.
Au niveau organisationnel, les DevOps nécessitent une communication continue, une bonne collaboration et des responsabilités partagées entre toutes les parties prenantes impliquées dans la distribution de logiciels. Cela inclut les équipes chargées du développement logiciel et des opérations informatiques, pour certains, mais aussi les équipes chargées de la sécurité, de la conformité, de la gouvernance, des risques et des secteurs d’activité, pour innover de manière rapide et continue, et se concentrer sur la qualité dès le départ.
En général, la meilleure façon d’y parvenir est de briser les silos et de réorganiser le personnel en équipes DevOps transversales et autonomes qui peuvent travailler sur des projets du début à la fin (de la planification à la rétroaction) sans faire de transferts à d’autres équipes ni attendre leur approbation. Dans le contexte du développement agile, le partage des responsabilités et la collaboration sont les fondements d’une focalisation partagée sur le produit et de résultats probants.
Au niveau technique, les DevOps nécessitent un certain engagement en faveur de l’automatisation, qui permet aux projets d’avancer au sein des workflows et entre eux. Elles nécessitent également un feedback et des mesures , qui permettent aux équipes d’accélérer les cycles et d’améliorer la qualité et les performances des logiciels en continu.
La promotion d’une culture de collaboration et la suppression des silos rapprochent le travail des développeurs et des équipes opérationnelles, ce qui accroît l’efficacité et réduit les workloads en raison de la combinaison des workflows. Comme les développeurs et les équipes opérationnelles partagent de nombreuses responsabilités, moins de surprises surviennent au cours des projets. Les équipes DevOps savent exactement dans quel environnement le code s’exécute lorsqu’elles le développent.
Les équipes DevOps peuvent livrer le nouveau code plus rapidement grâce à une collaboration accrue et à la création de versions plus ciblées (et plus fréquentes), à l’aide d’une architecture de microservices. Ce processus permet d’accélérer la mise sur le marché des améliorations, des innovations et des corrections de bugs.
Cela permet également aux organisations de s’adapter plus rapidement aux changements du marché et de mieux répondre aux besoins des clients, ce qui se traduit par une plus grande satisfaction de ces derniers et un avantage concurrentiel. Le processus de publication des logiciels peut être automatisé grâce à la distribution continue et à l’intégration continue.
La distribution et l’intégration continues impliquent des tests automatisés afin de garantir la qualité et la fiabilité des mises à jour des logiciels et de l’infrastructure. La surveillance et la journalisation permettent de contrôler les performances en temps réel.
L'automatisation, y compris une infrastructure telle que le code, peut aider à gérer le développement, les tests et la production, et permettre une mise à l'échelle plus rapide avec une plus grande efficacité.
Les DevSecOps incluent l’intégration, la livraison et le déploiement continus dans le processus de développement afin que la sécurité soit intégrée dès le départ, sans mise à niveau ni adaptation ultérieure nécessaire. Les équipes intègrent des tests et des audits de sécurité dans les workflows en utilisant l’infrastructure en tant que code pour maintenir le contrôle et suivre les processus de conformité.
Une approche DevOps peut contribuer à améliorer la satisfaction au travail en automatisant les tâches répétitives de routine et en permettant aux employés de se concentrer sur des tâches plus gratifiantes qui génèrent de la valeur pour l’entreprise.
Les exigences du DevOps et de la culture DevOps mettent l'accent sur les outils qui prennent en charge la collaboration asynchrone, intègrent de manière fluide les workflows DevOps et automatisent autant que possible l'ensemble du cycle de vie DevOps .
Les catégories d'outils de DevOps incluent :
Les outils de gestion de projet permettent aux équipes de constituer un dossier de témoignages d'utilisateurs (exigences) qui forment des projets de codage, de les décomposer en tâches plus petites et de suivre ces tâches jusqu'à leur achèvement. De nombreux outils prennent en charge les pratiques de gestion de projet Agile, telles que Scrum, Lean et Kanban, que les développeurs apportent aux DevOps. Les options open source populaires incluent GitHub Issues et Jira.
Il s’agit d’environnements de codage soumis à un contrôle des versions qui permettent à plusieurs développeurs de travailler sur la même base de code. Les référentiels de code doivent s’intégrer aux outils de CI/CD, de test et de sécurité, afin que le code soit automatiquement transféré à l’étape suivante lorsqu’il est intégré au référentiel. GitHub et GitLab font partie des référentiels de code open source.
Ces outils automatisent l’extraction, la construction, le test et le déploiement du code. Jenkins est l’outil open source le plus populaire en la matière ; de nombreuses alternatives open source antérieures, telles que CircleCI, ne sont plus disponibles qu’en version commerciale.
Pour les outils de déploiement continu (CD), Spinnaker se situe entre l’application et l’infrastructure en tant que couches de code. ArgoCD est un autre choix open source populaire pour le CI/CD natif de Kubernetes.
Ceux-ci comprennent des outils logiciels, des bibliothèques et les bonnes pratiques pour automatiser les tests unitaires, sous contrat, fonctionnels, de performance, de convivialité, d’intrusion et de sécurité. Les meilleurs de ces outils prennent en charge plusieurs langages. Certains ont recours à l’intelligence artificielle (IA) pour reconfigurer automatiquement les tests en fonction des modifications apportées au code. L’éventail des outils et des cadres de test est vaste. Les cadres d’automatisation des tests open source les plus populaires sont Selenium, Appium, Katalon, Robot Framework et Serenity (anciennement Thucydides).
Les outils de gestion de la configuration (également appelés outils d’infrastructure en tant que code) permettent aux ingénieurs DevOps de configurer et de fournir une infrastructure entièrement versionnée et documentée en exécutant un script. Les options open source incluent Ansible (Red Hat), Chef, Puppet et Terraform. Kubernetes exécute la même fonction pour les applications conteneurisées.
Les outils de surveillance aident les équipes DevOps à identifier et à résoudre les problèmes système. Ils collectent et analysent également les données en temps réel pour identifier l’impact des changements de code sur les performances des applications. Parmi les outils de surveillance open source, citons Datadog, Nagios, Prometheus et Splunk.
Ces outils recueillent les commentaires des utilisateurs par le biais de cartes thermiques (enregistrement des actions des utilisateurs à l’écran), de sondages et par les tickets créés en libre-service.
Le cloud natif est une approche de la création d’applications qui utilisent les technologies fondamentales du cloud computing. Les plateformes cloud permettent un développement, un déploiement, une gestion et une performance cohérents et optimaux des applications dans des environnements publics, privés et multicloud.
Aujourd’hui, les applications cloud natives sont généralement :
- Créé à partir de microservices : Composants à couplage lâche pouvant être déployés indépendamment qui possèdent leur propre pile autonome et communiquent entre eux via des API REST, la transmission d’événements en continu ou des brokers de messages.
- Déployées dans des conteneurs : unités de code exécutables contenant toutes les dépendances du code, des exécutions et du système d’exploitation nécessaires à l’exécution de l’application. Pour de nombreuses organisations, les conteneurs sont synonymes de conteneurs Docker, mais d’autres types sont également disponibles.
- Opéré (à l'échelle) en utilisant Kubernetes : une plateforme open source d'orchestration de conteneurs pour planifier et automatiser le déploiement, la gestion et la mise à l'échelle d'applications conteneurisées.
À bien des égards, le développement cloud natif et le DevOps sont faits l’un pour l’autre. Par exemple, le développement et la mise à jour de microservices, c'est-à-dire la livraison itérative de petites unités de code à une petite base de code, conviennent parfaitement aux cycles rapides de publication et de gestion de DevOps. Il serait difficile de faire face à la complexité d'une architecture de microservices sans le déploiement et une exploitation DevOps.
Une récente enquête menée par IBM auprès de développeurs et de responsables informatiques a révélé que 78 % des utilisateurs actuels de microservices prévoient d'investir plus de temps, d'argent et d'efforts dans l'architecture, et 56 % des non-utilisateurs sont susceptibles d'adopter les microservices d'ici deux ans.
En empaquetant et en fixant de manière permanente toutes les dépendances du système d’exploitation, les conteneurs permettent des cycles de CI/CD et de déploiement rapides, car toutes les opérations d’intégration, de test et de déploiement se déroulent dans le même environnement. L’orchestration Kubernetes exécute les mêmes tâches de configuration continue pour les applications conteneurisées qu’Ansible, Puppet et Chef pour les applications non conteneurisées.
La plupart des principaux fournisseurs de cloud computing, notamment AWS, Google, Microsoft Azure et IBM Cloud, proposent une solution de pipeline DevOps gérée.
En d'autres termes, DevSecOps est ce que DevOps était censé être dès le départ. Mais deux des premiers défis importants (et pendant un certain temps insurmontables) de l'adoption de DevOps étaient l'intégration de l'expertise en sécurité dans les équipes interfonctionnelles (un problème culturel) et la mise en œuvre de l'automatisation de la sécurité dans le cycle de vie de DevOps (un problème technique). La sécurité en est venue à être perçue comme une équipe de non, et comme un goulot d’étranglement coûteux dans de nombreuses pratiques DevOps.
Les DevSecOps sont apparus en réponse à un besoin spécifique d’intégrer et d’automatiser la sécurité comme prévu à l’origine. Dans les DevSecOps, la sécurité prend une place d’honneur, au même titre que le développement et les opérations. La sécurité est intégrée dans le processus de développement, avec une focalisation sur le produit.
DevOps et ingénierie de la fiabilité des sites (SRE)
L’ingénierie de la fiabilité des sites (SRE) utilise des techniques de génie logiciel pour automatiser les tâches d’exploitation informatique, telles que la gestion des systèmes de production, la gestion des changements, la réponse aux incidents et même l’intervention d’urgence, que les administrateurs de systèmes devraient autrement effectuer manuellement. La SRE cherche à transformer l’administrateur de système classique en ingénieur.
Son objectif est similaire à celui du DevOps, mais il est plus spécifique : il vise à concilier le désir d’une organisation de développer rapidement des applications et la nécessité de respecter les niveaux de performance et de disponibilité spécifiés dans les accords de niveau de service (SLA) conclus avec les clients.
Les ingénieurs en fiabilité des sites parviennent à cet équilibre en établissant un niveau acceptable de risque opérationnel causé par les applications, appelé budget d’erreurs, et en automatisant les opérations pour atteindre ce niveau.
Au sein d'une équipe DevOps transversale, la SRE peut servir de pont entre le développement et les opérations. La SRE fournit les indicateurs et les outils d'automatisation dont les équipes ont besoin pour faire passer les changements de code et les nouvelles fonctionnalités dans le pipeline DevOps aussi rapidement que possible, sans violer les conditions d'organisation de SLA.
À mesure que l’étendue des tâches pouvant être automatisées croît, d’autres fonctions sont ajoutées au DevOps, ce qui en génère de multiples variantes. Et plus le DevOps fait ses preuves, plus les investissements des entreprises augmentent.
Selon Verified Market Research, le marché des DevOps était évalué à 10,96 milliards de dollars en 2023, et il devrait atteindre 21,13 milliards de dollars d’ici 2031, avec un TCAC de 21,23 % de 2024 à 2031.
Pour assurer le succès des DevOps, les entreprises adoptent de plus en plus :
L’intelligence artificielle pour les opérations informatiques fait intervenir l’IA et le machine learning pour automatiser et rationaliser les opérations informatiques, ce qui permet d’analyser rapidement d’énormes volumes de données.
BizDevOps permet aux unités opérationnelles de collaborer au processus de développement de logiciels, ainsi qu'au développement et à l'exploitation. Également connu sous le nom de DevOps 2.0, ce changement culturel accélère le processus et conduit à des solutions plus solides qui s'alignent sur les objectifs de l'unité commerciale.
La conteneurisation est un autre moyen de créer de nouvelles efficacités : une application et ses dépendances sont encapsulées dans un package rationalisé et portable qui fonctionne sur presque toutes les plateformes.
L’ajout de fonctions de sécurité supplémentaires au tout début du développement a stimulé le DevSecOps. La sécurité n'est plus une préoccupation secondaire.
GitOps se concentre sur le stockage du code de l'application dans un dépôt Git afin qu'il soit contrôlé par version, disponible pour plusieurs membres de l'équipe et entièrement traçable et auditable. Ces mesures contribuent à accroître l'efficacité, la fiabilité et l'évolutivité.
Alors que les outils de surveillance traditionnels offrent une visibilité, les plateformes d’observabilité permettent de mieux comprendre les performances d’un système et, plus important encore, le contexte, le pourquoi de la performance. En plus de fournir cette compréhension globale, l’observabilité permet à toutes les parties prenantes d’accéder aux données dont elles ont besoin pour élaborer des solutions et créer de meilleures applications.
L’approche sans serveur (ou « serverless ») est un modèle de développement et d’exécution d’applications qui permet aux développeurs de générer et d’exécuter du code sans mettre en place ni gérer de serveurs ou d’infrastructure backend. Dans les architectures sans serveur, les développeurs écrivent le code de l’application et le déploient sur des conteneurs gérés par un fournisseur de services cloud.
Solutions connexes
Utilisez un logiciel DevOps puissant pour créer, déployer et gérer des applications cloud natives ultra-sécurisées sur plusieurs appareils, environnements et clouds.
Automatisez votre processus de livraison des logiciels pour améliorer votre productivité et votre efficacité opérationnelle.
Transformez les applications indispensables à la mission pour les environnements de cloud hybride avec stabilité, sécurité et agilité.
Innovez plus rapidement, réduisez les coûts d’exploitation et transformez les opérations informatiques (ITOps) dans un paysage en mutation grâce à une plateforme AIOps qui offre une visibilité sur les données de performance et les dépendances entre les environnements.
Ressources
Découvrez comment la modernisation de vos environnements d’application mainframe vous permettra d’obtenir de meilleurs résultats commerciaux.
Accédez à un rapport d’analyse exclusif de Gartner et découvrez comment l’IA pour l’informatique améliore les résultats métier, génère une augmentation des revenus et réduit les coûts et les risques pour les organisations.
Ce Redpaper d’IBM traite des stratégies et des solutions architecturales qui peuvent accélérer la modernisation de vos applications mainframe en tirant parti des environnements cloud hybrides. En particulier, consultez le chapitre 5 pour en savoir plus sur la modernisation des DevOps d’entreprise.
Découvrez Wazi Deploy, qui ajoute une option de déploiement d’applications par script, en open source, à l’ensemble des outils de développement IBM Developer for z/OS Enterprise Edition.
Découvrez un programme d’adoption précoce à valeur ajoutée, conçu pour accompagner les clients au cours des différentes étapes que nous estimons nécessaires à toute transformation DevOps.
Rejoignez la communauté DevSecOps pour vous tenir au courant des dernières tendances et sujets Z.
