DevOops - DevOps Antipatterns

On parle beaucoup de la philosophie DevOps et de ses dérivés (DevSecOps, GitOps, …). Il est vrai que ça apporte beaucoup de bonnes pratiques et d’outils pour accélérer le delivery jusqu’en Production.

Mais alors qu’est-ce que le DevOops (non il n’y a pas de faute) ?

• Prendre l’équipe dev/int/prod (au choix) existante et la renommer “équipe DevOps”
• Le super-outil-qui-fait-tout-de-la-mort-qui-tue vendu avec un beau logo “DevOps” sur la boite
• La sur-multiplication d’outils
• “Je ne comprends pas, ça fonctionne pourtant sur mon poste…”
• La mauvaise Definition of Done
• Chercher des “Ingénieurs DevOps”
• Chercher à “Terminer” sa transformation
• DevOps c’est magique

Le DevOops c’est simplement les mauvaises pratiques gravitant autour du DevOps, les anti-patterns. J’ai essayé de recenser ici celles qu’on rencontre le plus souvent et qui sont symptomatiques d’une compréhension partielle, voire mauvaise de la philosophie.

Prendre l’équipe dev/int/prod (au choix) existante et la renommer “équipe DevOps”

On ne le répètera jamais assez : DevOps est une philosophie. !! DevOps, Ce n’est pas une équipe [u]mais un travail d’équipe[/u]. Le changement de culture d’entreprise, l’outillage de la chaine complète de livraison, la communication, … ne peuvent pas être limités au sein d’une seule équipe.

Le super-outil-qui-fait-tout-de-la-mort-qui-tue vendu avec un beau logo “DevOps” sur la boite

De la même manière que ITIL, Agile, etc… on voit sur le marché un certain nombre d’outils et de solutions logicielles vendues pour DevOps. Vu que la philosophie DevOps couvre aussi bien l’outillage que les méthodes et la transformation de la culture d’entreprise, il est facile de comprendre qu’aucun logiciel (même la plus grosse usine à gaz) ne saurait couvrir le spectre complet du DevOps.

La sur-multiplication d’outils

Corollaire du point précédent, il est souvent contre-productif de multiplier à outrance les outils. Ansible, Puppet, Chef, Saltstack, Kubernetes, OpenShift, Terraform, Jenkins, CircleCI, etc … sont de très bons outils, mais n’oublions pas le principe KISS (Keep It Simple and Stupid) : restons simple.

Les risques sont bien évidement :

• la complexification de la chaine d’outillage
• la difficulté de trouver des profils connaissant tous ces outils
• le surcoût (infras, licences éventuelles, …)

“Je ne comprends pas, ça fonctionne pourtant sur mon poste…”

On peut mettre dans cette catégorie les deux erreurs classiques suivantes :

• Implémenter DevOps et sa Toolchain du côté des équipes de Dev, loin des Ops.
• Implémenter DevOps et sa Toolchain du côté des équipes Ops, loin des Devs.

Le principe même de la philosophie DevOps est au contraire de lisser le flux du développement et du déploiement applicatif sur toute la chaine. On peut être tenté de commencer à implémenter ses principes en commençant par un bout, mais ce n’est généralement pas une bonne méthode. En effet, une des plus grandes difficultés est la différence de but entre ces équipes (évolution versus stabilité), qu’il faut justement commencer à lisser pour avoir un socle culturel commun sur lequel se baser pour ensuite accélérer les process. Les équipes doivent se parler, échanger. Et c’est plus difficilement possible si chaque équipe commence à implémenter des choses chacun dans son coin.

La mauvaise Definition of Done

Definition of Done est, comme son nom l’indique, la définition de ce qui est “terminé”. Au niveau de granularité d’un équipe de développement, ça pourrait être par exemple le binaire versionné donné à l’équipe d’intégration.

C’est un bon début, mais ça ne fonctionne plus tel quel dans un contexte DevOps En effet, on ne peut plus se contenter de définir ce qui est terminé au niveau d’une équipe. Il faut penser global pour être en adéquation avec pipeline de livraison de la valeur au business. La seule Definition of Done qui importe vraiment, c’est quand le business peut créer de la valeur grâce à ce qui lui a été livré en Production.

Certains vont même plus loin, considérant le lifecycle complet : c’est à dire jusqu’à la décommission de l’application.

Chercher des “Ingénieurs DevOps”

Non ça n’existe pas. DevOps est une philosophie, une manière de concevoir et de faire les choses. N’importe qui peut s’approprier et appliquer ces concepts, peu importe son métier. D’ailleurs, le DevOps réunit par définition plusieurs métiers/profils.

Par contre oui, tout comme avec Agile ou ITIL par exemple, les profils que l’on recrute peuvent être sensibilisés et formés aux principes DevOps. Ils sont donc plus à même d’intégrer une équipe qui fonctionne de cette manière, ou seront en mesure d’apporter les bienfaits du DevOps si ce n’est pas le cas.

Un anti-pattern dérivé est la création d’une équipe “DevOps” à part constituée de ce genre de profils. Sans intégration au niveau de l’organisation on crée alors un nouveau silo…

Chercher à “Terminer” sa transformation

Désolé d’enfoncer des portes ouvertes, mais dans un contexte d’amélioration continue il n’y a jamais de “fin”. Le nouvel état souhaité n’est qu’une étape vers l’idéal (qui évolue dans le temps).

DevOps c’est magique

La philosophie DevOps apporte beaucoup de choses pour permettre d’accélérer son process de delivery et fluidifier les opérations IT. Malgré cela ce n’est pas magique : les outils et les process ne font pas tout. Un aspect souvent négligé car complexe est le changement de culture qui doit être le moteur de la transformation (et non l’inverse). C’est cette culture d’entreprise qui agit comme “carburant” pour la transformation en guidant et en motivant les personnes y prenant part.