Henri Gomez,avec 20 ans d’expérience de développement, architecte Java, finance et banque, continue à coder régulièrement. Il est Senior Director of IT Operations chez eXo Platform, éditeur Français de 160 personnes. Il est aussi commiter Apache Tomcat depuis 2001, co-fondateur JPackage (CPAN) et dernièrement, il travaille en tant que développeur sur le projet OpenJDK OS/X Build projet de construction d’OpenJDK7. Que celui qui a dit « tu peux pas coder après 40 ans » se lève que je vienne lui déposer 5 doigts sur la face.
DevOps
3 cercles : le développement, la partie QA et la production. Henri explique que l’on ne peut pas embaucher un Devops, ce serait finalement essayer d’embaucher de la Collaboration.
Devops n’est pas un produit, ni une personne : ce serait quelqu’un capable de faire 3 domaines. Ce n’est pas une méthodologie stricte mais de bons principes et des idées fortes. Ce n’est pas une recette miracle.
C’est un mouvement, avec de l’agilité sur l’ensemble de la chaine jusqu’à la production. C’est une nouvelle donne technique en partie en raison des personnes qui ont donné un nom à ce mouvement. C’est la possibilité d’avoir un autre rapport que celui de la force entre la production et le développement. Ce mouvement de 2009 est lié au fait que les initiateurs de ce mouvenent sont des technophiles.
Devops se veut la réponse à de nouveaux problèmes : déploiement massif et régulier. PRA Persistence Resilience Availability, continuité et Cloud.
C’est de l’Agile sur toute la chaine. Elles ont fait leurs preuves en dev, elles sont applicables sous conditions en QA et en production.
Une opération de production doit être dans le processus du développement du logiciel. Finalement il faut que la mise en production soit régulière, au même rythme que celui des releases. En effectuant souvent des mises en production vous réduisez le mode « héroïque ». Les déploiements fréquents rassurent les développeurs, les testeurs et les équipes de production.
Cela permet de roder la mécanique de production et de réduire les risques de découvertes tardives des incidents.
Lorsque vous livrez régulièrement, les équipes de production peuvent détecter rapidement les soucis et les faire remonter aux développeurs.
DevOps c’est aussi une pensé différent : Scale out au lieu de Scale in. Vous n’allez pas ajouter des centaines de processeurs à une seule machine, mais plutôt ajouter des machines moins puissantes et distribuer le travail. Cela demande de l’opérationnel.
Une touche de Dev pour les Ops : les gens de la production aiment faire du code et du développement pour automatiser et répéter rapidement certaines tâches. Les développeurs ont aussi à apprendre de la production, comment logger des messages, comment gérer proprement les connexions avec la base de données, où stocker les fichiers. Bref isoler ces 2 mondes correspond à une fausse perception du métier de développeur et de l’exploitation. C’est souvent une demande de l’organisation ou de la DSI, alors que le bon sens voudrait que les équipes soient co-localisées, que les personnes de l’exploitation soient aussi dédiées à un ou deux projets maximums…
Les équipes d’exploitations ont développé des outils puissants comme Chef ou Puppet, tous les deux écrits en Ruby. Ils savent utiliser un SCM et ils peuvent aider les développeurs, en travaillant en étroite collaboration avec les développeurs. En écoutant Henri, je ne peux m’empêcher de penser que beaucoup de développeurs ne s’intéressent pas à la production. Quelques uns sont incapables d’utiliser Unix. Comme ils sont incapables d’utiliser Firebugs lorsqu’ils font du web…
Faut-il séparer les opérationnels des développeurs ?
Le constat c’est que lorsque l’on oppose les équipes, cela mène à l’échec. Surtout entre les équipes de production et de développement. Or finalement si l’on met 2 chefs pour diriger chacun des départements, il est évident que chacune des équipes n’a pas les mêmes intérêts. Les développeurs veulent de la flexibilité et de l’innovation, là où la production souhaite des noyaux stables et des procédures de suivi bien documentées. Comment cela peut-il fonctionner ? Comment voulez-vous travailler avec un développeur qui n’a jamais ouvert un terminal ou une console Weblogic ?
Henri parle aussi de vocabulaire. Si vous brillez en société avec OOM, jar, war, Maven ou CI, est-ce que vous maitrisez aussi Selenium, appliance F5 ou zfs ?
Là où le développeur trouve normal de coder en dur les urls ou les paramètres, c’est une hérésie pour une personne de la production. Sécurité, monitoring et suivi métier de l’application… c’est aussi cela l’architecture. Peut-être pas uniquement votre cravate et vos slides powerpoint avec SOA/SOO/SCA/SPA…
Les backups et la reprise d’activité après un incident… Certains applications ne sont pas prévues pour être arrêtées. Au premier crash, il devient impossible de relancer des SI ou des applications. Le développeur dit : « t’inquiète pas, il est 18h20 et tu peux faire la mise en production… » et le responsable d’exploitation a alors l’impression d’être un vampire qui ne vit que la nuit…
Le principe de DevOps c’est aussi d’en finir avec la patate chaude. Pour cela il faut faire une analyse des besoins de chacun, du fonctionnel jusqu’à la production. Et chacun doit être considéré d’égal à égal.
Pour mieux travailler, vous pouvez aussi définir les livrables. Un fichier toto-SNAPSHOT.jar ce n’est pas un livrable. Il ne faut pas non plus entrer dans des grosses procédures lourdes inventées uniquement par des managers incompétents pour justifier finalement leur existence…
Chez eXo Platform
eXo Platform : 160 personnes dont 20 personnes en France, est une entreprise distribuée avec des équipes aux USA, en Ukraine, au Viet-nam et en Tunisie. Tout fonctionne avec des outils adaptés aux besoins d’un éditeur.
Henri parle un peu de l’infrastructure et des outils utilisés par eXo. Les outils sont classiques, mais les outils communs : JIRA, SVN/Git, Nexus, Confluence pour wiki et jenkins. Cela permet d’avoir les mêmes outils pour toutes les équipes : développeurs, productions, assurance qualité… Bref une réduction des coûts et une meilleur synergie entre les équipes.
Une demande de déploiement chez eXo c’est un ticket Jira. Cela permet d’utiliser les outils de planification de Jira, de décrire les opérations en cours et de faire des retours.
Les incidents de production sont des tickets : les données de production sont alors attachées au ticket, tout l’historique est attaché au ticket. Le développeur a donc directement l’ensemble des informations collectées par les opérationnels. On gagne du temps, et on comprend lorsqu’une nouvelle version est livrée qu’elle corrige un ticket donné.
SVN/Git est utilisé pour les sources des applications (dév) les sources des tests, les source du packaging, les manifests Puppets pour la pros et les sources des jobs Jenkins. Tout est librement accessible : comme dit Henri, on travaille tous dans la même maison.
Nexus est un repository des jars. Cela évite d’avoir des jars « bidouillés ». Cela renforce la livraison via Nexus. Pas de livraison par email. Cela rassure les équipes QA et production. Il n’y aura pas d’éléments déviants. On est dans une vraie démarche Editeur. eXo Platform est un éditeur avec une chaine logicielle très outillée.
La documentation par équipe est sur un seul repository. Des macros JIRA permettent d’avoir l’état de certaines tâches directement dans le wiki Confluence. C’est aussi un outil participatif.
Jenkins est aussi massivement utilisé. C’est un enchaineur d’événement. Connu d’abord comme un moteur d’intégration continue, c’est aussi un moteur de déploiement, de packaging et de tests continus. Tout ce qui est répété est automatisé, une vraie production au sens industriel du terme.
Henri présente en détail chacun des cas d’usage de Jenkins, qui dépasse largement la simple compilation d’un projet.
Conclusion
Il n’y a pas de cloisonnement chez eXo Platform. Chacun peut accéder à l’ensemble des informations. La participation et les échanges sont encouragés. Tout le monde utilise les mêmes outils. Jenkins qui était utilisé par la QA n’était pas utilisé par les équipes développements au début. Il a été mis en place rapidement pour toutes les équipes.
DevOps c’est une culture de la communication, comme l’Agile est finalement une culture de travail entre les équipes métiers et les développeurs.
0 no like
« Là où le développeur trouve normal de coder en dur les urls ou les paramètres » euh, on parle de quel genre de developeurs la???
Celui qu’on trouve beaucoup trop 😉
Plus sérieusement la grosse erreur c’est de hardcodé le host ou le port que ça soit dans l’appli ou les tests. Mais généralement l’erreur est souvent plus sournoise en hardcodant le context de deploiement d’une webapp par exemple.
« Les backups et la reprise d’activité après un incident… Certains applications ne sont pas prévues pour être arrêtées. »
J’ai vu aussi des appli dont les bases n’étaient pas prévues pour être purgées ou archivées. Dans certains contextes, ça peut devenir critique.
« Un fichier toto-SNAPSHOT.jar ce n’est pas un livrable. »
… pas plus qu’un titi.exe ou un ma_conf_perso.xml, effectivement.
Je constate dans tout ça que dans les grandes structures, finalement, on est sensibles aux mêmes choses que dans les petites, mais avec un degré assez différent tout de même : étant donné qu’une même personne peut être amenée à travailler à la fois sur la partie dev et sur la partie prod/exploit, soit il est suffisamment carré et il dispose de procédures et de méthodologies pour simplifier son travail et assurer une certaine qualité de « service », soit il la joue « artisanale » (dans le mauvais sens du terme) et là, ceux qui reprennent, ou même juste ceux qui assurent son remplacement finissent par jeter l’éponge au bout d’une semaine de galère…
Tout ça pour dire que même dans les petites structures, il faut savoir distinguer les deux métiers sans pour autant les opposer, mais en les faisant travailler ensemble.
Et lorsque sur un poste comme le mien, on est à cheval entre les deux, assurant des spec aux déploiements, en passant par les devs (des standards et des spécifiques clients), il faut savoir rester rigoureux sur toute la ligne.
Merci pour m’avoir rappelé cette leçon !