Devops - premières rencontres et survol

Ce mercredi 1er décembre j'ai eu le plaisir de participer à la première rencontre Devops parisienne; en voici un compte-rendu, et bien sûr je vais tenter de répondre à la question que vous vous posez déjà: "Devops, qu'est-ce que c'est encore que ce bidule ?"

Commençons par les ingrédients: un petit groupe (une douzaine de personnes) qui se réunissait dans une ambiance informelle et très auto-organisée, la plupart ne connaissant pas les autres participants présents, simplement pour discuter d'un sujet qui leur tenait à coeur: recette classique pour passer une soirée passionnante. (Merci au passage à nos hôtes, Theodo, et aux initiateurs, Philippe, Samuel et Fabrice.)

Ajoutons des bières et des pizzas; en effet "Devops" est un raccourci pour "developers and operations", c'est à dire des intervenants du développement (appelés diversement programmeurs, développeurs, codeurs, "softeux", etc.) et de l'exploitation ("exploitants", ingénieurs de production, administrateurs systèmes, etc.). Vous aurez compris qu'on est entre techniciens...

Pourtant il y a là deux cultures très différentes, et on s'en aperçoit vite à mesure que le tour de table pour faire les présentations commence, chacun y allant de son "troll", petite pique pour deviner à la réaction de chacun qui fait partie de quel bord, ça donne à peu près: "je m'appelle X et je préfère vi à emacs, il faut que j'en dise plus?" Le sujet qui nous réunit c'est justement le rapprochement entre deux cultures que l'organisation usuelle des projets de développement a eu tendance à séparer. (Parfois littéralement, au sens "les développeurs dans la grande salle du 3è étage, les exploitants à la cave".) Certains des effets néfastes de cette séparation sont proverbiaux dans la profession: "excuse n°1 du développeur: ça marche sur ma machine!".

Après le tour de table Raphaël a proposé d'organiser le reste de la réunion en Open Space, ce qui nous a permis d'apprécier l'étendue des sujets qui nous intéressaient. De mémoire et en vrac:

• des outils (Chef ou Puppet) pour gérer les configurations système
• exploiter la virtualisation du développement à l'exploitation
• intégrer la création de packages dans le build automatisé
• déploiement maîtrisé des applications Web 
• ...et d'autres que j'oublie...

 Cette liste ne vous apprend sans doute pas grand-chose sur ce que veut dire "Devops"? C'est justement tout l'intérêt de cette communauté naissante.

Je m'explique: de façon très similaire à l'invention en 2001 du terme "Agile", la communauté Devops est née du sentiment diffus d'un certain nombre de personnes qu'elles avaient, chacune dans leur coin, eu des idées convergentes pour résoudre des difficultés lancinantes dans leur métier. En se rencontrant et en donnant un nom (une étiquette, certes) à cette convergence elles espèrent donner plus de visibilité à la fois à ces difficultés et aux solutions proposées.

Il s'agit donc de briser les "silos" qui isolent les développeurs et les exploitants chacun dans leur coin, avec de nombreuses conséquences néfastes: par exemple des projets qui semblent "réussis" techniquement (code propre et bien testé) et fonctionnent très bien... jusqu'au jour de la "mise en prod" où rien ne va plus: quelques connections simultanées et le serveur "tombe", ou encore une base de données ralenties par des accès mal conçus.

On retrouve dans cette volonté de "déspécialiser" une constante de la culture Agile, au sein de laquelle d'ailleurs les fondateurs de Devops ont fait leurs armes. Le discours Agile a cherché à modifier, voire à effacer les frontières entre développeurs et clients, entre développeurs et testeurs, ou plus récemment entre développeurs et ergonomes; Devops vise à abolir une frontière supplémentaire. Plutôt que développer dans leur coin des applications qu'ils vont ensuite "balancer par-dessus le mur" aux exploitants, les développeurs sont encouragés à travailler dès le début du projet avec eux et à les intégrer à l'équipe.

De même que le discours Agile s'oppose à des approches "cérémoniales" ou totalisantes du développement, de même Devops se positionne comme une réponse "Agile" aux démarches ITIL ou Cobit très prisées dans le domaine de l'exploitation.

On retrouve donc dans l'approche Devops, d'une part des outils et pratiques "empruntés" à l'approche Agile:

• outils de management visuel (on parle de "visible ops") pour créer de la transparence
• alignement sur un rythme itératif et incrémental (mettre en production au rythme du développement)
• automatisation du test
• intégration continue

Mais on va également trouver dans Devops des solutions spécifiques, transposant l'approche Agile au métier de l'exploitation, ou qui visent à établir un nouveau contrat avec les développeurs:

• l'automatisation du "build" ne doit pas se cantonner à produire un exécutable mais va jusqu'au bout de la chaîne en produisant un "package" dont l'installation est répétable et même automatisable
• considérer la description d'une infrastructure système comme du code, et intégrer ce code à la gestion de version au même titre que le code applicatif; c'est l'intérêt d'outils comme Chef ou Puppet
• de même qu'on ne teste pas à la main, on n'installe pas à la main, on ne configure pas à la main, etc. - tout ce qui est manuel et répétitif représente de la connaissance et il faut capturer cette connaissance sous la forme de fichiers texte ou de code
• intégrer très tôt dans le cycle de développement les questions de surveillance et de gestion de l'application, de benchmarking des performances, etc. - en d'autres termes adopter une vision d'ensemble
• plus généralement considérer qu'on est "tous dans le même bateau" et qu'il n'est pas productif de chercher "à qui reviennent les reproches" lors d'un incident en production: abolir les petits jeux qu'on voit fréquemment pour savoir si c'est un bug ou un défaut de surveillance qui est à l'origine d'une panne par exemple; adopter des outils, des processus et surtout une responsabilité partagées

Vous pourrez trouver plus d'information ailleurs sur le Web:

• What is this Devops thing, anyway? de Patrick Debois
• Devops Best Practices (concis et précis)
• What is Devops? de Rodrigo Campo
• What is Devops? de Damon Edwards

Les parallèles avec la communauté Agile sont intéressants, notamment le fait que la question "qu'est-ce que DevOps" ne donne pas pour l'instant lieu à une réponse brève, précise et circonstanciée, le mouvement se dérobant aux tentatives de définition. On pourrait le réduire à des outils: de fait au cours de la soirée de mercredi nous avons beaucoup parlé d'outils (j'ai découvert l'existence de Chef, Puppet, Vagrant et d'autres outils et je vais m'y intéresser, par curiosité et pour ma culture générale), mais ce serait la même erreur que de réduire l'approche Agile à des outils.

Dans les deux cas, il ne s'agit ni de définir des méthodologies, d'imposer des processus ou des outils,  mais de créer, d'animer et de se réclamer d'une communauté; l'objet de cette communauté étant l'élaboration et la conservation d'un ensemble de pratiques, non pas pour leur valeur en soi (on ne "sacralise" pas les pratiques) mais pour les bénéfices que ces pratiques apportent aux projets.