Une histoire fictive de la réalité
Credit photo Steve Chilton http://www.flickr.com/photos/steve_chilton/2322020454/sizes/z/in/photostream/
J’imagine votre joie en ce beau vendredi. Il est 17h50 et vous venez juste de réussir à construire votre projet avec Maven. Après 3 jours d’efforts surhumains, vous avez enfin terminé le packaging de votre logiciel/projet/truc-du-moment. Comme le projet était à mettre en prod il y a 2 jours, vous êtes largement dans les temps avec seulement 48 heures de retard. Donc tout va bien, vous êtes prêt à passer en prod.
Et il est maintenant temps d’appeler le gars de l’exploite.
Pour ceux qui ne connaissent pas le gars de l’exploite, c’est ce bonhomme qui ne vit que la nuit, qui passe son temps à installer, configurer, patcher, arrêter, relancer et surtout installer les logiciels que vous développpez.
En règle générale vous n’avez que de brefs échanges au téléphone. Souvent des Onomatopées pour sa part comme « Mouais, mmmfff, grrr, cool ». Alors que de votre côté vous avez vos phrases toutes faites auxquelles il ne réagit plus comme ma favorite « Mais sur mon poste ça marchaaaiiit » ou « Ben l’intégration continue elle est verte, alors ça doit marchéeeee » et encore une autre : « Je comprends, chez moi ça marche avec H2 in-memory et Tomcat. Pourquoi cela ne marcherait-il pas avec Websfear et Ourahcleu ? »
Nous avons donc à notre gauche un expert système aussi sexy que Sébastien Chabal et à notre droite un développeur protégé par son bouclier « Maven+ ». Et vous, chef de projet/architecte/femme au foyer devez faire cohabiter ces 2 espèces…
Le développeur a une fâcheuse tendance à ne pas penser qu’un jour, peut-être, son logiciel sera mis en production. L’exploitant système d’autre part a une tendance ennuyante à demander des conditions de prods, quant bien même l’installation n’est prévue que pour 2 testeurs.
Bref cela donne beaucoup d’échanges intéressants.
Heureusement que l’on fait pas ça hein…
Il y a heureusement un mouvement intéressant qui prend de l’ampleur, et dont nous aurons l’occasion de parler dans les mois qui viennent : DevOps
J’ai entendu parler de DevOps à Devoxx 2010 pour la première fois. Il s’agit d’un ensemble de techniques collaboratives pour que les développeurs, les personnes de l’exploitation système et les équipes de tests travaillent plus efficacement ensembles. C’est aussi un mot pour regrouper plusieurs idées brillantes dont la première serait « et si on arretait de travailler comme des bourrins« .
Il y a le commerce équitable où tu respectes le gars qui fait du café en Colombie.
Il y a Devops pour envisager de manière différente la relation développeur-testeur-gars de l’exploitation.
Basé sur des valeurs Agiles, DevOps propose de livrer souvent, simplement et par petits incréments votre logiciel. Cela semble logique dans la suite du mouvement amorcé dans le développement, avec l’essor des méthodes Agiles comme Scrum par exemple.
Le petit plus du mouvement DevOps : il est initié par les experts systèmes des grands du Web. Il est plus centré sur la mise en production et l’assurance qualité. Ne cherchez pas de certification DevOps, nous parlons bien d’une manière de travailler différemment.
De la même manière que vous avez de l’intégration continue, vous pourriez avoir aussi une mise en production continue. L’essor du Cloud et des systèmes de virtualisation expliquent aussi l’apparition de ce mouvement. Il est désormais possible non pas de mettre en production un logiciel, mais carrément une image virtuelle complète et validée. Le temps de l’installation d’une application sur un serveur d’app est peut-être même terminé. Il sera demain plus simple d’installer et de démarrer une machine virtuelle, plutôt que de perdre du temps avec un serveur d’application Java.
So-li-da-ri-té
DevOps c’est aussi un ensemble de pratiques afin de favoriser le travail entre les développeurs, les testeurs et les équipes systèmes. Cela va à l’encontre des silos érigés dans les DSI ces dernières années. Il est plus efficace de co-localiser un développeur, une personne de la production et un ingénieur qualité, que de les disperser dans 3 sites différentes. Retirez aussi les micro-managers qui ne servent à rien et laissez-les travailler. Bon, du coup la DSI ne sert plus à grand chose, mais qui en doute encore hein ?
Automatisation
Pour être efficace, une démarche « DevOps » doit aussi viser l’hyper industrialisation des processus. Oh que j’aime cette phrase de consultant…. Attendez j’en essaye une autre… l’automatisation des tâches répétitives permet de réduire les facteurs de coûts et d’améliorer la livraison des incréments de manière itérative…. ça se voit que j’ai vendu du SOA.
Blague à part, vous l’aurez compris, pour être efficace il faut travailler avec les exploitants systèmes et les équipes qualités. En France les équipes qualités ne sont pas valorisées. Elles sont même absentes de certains projets. Lorsque j’étais chez Reuters, c’était le chef QA qui décidait ou non de la sortie de notre logiciel. Imaginez un instant que ce ne soit pas le chef de projet… Respirez… pensez-y encore…. voilà… vous pensez DevOps.
Développer c’est aussi mettre en production
Etre développeur dans une approche DevOps, c’est aller voir les personnes de l’exploitation. C’est passer une journée avec eux afin de comprendre les problèmes rencontrés. Ce sera très enrichissant et cela vous permettra de voir ce que font réellement les clients.
Chaque développeur devrait être capable de construire l’ensemble du projet puis de l’installer. Il n’est pas normal qu’une seule personne soit en charge de packager et livrer l’application. Nous devons être tous responsable du logiciel.
Les développeurs sont en général assez mauvais sous Unix. Allez je vais essayer de voir si tu sais répondre à cette série de questions simples :
– Que se passe-t-il si je fais un kill -3 sur le pid d’un process Java sous Unix ?
– A quoi sert la commande jps livrée dans le JDK 6 ?
– Comment remplacer le caractère ^M avec vi ?
Si tu réponds à ces 3 questions, tu es un maître. Si tu connais au moins l’une des réponses, c’est pas mal. Sinon… et bien sinon c’est pas grave, tu es comme la majorité des personnes.
L’effet silo
Soyons réaliste : beaucoup de projets informatiques actuels ne sont pas adaptés aux idées du mouvement DevOps. Nous avons mis en place des départements isolés. L’équipe métier, l’équipe technique, l’assurance qualité et l’équipe d’exploitation. Chaque silo est bien séparé. La communication s’effectue par l’intermédiaire de « réunions » avec des « phones-calls », alors que parfois les équipes sont dans le même bâtiment… Très rapidement cela conduit à une polarisation des relations entre les équipes. C’est « eux » contre « nous »…
Alors qu’un chef courageux prenne ces équipes et les mettent dans un même espace. Du métier à l’exploitation. Voyons ce que cela donne, ayons le courage d’aller à l’envers de ce qui coûte de plus en plus cher au fil du temps… C’est ça DevOps.
Je pense aussi qu’il y a un effet génération. Les 40 ans et plus ont une vision des années 90, sans Twitter et sans Facebook. Alors que la tranche 25-40 ans ne comprend pas pourquoi la mise en production d’un projet doit rester héroïque. Si les choses changent, c’est aussi parce que nous en avons marre de devoir envoyer 3 emails pour relancer « dans l’urgence » un serveur…
Conclusion
DevOps est un nouveau buzz word appuyé cependant par des acteurs du Webs. Une fois encore, ils viennent bousculer le monde de l’entreprise avec une approche Agile des relations développeurs/assurance qualité/production. C’est aussi une nouvelle fracture entre l’approche classique, majoritaire dans les DSI aujourd’hui, et l’approche Web mise en oeuvre par les petites structures.
C’est un mouvement lancé par des personnes qui pensent qu’il faut construire des logiciels avec de bonnes équipes, de bonnes relations inter-équipes et de bonnes technologies. Le plus important c’est le dernier mètre, les derniers instants avant que votre plateforme soit lancé. C’est aussi une vision où par exemple la mise en production n’a pas lieu dans 20 mois mais dès le premier mois. C’est une vision où le développeur prend conscience des problèmes d’exploitations. Plutôt que de s’auto-congratuler sur une approche DAO/Service, il pensera à faire une couche de logging efficace et pratique à utiliser.
Je pense que nous aurons l’occasion d’en parler dans les mois qui viennent. Surveillez les blogs des voisins comme Xebia, Octo ou Ippon Technologies, je pense que le sujet est intéressant à débattre.
Ressources
Blog de Patrick Debois (cité par Sébastien ci-dessous dans les commentaires)
Très bonne présentation sur DevOps sur son son blog. Le slide sur Kanban avec l’abattage à la chaîne est énorme… Et la métaphore du barbecue, j’ai adoré. A invité d’urgence à Agile France. Vous trouverez pleins d’astuces, comme l’appel de l’API Rest de Nexus via des scripts. Cela vous permet de récupérer la dernière SNAPSHOT de votre projet pour l’installer (dédicace à Emmanuel Servent de Xebia, il comprendra).
Blog de Stephen Nelson-Smith, Agile Sysadmin. Beaucoup d’articles intéressants comme la notion de golden image
Continuous Delivery, le blog de Jez Humble et Dave Farley est intéressant. Jez est product Manager de Go, un logiciel de ThoughtWorks Studios. Go permet de gérer la compilation, l’installation et le lancement de campagne de tests pour différents environnements (UAT, Prod, Dev) très simplement. C’est un outil d’industrialisation intéressant avec une édition community.
Il y a un même un DEVOPS_Borat sur Twitter qui balance pas mal de trucs marrants.
Réponses aux questions
1) Sous Unix pour générer une Stack Trace d’un processus Java vous pouvez envoyer le signal QUIT à un processus Java. Par exemple kill -3
Sous Windows il suffit de sélectionner la fenêtre où tourne votre application et de faire Ctrl-Break.
2) La commande jps que peu de monde connaît, alors qu’elle fait partie de Java 6, permet de lister les processus Javas qui tournent sur votre machine.
3) Pour remplacer le terminateur de fin de ligne Windows lorsque vous êtes sous Unix, avec vi voici la suite de touche à jouer : [Esc] : % s / [Ctrl-V] [Ctrl-M] / / g . Il y a aussi sinon la commande dos2unix et des milliers d’autres façons de faire
Salut Nico,
c’est le mois devop on dirait, tout le monde en parle ((c)(tm) Ardisson).
> Le petit plus du mouvement DevOps : il est initié par les experts
> systèmes des grands du Web
Je connais mal l’histoire devop mais je crois que cela vient plutot d’Europe, genre CITCON et le terme vient de Patrick Debois (c’est pas lui qui à fait la pres à Devoxx d’ailleurs ?), un consultant belge. D’ailleurs les 1ers devops days (en 2009) était en Belgique. Je me souviens que Patrick parlait déja de ça en 2008 (à Agile Open, coucou Patrick !) sans utiliser le terme car il n’existait pas.
Ceci dit, les grands du Web comme tu dit doivent pratiquer ces techniques depuis longtemps (je crois qu’Amazon met en prod tout les jours par ex.).
> Ne cherchez pas de certification DevOps, nous parlons bien d’une
> manière de travailler différemment
Rhaa, voila un manque qu’il est important de combler. Merci pour le Business Plan 🙂
> Développer c’est aussi mettre en production
Je pose souvent cette question à des développeurs « quel est le but de ton métier ? » La réponse classique est « coder ». Ce à quoi je réponds « non, c’est livrer du logiciel. Tant que les gens n’utilisent pas ton code, ton boulot n’est pas terminé. »
Je trouve donc que ton « aussi » est de trop. Un code qui reste sur Git (pardon SVN), c’est la moitié du chemin.
> – Que se passe-t-il si je fais un kill -3 sur le pid d’un process Java sous Unix ?
Envoie un signal QUIT
> – A quoi sert la commande jps livrée dans le JDK 6 ?
Commande status
> – Comment remplacer le caractère ^M avec vi ?
:%s/^M// (exercice purement fictif, nous sommes tous sous Unix 🙂
> Soyons réaliste : beaucoup de projets informatiques actuels ne
> sont pas adaptés aux idées du mouvement DevOps.
Je trouve que la séparation dev / op est du même acabit que MOE / MOA. Cela mettra autant de temps pour virer l’une que l’autre. Non ?
> Je pense aussi qu’il y a un effet génération. Les 40 ans…
Tu devrais arrêter de critiquer les vieux, tu vas bientot les avoir :). Et moi aussi d’ailleurs 🙁
> je pense que le sujet est intéressant à débattre
Cf mon retour d’expérience sur la ml Paris devop :
http://groups.google.com/group/paris-devops/browse_thread/thread/7619021dfdbdd851
Au plaisir d’en discuter autour d’une bière.
@sdouche j’ai encore largement le temps, je n’ai que 100011 ans
>2) La commande jps que peu de monde connaît, alors qu’elle fait partie de Java 6, permet de lister les processus Javas qui tournent sur votre machine.
Pour jps, n’oubliez pas de dire à votre sysadmin préféré de ne pas nettoyer le /tmp ! jps s’appuye sur un répertoire créé par au démarrage de chaque JVM pour lister les processus Java en cours d’exécution (typiquement /tmp/hsperfdata_%USERNAME%/%PROCESS_ID%)
Je connais un projet, impliquant une équipe importante. Il y a peu de communication entre les différents intervenants. D’autant plus qu’elle pratique le « nearshore ». Et dans ce cas, la politique mise en place, que l’on retrouve au niveau de chaque individu, consiste à faire respecter un ensemble de règles (tacites, bien entendu) permettant l’application du principe CYA ou « cover your ass ». C’est bien embêtant, car à chaque fois qu’on parle d’amélioration, il y a des petites réponses qui fusent à droite à gauche, dans le style « tu vas te faire taper sur les doigts » ou « tu vas te faire tirer les oreilles par untel », ou dans un autre style « d’accord, mais là je suis occupé, on verra ça plus tard ». Non, au lieu de ça, on décide de distancer encore plus
les participantsles ressources: les développeurs en nearshore et le reste (chefs, architectes, MOA, etc.) à Paris. C’est beaucoup mieux comme ça! En effet, on peut avoir plus de développeurs car moins chers. Et s’il y en a qui partent, il en reste suffisamment pour avancer dans les projets le temps de trouver les remplaçants. C’est une superbe idée pour diminuer les risques dû au turnover (sarcasme inside).Tout ça pour dire que j’apprécie l’idée qui consiste à mettre dans la même équipe tous les représentants de la « chaîne de production ». Cela améliore la communication entre les acteurs du projet, c’est vraiment essentiel.
Dans un style plus détendu, la définition de DevOps Borat sur twitter 😉
@david: un admin n’efface pas a la main /tmp mais utilise un utilitaire comme tmpreaper qui efface au bout d’un certain nombre de jours de non utilisation (et n’efface pas symlink, socket et fifo). Sinon c’et un gros bourrin :).
devops et pas DevOps … l’idée c’est bien de ne pas séparer Dev et Ops mais de tous travailler ensemble.
> Le petit plus du mouvement DevOps : il est initié par les experts systèmes des grands du Web
C’est Patrick Debois un Belge qui est à l’origine du mot … et lui non plus n’aime pas la typo DevOps … je t’invites à lire http://devops.fr/
Le déploiement et la livraison sont des sujets si simples quand ils sont traîtés avec un peu de bon sens.
Perso, je n’ai pas besoin d’un nouveau buzword. Pour une livraison « classique », une structuration du livrable et une doc d’une ou deux pages suffit bien souvent. Quand je parle de doc, je parle d’une vrai doc. Celle qui est MAJ et testée avant.
Et puis, s’il est vrai que les dévelopeurs Java n’ont pas un super niveau en Unix (je précise Java parce que c’est beaucoup moins vrai pour certaines autres technos comme PHP), il serait bon que les admins sys finissent un jour par avoir un bon niveau en architecture Java. Chez nous c’est ce qu’on fait; les uns forment les autres.
Pour « jps », c’est sympa de le savoir mais c’est franchement plus limité qu’un « ps [lessupersoptionsdelamort] | grep java » ou qu’un « cat /proc/monPID/letrucquejeveuxconnaitre »
@Thomas : c’est noté, je reprendrai l’article afin de rendre à Patrick la paternité du mot.