Par Olenka Van Schendel<\/h3>\n<\/div><\/div><\/div>En 2018, le probl\u00e8me du silo<\/strong> informatique persiste.\u00a0 Le foss\u00e9 entre les initiatives num\u00e9riques et le d\u00e9veloppement du Legacy \u00e9puise les budgets informatiques et entra\u00eene des livraisons incoh\u00e9rentes vers la production.<\/p>\nLes erreurs d\u00e9tect\u00e9es \u00e0 ce niveau ont un impact business direct\u00a0: le co\u00fbt moyen d’un incident majeur d\u2019une application logicielle strat\u00e9gique en production par heure est de 1 M$, soit dix fois le co\u00fbt horaire moyen de dysfonctionnement mat\u00e9riel (*).\u00a0 Et \u00e9tonnamment, 70 % des erreurs de production sont dues \u00e0 des erreurs de d\u00e9ploiement, et seulement 30 % \u00e0 des erreurs de code. Pourtant, les DSI responsables de diverses cultures informatiques d\u2019aujourd\u2019hui manquent de visibilit\u00e9 et de contr\u00f4le sur le processus de d\u00e9ploiement des logiciels.<\/p>\n
Quelles solutions \u00e9mergent\u00a0? Depuis le dernier Gartner Symposium, nous assistons \u00e0 la convergence des technologies de Release Management<\/strong> et DevOps<\/strong>.\u00a0 Enterprise DevOps<\/strong> arrive \u00e0 maturit\u00e9.<\/p>\nEn tant que mouvement dominant, la communaut\u00e9 DevOps assume la responsabilit\u00e9 op\u00e9rationnelle synonyme de succ\u00e8s.\u00a0 L’agilit\u00e9 du “Dev” confronte les contraintes et les politiques d’entreprise famili\u00e8res aux “Ops”.<\/p>\n<\/div>
Sommaire :<\/h2>\n\n- Du CI\/CD vers l\u2019Entreprise DevOps<\/a><\/li>\n
- Qu’est-ce qui retient DevOps ? Le bimodal IT d\u00e9tient la cl\u00e9<\/a><\/li>\n
- Les limites du CI\/CD<\/a><\/li>\n
- De l’automatisation des versions d’application (ARA) \u00e0 l’orchestration (ARO)<\/a><\/li>\n
- Enterprise DevOps : concilier qualit\u00e9 et rapidit\u00e9 des d\u00e9ploiements<\/a><\/li>\n
- Comment faire la transition des syst\u00e8mes Legacy vers DevOps ?<\/a><\/li>\n
- Tirer parti des pipelines CI\/CD existants<\/a><\/li>\n
- Moderniser votre capital IT<\/a><\/li>\n<\/ul>\n<\/div><\/div>\n
Du CI\/CD vers l\u2019Entreprise DevOps<\/h2>\n
Les environnements informatiques d’aujourd’hui se composent d’un m\u00e9lange complexe d’applications compos\u00e9es chacune de centaines de micro services, de conteneurs et de multiples technologies de d\u00e9veloppement – y compris des plates-formes existantes qui se sont av\u00e9r\u00e9es si fiables et pr\u00e9cieuses pour l’entreprise que m\u00eame en 2018, elles constituent toujours le c\u0153ur de nombreuses applications commerciales parmi les plus importantes au monde.<\/p>\n
De nombreux pipelines CI\/CD<\/strong> ont \u00e9t\u00e9 efficaces en mati\u00e8re d’approvisionnement, de configuration de l’environnement et d’automatisation du d\u00e9ploiement des applications. Mais jusqu’\u00e0 pr\u00e9sent, ils n’ont pas r\u00e9ussi \u00e0 donner au niveau de l\u2019entreprise les r\u00e9ponses aux questions qu’elle se pose sur la conformit\u00e9 aux r\u00e9glementations, la gouvernance et la s\u00e9curit\u00e9.<\/p>\nCe qu’on appelle aujourd’hui les pipelines DevOps<\/strong> sont souvent des cha\u00eenes d’outils disparates, fragiles et sur mesure. Con\u00e7us principalement pour les environnements natifs du Cloud, ils ont automatis\u00e9 avec succ\u00e8s un processus reproductible pour faire fonctionner, tester et livrer les applications.<\/p>\nMais la plupart n’ont pas la couche technologique n\u00e9cessaire pour g\u00e9rer les plates-formes h\u00e9rit\u00e9es 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\u00e9tuel d’arr\u00eats de production et de co\u00fbts incontr\u00f4l\u00e9s.<\/p>\n
Des solutions \u00e9mergent. \u00c9coutez l’exp\u00e9rience de SpareBank1 <\/a>comme exemple r\u00e9cent. La prochaine phase de la gestion des versions est d\u00e9j\u00e0 en place. Enterprise DevOps offre un pipeline de livraison de logiciels unique et commun \u00e0 travers toutes les cultures de d\u00e9veloppement informatique et une transparence de bout en bout sur l’\u00e9tat des versions. Ce blog explique comment nous en sommes arriv\u00e9s l\u00e0.<\/p>\n<\/p>\n<\/div>\nQu’est-ce qui retient DevOps ? Le bimodal IT d\u00e9tient la cl\u00e9<\/h2>\n
Ces derni\u00e8res ann\u00e9es ont vu l’\u00e9mergence du “Bimodal IT<\/strong>“, une pratique de gestion informatique qui reconna\u00eet deux types – et deux vitesses – de d\u00e9veloppement logiciel et prescrit des processus distincts mais coordonn\u00e9s pour chacun.<\/p>\nGartner Research d\u00e9finit le Bimodal IT comme ” la pratique consistant \u00e0 g\u00e9rer deux styles de travail distincts mais coh\u00e9rents : l’un ax\u00e9 sur la pr\u00e9dictibilit\u00e9 et l’autre sur l’exploration “.<\/p>\n
Dans la pratique, cela n\u00e9cessite deux voies parall\u00e8les, l’une soutenant le d\u00e9veloppement rapide d’applications pour les projets d’innovation num\u00e9rique, et l’autre, plus lente, pour la maintenance continue des applications sur les principaux actifs logiciels.<\/p>\n
![\"Bimodal](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2018\/10\/Bimodal-IT.png\")
<\/p>\n
Selon Gartner, les styles de travail en IT se r\u00e9partissent en deux modes. Le mode bimodal 1 est optimis\u00e9 pour des domaines plus pr\u00e9visibles et mieux compris. Il met l’accent sur l’exploitation de ce qui est connu, tout en transformant l’environnement existant en un \u00e9tat qui convient \u00e0 un monde num\u00e9rique. Le mode 2 est exploratoire, exp\u00e9rimental pour r\u00e9soudre de nouveaux probl\u00e8mes et optimis\u00e9 pour les zones de flous. Ces initiatives commencent souvent par une hypoth\u00e8se qui est test\u00e9e et adapt\u00e9e au cours d’un processus impliquant de courtes it\u00e9rations, adoptant potentiellement une approche de produit minimum viable (MVP). Les deux modes sont essentiels dans une entreprise pour cr\u00e9er une valeur substantielle et entra\u00eener des changements organisationnels importants, et ni l’un ni l’autre ne sont statiques. Combiner une \u00e9volution plus pr\u00e9visible des produits et des technologies (mode 1) \u00e0 une nouvelle et plus innovante (mode 2) est l’essence m\u00eame du mod\u00e8le bimodal. Tous deux jouent un r\u00f4le essentiel dans la transformation num\u00e9rique.<\/p>\n
Les syst\u00e8mes Legacy comme IBM i et z\/OS entrent souvent dans la cat\u00e9gorie Mode 1. Les nouveaux d\u00e9veloppements sur Windows, Unix et Linux tombent g\u00e9n\u00e9ralement dans le mode 2.<\/p>\n<\/p>\n
<\/div>\nLes limites du CI\/CD<\/h2>\n
Une livraison<\/strong> fluide des logiciels<\/strong> 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\u00e9n\u00e9ralis\u00e9e de l’int\u00e9gration continue automatis\u00e9e et de la livraison continue (CI\/CD). Mais soyons clairs sur ce qu’est le CI\/CD<\/a> et ce qu’il n’est pas.<\/p>\nL’int\u00e9gration continue<\/strong> (CI) est un ensemble de pratiques de d\u00e9veloppement qui incitent les \u00e9quipes \u00e0 mettre en \u0153uvre de petits changements et \u00e0 v\u00e9rifier fr\u00e9quemment le code dans les r\u00e9f\u00e9rentiels partag\u00e9s. CI commence \u00e0 la fin de la phase de code et demande aux d\u00e9veloppeurs d’int\u00e9grer du code dans le r\u00e9f\u00e9rentiel plusieurs fois par jour. Chaque contr\u00f4le est ensuite v\u00e9rifi\u00e9 par une build et test automatis\u00e9s, ce qui permet aux \u00e9quipes de d\u00e9tecter et de corriger les probl\u00e8mes rapidement.
\nLa Livraison Continue (CD) <\/strong>prend en charge les phases du SDLC, l\u00e0 o\u00f9 se termine le CI : provision des environnements de test, d\u00e9ploiement des tests, validation des tests et d\u00e9ploiement en production.
\nLe d\u00e9ploiement continu<\/strong> prolonge la livraison continue : chaque changement qui r\u00e9ussit les tests automatis\u00e9s est automatiquement d\u00e9ploy\u00e9 en production. Selon DevOps, le d\u00e9ploiement continu devrait \u00eatre l’objectif de la plupart des entreprises qui ne sont pas contraintes par des exigences r\u00e9glementaires ou autres.
\nLe probl\u00e8me est que la plupart des pipelines CI\/CD sont limit\u00e9s dans leur utilisation du ” cloud-native “, \u00e9galement appel\u00e9es nouvelles technologies de l’entreprise. Les entreprises d’aujourd’hui attendent la prochaine \u00e9volution, celle d’un pipeline commun et partag\u00e9 \u00e0 travers toutes les cultures technologiques. Pour y parvenir, de nombreuses organisations devront passer d’une simple automatisation \u00e0 de la business release coordination, ou orchestration<\/strong>.<\/p>\n<\/div><\/div><\/div>L\u2019adoption de DevOps se d\u00e9veloppe plus rapidement que jamais. D\u00e9couvrez quelles sont les derni\u00e8res pr\u00e9visions DevOps et comment cette culture agile d\u2019entreprise am\u00e9liore l\u2019efficacit\u00e9 dans tous les secteurs d\u2019activit\u00e9 !<\/strong><\/p>\n<\/div>D\u00e9couvrez l’infographie<\/span><\/i><\/a><\/div><\/div><\/div><\/div><\/div><\/div>\nDe l’automatisation des versions d’application (ARA) \u00e0 l’orchestration (ARO)<\/h2>\n
L’automatisation des versions d’applications<\/strong> (ARA) implique le conditionnement et le d\u00e9ploiement d’une application, d’une mise \u00e0 jour ou d’une version depuis le d\u00e9veloppement, dans divers environnements et m\u00eame jusqu’en production. Les outils ARA associent des fonctionnalit\u00e9s d’automatisation du d\u00e9ploiement, de gestion de l’environnement et de mod\u00e9lisation.
\nD’ici 2020, Gartner pr\u00e9voit que plus de 50 % des entreprises mondiales auront mis en \u0153uvre au moins une solution d’Application Release Automation, contre moins de 15 % en 2017. Depuis sa cr\u00e9ation il y a environ sept ans, le march\u00e9 des solutions ARA a atteint 228,2 millions de dollars en 2016, en hausse de 31,4 % par rapport \u00e0 2015. Le march\u00e9 devrait continuer de cro\u00eetre \u00e0 un taux de croissance annuel compos\u00e9 (TCAC) estim\u00e9 \u00e0 20 % jusqu’en 2020.
\nLe march\u00e9 de l’ARA \u00e9volue rapidement en r\u00e9ponse aux exigences croissantes des entreprises qui souhaitent \u00e0 la fois \u00e9tendre les initiatives DevOps et am\u00e9liorer l’agilit\u00e9 du release management dans de multiples cultures, processus et g\u00e9n\u00e9rations de technologies. Nous voyons ARA se transformer en une nouvelle discipline, l’ Application Release Orchestration<\/strong> (ARO).
\nUne couche au-dessus d\u2019ARA, les outils ARO (Application Release Orchestration) organisent et coordonnent les t\u00e2ches automatis\u00e9es en un flux de travail consolid\u00e9 de release management. Ils am\u00e9liorent les meilleures pratiques<\/strong> en d\u00e9pla\u00e7ant les artefacts, les applications, les configurations et m\u00eame les donn\u00e9es li\u00e9es 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\u00e9 sur l’ensemble du processus de d\u00e9ploiement du logiciel.
\nARO est la pierre angulaire d’ Enterprise DevOps<\/strong>.<\/p>\n<\/div>\nEnterprise DevOps : concilier qualit\u00e9 et rapidit\u00e9 des d\u00e9ploiements<\/h2>\n
Enterprise DevOps est encore r\u00e9cent et des d\u00e9finitions divergentes \u00e9mergent. Consid\u00e9rez-le comme DevOps at Scale<\/strong>.
\nTout comme pour le bimodal IT, les grandes entreprises ont recours aux \u00e9quipes DevOps pour construire et d\u00e9ployer des logiciels via des pipelines individuels et parall\u00e8les. Les pipelines<\/strong> circulent en continu du d\u00e9veloppement \u00e0 l’int\u00e9gration et au d\u00e9ploiement de mani\u00e8re it\u00e9rative. Chaque pipeline parall\u00e8le utilise des cha\u00eenes d’approvisionnement pour automatiser<\/strong> ou orchestrer<\/strong> les phases et sous-phases du SDLC Enterprise DevOps.
\nA un certain niveau, les phases du SDLC Enterprise DevOps peuvent \u00eatre r\u00e9sum\u00e9es de cette mani\u00e8re : planification, analyse, design, code, commit, test unitaire, test d’int\u00e9gration, test fonctionnel, test de d\u00e9ploiement, test d’acceptation, d\u00e9ploiement en production, impl\u00e9mentation et feed-back utilisateur.
\nLes \u00e9tapes et les t\u00e2ches de l’ED-SDLC peuvent diff\u00e9rer en fonction des pipelines o\u00f9 il peut y avoir un niveau d’importance diff\u00e9rent pour chaque \u00e9tape ou sous-\u00e9tape. Par exemple, en mode bimodal 1 sur un SOR, les phases de planification, d’analyse et de conception peuvent \u00eatre plus importantes qu’en mode bimodal 2. Dans le mode bimodal 2 sur un SOE, la fr\u00e9quence du commit, du test unitaire, du test d’int\u00e9gration et du test fonctionnel peut \u00eatre bien plus \u00e9lev\u00e9e.
\nLe risque d’erreur de d\u00e9ploiement est \u00e9lev\u00e9 dans les environnements d’entreprise<\/strong> parce que les cha\u00eenes d’approvisionnement dans chaque pipeline diff\u00e8rent et qu’il existe des d\u00e9pendances entre les artefacts dans diff\u00e9rents pipelines. L’orchestration est n\u00e9cessaire pour coordonner les processus \u00e0 travers les pipelines. L’orchestration \u00e9quivaut \u00e0 une automatisation plus sophistiqu\u00e9e, avec de l’intelligence int\u00e9gr\u00e9e et l’objectif ultime d’\u00eatre autonome.<\/p>\n<\/div>\nComment faire la transition des syst\u00e8mes Legacy vers DevOps ?<\/h2>\n
En r\u00e9ponse aux d\u00e9fis du Bimodal IT, nous avons atteint un point de convergence<\/strong> entre les pratiques classiques du DevOps et du Release Management.
\nDepuis plus de 25 ans, Arcad Software permet aux grandes entreprises et aux PME d’am\u00e9liorer le d\u00e9veloppement de logiciels gr\u00e2ce \u00e0 des outils uniques et des techniques innovantes. Au cours de cette p\u00e9riode, nous avons d\u00e9velopp\u00e9 une expertise unique des syst\u00e8mes IBM i<\/strong> et z\/OS<\/strong> existants. Aujourd’hui, nous sommes reconnus<\/strong> 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.
\nDe nombreux fournisseurs d’ARO s’attendent \u00e0 de nouveaux d\u00e9veloppements sur Windows, Unix et Linux et, par cons\u00e9quent,que les syst\u00e8mes legacy ne seront plus qu’un lointain souvenir. ARCAD est diff\u00e9rent ; nous comprenons la n\u00e9cessit\u00e9 de tirer le meilleur parti de l’investissement de votre entreprise<\/strong> effectu\u00e9 dans les syst\u00e8mes legacy au cours des derni\u00e8res d\u00e9cennies, ainsi que les exigences et les d\u00e9fis li\u00e9s \u00e0 la valorisation de ces applications legacy.<\/p>\nARCAD peut s’assurer que vous pouvez offrir \u00e0 vos responsables d’applications et parties prenantes une solution pratique et int\u00e9gr\u00e9e, \u00e9tape par \u00e9tape, pour fournir \u00e0 la fois DevOps et ARO pour les applications nouvelles et legacy, plut\u00f4t que des projets co\u00fbteux et risqu\u00e9s de remplacement de l’infrastructure.<\/p>\n<\/div><\/div><\/div>
D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div>T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div><\/div>\nTirer parti des pipelines CI\/CD existants<\/h2>\n
Les organisations disposent aujourd’hui d’un grand nombre d’outils pour mettre en \u0153uvre DevOps. Les outils se superposent et le danger est “l’\u00e9talement de la cha\u00eene d’outils”. Pourtant, aucun outil ne peut \u00e0 lui seul r\u00e9pondre \u00e0 tous les besoins dans un environnement de d\u00e9veloppement moderne. Il est donc essentiel que tous les outils s\u00e9lectionn\u00e9s s’int\u00e8grent<\/strong> facilement les uns aux autres.
\nLa solution ARCAD pour DevOps<\/a> a une architecture ouverte et s’int\u00e8gre facilement aux outils standards tels que Git, Jenkins, JIRA, ServiceNow<\/strong>. Elle est capable d’orchestrer la livraison de tous les actifs applicatifs de l’entreprise, depuis les technologies Cloud les plus r\u00e9centes jusqu’au code de base qui sous-tend votre entreprise.<\/p>\nLes solutions ARCAD \u00e9tendent et adaptent votre pipeline DevOps<\/strong> existant en un flux de travail sans friction qui supporte TOUTES les plateformes de votre business.<\/p>\n<\/p>\n
En 2018, le probl\u00e8me du silo<\/strong> informatique persiste.\u00a0 Le foss\u00e9 entre les initiatives num\u00e9riques et le d\u00e9veloppement du Legacy \u00e9puise les budgets informatiques et entra\u00eene des livraisons incoh\u00e9rentes vers la production.<\/p>\n Les erreurs d\u00e9tect\u00e9es \u00e0 ce niveau ont un impact business direct\u00a0: le co\u00fbt moyen d’un incident majeur d\u2019une application logicielle strat\u00e9gique en production par heure est de 1 M$, soit dix fois le co\u00fbt horaire moyen de dysfonctionnement mat\u00e9riel (*).\u00a0 Et \u00e9tonnamment, 70 % des erreurs de production sont dues \u00e0 des erreurs de d\u00e9ploiement, et seulement 30 % \u00e0 des erreurs de code. Pourtant, les DSI responsables de diverses cultures informatiques d\u2019aujourd\u2019hui manquent de visibilit\u00e9 et de contr\u00f4le sur le processus de d\u00e9ploiement des logiciels.<\/p>\n Quelles solutions \u00e9mergent\u00a0? Depuis le dernier Gartner Symposium, nous assistons \u00e0 la convergence des technologies de Release Management<\/strong> et DevOps<\/strong>.\u00a0 Enterprise DevOps<\/strong> arrive \u00e0 maturit\u00e9.<\/p>\n En tant que mouvement dominant, la communaut\u00e9 DevOps assume la responsabilit\u00e9 op\u00e9rationnelle synonyme de succ\u00e8s.\u00a0 L’agilit\u00e9 du “Dev” confronte les contraintes et les politiques d’entreprise famili\u00e8res aux “Ops”.<\/p>\n<\/div> Les environnements informatiques d’aujourd’hui se composent d’un m\u00e9lange complexe d’applications compos\u00e9es chacune de centaines de micro services, de conteneurs et de multiples technologies de d\u00e9veloppement – y compris des plates-formes existantes qui se sont av\u00e9r\u00e9es si fiables et pr\u00e9cieuses pour l’entreprise que m\u00eame en 2018, elles constituent toujours le c\u0153ur de nombreuses applications commerciales parmi les plus importantes au monde.<\/p>\n De nombreux pipelines CI\/CD<\/strong> ont \u00e9t\u00e9 efficaces en mati\u00e8re d’approvisionnement, de configuration de l’environnement et d’automatisation du d\u00e9ploiement des applications. Mais jusqu’\u00e0 pr\u00e9sent, ils n’ont pas r\u00e9ussi \u00e0 donner au niveau de l\u2019entreprise les r\u00e9ponses aux questions qu’elle se pose sur la conformit\u00e9 aux r\u00e9glementations, la gouvernance et la s\u00e9curit\u00e9.<\/p>\n Ce qu’on appelle aujourd’hui les pipelines DevOps<\/strong> sont souvent des cha\u00eenes d’outils disparates, fragiles et sur mesure. Con\u00e7us principalement pour les environnements natifs du Cloud, ils ont automatis\u00e9 avec succ\u00e8s un processus reproductible pour faire fonctionner, tester et livrer les applications.<\/p>\n Mais la plupart n’ont pas la couche technologique n\u00e9cessaire pour g\u00e9rer les plates-formes h\u00e9rit\u00e9es 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\u00e9tuel d’arr\u00eats de production et de co\u00fbts incontr\u00f4l\u00e9s.<\/p>\n Des solutions \u00e9mergent. \u00c9coutez l’exp\u00e9rience de SpareBank1 <\/a>comme exemple r\u00e9cent. La prochaine phase de la gestion des versions est d\u00e9j\u00e0 en place. Enterprise DevOps offre un pipeline de livraison de logiciels unique et commun \u00e0 travers toutes les cultures de d\u00e9veloppement informatique et une transparence de bout en bout sur l’\u00e9tat des versions. Ce blog explique comment nous en sommes arriv\u00e9s l\u00e0.<\/p>\n<\/p>\n Ces derni\u00e8res ann\u00e9es ont vu l’\u00e9mergence du “Bimodal IT<\/strong>“, une pratique de gestion informatique qui reconna\u00eet deux types – et deux vitesses – de d\u00e9veloppement logiciel et prescrit des processus distincts mais coordonn\u00e9s pour chacun.<\/p>\n Gartner Research d\u00e9finit le Bimodal IT comme ” la pratique consistant \u00e0 g\u00e9rer deux styles de travail distincts mais coh\u00e9rents : l’un ax\u00e9 sur la pr\u00e9dictibilit\u00e9 et l’autre sur l’exploration “.<\/p>\n Dans la pratique, cela n\u00e9cessite deux voies parall\u00e8les, l’une soutenant le d\u00e9veloppement rapide d’applications pour les projets d’innovation num\u00e9rique, et l’autre, plus lente, pour la maintenance continue des applications sur les principaux actifs logiciels.<\/p>\n Selon Gartner, les styles de travail en IT se r\u00e9partissent en deux modes. Le mode bimodal 1 est optimis\u00e9 pour des domaines plus pr\u00e9visibles et mieux compris. Il met l’accent sur l’exploitation de ce qui est connu, tout en transformant l’environnement existant en un \u00e9tat qui convient \u00e0 un monde num\u00e9rique. Le mode 2 est exploratoire, exp\u00e9rimental pour r\u00e9soudre de nouveaux probl\u00e8mes et optimis\u00e9 pour les zones de flous. Ces initiatives commencent souvent par une hypoth\u00e8se qui est test\u00e9e et adapt\u00e9e au cours d’un processus impliquant de courtes it\u00e9rations, adoptant potentiellement une approche de produit minimum viable (MVP). Les deux modes sont essentiels dans une entreprise pour cr\u00e9er une valeur substantielle et entra\u00eener des changements organisationnels importants, et ni l’un ni l’autre ne sont statiques. Combiner une \u00e9volution plus pr\u00e9visible des produits et des technologies (mode 1) \u00e0 une nouvelle et plus innovante (mode 2) est l’essence m\u00eame du mod\u00e8le bimodal. Tous deux jouent un r\u00f4le essentiel dans la transformation num\u00e9rique.<\/p>\n Les syst\u00e8mes Legacy comme IBM i et z\/OS entrent souvent dans la cat\u00e9gorie Mode 1. Les nouveaux d\u00e9veloppements sur Windows, Unix et Linux tombent g\u00e9n\u00e9ralement dans le mode 2.<\/p>\n<\/p>\n Une livraison<\/strong> fluide des logiciels<\/strong> 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\u00e9n\u00e9ralis\u00e9e de l’int\u00e9gration continue automatis\u00e9e et de la livraison continue (CI\/CD). Mais soyons clairs sur ce qu’est le CI\/CD<\/a> et ce qu’il n’est pas.<\/p>\n L’int\u00e9gration continue<\/strong> (CI) est un ensemble de pratiques de d\u00e9veloppement qui incitent les \u00e9quipes \u00e0 mettre en \u0153uvre de petits changements et \u00e0 v\u00e9rifier fr\u00e9quemment le code dans les r\u00e9f\u00e9rentiels partag\u00e9s. CI commence \u00e0 la fin de la phase de code et demande aux d\u00e9veloppeurs d’int\u00e9grer du code dans le r\u00e9f\u00e9rentiel plusieurs fois par jour. Chaque contr\u00f4le est ensuite v\u00e9rifi\u00e9 par une build et test automatis\u00e9s, ce qui permet aux \u00e9quipes de d\u00e9tecter et de corriger les probl\u00e8mes rapidement. L\u2019adoption de DevOps se d\u00e9veloppe plus rapidement que jamais. D\u00e9couvrez quelles sont les derni\u00e8res pr\u00e9visions DevOps et comment cette culture agile d\u2019entreprise am\u00e9liore l\u2019efficacit\u00e9 dans tous les secteurs d\u2019activit\u00e9 !<\/strong><\/p>\n<\/div> L’automatisation des versions d’applications<\/strong> (ARA) implique le conditionnement et le d\u00e9ploiement d’une application, d’une mise \u00e0 jour ou d’une version depuis le d\u00e9veloppement, dans divers environnements et m\u00eame jusqu’en production. Les outils ARA associent des fonctionnalit\u00e9s d’automatisation du d\u00e9ploiement, de gestion de l’environnement et de mod\u00e9lisation. Enterprise DevOps est encore r\u00e9cent et des d\u00e9finitions divergentes \u00e9mergent. Consid\u00e9rez-le comme DevOps at Scale<\/strong>. En r\u00e9ponse aux d\u00e9fis du Bimodal IT, nous avons atteint un point de convergence<\/strong> entre les pratiques classiques du DevOps et du Release Management. ARCAD peut s’assurer que vous pouvez offrir \u00e0 vos responsables d’applications et parties prenantes une solution pratique et int\u00e9gr\u00e9e, \u00e9tape par \u00e9tape, pour fournir \u00e0 la fois DevOps et ARO pour les applications nouvelles et legacy, plut\u00f4t que des projets co\u00fbteux et risqu\u00e9s de remplacement de l’infrastructure.<\/p>\n<\/div><\/div><\/div> D\u00e9couvrez comment ARCAD for DevOps permet de contr\u00f4ler les co\u00fbts et d\u2019acc\u00e9l\u00e9rer les d\u00e9ploiements d\u2019applications dans des environnements technologiques h\u00e9t\u00e9rog\u00e8nes.<\/strong><\/p>\n<\/div> Les organisations disposent aujourd’hui d’un grand nombre d’outils pour mettre en \u0153uvre DevOps. Les outils se superposent et le danger est “l’\u00e9talement de la cha\u00eene d’outils”. Pourtant, aucun outil ne peut \u00e0 lui seul r\u00e9pondre \u00e0 tous les besoins dans un environnement de d\u00e9veloppement moderne. Il est donc essentiel que tous les outils s\u00e9lectionn\u00e9s s’int\u00e8grent<\/strong> facilement les uns aux autres. Les solutions ARCAD \u00e9tendent et adaptent votre pipeline DevOps<\/strong> existant en un flux de travail sans friction qui supporte TOUTES les plateformes de votre business.<\/p>\n<\/p>\nSommaire :<\/h2>\n
\n
Du CI\/CD vers l\u2019Entreprise DevOps<\/h2>\n
Qu’est-ce qui retient DevOps ? Le bimodal IT d\u00e9tient la cl\u00e9<\/h2>\n
<\/p>\nLes limites du CI\/CD<\/h2>\n
\nLa Livraison Continue (CD) <\/strong>prend en charge les phases du SDLC, l\u00e0 o\u00f9 se termine le CI : provision des environnements de test, d\u00e9ploiement des tests, validation des tests et d\u00e9ploiement en production.
\nLe d\u00e9ploiement continu<\/strong> prolonge la livraison continue : chaque changement qui r\u00e9ussit les tests automatis\u00e9s est automatiquement d\u00e9ploy\u00e9 en production. Selon DevOps, le d\u00e9ploiement continu devrait \u00eatre l’objectif de la plupart des entreprises qui ne sont pas contraintes par des exigences r\u00e9glementaires ou autres.
\nLe probl\u00e8me est que la plupart des pipelines CI\/CD sont limit\u00e9s dans leur utilisation du ” cloud-native “, \u00e9galement appel\u00e9es nouvelles technologies de l’entreprise. Les entreprises d’aujourd’hui attendent la prochaine \u00e9volution, celle d’un pipeline commun et partag\u00e9 \u00e0 travers toutes les cultures technologiques. Pour y parvenir, de nombreuses organisations devront passer d’une simple automatisation \u00e0 de la business release coordination, ou orchestration<\/strong>.<\/p>\n<\/div><\/div><\/div>De l’automatisation des versions d’application (ARA) \u00e0 l’orchestration (ARO)<\/h2>\n
\nD’ici 2020, Gartner pr\u00e9voit que plus de 50 % des entreprises mondiales auront mis en \u0153uvre au moins une solution d’Application Release Automation, contre moins de 15 % en 2017. Depuis sa cr\u00e9ation il y a environ sept ans, le march\u00e9 des solutions ARA a atteint 228,2 millions de dollars en 2016, en hausse de 31,4 % par rapport \u00e0 2015. Le march\u00e9 devrait continuer de cro\u00eetre \u00e0 un taux de croissance annuel compos\u00e9 (TCAC) estim\u00e9 \u00e0 20 % jusqu’en 2020.
\nLe march\u00e9 de l’ARA \u00e9volue rapidement en r\u00e9ponse aux exigences croissantes des entreprises qui souhaitent \u00e0 la fois \u00e9tendre les initiatives DevOps et am\u00e9liorer l’agilit\u00e9 du release management dans de multiples cultures, processus et g\u00e9n\u00e9rations de technologies. Nous voyons ARA se transformer en une nouvelle discipline, l’ Application Release Orchestration<\/strong> (ARO).
\nUne couche au-dessus d\u2019ARA, les outils ARO (Application Release Orchestration) organisent et coordonnent les t\u00e2ches automatis\u00e9es en un flux de travail consolid\u00e9 de release management. Ils am\u00e9liorent les meilleures pratiques<\/strong> en d\u00e9pla\u00e7ant les artefacts, les applications, les configurations et m\u00eame les donn\u00e9es li\u00e9es 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\u00e9 sur l’ensemble du processus de d\u00e9ploiement du logiciel.
\nARO est la pierre angulaire d’ Enterprise DevOps<\/strong>.<\/p>\nEnterprise DevOps : concilier qualit\u00e9 et rapidit\u00e9 des d\u00e9ploiements<\/h2>\n
\nTout comme pour le bimodal IT, les grandes entreprises ont recours aux \u00e9quipes DevOps pour construire et d\u00e9ployer des logiciels via des pipelines individuels et parall\u00e8les. Les pipelines<\/strong> circulent en continu du d\u00e9veloppement \u00e0 l’int\u00e9gration et au d\u00e9ploiement de mani\u00e8re it\u00e9rative. Chaque pipeline parall\u00e8le utilise des cha\u00eenes d’approvisionnement pour automatiser<\/strong> ou orchestrer<\/strong> les phases et sous-phases du SDLC Enterprise DevOps.
\nA un certain niveau, les phases du SDLC Enterprise DevOps peuvent \u00eatre r\u00e9sum\u00e9es de cette mani\u00e8re : planification, analyse, design, code, commit, test unitaire, test d’int\u00e9gration, test fonctionnel, test de d\u00e9ploiement, test d’acceptation, d\u00e9ploiement en production, impl\u00e9mentation et feed-back utilisateur.
\nLes \u00e9tapes et les t\u00e2ches de l’ED-SDLC peuvent diff\u00e9rer en fonction des pipelines o\u00f9 il peut y avoir un niveau d’importance diff\u00e9rent pour chaque \u00e9tape ou sous-\u00e9tape. Par exemple, en mode bimodal 1 sur un SOR, les phases de planification, d’analyse et de conception peuvent \u00eatre plus importantes qu’en mode bimodal 2. Dans le mode bimodal 2 sur un SOE, la fr\u00e9quence du commit, du test unitaire, du test d’int\u00e9gration et du test fonctionnel peut \u00eatre bien plus \u00e9lev\u00e9e.
\nLe risque d’erreur de d\u00e9ploiement est \u00e9lev\u00e9 dans les environnements d’entreprise<\/strong> parce que les cha\u00eenes d’approvisionnement dans chaque pipeline diff\u00e8rent et qu’il existe des d\u00e9pendances entre les artefacts dans diff\u00e9rents pipelines. L’orchestration est n\u00e9cessaire pour coordonner les processus \u00e0 travers les pipelines. L’orchestration \u00e9quivaut \u00e0 une automatisation plus sophistiqu\u00e9e, avec de l’intelligence int\u00e9gr\u00e9e et l’objectif ultime d’\u00eatre autonome.<\/p>\nComment faire la transition des syst\u00e8mes Legacy vers DevOps ?<\/h2>\n
\nDepuis plus de 25 ans, Arcad Software permet aux grandes entreprises et aux PME d’am\u00e9liorer le d\u00e9veloppement de logiciels gr\u00e2ce \u00e0 des outils uniques et des techniques innovantes. Au cours de cette p\u00e9riode, nous avons d\u00e9velopp\u00e9 une expertise unique des syst\u00e8mes IBM i<\/strong> et z\/OS<\/strong> existants. Aujourd’hui, nous sommes reconnus<\/strong> 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.
\nDe nombreux fournisseurs d’ARO s’attendent \u00e0 de nouveaux d\u00e9veloppements sur Windows, Unix et Linux et, par cons\u00e9quent,que les syst\u00e8mes legacy ne seront plus qu’un lointain souvenir. ARCAD est diff\u00e9rent ; nous comprenons la n\u00e9cessit\u00e9 de tirer le meilleur parti de l’investissement de votre entreprise<\/strong> effectu\u00e9 dans les syst\u00e8mes legacy au cours des derni\u00e8res d\u00e9cennies, ainsi que les exigences et les d\u00e9fis li\u00e9s \u00e0 la valorisation de ces applications legacy.<\/p>\nTirer parti des pipelines CI\/CD existants<\/h2>\n
\nLa solution ARCAD pour DevOps<\/a> a une architecture ouverte et s’int\u00e8gre facilement aux outils standards tels que Git, Jenkins, JIRA, ServiceNow<\/strong>. Elle est capable d’orchestrer la livraison de tous les actifs applicatifs de l’entreprise, depuis les technologies Cloud les plus r\u00e9centes jusqu’au code de base qui sous-tend votre entreprise.<\/p>\n
![\"Olenka](\"https:\/\/www.arcadsoftware.fr\/arcad\/wp-content\/uploads\/2026\/03\/olenka-van-schendel.png\" "\\"olenka-van-schendel\\"")
<\/span><\/div><\/div><\/div>