L’avènement de l’Enterprise DevOps : relever le défi des silos IT

Par Olenka Van Schendel

En 2018, le problème du silo informatique persiste.  Le fossé entre les initiatives numériques et le développement du Legacy épuise les budgets informatiques et entraîne des livraisons incohérentes vers la production.

Les erreurs détectées à ce niveau ont un impact business direct : le coût moyen d’un incident majeur d’une application logicielle stratégique en production par heure est de 1 M$, soit dix fois le coût horaire moyen de dysfonctionnement matériel (*).  Et étonnamment, 70 % des erreurs de production sont dues à des erreurs de déploiement, et seulement 30 % à des erreurs de code. Pourtant, les DSI responsables de diverses cultures informatiques d’aujourd’hui manquent de visibilité et de contrôle sur le processus de déploiement des logiciels.

Quelles solutions émergent ? Depuis le dernier Gartner Symposium, nous assistons à la convergence des technologies de Release Management et DevOps.  Enterprise DevOps arrive à maturité.

En tant que mouvement dominant, la communauté DevOps assume la responsabilité opérationnelle synonyme de succès.  L’agilité du « Dev » confronte les contraintes et les politiques d’entreprise familières aux « Ops ».

Du CI/CD vers l’Entreprise DevOps

Les environnements informatiques d’aujourd’hui se composent d’un mélange complexe d’applications composées chacune de centaines de micro services, de conteneurs et de multiples technologies de développement – y compris des plates-formes existantes qui se sont avérées si fiables et précieuses pour l’entreprise que même en 2018, elles constituent toujours le cœur de nombreuses applications commerciales parmi les plus importantes au monde.

De nombreux pipelines CI/CD ont été efficaces en matière d’approvisionnement, de configuration de l’environnement et d’automatisation du déploiement des applications. Mais jusqu’à présent, ils n’ont pas réussi à donner au niveau de l’entreprise les réponses aux questions qu’elle se pose sur la conformité aux réglementations, la gouvernance et la sécurité.

Ce qu’on appelle aujourd’hui les pipelines DevOps sont souvent des chaînes d’outils disparates, fragiles et sur mesure. Conçus principalement pour les environnements natifs du Cloud, ils ont automatisé avec succès un processus reproductible pour faire fonctionner, tester et livrer les applications.

Mais la plupart n’ont pas la couche technologique nécessaire pour gérer les plates-formes héritées comme IBM i (aka iSeries, AS/400) et mainframe z/OS, laissant un « maillon faible » dans le processus de livraison. Cette approche en silo de l’outillage DevOps comporte le risque perpétuel d’arrêts de production et de coûts incontrôlés.

Des solutions émergent. Écoutez l’expérience de SpareBank1 comme exemple récent. La prochaine phase de la gestion des versions est déjà en place. Enterprise DevOps offre un pipeline de livraison de logiciels unique et commun à travers toutes les cultures de développement informatique et une transparence de bout en bout sur l’état des versions. Ce blog explique comment nous en sommes arrivés là.

Qu’est-ce qui retient DevOps ? Le bimodal IT détient la clé

Ces dernières années ont vu l’émergence du « Bimodal IT« , une pratique de gestion informatique qui reconnaît deux types – et deux vitesses – de développement logiciel et prescrit des processus distincts mais coordonnés pour chacun.

Gartner Research définit le Bimodal IT comme  » la pratique consistant à gérer deux styles de travail distincts mais cohérents : l’un axé sur la prédictibilité et l’autre sur l’exploration « .

Dans la pratique, cela nécessite deux voies parallèles, l’une soutenant le développement rapide d’applications pour les projets d’innovation numérique, et l’autre, plus lente, pour la maintenance continue des applications sur les principaux actifs logiciels.

Selon Gartner, les styles de travail en IT se répartissent en deux modes. Le mode bimodal 1 est optimisé pour des domaines plus prévisibles et mieux compris. Il met l’accent sur l’exploitation de ce qui est connu, tout en transformant l’environnement existant en un état qui convient à un monde numérique. Le mode 2 est exploratoire, expérimental pour résoudre de nouveaux problèmes et optimisé pour les zones de flous. Ces initiatives commencent souvent par une hypothèse qui est testée et adaptée au cours d’un processus impliquant de courtes itérations, adoptant potentiellement une approche de produit minimum viable (MVP). Les deux modes sont essentiels dans une entreprise pour créer une valeur substantielle et entraîner des changements organisationnels importants, et ni l’un ni l’autre ne sont statiques. Combiner une évolution plus prévisible des produits et des technologies (mode 1) à une nouvelle et plus innovante (mode 2) est l’essence même du modèle bimodal. Tous deux jouent un rôle essentiel dans la transformation numérique.

Les systèmes Legacy comme IBM i et z/OS entrent souvent dans la catégorie Mode 1. Les nouveaux développements sur Windows, Unix et Linux tombent généralement dans le mode 2.

Les limites du CI/CD

Une livraison fluide des logiciels est l’un des principaux objectifs de l’entreprise. L’industrie IT a fait un bond en avant dans cette direction avec l’adoption généralisée de l’intégration continue automatisée et de la livraison continue (CI/CD). Mais soyons clairs sur ce qu’est le CI/CD et ce qu’il n’est pas.

L’intégration continue (CI) est un ensemble de pratiques de développement qui incitent les équipes à mettre en œuvre de petits changements et à vérifier fréquemment le code dans les référentiels partagés. CI commence à la fin de la phase de code et demande aux développeurs d’intégrer du code dans le référentiel plusieurs fois par jour. Chaque contrôle est ensuite vérifié par une build et test automatisés, ce qui permet aux équipes de détecter et de corriger les problèmes rapidement.
La Livraison Continue (CD) prend en charge les phases du SDLC, là où se termine le CI : provision des environnements de test, déploiement des tests, validation des tests et déploiement en production.
Le déploiement continu prolonge la livraison continue : chaque changement qui réussit les tests automatisés est automatiquement déployé en production. Selon DevOps, le déploiement continu devrait être l’objectif de la plupart des entreprises qui ne sont pas contraintes par des exigences réglementaires ou autres.
Le problème est que la plupart des pipelines CI/CD sont limités dans leur utilisation du  » cloud-native « , également appelées nouvelles technologies de l’entreprise. Les entreprises d’aujourd’hui attendent la prochaine évolution, celle d’un pipeline commun et partagé à travers toutes les cultures technologiques. Pour y parvenir, de nombreuses organisations devront passer d’une simple automatisation à de la business release coordination, ou orchestration.

De l’automatisation des versions d’application (ARA) à l’orchestration (ARO)

L’automatisation des versions d’applications (ARA) implique le conditionnement et le déploiement d’une application, d’une mise à jour ou d’une version depuis le développement, dans divers environnements et même jusqu’en production. Les outils ARA associent des fonctionnalités d’automatisation du déploiement, de gestion de l’environnement et de modélisation.
D’ici 2020, Gartner prévoit que plus de 50 % des entreprises mondiales auront mis en œuvre au moins une solution d’Application Release Automation, contre moins de 15 % en 2017. Depuis sa création il y a environ sept ans, le marché des solutions ARA a atteint 228,2 millions de dollars en 2016, en hausse de 31,4 % par rapport à 2015. Le marché devrait continuer de croître à un taux de croissance annuel composé (TCAC) estimé à 20 % jusqu’en 2020.
Le marché de l’ARA évolue rapidement en réponse aux exigences croissantes des entreprises qui souhaitent à la fois étendre les initiatives DevOps et améliorer l’agilité du release management dans de multiples cultures, processus et générations de technologies. Nous voyons ARA se transformer en une nouvelle discipline, l’ Application Release Orchestration (ARO).
Une couche au-dessus d’ARA, les outils ARO (Application Release Orchestration) organisent et coordonnent les tâches automatisées en un flux de travail consolidé de release management. Ils améliorent les meilleures pratiques en déplaçant les artefacts, les applications, les configurations et même les données liées aux applications tout au long du processus du cycle de vie des applications. ARO couvre l’ensemble du processus de livraison logicielle et fournit une visibilité sur l’ensemble du processus de déploiement du logiciel.
ARO est la pierre angulaire d’ Enterprise DevOps.

Enterprise DevOps : concilier qualité et rapidité des déploiements

Enterprise DevOps est encore récent et des définitions divergentes émergent. Considérez-le comme DevOps at Scale.
Tout comme pour le bimodal IT, les grandes entreprises ont recours aux équipes DevOps pour construire et déployer des logiciels via des pipelines individuels et parallèles. Les pipelines circulent en continu du développement à l’intégration et au déploiement de manière itérative. Chaque pipeline parallèle utilise des chaînes d’approvisionnement pour automatiser ou orchestrer les phases et sous-phases du SDLC Enterprise DevOps.
A un certain niveau, les phases du SDLC Enterprise DevOps peuvent être résumées de cette manière : planification, analyse, design, code, commit, test unitaire, test d’intégration, test fonctionnel, test de déploiement, test d’acceptation, déploiement en production, implémentation et feed-back utilisateur.
Les étapes et les tâches de l’ED-SDLC peuvent différer en fonction des pipelines où il peut y avoir un niveau d’importance différent pour chaque étape ou sous-étape. Par exemple, en mode bimodal 1 sur un SOR, les phases de planification, d’analyse et de conception peuvent être plus importantes qu’en mode bimodal 2. Dans le mode bimodal 2 sur un SOE, la fréquence du commit, du test unitaire, du test d’intégration et du test fonctionnel peut être bien plus élevée.
Le risque d’erreur de déploiement est élevé dans les environnements d’entreprise parce que les chaînes d’approvisionnement dans chaque pipeline diffèrent et qu’il existe des dépendances entre les artefacts dans différents pipelines. L’orchestration est nécessaire pour coordonner les processus à travers les pipelines. L’orchestration équivaut à une automatisation plus sophistiquée, avec de l’intelligence intégrée et l’objectif ultime d’être autonome.

Comment faire la transition des systèmes Legacy vers DevOps ?

En réponse aux défis du Bimodal IT, nous avons atteint un point de convergence entre les pratiques classiques du DevOps et du Release Management.
Depuis plus de 25 ans, Arcad Software permet aux grandes entreprises et aux PME d’améliorer le développement de logiciels grâce à des outils uniques et des techniques innovantes. Au cours de cette période, nous avons développé une expertise unique des systèmes IBM i et z/OS existants. Aujourd’hui, nous sommes reconnus par Gartner Research comme un acteur important dans le domaine de l’Enterprise DevOps et de l’ARO, tant pour les plateformes Legacy que modernes.
De nombreux fournisseurs d’ARO s’attendent à de nouveaux développements sur Windows, Unix et Linux et, par conséquent,que les systèmes legacy ne seront plus qu’un lointain souvenir. ARCAD est différent ; nous comprenons la nécessité de tirer le meilleur parti de l’investissement de votre entreprise effectué dans les systèmes legacy au cours des dernières décennies, ainsi que les exigences et les défis liés à la valorisation de ces applications legacy.

ARCAD peut s’assurer que vous pouvez offrir à vos responsables d’applications et parties prenantes une solution pratique et intégrée, étape par étape, pour fournir à la fois DevOps et ARO pour les applications nouvelles et legacy, plutôt que des projets coûteux et risqués de remplacement de l’infrastructure.

Tirer parti des pipelines CI/CD existants

Les organisations disposent aujourd’hui d’un grand nombre d’outils pour mettre en œuvre DevOps. Les outils se superposent et le danger est « l’étalement de la chaîne d’outils ». Pourtant, aucun outil ne peut à lui seul répondre à tous les besoins dans un environnement de développement moderne. Il est donc essentiel que tous les outils sélectionnés s’intègrent facilement les uns aux autres.
La solution ARCAD pour DevOps a une architecture ouverte et s’intègre facilement aux outils standards tels que Git, Jenkins, JIRA, ServiceNow. Elle est capable d’orchestrer la livraison de tous les actifs applicatifs de l’entreprise, depuis les technologies Cloud les plus récentes jusqu’au code de base qui sous-tend votre entreprise.

Les solutions ARCAD étendent et adaptent votre pipeline DevOps existant en un flux de travail sans friction qui supporte TOUTES les plateformes de votre business.

Moderniser votre capital IT

Si l’avenir des applications legacy vous préoccupe, les solutions complémentaires d’ARCAD peuvent automatiser la modernisation de vos bases de données et de votre code legacy – en augmentant leur flexibilité dans les architectures informatiques modernes et en facilitant l’embauche de jeunes développeurs de talent, et en garantissant que les nouveaux recrutés pourront travailler efficacement en équipe avec les membres expérimentés de votre équipe.

Avec 25 ans d’expérience dans le Release Management et de collaboration avec les équipes legacy et Digital IT les plus importantes et les plus respectées à travers le monde, ARCAD Software a intégré la sécurité, la conformité et la réduction des risques dans toutes ses offres. C’est exactement ce vers quoi DevOps se dirige.

(*) Source: IDC

Olenka Van Schendel

VP Strategic Marketing & Business Development

Avec 28 ans d’expérience dans les systèmes distribués et IBM i, Olenka a débuté dans le domaine de l’intelligence artificielle et du traitement du langage naturel, en travaillant comme ingénieur logiciel, principalement sous UNIX. Elle s’est rapidement spécialisée dans le développement d’outils logiciels intégrés comprenant des compilers, des débuggers et des systèmes de gestion du code source. En tant que VP Business Development au sein du groupe ARCAD Software, elle continue à se consacrer à la gestion du cycle de vie des applications (ALM) et à l’outillage DevOps dans une perspective multiplateforme, notamment IBM i.