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.

Agile 2010, compte-rendu partial

J'ai participé à la conférence Agile2010 mi-août et comme chaque année ce fut une semaine bien chargée.

Résurgence d'XP ou clivage?

L'un des faits marquants est l'initiative prise par certains de nos amis, associés notamment au mouvement "software craftsmanship", de redonner un coup de projecteur sur le volet technique des pratiques agiles. Cory Foy et Cory Haines ont ainsi annoncé, puis confirmé lors d'un événement "Code Retreat", en marge d'Agile2010, la tenue l'an prochain d'une conférence "XP Universe 2011".

L'annonce inquiète certains, qui y voient le signe d'une fragmentation de la communauté. Pour d'autres c'est une bonne nouvelle, car le contenu d'Agile2010 est très largement occupé par des sujets autres que le code: management, coaching, UX, DevOps, etc...

Pour d'autres encore c'est l'occasion de méditer sur le sens profond de cette conférence et de la marque Agile: j'ai ainsi entendu "Agile est le nom que l'on donne au courant qui s'intéresse à l'ensemble de la chaîne de valeur, et qui regroupe plusieurs disciplines qui s'intéressent chacune à un bout de la chaîne". Ca vous donne une idée des états d'âme du leadership de la communauté...

DevOps, un nouveau "courant" à surveiller

Le mot "nouveau" est tout relatif, cela fait au moins deux ans que des collègues comme Patrick Debois militent pour intégrer sous la bannière Agile des modes de collaboration plus efficaces entre développeurs et exploitants (Ops comme Opérations, d'où DevOps).

Cette année cependant ce groupe a fait parler de lui d'une part en apportant plusieurs sessions, d'autre part en mettant en scène un clone du personnage Borat ("de glorieuse nation Kazakhstan!") qui a sévi sur Twitter pendant toute la conférence. Blague à part, c'est une idée qui fait son chemin.

Lean Startup ou "Feedback Driven Development"

L'une des présentations les plus enrichissantes pour moi concernait les idées pour marier l'approche Lean Startup popularisée par Eric Ries avec les techniques de développement agile. J'ai particulièrement apprécier la présentation concrète - "voici des choses que vous pouvez faire en rentrant au boulot" - combinée avec une bonne maîtrise de la philosophie sous-jacente - "inclure vos clients finaux dans la boucle de développement de la façon la plus resserrée possible".

C'est ce mélange qui fait les meilleures sessions de nos conférences, je voudrais hélas qu'il soit plus systématique à Agile 2010 qui prend peut-être une teinte un peu spéculative, portée sur l'abstraction et l'auto-congratulation.

La certification toujours (hélas) d'actualité

J'ai eu une longue conversation avec Alistair Cockburn, une des stars de la communauté, j'avais été très déçu par son annonce pendant l'été d'un nouveau programme de certification appelé ICAgile.

Déçu parce qu'à mon sens la communauté n'a plus confiance dans les programmes de certification depuis les déboires qu'a connu la Scrum Alliance, et qu'il n'est plus temps de continuer à chercher à "refaire la même chose mais correctement". Il faut remettre les choses à plat et proposer au marché de plus en plus acheteur de compétences agiles une façon plus claire, plus crédible, d'identifier ces compétences. Le schéma de certification proposé par ICAgile me semble trop proche de ceux que nous avons déjà connus, trop flou sur les questions de gouvernance et d'éthique, trop vulnérable aux conflits d'intérêts.

Cela dit le travail d'Alistair rejoint celui de l'Institut sur au moins un point, la nécessité de formaliser un peu la cartographie de ces compétences. Au-delà, et malgré une évidente bonne volonté de sa part, nous ne sommes pas sur la même longueur d'onde.

Recherche: un fossé à combler

Une table ronde sur la recherche en matière de pratiques agiles m'a permis de faire le point avec des chercheurs et des praticiens. Participaient notamment Scott Ambler et Frank Maurer, avec deux points de vue très différents. Scott met l'accent sur le peu de données empiriques, Frank se montre pessimiste sur l'intérêt que portent les chercheurs en général aux pratiques agiles comme sujet de recherche.

Au cours de la semaine j'ai discuté avec plusieurs personnes à ce sujet et il m'est finalement venu une formule pour résumer l'ambition de l'Institut en ce qui concerne la recherche et l'enseignement: "le Génie Logiciel existe depuis 40 ans, et presque toutes les universités ont un département GL, alors que cette discipline semble n'avoir résolu aucune des difficultés qu'elle a été créée pour résoudre; l'objectif de l'Institut c'est créer des départements Agilité dans les universités, pour faire avancer l'état de l'art..."

Les prix Pask

Cette année les lauréats du prix Gordon Pask sont... des lauréates, ça nous change un peu. Le prix décerné annuellement depuis 2006 est destiné à mettre en avant deux personnes dont le comité estime que la communauté devrait les écouter, même si ce qu'elles ont à dire est un peu bizarre. Il a été attribué à Liz Keogh, infatigable pédagogue du BDD (Behaviour-Driven Development), ainsi qu'à Elizabeth Hendrickson, initiatrice d'un travail de réflexion et de synthèse sur les tests automatisés au delà du clivage test unitaire - test de recette. Le test à l'honneur, donc, et la technique, mais aussi la gent féminine.

 
Reprendre contact...

Comme tous les ans la conférence a été l'occasion de retrouver pas mal de collègues et amis, et de leur (re)parler du projet de l'Institut. Les retours sont unanimement positifs.