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 opérations 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 ».
Hmmm… laissez-moi réfléchir… non. Quel est le problème ? Cela 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, comment ferez-vous ? Et si Lucas venait à passer sous un camion, comment feriez-vous ?
Ç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é. 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 « une équipe de DevOps », et 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 développeurs qui ont une compétence en gestion des opérations. Cela signifie que moi, développeur, je ne peux pas me désintéresser de ces sujets. Un dev qui se fiche de savoir comment faire passer son code en production, c’est comme un cuisinier qui fait prétendument un très beau soufflet mais ne s’est jamais préoccupé de savoir comment le cuire.
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. 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 chargée 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 mouvement DevSecOps. Un premier vernis sur ces sujets n’est plus vraiment optionnel aujourd’hui.