{"id":28314,"date":"2018-10-12T15:31:48","date_gmt":"2018-10-12T13:31:48","guid":{"rendered":"http:\/\/arcadsoftware.com\/?p=28314"},"modified":"2026-03-13T12:17:02","modified_gmt":"2026-03-13T10:17:02","slug":"quelles-evolutions-pour-le-devops","status":"publish","type":"post","link":"https:\/\/www.arcadsoftware.fr\/arcad\/infos-et-evenements\/blog-fr\/quelles-evolutions-pour-le-devops\/","title":{"rendered":"Quelles \u00e9volutions pour le DevOps ?"},"content":{"rendered":"

par Marc Dallas <\/h3>\n<\/div><\/div><\/div>

Le concept DevOps<\/a><\/strong> s\u2019est largement d\u00e9velopp\u00e9 ces derni\u00e8res ann\u00e9es dans de nombreuses organisations souhaitant r\u00e9pondre plus efficacement \u00e0 leurs enjeux business.
\nSi DevOps concernait jusque-l\u00e0 principalement les services IT, il se r\u00e9pand aujourd\u2019hui sur l\u2019ensemble de la cha\u00eene de l\u2019entreprise et entra\u00eene de nombreuses \u00e9volutions<\/strong>.<\/p>\n

DevOps, avant tout une gestion du changement<\/h2>\n

Les organisations qui ont mis en place tout ou partie de DevOps<\/a><\/strong> ont depuis longtemps identifi\u00e9 et valid\u00e9 qu\u2019une telle d\u00e9marche garantissait un retour sur investissement.
\nPar contre, beaucoup d\u2019autres ont abord\u00e9 et \u00e9tudi\u00e9 DevOps mais ne l\u2019ont pas encore traduit dans les faits.
\nLa raison principale est que DevOps est avant tout une d\u00e9marche de gestion du changement<\/strong>.
\nEn effet, DevOps ne se r\u00e9sume pas \u00e0 choisir la bonne solution d\u2019automatisation. Il est surtout important de se faire accompagner dans cette d\u00e9marche, et c\u2019est de la responsabilit\u00e9 d\u2019un \u00e9diteur. Dans un projet DevOps, les niveaux de maturit\u00e9 et de compr\u00e9hension sont diff\u00e9rents suivant les organisations. Un fournisseur de solutions DevOps a donc un devoir de conseil<\/strong> et d\u2019accompagnement dans la gestion du changement et doit apporter de la valeur<\/strong>. Il doit \u00e9galement prendre en compte l\u2019entreprise dans sa particularit\u00e9, sa diversit\u00e9. Dans le cas contraire, un projet DevOps n\u2019a aucune chance d\u2019aboutir.<\/p>\n

L\u2019apparition de DevSecOps et BizOps<\/h2>\n

L\u2019apparition de ces termes est directement li\u00e9e \u00e0 la difficult\u00e9 de la relation entre le d\u00e9veloppement et l\u2019op\u00e9rationnel.
\nA l\u2019\u00e9poque, le d\u00e9veloppement s\u2019\u00e9tait organis\u00e9 avec l\u2019arriv\u00e9e de m\u00e9thodes agiles<\/strong>, alors que l\u2019op\u00e9rationnel repr\u00e9sentait un goulot d\u2019\u00e9tranglement. Pour que le cycle soit fluide, il fallait donc absolument int\u00e9grer les op\u00e9rations.
\nUne communication s’est alors cr\u00e9\u00e9e, et une reconnaissance des contraintes entre les diff\u00e9rents services a \u00e9t\u00e9 mise en place. Nous sommes pass\u00e9s dans une posture de dialogue, d\u2019\u00e9changes et d\u2019\u00e9laboration des processus : reconnaissance du m\u00e9tier de l\u2019autre et int\u00e9gration des contraintes de chacun pour pouvoir avoir une zone de discussion commune.<\/p>\n

L\u2019apparition de nouveaux termes relatifs au DevOps<\/strong> repr\u00e9sente simplement une extension de la posture de communication \u00e0 l\u2019ensemble des services, une progression dans la mutation des entreprises.
\nLe DevSecOps<\/strong>, par exemple, a pour objectif de renforcer la s\u00e9curit\u00e9 en l\u2019int\u00e9grant d\u00e8s le d\u00e9but du processus de d\u00e9veloppement des applications. D\u2019autres services pourraient d’ailleurs \u00eatre rajout\u00e9s dans la cha\u00eene.
\nCela veut surtout dire qu\u2019aujourd\u2019hui les entreprises prennent conscience qu\u2019il y a une n\u00e9cessit\u00e9 d\u2019avoir une cha\u00eene logistique globale<\/strong> qui, \u00e0 chaque articulation, int\u00e8gre la m\u00eame posture que celle d\u00e9crite par DevOps.<\/p>\n

BizOps<\/strong> est davantage un terme g\u00e9n\u00e9rique. Il s\u2019agit d\u2019une cha\u00eene entre le business et l\u2019op\u00e9rationnel. C\u2019est une contraction que l’on pourrait finalement appeler \u00ab BizDevSecOps \u00bb.
\nElle implique la direction strat\u00e9gique \u00e0 l\u2019op\u00e9rationnel. Nous devrions d\u2019ailleurs ne plus parler d\u2019Ops aujourd\u2019hui, mais d\u2019utilisateurs (BizUsers).
\nNous revenons finalement \u00e0 de vieilles notions telles que le BtoB ou le BtoC, except\u00e9 le fait que l’on int\u00e8gre aujourd\u2019hui \u00e0 la connotation de ces termes un changement d\u2019organisation interne, n\u00e9cessaire \u00e0 l\u2019entreprise. Cela permet d\u2019obtenir une granularit\u00e9 de travail pour pouvoir se concentrer sur la r\u00e9solution de probl\u00e8mes dans un domaine particulier. Il s\u2019agit de d\u00e9finir et d\u2019ex\u00e9cuter toutes les actions requises et les automatiser<\/strong> dans un environnement de livraison continue.
\nC\u2019est toute la notion de Release Coordination<\/strong>, de la direction strat\u00e9gique jusqu\u2019\u00e0 la mise \u00e0 disposition aupr\u00e8s de l\u2019utilisateur.<\/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>

Les challenges de l\u2019Enterprise DevOps<\/h2>\n

La notion d\u2019Enterprise DevOps<\/strong> permet de positionner DevOps comme une strat\u00e9gie<\/strong> d\u2019entreprise, un processus qui apporte de la plus-value \u00e0 l\u2019organisation, et pas uniquement dans les services informatiques.
\nLes enjeux en termes d\u2019identification, de validation de release entre les diff\u00e9rents services, d\u2019explication d\u2019un goulot d\u2019\u00e9tranglement, de temps de d\u00e9cision, de r\u00e9alisation ou temps de mise \u00e0 disposition, s\u2019ils sont r\u00e9solus \u00e0 l\u2019\u00e9chelle du DevOps, peuvent \u00eatre un terrain exp\u00e9rimental. Cette notion d\u2019articulation<\/strong> interservices pourra alors \u00eatre \u00e9tendue \u00e0 l\u2019ensemble de l\u2019entreprise, ce qui permettra de facto d\u2019augmenter le retour sur investissement sur la globalit\u00e9.
\nEt c\u2019est l\u00e0 tout le d\u00e9fi de l\u2019Enterprise DevOps : que l\u2019ensemble de l\u2019entreprise prenne conscience de la plus-value<\/strong> apport\u00e9e par ce changement de collaboration entre services.
\nTout ce travail g\u00e9r\u00e9 \u00e0 l\u2019\u00e9chelle microscopique entre Dev et Ops sera alors impl\u00e9ment\u00e9 \u00e0 une \u00e9chelle macroscopique au sein de l\u2019ensemble de la cha\u00eene de l\u2019entreprise (de la d\u00e9cision strat\u00e9gique \u00e0 l\u2019utilisateur final).<\/p>\n<\/div><\/div><\/div>

Vous souhaitez mettre en place une strat\u00e9gie DevOps sur IBM i ? Ce White Paper est pour vous !<\/strong><\/p>\n<\/div>

T\u00e9l\u00e9charger la datasheet<\/span><\/i><\/a><\/div><\/div><\/div>

<\/h2>\n

Les enjeux de DevOps for Database<\/h2>\n

M\u00eame si elle n\u2019est pas nouvelle, la notion de donn\u00e9e prend aujourd\u2019hui de l\u2019ampleur.
\nAfin de gagner du temps et d\u2019\u00e9viter les d\u00e9veloppements, la notion de param\u00e9trage de donn\u00e9es (quelles qu\u2019elles soient et sans pr\u00e9sager de la structure technologique de gestion de donn\u00e9es sous-jacentes), a \u00e9t\u00e9 introduite de fa\u00e7on \u00e0 modifier le comportement de la solution en fonction des donn\u00e9es qui ont \u00e9t\u00e9 saisies.
\nCes donn\u00e9es de param\u00e9trage ont donc un impact sur le comportement de la solution. A ce titre-l\u00e0, ces donn\u00e9es appartiennent au domaine du d\u00e9veloppement et du fonctionnement de l\u2019application.<\/p>\n

G\u00e9n\u00e9ralement, le volume de donn\u00e9es restant faible, des processus d\u00e9grad\u00e9s sont utilis\u00e9s pour la mise en production.
\nCes processus d\u00e9grad\u00e9s ne permettent donc pas d\u2019effectuer des rollbacks<\/strong>, ni par exemple d\u2019identifier le niveau de version du syst\u00e8me install\u00e9, mais tout cela est consid\u00e9r\u00e9 comme anecdotique puisque le volume de donn\u00e9es reste faible.
\nPourtant, la criticit\u00e9<\/strong> est tr\u00e8s importante.
\nEn proc\u00e9dant de cette mani\u00e8re, la cha\u00eene de qualit\u00e9 est rompue, et cela peut mener \u00e0 un incident de production qui engendrera des pertes financi\u00e8res parfois \u00e9normes, mais aussi une perte de confiance dans le processus de d\u00e9ploiement.
\nIl ne faut donc pas se concentrer uniquement sur la fr\u00e9quence de d\u00e9ploiement, mais aussi sur la criticit\u00e9 de ce que repr\u00e9sentent ces donn\u00e9es.
\nElles doivent donc suivre la m\u00eame cha\u00eene de qualit\u00e9 que les applications, ce que promet DevOps for Database<\/strong>.<\/p>\n

Conclusion<\/h3>\n