DevOps : le grand malentendu

C'est l'histoire d'un mot, "DevOps".

C'est une histoire qu'on ne veut plus entendre, le "ça marche sur ma machine", et ensuite on met 3 mois pour passer en prod. D'autant que dans l'entreprise, c'est une équipe dédiée qui gère la prod et que c'est un point de passage obligé. Une équipe qui vous rétorque que vous n'avez pas utilisé le bon template pour la documentation et que de toute manière là c'est l'été, on freeze toutes les mises en prod pour 2 mois 😱.

D'où l'idée que gérer la prod, et plus largement les opérations, doit être une responsabilité de l'équipe de développement. Développer et gérer les opérations. Passer en production le plus fréquemment possible pour rendre l'opération moins douloureuse. Plusieurs fois par jour, voire à chaque commit (trunk-based development).

En tout cas :

You build it, you run it.

L'idée est excellente, là-dessus rien à redire.

Ce qui est problématique, ce sont plutôt les usages qu'on en fait. À commencer par le fameux : "Je te présente Lucas, le DevOps de l'équipe".

Ah ben oui… mais non en fait ! Quel est le problème ? Ça signifie qu'une seule personne va prendre en charge les opérations de toute l'équipe. Quand Lucas sera en vacances pendant tout le mois d'août, on fera comment ? Et si Lucas passe sous un camion — paix à son âme — on fait comment ?

Ça ne vous rappelle rien ?

Bingo ! C'est le même problème qu'auparavant, mais à l'échelle de l'équipe 👏

Vous me direz que tout ça est moyennement vrai, dans la mesure où Lucas aura mis en place une pipeline de CI/CD avant de devenir intime avec le camion. Bien joué Lucas. Et vous aurez raison : il faut espérer que la pipeline marche même si Lucas n'est pas là, c'est un peu ce qu'on demande à une pipeline de CI/CD.

Sauf que "Lucas, le DevOps de l'équipe", c'est la version soft, pour les moins de 18 ans 🔞. La version adulte, c'est "un DevOps pour plusieurs équipes", voire "une équipe de DevOps" (c'est du vécu, il va sans dire).

Snif, quand-même 😢

Alors, que faire ? Comme souvent, il suffit de revenir au concept originel et d'écouter ce que le mot "DevOps" veut nous dire : des devs qui ont une compétence ops. Cela signifie que moi, développeur, je ne peux pas me désintéresser des sujets opérationnels. Un dev qui se fiche de savoir comment faire passer son code en production, c'est comme un dev qui se fiche de savoir comment versionner son code. C'est comme un pâtissier qui se fiche de savoir comment faire cuire sa tarte tatin (*).

Au fond, l'ops devrait être a minima une compétence secondaire des T-shaped persons tant recherchées. C'est-à-dire que je dois être en mesure de faire des choses simples par moi-même, par exemple mettre en place une CI/CD via GitHub pour déployer sur Docker, le tout en monorepo avec une gestion propre des secrets. Simple et efficace. Le but est d'aller facilement en prod, pas de faire du K8S ou du Terraform.

Qu'une personne ait plus d'affinité pour ces sujets et contribue à faire monter le reste de l'équipe en compétence, c'est très bien. C'est idéal, même. Mais se décharger sur cette personne et lui confier tous les sujets ops, c'est se tirer une balle dans le pied.

Le DevOps est une pratique collective. Avoir dans son équipe une personne en charge de toute l'ops, c'est passer à côté de l'esprit du DevOps.

Même chose pour la sécurité. Je ne peux pas ignorer les bases de la sécurité, sinon je deviens une faille ambulante 😱 D'où le DevSecOps.

En clair, le DevOps ou le DevSecOps c'est pas vraiment une option quand on est dev !

(*) Chose très simple, d'ailleurs : tu mets au four, et t'atteinds ! OK, je sors.