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

Qu'est-ce que DevOps ?

DevOps nous a donné un avantage

« DevOps nous a aidés à accélérer les livraisons et nous a donné un avantage en termes de délai de commercialisation. Nous sommes maintenant capables de livrer chaque jour, contre une fois tous les 6 mois, et de pusher les correctifs vers nos clients en l'espace de quelques heures. »

— Hamesh Chawla, Vice-Président de l'ingénierie chez Zephyr

DevOps est un ensemble de pratiques qui automatisent les processus entre les équipes de développement et IT afin de leur permettre de développer, tester et livrer des logiciels plus rapidement et avec plus de fiabilité. Le concept de DevOps repose sur la mise en place d'une culture de la collaboration entre les équipes qui étaient, historiquement, cloisonnées. Parmi les avantages assurés, le gain de confiance, l'accélération des livraisons, la capacité à résoudre les tickets plus rapidement ou encore la gestion plus efficace des tâches non planifiées.

Chez Atlassian, DevOps est la deuxième contraction la plus célèbre après Brangelina (Brad Pitt et Angelina Jolie) et combine les avantages du développement logiciel et des opérations IT. Et, tout comme nos blagues, cela requiert quelques explications. 

À 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, l'automatisation, la livraison continue 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 business et aux clients.

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 de l'IT/des opérations avaient des objectifs distincts (et souvent opposés), leur propre leadership, des indicateurs clés de performance 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 utilisez les méthodologies Agile pour la planification et le développement, mais vous cherchez encore à livrer du code sans catastrophe. Vous avez entendu parler de DevOps et de son effet apparemment magique sur les équipes, et vous pensez que vous aimeriez profiter, vous aussi, de cette magie.

La mauvaise nouvelle ? 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 ajoutée de DevOps et qu'elle apporte de petits changements incrémentiels, votre équipe peut débuter son parcours DevOps dès maintenant. Voyons maintenant chacun de ces avantages plus en détail.

L'infrastructure IaC (Infrastructure As Code) nous a permis d'exécuter 10 fois plus de builds, sans devoir renforcer notre équipe. — Michael Knight, Ingénieur de build chez Atlassian

Quels avantages en tirez-vous ?

Collaboration et confiance

La culture est le principal facteur de réussite d'une initiative DevOps. Instaurer une culture de la responsabilité partagée, de la transparence et du feedback accéléré est incontournable pour chaque équipe DevOps ultra performante.

Les équipes cloisonnées n'adhèrent souvent pas à la « pensée systémique » de DevOps. Penser de façon systémique signifie être sensible à l'impact de vos actions sur votre équipe, mais aussi sur toutes les autres équipes impliquées dans le processus de livraison. Le manque de visibilité et les objectifs partagés impliquent 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. La vélocité et la qualité sont alors affectées. DevOps impose un changement d'état d'esprit, qui vise à observer le processus de développement de façon holistique et à éliminer les cloisons entre les équipes de développement et opérationnelles.

Livrez plus rapidement et travaillez plus intelligemment

Tout est question de vitesse. Les équipes qui adoptent DevOps livrent plus souvent, avec plus de qualité et de stabilité.

L'absence de tests automatisés et de cycles de revue bloque la mise en production, et 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 OpEx, imposent un changement de contexte et cassent la dynamique. Grâce à l'automatisation ainsi qu'aux outils et processus standardisés, les équipes peuvent accroître la productivité et livrer plus souvent, avec moins d'à-coups.

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 que jamais.

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.

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 priorisation 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 priorisation 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.

Culture

Si nous pouvions résumer la culture DevOps en un mot, ce serait la « collaboration ». Et si nous pouvions en utiliser deux, nous parlerions de « collaboration transverse ». (OK, c'en sont plutôt trois.)

Tous les outils et l'automatisation du monde ne sont d'aucune utilité s'ils ne sont pas complétés par le réel désir de collaboration entre les équipes de développement et IT/opérationnelles. DevOps ne résout pas les problèmes d'outils. Il résout les problèmes humains. Par conséquent, il est fort peu probable qu'un beau jour vous passiez la tête par la porte de votre bureau, vous regardiez autour de vous et vous découvriez que les équipes de votre entreprise incarnent la culture DevOps. Cependant, vous pouvez prendre quelques mesures simples pour la promouvoir.

Pensez à DevOps comme à Agile, mais n'oubliez pas les équipes opérationnelles. 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. Chez Atlassian, nous intégrons même le marketing à nos équipes produit.

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 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. Le temps passé à écouter et à partager son savoir-faire en vaut la peine, car cela rend la gestion des livraisons et le dépannage d'urgence beaucoup plus efficaces.

Et en parlant d'urgences, il s'agit d'un test efficace 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 ? Chacun part-il du principe que ses collègues ont pris les meilleures décisions possible sur la base des informations et des ressources dont ils disposaient ? L'incident post-mortem a-t-il pour objectif de corriger les processus plutôt que de pointer les autres du doigt ? Si la réponse est « oui », il y a fort à parier que votre équipe a intégré la culture 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 s'assurent que les objectifs de chacun sont alignés et les redéfinissent si nécessaire. 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.

Automatisation

Investir dans l'automatisation élimine 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 commencent 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 qui ont réussi et les mettre en production à l'aide de déploiements automatisés. Comme vous l'aurez peut-être deviné, la livraison continue n'est pas une chose rapide et facile à mettre en place, mais le retour sur investissement en vaut la peine.

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. Les développeurs peuvent ainsi les résoudre plus facilement. Et le déploiement automatisé alerte les équipes IT 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.

Autre contribution majeure de DevOps : 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é.

Entendons-nous bien, les systèmes évoluent en permanence. Mais nous pouvons créer une façade immuable en utilisant le code pour le provisionnement, de sorte que le reprovisionnement d'un serveur compromis soit plus rapide que sa réparation – sans parler de la fiabilité. Cela réduit également les risques. Les équipes de développement et opérationnelles peuvent intégrer de nouvelles langues ou technologies à l'aide du code de provisionnement, puis partager les mises à jour entre elles. Les problèmes de compatibilité apparaissent immédiatement, plutôt que de se manifester au beau milieu d'une livraison.

« 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.

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.

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.

Nous motivons nos équipes à l'aide d'objectifs ambitieux, et nous nous assurons qu'elles disposent de l'autonomie et des ressources nécessaires pour les atteindre. Nous recrutons des personnes intelligentes et ambitieuses, et nous nous attendons à ce qu'elles échouent à certains moments.

Dans le contexte de 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. (Lisez le billet sur l'outil Chaos Monkey de Nexflix pour découvrir un exemple parfait.) 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 l'équipe qui a m***é. Pourquoi ? Parce que l'amélioration continue va de pair avec les défaillances.

DevOps a évolué : les équipes de développement se chargent davantage des opérations, et c'est ainsi que fonctionne Chef. Nous ne pouvons plus nous contenter de livrer aveuglément. Nos ingénieurs sont chargés du QA, de la programmation et de l'exécution de leurs propres tests avant la livraison des logiciels aux clients. — Julian Dunn, Responsable produit chez Chef

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 logs…

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 correctifs que les fonctionnalités, vous permettra de parvenir à un consensus et d'obtenir l'appui des parties prenantes plus facilement.

DevOps ne concerne pas qu'une seule personne : c'est un travail collectif. — Christophe Capel, Responsable produit principal, Jira Service Desk

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 de 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.

Si vous bravez les difficultés ensemble, vous éprouverez d'autant plus de plaisir à célébrer vos réussites. Vous saurez que la culture DevOps aura pris ses quartiers au sein de votre entreprise à partir du moment où l'équipe de développement commencera à apporter des bagels à l'équipe opérationnelle les jours de livraison.

Un feedback positif de ses pairs est aussi motivant que le salaire qui tombe à la fin du mois ou nos ambitions professionnelles. Il est important de mettre publiquement à l'honneur un collègue qui empêché la survenue d'un vilain bug. Si votre département prévoit un budget discrétionnaire pour les mentions spéciales, mettez-le à profit !

Prêts à entamer votre parcours DevOps ?

Entamez votre parcours