Close

DevOps : éliminer les cloisons entre les équipes de développement et opérationnelles

Icône de boucle DevOps

Qu'est-ce que DevOps ?

DevOps est un ensemble de pratiques visant à automatiser et intégrer les processus entre les équipes de développement et informatiques, afin de leur permettre de développer, de tester et de publier des logiciels plus rapidement et de manière plus fiable. Le terme DevOps a été formé en combinant les mots « développement » et « opérations » et signifie un virage culturel comblant le fossé entre les équipes de développement et opérationnelles qui étaient, historiquement, cloisonnées. 

Boucle de l'infini Atlassian DevOps

À la base, DevOps est une culture, un courant de pensée, une philosophie.

C'est une poignée de main ferme entre les équipes de développement et opérationnelles. L'accent est mis sur le changement de mentalité, la collaboration accrue et l'intégration plus poussée. DevOps associe la méthodologie Agile, Git, la livraison continue, l'automatisation, et bien plus encore pour aider les équipes de développement et opérationnelles à gagner en efficacité, à innover plus rapidement et à offrir plus de valeur ajoutée aux entreprises et aux clients.


DevOps ne concerne pas qu'une seule personne : c'est un travail collectif.

Christophe Capel
Principal Product Manager, Jira Service Desk

Logo Chef.io

Qui adopte DevOps ?

La société Chef est à l'origine de la plateforme Chef Automate pour les workflows DevOps. Des dizaines de milliers de développeurs utilisent Chef pour tester, automatiser et gérer les infrastructures. À l'avant-garde du mouvement DevOps, la société de Seattle livre des produits comme Chef, InSpec, Habitat et Chef Automate pour proposer de nouvelles méthodes de développement et de livraison de logiciels et d'applications. Chef utilise la plateforme Atlassian afin d'expérimenter et d'affiner ses propres pratiques DevOps.

L'histoire de DevOps

Le mouvement DevOps a commencé à s'unifier entre 2007 et 2008, lorsque les équipes opérationnelles et de développement ont clairement exprimé ce qu'elles qualifiaient de dysfonctionnement majeur dans le secteur.

Elles ont pesté contre le modèle de développement traditionnel, qui appelait un cloisonnement organisationnel et fonctionnel entre les programmeurs, les équipes de déploiement et le support.

Les développeurs et les experts informatiques/opérationnels avaient des objectifs distincts (et souvent opposés), leur propre leadership, des indicateurs de performance clé différents au moyen desquels ils étaient évalués et, bien souvent, ils travaillaient à des étages voire dans des bâtiments séparés. Résultat : les équipes étaient cloisonnées, elles ne se préoccupaient que de leur propre fief, faisaient des heures supplémentaires, bâclaient les livraisons, et les clients étaient mécontents. Il devait y avoir une méthode plus efficace. Les deux communautés se sont donc réunies et ont commencé à échanger. Des experts tels que Patrick Dubois, Gene Kim ou encore John Willis étaient aux commandes.

Ce qui a commencé par des forums en ligne et des réunions locales s'est désormais popularisé dans l'univers du développement. C'est d'ailleurs probablement ce qui vous a amené ici ! Votre équipe et vous-même éprouvez des difficultés en raison de silos et d'un manque de communication au sein de votre entreprise.

Vous appliquez les méthodologies Agile pour la planification et le développement, mais vous cherchez encore à livrer du code sans catastrophe. Vous avez certainement entendu parler de DevOps et de son effet apparemment magique sur les équipes. En effet, la quasi-totalité (99 %) des équipes DevOps sont confiantes quant au succès de leur code qui sera mis en production, selon une enquête menée par Atlassian¹ auprès de 500 experts DevOps. 

Cependant, DevOps n'est pas la panacée, et les transformations ne s'opèrent pas en une nuit. La bonne nouvelle ? Inutile d'attendre que les cadres supérieurs mettent en place une initiative à grande échelle. Si elle comprend la valeur de DevOps et qu'elle apporte de petits changements incrémentiels, votre équipe peut débuter son parcours DevOps sans plus attendre. Voyons maintenant chacun de ces avantages plus en détail.

Par rapport aux cadres supérieurs, les experts DevOps « sur le terrain » sont plus susceptibles de convenir qu'il est difficile de mesurer l'impact des progrès et des réussites DevOps : 62 % sont d'accord avec cette affirmation, contre 46 % pour les cadres supérieurs.

Enquête Atlassian sur les experts DevOps

Avantages

Icône de relation entre personnes

Collaboration et confiance

Nous avons mené une enquête qui a révélé que le principal facteur permettant à uneéquipe DevOps d'être performante est la collaboration. L'instauration d'une culture de responsabilité partagée, de transparence et de feedback plus rapide est le fondement de toute équipe DevOps ultra performante. Toujours selon notre enquête, la collaboration et la résolution de problèmes sont les éléments les plus importants d'une culture DevOps réussie. 

Les équipes cloisonnées n'adhèrent souvent pas à la « pensée systémique » préconisée par DevOps. La « pensée systémique » consiste à être conscient de la façon dont vos actions affectent non seulement votre équipe, mais aussi toutes les autres équipes impliquées dans le processus de livraison. Le manque de visibilité et d'objectifs partagés implique un manque de planification des dépendances, un mauvais alignement des priorités, une mentalité où les autres sont pointés du doigt et où l'on affirme que ce n'est pas notre problème, ce qui se traduit par une vélocité plus lente et une qualité inférieure. DevOps est ce changement de mentalité qui consiste à considérer le processus de développement de manière holistique et à faire tomber les barrières entre le développement et les opérations.

Icône de compteur

Livrez plus rapidement et travaillez plus intelligemment

Tout est question de vitesse. Les équipes qui adoptent la livraison DevOps livrent plus souvent, de façon plus qualitative et plus stable.  

L'absence de tests automatisés et de cycles de revue ralentit la mise en production, tandis que les temps de réponse aux incidents médiocres sont l'ennemi de la vélocité et de la confiance. Les outils et processus disparates augmentent les coûts d'exploitation, imposent un changement de contexte et peuvent casser la dynamique. Pourtant, grâce à des outils qui favorisent l'automatisation et les nouveaux processus, les équipes peuvent accroître leur productivité et livrer plus fréquemment avec moins de perturbations.

Icône de battements de cœur

Réduisez la durée de résolution

L'équipe dont la boucle de feedback est la plus rapide prospère. Grâce à la transparence totale et à la communication fluide, les équipes DevOps peuvent réduire les temps d'arrêt et résoudre les tickets plus rapidement.

Si les tickets critiques ne sont pas résolus rapidement, la satisfaction des clients chute. Les tickets importants passent au travers des mailles du filet en l'absence de communication ouverte. En conséquence, la tension et la frustration augmentent au sein des équipes. Les équipes de développement et opérationnelles « swarment » sur les tickets, résolvent les incidents et débloquent plus rapidement le pipeline de livraison grâce à la communication ouverte.

Icône d'outils

Gérez plus efficacement les tâches non planifiées

Chaque équipe est confrontée à des tâches non planifiées, une réalité qui se répercute bien souvent sur la productivité. Grâce aux processus établis et à la hiérarchisation claire des tâches, les équipes de développement et opérationnelles peuvent mieux gérer les tâches non planifiées, tout en se concentrant sur celles qui le sont.

Le transfert et la hiérarchisation des tâches non planifiées entre les différents systèmes et équipes s'avèrent inefficaces et détournent l'attention des employés du travail à faire. Cependant, les équipes peuvent mieux anticiper et partager les tâches non planifiées grâce à la visibilité accrue et à la rétrospection proactive.

Le framework CALMS pour DevOps

CALMS est un framework qui évalue la capacité d'une entreprise à adopter les processus DevOps et qui permet de mesurer la réussite lors d'une transformation DevOps. L'acronyme a été inventé par Jez Humble, co-auteur du « DevOps Handbook ». Voici sa signification :


Icône de maillot

Culture

DevOps n'est pas simplement un processus, ou une approche différente du développement : c'est un virage culturel. La collaboration est un élément essentiel de la culture DevOps.

Tous les outils et toute l'automatisation du monde ne sont d'aucune utilité si les équipes de développement et informatiques/opérationnelles ne travaillent pas ensemble. DevOps ne résout pas les problèmes d'outils. Il résout les problèmes humains. 

Considérez DevOps comme une évolution des équipes Agile, à la différence près que les opérations sont maintenant incluses par défaut. Constituer des équipes orientées projet ou produit pour remplacer les équipes basées sur des fonctions vous place assurément sur la bonne voie. Incluez les équipes de développement, de QA, de gestion de produit, de conception, de gestion de projet, opérationnelles, ainsi que toute autre compétence nécessaire pour le projet. Plutôt que de laisser une seule équipe tout faire ou d'engager des « professionnels DevOps », il est plus important d'avoir des équipes de projet qui peuvent travailler ensemble en toute transparence.  

Pour favoriser la collaboration, la meilleure façon consiste à partager un objectif commun et à établir un plan pour l'atteindre ensemble. Dans certaines entreprises, un passage abrupt aux équipes de projet peut s'avérer être un trop grand pas, trop rapide. Vous devez donc avancer pas à pas. Si elles le jugent opportun, les équipes de développement peuvent (et devraient) inviter les membres de l'équipe opérationnelle à participer aux sessions de planification des sprints, aux stand-ups quotidiens et aux démos de sprint. Les équipes opérationnelles peuvent inviter à leurs réunions leurs principaux développeurs. Cette méthode Agile et organique permet de suivre les projets, les idées et les difficultés de tout un chacun. 

Les défis et même les urgences sont des tests efficaces de la culture DevOps. Vos équipes de développement, opérationnelles et de support client « swarment »-elles à la résolution des problèmes en groupe ? Le post-mortem d'incident vise-t-il à corriger les processus plutôt qu'à pointer du doigt ? Si la réponse est « oui », c'est une bonne indication que votre équipe travaille au sein d'une structure DevOps.

Notez que les entreprises les plus fructueuses ont intégré la culture DevOps dans tous leurs départements et à tous les échelons de l'organigramme. Elles disposent de canaux de communication ouverts et échangent fréquemment. Elles partent du principe que la satisfaction des clients relève tout autant de la responsabilité des chefs de produit que de celle des équipes de développement. Elles comprennent que DevOps n'est pas le fardeau d'une équipe. C'est un travail collectif.

Icône d'engrenages

Automatisation

L'automatisation permet d'éliminer les tâches manuelles répétitives, exploite des processus reproductibles et crée des systèmes fiables.

L'automatisation du développement, des tests, du déploiement et des tâches de provisionnement constitue un point de départ classique pour les équipes qui n'ont pas encore franchi ce cap. Et à quoi bon se mentir : quelle meilleure motivation pour les équipes de développement, de test et opérationnelles que de collaborer pour développer des systèmes qui profitent à tous ?

Les équipes qui débutent avec l'automatisation démarrent généralement par la livraison continue : soumettre chaque changement de code à une batterie de tests automatisés (une opération souvent facilitée par l'infrastructure basée dans le cloud), puis créer un package des builds fonctionnels et les mettre en production grâce à des déploiements automatisés. 

Pourquoi ? Les ordinateurs exécutent des tests de façon plus rigoureuse et plus fiable que les êtres humains. Ces tests détectent les bugs et les failles de sécurité au plus tôt. De plus, le déploiement automatisé alerte les équipes informatiques et opérationnelles de toute « dérive » du serveur entre les environnements, ce qui réduit – voire élimine – les surprises au moment de la livraison.

Une autre contribution majeure de DevOps est le concept de CaC ou « Configuration as Code ». Les développeurs s'efforcent de créer des applications modulaires et composables, car elles sont plus fiables et plus faciles à administrer. Cet état d'esprit peut être étendu à l'infrastructure qui les héberge, qu'elle se trouve dans le cloud ou sur le réseau de la société.

« Configuration as Code » et « livraison continue » ne sont pas les seuls types d'automatisation observés à l'ère DevOps, mais cela vaut la peine d'en parler, car ils contribuent à éliminer les cloisons entre les équipes de développement et opérationnelles. Et, lorsque DevOps s'appuie sur les déploiements automatisés pour envoyer du code minutieusement testé à des environnements provisionnés de la même façon, la mentalité « Ça fonctionne sur ma machine » n'est plus pertinente.

Icône Lean DevOps

Lean

Lorsque nous parlons de « Lean » dans le contexte des logiciels, nous pensons généralement à éliminer les activités à faible valeur ajoutée pour travailler plus rapidement. En un mot, être Agile. Les concepts d'amélioration continue et de reconnaissance des échecs sont d'autant plus pertinents pour DevOps qu'ils posent les bases d'un état d'esprit expérimental.

Une mentalité DevOps identifie des opportunités d'amélioration continue en permanence. Certaines sont évidentes, comme la tenue de rétrospectives régulières pour améliorer les processus de l'équipe. D'autres sont plus subtiles, comme les tests de différentes approches d'intégration de nouveaux utilisateurs de vos produits par deux cohortes (A et B).

Nous devons remercier le développement Agile pour avoir popularisé l'amélioration continue. Les premiers partisans de la méthodologie Agile ont prouvé qu'un simple produit mis entre les mains d'un client dès aujourd'hui a plus de valeur qu'un produit parfait qui sera livré aux clients dans six mois. Si le produit est amélioré en continu, les clients restent fidèles.

Et devinez quoi : l'échec est inévitable. Vous feriez donc bien de faire en sorte que votre équipe l'assimile, s'en remette et en tire des leçons (certains parleraient d'une mentalité antifragile). Chez Atlassian, nous pensons que si vous n'échouez pas au moins une fois, vous ne faites pas assez d'efforts.

Dans le contexte DevOps, l'échec n'est pas une infraction. Les équipes partent du principe que quelque chose va finir par mal tourner, c'est pourquoi elles mettent tout en œuvre pour détecter rapidement les bugs et les résoudre. Les post-mortems se concentrent sur les aspects sur lesquels les processus ont échoué et sur les méthodes pour les renforcer, et non sur le membre de l'équipe qui a m***é. Pourquoi ? Parce que l'amélioration continue va de pair avec les défaillances.

Icône de règle

Mesure

Il est difficile de prouver que les efforts que vous déployez en vue de l'amélioration continue améliorent réellement les données. Fort heureusement, il existe de nombreux outils et technologies permettant de mesurer les performances : durée d'utilisation de votre produit par les utilisateurs, ventes générées par un billet de blog, fréquence des alertes critiques dans vos journaux…

Bien que vous puissiez mesurer la plupart des indicateurs, cela ne veut pas dire que vous devriez le faire. Prenez un projet de développement Agile et commencez par le début :

  • Combien de temps vous a-t-il fallu pour passer du développement au déploiement ?
  • À quelle fréquence les bugs ou les défaillances se reproduisent-ils ?
  • De combien de temps avez-vous besoin pour reprendre vos activités après une panne système ?
  • Combien de personnes utilisent-elles votre produit à cet instant ?
  • Combien d'utilisateurs avez-vous gagnés/perdus cette semaine ?

Si vous mettez des bases solides en place, il est facile de suivre des métriques plus sophistiquées sur l'utilisation des fonctionnalités, le parcours client et les accords de niveau de service (SLA). Les informations qui vous parviennent tombent à point nommé, quand le moment est venu d'établir une feuille de route et de définir les spécifications de votre prochain grand projet.

Toutes ces précieuses données aideront votre équipe à prendre des décisions, mais elles ont encore plus d'impact lorsqu'elles sont partagées avec d'autres équipes, en particulier celles d'autres départements. Par exemple, votre équipe marketing a besoin de nouvelles fonctionnalités géniales dont elle peut faire la promotion. Mais, dans le même temps, vous constatez que vous perdez des clients, car le produit accumule une dette technique. L'utilisation de données utilisateur pour appuyer votre feuille de route, même si elle concerne davantage les corrections que les fonctionnalités, vous permettra de parvenir à un consensus et d'obtenir l'appui des parties prenantes plus facilement.

Icône de bulles de discussion

Partage

Le désaccord de longue date entre les équipes de développement et opérationnelles est principalement dû à l'absence de terrain d'entente. Nous pensons que partager la responsabilité et les réussites contribuera grandement à combler ce fossé. Les équipes de développement s'attireront les bonnes grâces des équipes opérationnelles en endossant l'un de leurs plus lourds fardeaux : le pager. L'un des grands principes DevOps est que le développeur d'une application doit également participer à sa livraison et à son exécution.

Cela ne veut pas dire que vous recrutez des développeurs et que vous devez vous attendre à ce qu'ils excellent sur le plan opérationnel. Non, cela signifie que les équipes de développement et opérationnelles collaborent durant chaque phase du cycle de vie de l'application.

Les équipes qui adoptent DevOps jouent souvent un rôle variable ; les développeurs résolvent les tickets soumis par les utilisateurs finaux, tout en apportant une réponse aux problèmes de production. Ils réagissent aux tickets urgents soumis par les clients, créent des correctifs si nécessaire et travaillent sur le backlog des défauts signalés par les utilisateurs. Le « développeur en support » en apprend plus sur la façon dont l'application est utilisée sur le terrain. En se tenant à la disposition de l'équipe opérationnelle, les équipes de développement instaurent la confiance et le respect mutuel.

Autant nous souhaitions disposer d'une baguette magique pour transformer toutes les équipes en équipes DevOps ultra performantes, autant les transformations DevOps nécessitent un mélange de pratiques, de philosophies culturelles et d'outils. Mais, comme vous l'avez lu, les avantages du décloisonnement des équipes de développement et opérationnelles en valent la peine : confiance accrue, livraisons plus rapides, déploiements plus fiables et meilleure boucle de feedback entre les équipes et les clients.

Implémenter DevOps n'est pas une mince affaire. Pourtant, avec le framework, les efforts et les outils appropriés, une organisation peut opérer une transformation DevOps pour en tirer des avantages significatifs. 

Envoyez un e-mail à l'adresse press@atlassian.com pour de plus amples informations sur l'enquête, menée en partenariat avec Cite Research.

Prêts à entamer votre parcours DevOps ?