BT

Le pair-devopsing par Fabrice Bernhard
Enregistré à :

Interview avec Fabrice Bernhard par Eric Bellemon le 06 sept. 2013 |
  • Télécharger
  • MP3
07:14

Bio Diplômé de l’école Polytechnique et l’ETH Zürich, Fabrice occupe le poste de directeur technique chez Theodo et intervient dans l'amélioration des stratégies techniques. Il assure en particulier l'adoption des dernières innovations techniques qui permettent d'accélérer la réalisation et garantir la maintenabilité des projets webs sur lesquels Theodo intervient.

Cette conférence réunit des participants et des conférenciers venus du monde entier autour d’un sujet commun: la culture “DevOps”:, ses techniques et ses bonnes pratiques. Le format de la conférence est simple: présentations le matin, et mini-sessions d’échange avec la méthodologie open space l’après midi.

   

1. InfoQ: Bonjour Fabrice, peux-tu te présenter et nous dire ce qui t'amène aujourd'hui aux Devops Days Paris ?

Fabrice : Bonjour, je m'appelle Fabrice Bernhard. Je suis le cofondateur et le directeur technique de deux boites. La première c'est allomatch.com, le site du sport dans les bars, qui permet de trouver quand il y a un match de foot le soir un bar pas trop loin de chez soi qui le diffuse. Deux ans après, j'ai créé avec mon associé, une deuxième boite qui s'appelle Theodo, une boite de service, qui fait du développement web sur mesure avec un focus fort sur l'idée d'amener la vitesse des meilleures start-up sur les projets de nos clients. Ça m'a amené au Devops, parce que d'un coté j'avais la partie éditeur d'allomatch où je devais maintenir un site sur le long terme et puis j'ai été amené à voir les problématiques plus de services, grâce à Theodo.

   

2. InfoQ: Tu es donc le cofondateur de Theodo, comment appliques-tu les principes Devops dans la création d'applications avec tes clients ?

Fabrice : On a ce focus dès le premier contact avec le client sur la vitesse de réalisation, mais au sens vitesse business, donc plus Lean Startup. Ça fait longtemps que l'on fait du Scrum, qui permet de développer très vite, mais ça ne suffit pas à donner la vraie vélocité business parce que l'on peut très bien développer très vite et mettre en prod au bout de 2 ans. C'est pour ça que l'on va vraiment se focaliser sur plein de choses, des idées Devops, mettre en prod très rapidement, avoir le serveur de prod dès le début du projet, ce genre d'idées qui sont fortes et que l'on va vendre à nos clients, non pas par le biais du Devops, mais par le biais du Lean Startup, qui est de dire "voilà, pour que votre business réussise, il faut vraiment itérer très rapidement en production".

   

3. InfoQ: Quels sont les principaux points de blocage que tu rencontres généralement ?

Fabrice : C'est les points de blocage classiques quand on essaye de faire de l'agile avec des gens qui ne connaissent pas, il faut faire de la pédagogie et il y a aussi un point de blocage au niveau de l'organisation. En particulier, ce qui est intéressant au niveau Devops, c'est que ça secoue beaucoup l'idée que l'hébergement est quelque chose de séparé. On va devoir demander des accès root aux serveurs, ce qui marche très bien si la personne ne veut pas s'occuper de l'hébergement, mais qui pose problème si l'on doit s'interfacer avec une DSI qui est censée gérer l'hébergement.

   

4. InfoQ: Quand on parle de Devops, on a à l'esprit l'automatisation des déploiements, quelles sont les autres facettes du Devops ?

Fabrice : L'idée phare de Devops, c'est toute la culture technique qui va permettre le Lean Startup. Le déploiement rapide c'est un point très important, on parle beaucoup d'outils de provisionning comme Puppet et Chef qui sont vraiment nécessaires dès que l'on commence à faire du scaling dans le cloud. Quand on n'en fait pas, c'est un peu moins nécessaire, mais ça reste très intéressant pour reproduire le même environnement en développement et en production. L'idée principale c'est avant tout d'accélérer le cycle de mise en production.

   

5. InfoQ: Quelle est la principale erreur que tu remarques dans les équipes qui essayent d'appliquer la culture Devops ?

Fabrice : L'erreur que l'on retrouve tout le temps dans une équipe de développement, c'est cette idée de toujours sous-estimer le coût de la mise en production. Et donc s'il y a une chose à faire, c'est que la mise en production doit avoir lieu le premier jour. Avoir adressé les risques des mises en production dès le premier jour, ça va énormément simplifier les choses et permettre d'anticiper énormément de problèmes et se mettre dans l'idée de déployer très souvent en production.

   

6. InfoQ: La communication est essentielle pour la réussite d'un projet, est-ce que tu as des astuces pour aider à la communication autour de Devops et améliorer le transfert de compétences ?

Fabrice : Une des idées est que quand un Ops va intervenir sur le projet des développeurs, c'est de lui interdir de pouvoir le faire tout seul. Un Ops qui intervient sur un projet doit le faire en pair-devopsing avec un développeur du projet.

   

7. InfoQ: Quel est le principe du pair-devopsing ?

Fabrice : Le pair-devopsing est basé sur le pair-programming, qui est de dire qu'à deux personnes sur le même ordinateur, on a finalement plein de gains long terme et donc c'est rentable. L'idée du pair-devopsing, c'est d'adresser une problématique de la méthode Scrum qui est qu'est-ce qu'il se passe si on veut que l'équipe technique résolve les problèmes elle-même, mais qu'il lui manque une expertise technique. Dans ce cas, le pair-devopsing c'est l'idée de résoudre ça en ne permettant pas à l'Ops de résoudre le problème technique à leur place, mais de le faire sous forme de mentoring, de tutorat, d'un des développeurs de l'équipe et donc de le former par la même occasion et donc apporter cette nouvelle compétence dans l'équipe Scrum.

   

8. InfoQ: Un point que tu abordes dans ton talk, c'est l'inintérêt des développeurs vis-à-vis de la prod. Comment les convaincre à s'y intéresser ?

Fabrice : Je pense que c'est une question de contrat moral, c'est très difficile de demander à un développeur, à partir du moment où on s'était mis d'accord qu'il avait un rôle de développement, de passer à un rôle d'astreinte. La première solution, c'est déjà de le prévoir en amont. La notion d'astreinte, c'est la notion la plus importante parce que je ne pense pas que ce soit une question d'implication, les développeurs sont toujours fans de leurs bébés, mais c'est une question de contrat moral, on ne peut pas demander à quelqu'un de se concentrer toute la journée très fort et ensuite, la nuit, d'être d'astreinte sans l'avoir au moins prévenu en amont.

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2013 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT