En quoi le quotidien des devs est-il impacté par l'approche DevOps ?

Rappel du devOps

Le devOps est une méthode et une culture de travail qui a pour objectif de réunir les ops et les développeurs afin de créer une équipe soudée et fonctionnelle. Les ops, aussi appelés Site Reliability Engineers (SRE), sont les gardiens de l’infrastructure informatique (scalabilité, résilience, réversibilité, etc). Tandis que les développeurs mettent en place des fonctionnalités afin d’ajouter de la valeur et les dernières innovations sur le produit / service. Une approche DevOps permet d’avoir un cycle de release plus court et de meilleure qualité, ainsi que des objectifs communs pour les développeurs et les ops.

Rappel métier du métier de développeur

Pour comprendre le quotidien d’un développeur, il faut savoir quel est le métier de ce dernier. Un développeur est également appelé un programmeur, un développeur de logiciel ou un codeur. Le travail du développeur est de créer et/ou d'implémenter des logiciels informatiques et d' écrire du code. Les développeurs écrivent, testent, débugent et maintiennent les programmes informatiques.

Le métier de développeur est vraiment différent selon le type d'entreprise pour laquelle vous travaillez, votre spécialité, la plateforme (logiciel, web, jeux vidéo, etc.) et le langage de programmation. Par exemple, vous pouvez être :

• Développeur frontend
• Développeur backend
• Développeur full stack
• Développeur web
• Webdesigner

Impact du DevOps sur un ancien développeur backend devenu Ops : Arthur, SRE chez Padok

Quelles sont les différences entre une approche devOps et une approche dite traditionnelle ?

Quand nous sommes équipe DevOps, les développeurs maîtrisent l'infrastructure sur laquelle leurs applications tournent. Ils comprennent ce qu’il se passe. Il n'y a pas de séparation, la responsabilité est partagée. Concrètement, ils itèrent plus vite, ils savent comment faire pour que l'infrastructure réponde à leurs besoins et ils ajoutent plus de valeur au produit qu'ils développent.

Une équipe dite traditionnelle (sans approche DevOps) est composée d’au minimum 2 équipes, elles communiquent peu et n’ont pas les mêmes objectifs. Les développeurs veulent aller vite et ajouter des fonctionnalités. Alors que les ops veulent réduire le nombre de déploiements car chaque modification est potentiellement un nouveau problème. Historiquement les ops devaient s’assurer que tout fonctionnait correctement.

Avec une approche DevOps, tout le monde est responsable de la production. Les développeurs et ops doivent aligner leurs objectifs : la production doit tourner et apporter de la valeur à l’entreprise.

Le DevOps m’a permis de maîtriser une grande partie des technologies que j’utilise. Je maîtrise et j’apprends beaucoup plus de choses. Je ne suis plus “juste” développeur. Je comprends bien mieux l’intégralité des projets sur lesquels je travaille. Je ne maîtrise pas tout mais le DevOps m’a inculqué une culture générale qui m’a rendu plus fort.

Vois-tu un autre avantage au DevOps ?

C’est moins stressant car les développeurs et les ops ne sont plus adversaires . Le DevOps permet de rendre les équipes autonomes.

Il réduit également le temps de release, tout va beaucoup plus vite . A une époque, je ne faisais que développer, je ne passais en production qu’à la fin de la journée ou de la semaine. Maintenant je mets en production dès que j’ai terminé une petite partie. L’avantage c’est que si ta production casse, l’impact est moindre. C’est également beaucoup plus facile de connaître l’origine du problème et bien plus rapide de le résoudre car je n’ai effectué qu’une petite modification.

Inconvénient(s) ?

Pour un développeur qui a uniquement envie de travailler sur son application, le DevOps va être pénible, ça va le forcer à prendre des responsabilités sur tout. Le DevOps peut entraîner des changements organisationnels qui peuvent aller à l’encontre des habitudes de certains développeurs. Une telle approche change le quotidien, il faut en avoir envie.

Selon toi, quels sont les pré-requis pour adopter une approche devOps ?

Il faut être prêt à collaborer, itérer constamment et mettre son égo de côté. Lorsqu’il y a un incident en production, c’est la faute de personne. On intègre cette culture du “blameless”.

Pour adopter une approche DevOps, il faut vouloir sortir de la relation hiérarchique qui peut exister entre les développeurs et les ops, à savoir qui travaille pour qui ? Dans une approche sans DevOps, les ops viennent en support aux développeurs, ils rendent service aux développeurs et ce n’est pas réciproque. L’approche DevOps permet de réunir les équipes de développeurs et d’ops. Le but est que les séparations entre les équipes passent par des interfaces automatiques. L’idée est de rendre les infrastructures plus simples et autonomes pour que les développeurs ne rencontrent pas de souci. Globalement c’est d’obtenir une plateforme as a service.

Quelles sont les difficultés que tu as rencontrées en travaillant avec une approche devOps ?

Beaucoup de développeurs n’avaient pas envie de comprendre l’infrastructure. Ils n’avaient pas envie de savoir ce qu’il se passait derrière leurs applications, ce n’était pas leur problème et ils ne voulaient pas que ça le devienne.

S’il y avait un bug, 2 options étaient possibles :

• Soit le bug était dans leur code
• Soit il était dans l’infrastructure. Par conséquent, c'était aux ops de régler le problème.

Avec une approche DevOps, il faut aller voir l’expert de l’infrastructure de ton équipe et non transmettre le problème à une équipe qui n’est pas la tienne.

Ce n’est pas toujours simple d’intégrer un ops à une équipe de développeurs. Ils ont tendance à se dire “Ah cool il va régler le problème”, au lieu de se dire “Ah cool il va m’aider à comprendre comment résoudre le problème”.

Impact du devops sur un développeur backend : Clément, Software Architect chez Ekino

Quelles sont les différences entre une approche devOps et une approche dite traditionnelle ?

Pour moi le devOps c’est être un développeur qui va savoir travailler avec les ops. Ce que ça change de travailler avec des ops ? Cela fluidifie énormément les échanges, les développeurs se sentent beaucoup plus impliqués dans le quotidien des ops et les ops plus concernés par les problématiques des développeurs.

Les équipes de développeurs avec une approche dite traditionnelle étaient appelées : équipe infra ou réseau. Les développeurs et les ops vivaient leur vie chacun de leur côté même s'ils étaient sur le même projet. Ils ne s'appréciaient pas forcément, ils se rejetaient la faute. Les développeurs n’étaient pas motivés à aller voir les ops, les ops accusaient les développeurs dès qu’il y avait un souci.

Une approche DevOps accélère grandement la communication. Elle permet aux développeurs et aux ops de travailler ensemble. Les projets sont de meilleure qualité, il n’y a pas de non-dit, pas de “passe plats”, de choses faites dans le dos. Le DevOps permet également d’éviter les sujets “politiques”.

Vois-tu d’autres avantages au DevOps ?

Une approche DevOps permet de réduire le temps de release. Les ops sont directement intégrés à l’équipe, avant ils étaient une équipe support et les développeurs ne savaient pas vraiment ce qu’il se passait derrière. Grâce au DevOps, les ops sont tout autant concernés que les développeurs sur les deadlines. Développeurs et ops ont alors les mêmes objectifs , ça va accélérer les choses grâce à une meilleure planification.

Il y a également moins de rétention d’informations. Avant le DevOps, lorsque les équipes étaient séparées, il y avait beaucoup d’éléments dont les développeurs n’avaient pas connaissance. Les développeurs et les ops ne communiquaient pas à l’extérieur de leur propre équipe. Ainsi, il était impossible de s’aider et de s'aiguiller. Une approche DevOps a permis de standardiser les pratiques. Ces dernières sont devenues communes aux développeurs et aux ops. Les développeurs connaissent les briques et comment elles fonctionnent les unes avec les autres. Développeurs et ops vont plus vite et se comprennent mieux.

Vois-tu un ou des inconvénients au devOps ?

Je ne vois pas d’inconvénient par rapport aux anciennes méthodes ou équipes.
Je trouve ça bien mieux que ce que l’on faisait avant. J’ai commencé à travailler avec une approche DevOps en 2016. Avant ça, je travaillais dans une équipe de développeurs dite traditionnelle, et je n’ai aucune envie de fonctionner à nouveau comme cela.

Selon toi, quels sont les pré-requis pour adopter une approche devOps ?

En termes de compétences techniques, il faut avoir des bases sur le métier des Ops et les technologies utilisées. Par exemple, si le projet qu’on partage utilise le cloud d’Amazon, il faut savoir un minimum ce qu’il se passe sur Amazon, connaître les mots clés et savoir les employer correctement.

En termes de soft skills (compétences comportementales), il faut être capable de travailler en équipe (même si c’est censé être le cas entre les développeurs à l’origine). Les Ops ne sont pas développeurs. Tout comme les développeurs ne sont pas des ops, il ne faut pas l’oublier. Des choses évidentes pour nous développeurs ne le sont pas pour les Ops et inversement. Il y a du travail de vulgarisation et d’adaptation.

Quelles sont les difficultés que tu as rencontrées en travaillant avec une approche devOps ?

La première difficulté est la proximité. Les ops sont présents au daily le matin, il faut inclure des personnes (ops comme développeurs) d’équipes distinctes qui ne sont pas toujours sur le même projet. En tant que développeur, nous devons être moteur là-dessus. Nous devons être capables de réunir les équipes, de créer une cohésion en facilitant et en encourageant les échanges. Il faut que les développeurs et les ops aillent au-delà des petits préjugés qu’ils ont les uns envers les autres. Il faut être capable de se lever et d’aller voir un ops pour s'asseoir à côté dans le but de travailler ensemble. Nous n’avons plus à faire des demandes système qui prenaient 2 à 3 semaines dont nous n’avions aucune visibilité sur l’avancement de cette dernière.

La seconde est qu’il faut être capable de faire preuve d'empathie, nous ne sommes plus face à des machines. Les développeurs comprennent les difficultés que rencontrent les ops et réciproquement. Nous sommes plus à même de s’aider et, ainsi, de créer une vraie collaboration.

Selon toi, quelle est la différence d’une approche Devops pour des développeurs Frontend par rapport à ce que tu m’as cité précédemment ?

Les développeurs backend sont entre l’infrastructure (les ops) et le front (développeurs frontend). Ils ont autant d’interactions avec les ops qu’avec les développeurs frontend. Initialement, c’était quasiment toujours les développeurs backend qui allaient voir les ops (de part leur activité transverse), contrairement aux développeurs frontend qui ont moins besoin d’aller voir les ops. Je trouve que sur mon projet actuel, l’approche DevOps a permis aux développeurs frontend de se sentir plus impliqués par les problématiques liées à l'infrastructure.

Développer une approche DevOps au sein de son entreprise et de ses équipes est un défi avec sa part de difficultés. Cependant, le DevOps présente de nombreux avantages, il permet notamment de gagner du temps, d’améliorer la qualité du produit/service et l’ambiance dans les équipes. Les retours d’Arthur et de Clément nous prouvent que le DevOps permet d’avoir des équipes plus fortes, plus efficaces et soudées, un temps de release plus court et des experts avec des connaissances plus poussées !