Ce que vous devez savoir sur le DevOps

Si vous avez utilisé le terme « DevOps » pour désigner un poste, vous avez peut-être commis une grave erreur. Cela paraît anodin : après tout, le DevOps, c’est bien de cela qu’il s’agit, non ? Si vous êtes responsable marketing, recruteur ou non-ingénieur dans votre entreprise, c’est peut-être l’impression que cela peut donner.

Mais rien n'est plus faux. Il s'agit en réalité d'une philosophie et d'un ensemble de pratiques qui guident le travail de vos équipes d'ingénierie et informatiques. Et l'utilisation inappropriée de ce terme est parfois mal perçue par les équipes techniques, même si elles affichent le titre d'« ingénieur DevOps » sur leur profil LinkedIn.

L'utilisation inappropriée de ce terme peut engendrer de nombreux problèmes. Elle risque de créer des silos supplémentaires au sein de votre organisation, ou d'affecter négativement la collaboration et la productivité des équipes, limitant ainsi l'efficacité et la responsabilisation du travail DevOps.

Pour contrer les interprétations erronées de ce qu'est le DevOps et de sa signification, il est utile de savoir pourquoi c'est important et d'où vient cette idée.

Pourquoi DevOps n'est pas un titre de poste

Le DevOps est une méthode de travail qui privilégie la collaboration, la communication ouverte et le partage fluide des idées et du code. Pour de nombreuses organisations qui adoptent un modèle DevOps, il s'agit d'un changement de culture, et la communication autour de ce concept est essentielle.

Un travail DevOps de qualité exige des tests, des itérations et même la possibilité de casser des choses. Ce processus doit se dérouler rapidement, sans heurts et, surtout, sans recherche de coupable. Désigner une personne comme responsable DevOps ou comme membre de l'équipe pourrait laisser entendre que seules ces personnes sont responsables du DevOps et que, en cas d'échec, ces échecs seraient considérés comme individuels plutôt que systémiques.

Comme l'écrit Chip Locke, les développeurs et les ingénieurs d'exploitation ont des profils différents, et les fusionner en un seul rôle risque d'être contre-productif. Lorsque les équipes de développement et d'exploitation sont contraintes de travailler ensemble au lieu d'être encouragées à collaborer, il en résulte des valeurs concurrentes et des résultats parfois décevants. De plus, implémenter le DevOps comme une troisième équipe intercalée entre les équipes de développement et d'exploitation est une recette pour le désastre. Tenter de résoudre le problème en fusionnant ces silos ne fait qu'empirer les choses.

Alors, qu'est-ce que le DevOps ?

Il n'existe pas de définition standard du DevOps. Selon The Agile Admin, le DevOps est une « méthodologie de collaboration ». Autrement dit, il s'agit d'une « administration agile des systèmes ». Concrètement, le DevOps consiste pour les développeurs et les ingénieurs d'exploitation à travailler ensemble, en partageant des valeurs, des principes, des méthodes, des pratiques et des outils communs, afin de concevoir, maintenir et améliorer les systèmes, tout au long de leur cycle de vie.

Cette définition ne tient pas sur une carte de visite. Pourtant, bien la définir est essentiel pour votre organisation. Car le DevOps ne consiste pas à ce que les développeurs prennent le relais des équipes d'exploitation, ni l'inverse. Il ne s'agit pas non plus uniquement d'outils partagés (même si cela en fait partie). Il s'agit de mettre en œuvre des changements à l'échelle des systèmes et des cultures pour améliorer l'expérience client, éliminer les obstacles et favoriser la collaboration et la communication entre des équipes parfois en désaccord.

D'où vient le DevOps ?

Comment le DevOps est-il devenu l'option privilégiée de nombreuses entreprises de logiciels ? Les données montrent que le DevOps aide les entreprises à fournir de meilleurs produits logiciels et à s'adapter plus rapidement à l'évolution rapide du marché en prenant en charge des déploiements de code plus rapides.

L'administration agile trouve ses racines dans les mouvements d'administration système agile et de gestion des systèmes d'entreprise. Ces deux approches sont nées d'un besoin d'améliorer les processus métier en tirant parti de frameworks d'entreprise plus rapides, plus légers et open source, proposés par les grands fournisseurs. Parallèlement, l'administration système agile se généralisait en Europe, les entreprises transposant les principes du lean manufacturing et de l'agilité dans leurs services informatiques à travers le continent.

Mais malgré ces progrès, les entreprises restaient fortement cloisonnées et dangereusement rigides.

Des outils plus performants, conjugués à l'échec de projets complexes ou lourds, ont créé ce que The Agile Admin appelle « la conjoncture idéale ». Nous avions les moyens de faire mieux. Le DevOps était né.

Le terme a été inventé par Patrick Debois et Andrew « Clay » Shafer en 2009. La philosophie a pris son essor lorsque Debois a organisé le premier événement DevOps Days à Gand, en Belgique. La suite, comme on dit, appartient à l'histoire.

Comprendre ce contexte historique permet de saisir plus facilement pourquoi les ingénieurs sont réticents face à l'idée du DevOps comme intitulé de poste ou rôle au sein d'une entreprise. En abordant et en comprenant correctement le DevOps, vous contribuerez non seulement au bien-être de vos talents techniques, mais vous favoriserez également l'intégration des principes DevOps au sein de votre organisation.