Ce que vous devez savoir sur DevOps

Si vous avez utilisé le terme « DevOps » comme intitulé de poste, vous avez peut-être fait une grave erreur. Cela semble anodin : après tout, DevOps n'est-il pas quelque chose que vous faites ? Si vous êtes un spécialiste du marketing, un responsable du recrutement ou un non-ingénieur dans votre entreprise, cela peut sembler être le cas.

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 impropre du terme n'est pas toujours bien accueillie par les équipes techniques, même si elles ont « DevOps Engineer » sur leur profil LinkedIn.

L'utilisation inappropriée de ce terme peut entraîner de nombreux problèmes. Elle peut créer des silos supplémentaires au sein de votre organisation ou avoir un impact négatif sur la manière dont les équipes collaborent et accomplissent leurs tâches, limitant ainsi l'efficacité et la responsabilité du travail DevOps.

Pour contrer les interprétations erronées de ce qu’est DevOps et de ce que cela signifie, il est utile de savoir pourquoi c’est important et d’où vient l’idée.

Pourquoi DevOps n'est pas un titre de poste

DevOps est une méthode de travail qui met l'accent sur la collaboration, la communication ouverte et le partage transparent d'idées et de code. Pour de nombreuses organisations qui adoptent un modèle DevOps, cela représente un changement de culture, et le message qui l'entoure est important.

Un bon travail DevOps nécessite de tester, d'itérer et même de casser des éléments. Cela doit se faire rapidement, sans friction et, surtout, sans reproche. Définir quelqu'un comme responsable ou équipe DevOps pourrait impliquer que seules ces personnes sont responsables de DevOps, et qu'en cas d'échec, ces échecs sont des échecs individuels plutôt que systémiques.

Comme l’écrit Chip Locke, les développeurs de logiciels et les ingénieurs d’exploitation peuvent être des types de personnes différents, et essayer de les combiner dans un seul rôle peut ne pas être efficace. Lorsque les développeurs et les opérateurs sont contraints de jouer un rôle ou une équipe unique au lieu d’être encouragés à collaborer entre leurs équipes individuelles, il en résulte des valeurs concurrentes et (parfois) des résultats sous-optimaux. De plus, la mise en œuvre de DevOps en tant que troisième équipe située entre les équipes de développement et d’exploitation est une recette pour un désastre. Essayer de résoudre le problème en combinant ces silos ne fait qu’empirer les choses.

Alors, qu’est-ce que DevOps ?

Il n'existe pas de définition standard de DevOps. Selon The Agile Admin, DevOps est une « méthodologie de collaboration ». En d'autres termes, le site parle d'« administration agile de systèmes ». Cela signifie que DevOps consiste en une collaboration entre développeurs de logiciels et ingénieurs opérationnels, autour de valeurs, de principes, de méthodes, de pratiques et d'outils communs, pour créer, maintenir et améliorer des systèmes, tout au long du cycle de vie des services.

Cette définition ne tient pas sur une carte de visite. Mais la définir correctement est important pour votre organisation. En effet, DevOps ne consiste pas à ce que les développeurs de logiciels prennent le relais des opérations, ou que les opérations prennent le relais des développeurs. Et il ne s'agit pas seulement d'outils partagés (même si cela en fait partie). Il s'agit de mettre en œuvre des changements dans des systèmes et des cultures entiers pour améliorer la façon dont les clients reçoivent les produits et les services, en supprimant les barrières et en favorisant la collaboration et la communication entre deux équipes parfois en désaccord.

D'où vient DevOps ?

Comment DevOps est-il devenu l'option préférée de nombreuses sociétés de logiciels ? Les données montrent que DevOps aide les entreprises à fournir de meilleurs produits logiciels et à s'adapter plus rapidement aux réalités du marché en constante évolution en prenant en charge des déploiements de code plus rapides.

L'administration agile est à l'origine de l'essor de DevOps dans les mouvements d'administration de systèmes agile et de gestion de systèmes d'entreprise. Ces deux mouvements sont nés d'un besoin d'améliorer les processus métier en tirant parti de cadres d'entreprise plus rapides, plus petits et open source de « grands fournisseurs ». Dans le même temps, l'administration de systèmes agiles est devenue courante en Europe, les entreprises appliquant les leçons de la fabrication allégée et agile aux services informatiques de tout le continent.

Mais malgré ces avancées, les entreprises étaient encore cloisonnées et dangereusement inflexibles.

L’amélioration des outils, combinée à l’échec des implémentations lourdes ou de grande envergure, a créé ce que l’administrateur agile appelle « la tempête parfaite ». Nous avions les moyens de faire mieux les choses. DevOps était né.

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

Et lorsque vous comprenez cette histoire, il est plus facile de comprendre pourquoi les ingénieurs s'irritent à l'idée que DevOps soit un titre de poste ou un rôle dans l'entreprise. En faisant référence à DevOps et en réfléchissant correctement à ce sujet, vous ne ferez pas que rendre les talents techniques de votre entreprise plus heureux. Vous contribuerez également à intégrer les principes DevOps au sein de votre organisation.