Automic, désormais acquis par CA Technologies En savoir plus >
 

Reconstruire les principes du DevOps

En donnant lieu à un nombre apparemment infini d’interprétations, le DevOps peut parfois apparaître comme une véritable énigme. Alors, comment définir un ensemble de principes fondamentaux pour guider nos projets de transformation numérique ?

French - Ron Gidron
Ron Gidron, June 19, 2017 2:30 pm
Blog > DevOps | ARA | CA Automic Release Automation > Reconstruire les principes du DevOps

Qu’est-ce que le DevOps ? Quels sont les principes universels du DevOps ? Comment construire une équipe DevOps ? Voici le genre de questions que l’on vous pose souvent lorsque vous êtes un passionné/évangéliste/prosélyte assumé du DevOps. Je sais qu’en grandissant, on nous enseigne qu’il n’y a pas de mauvaises questions, mais à l’heure où les organisations accomplissent leur transformation numérique, ces questions exigent un contexte et un point de référence ; sinon, il est impossible d’y apporter des réponses pertinentes ou précises. Pourquoi ?

Le DevOps est un état de flux constant

Même s’il était possible de répondre à ces questions, ce qui constituait une définition du DevOps à l’époque de sa fondation ne définit pas forcément le DevOps aujourd’hui. Le DevOps peut être mis en œuvre de manière complètement différente d’une entreprise à l’autre – en fonction de la taille, des outils, de la fréquence des lancements et ainsi de suite. Alors, comment définir le DevOps ? Si rien n’est immuable, comment établir des directives sous-jacentes pour guider nos projets de transformation numérique ? Comment ériger un cadre depuis lequel nous pouvons élaborer des réponses simples aux questions ci-dessus ?

En gardant cela à l’esprit, pour tenter de construire les principes du DevOps, il est intéressant de regarder quels aspects ont perduré ou disparu au cours de son évolution. À cet égard, peu d’outils adoptés par les premiers adeptes du mouvement DevOps sont encore utilisés dans leur forme originale. Le DevOps ne peut donc manifestement pas être simplement défini par ses outils.

La fin et les moyens

Toutefois, il n’y a pas que les outils qui changent ; les attentes, les méthodologies et les approches ont toutes évolué. En revanche, un aspect qui est resté constant est la volonté de livrer plus rapidement, avec davantage de qualité. Cependant, cet aspect est-il vraiment propre au DevOps ? Ou fait-il simplement partie de l’objectif global de la transformation numérique ?

En vérité, c’est certainement l’objectif ultime de toute entreprise, et le DevOps offre un moyen d’y parvenir. Je répondrais donc c’est la culture d’un environnement qui favorise la mise en place d’objectifs et d’ambitions communs qui est propre au DevOps. Les équipes de développement, de test, opérationnelles et de sécurité ne doivent pas être considérées comme autant d’unités distinctes, mais plutôt comme une entité unifiée, dont les différents composants s’intègrent les uns aux autres.

Avant l’avènement du DevOps, l’infrastructure et les environnements des différents services étaient très distincts ; désormais, il est habituel de voir de petites équipes de développement compter dans leurs rangs un spécialiste des opérations et des tests. Ces petites équipes peuvent à leur tour travailler en autonomie ou s’intégrer à un ensemble plus vaste.

Toutefois, cela ne signifie pas que les rôles définis disparaissent, mais plutôt que les différentes composantes (Ops, Dev et tests) doivent travailler ensemble, dans un même but, et non se livrer une lutte acharnée ou essayer d’affirmer leur autorité. Et cette attitude doit circuler à travers toute l’entreprise, idéalement depuis la base. Si le DevOps est fondamentalement un concept qui débute sur le terrain, avec les développeurs et le personnel opérationnel, il a également besoin du soutien et de la collaboration de l’ensemble de l’ensemble de la hiérarchie, jusqu’aux cadres dirigeants.

Au final, le DevOps incarne un changement d’état d’esprit, de culture et de mentalité ; un changement qui doit se dérouler en harmonie avec le mantra qui a accompagné l’ère de la transformation numérique : « Toute entreprise est une entreprise de génie logiciel ».

Comprendre la relation du DevOps et les méthodologies agiles

Il est rare que DevOps soit mentionné sans évoquer la méthodologie agile. Ces deux concepts sont étroitement liés et si l’on peut croire que les méthodologies agiles sont issues d’un nouveau mode de réflexion inspiré par le DevOps, c’est plutôt le contraire qui est vrai. Le DevOps était à l’origine un moyen de faciliter la mise en œuvre du Manifeste agile.

Pour garantir une livraison agile des logiciels, il était impératif d’abattre les silos. Et dans une large mesure, il était nécessaire d’introduire la méthodologie Agile au niveau opérationnel. Ceci constitue un excellent exemple de la manière dont la réflexion DevOps a évolué et s’est modérée au fil du temps. Simplement réunir des personnes sous un même toit ne suffit plus ; les barrières persisteraient, et les opérations demeureraient un goulet d’étranglement grevant le cycle de vie de lancement. L’agilité au sein des équipes de développement ne suffirait pas à produire les résultats attendus, car même si les équipes de développement et opérationnelles avaient le même objectif, ils emploieraient des outils et des processus différents pour l’atteindre.

Comprendre l’avenir du DevOps

Chose importante, le DevOps n’est pas une mode éphémère ou un phénomène qui sera brièvement sur toutes les lèvres avant de disparaître. En définitive, c’est un changement de mentalité, qui nous permet d’adopter des méthodes de travail agiles, de mettre en œuvre la livraison continue et de transformer nos entreprises à l’ère numérique.

Par conséquent, s’il est presque impossible de donner une définition unique du DevOps, cette approche comporte des thèmes et des motifs récurrents. La collaboration et la communication sont fondamentales. Toutefois, il s’agit également d’une culture immatérielle, d’une évolution des processus de réflexion menant à une évolution des processus physiques. C’est cela qui réunit les services et postes disparates pour leur permettre d’opérer comme une entité unique, alors même qu’ils possèdent des rôles bien distincts. Dès lors, nous pouvons commencer à répondre à des questions plus précises et à définir une stratégie de transformation numérique.

New Call-to-action

DevOps
ARA
CA Automic Release Automation
Back to the blog
French - Ron Gidron

Ron Gidron

Ron Gidron est Directeur du Marketing produit Release Automation chez Automic Software. Il a 14 ans d’expérience dans le marketing produit, le management de produit et l’avant-vente à la fois dans des startups et des grandes entreprises. Ron est fasciné par l’intersection des logiciels, des utilisateurs et des tendances du marché.