Antidot à la Web Intelligence Summer School

WISS 2015
La Web Intelligence Summer School 2015 aura lieu du 31 août au 4 septembre à l’Université de Saint Étienne.

La thématique cette édition 2015 est « Répondre à des questions avec le Web » :

  • Publication de données web : données liées Linked Data,  normes et techniques du web sémantique / web des données
  • Comprendre et analyser une question en langage naturel : NLP / traitement du langage naturel
  • Trouver des données pour répondre à la question et à justifier la réponse : intégration / curation / extraction de données
  • Présenter les réponses : représentation graphique et  visuelle

Vous trouverez ici le programme complet de la Web Intelligence Summer School.

Membre de l’équipe Recherche d’Antidot, Ludovic Samper y donnera mardi 1er septembre de 10h30 à 12h30 un cours de 2 heures sur les techniques d’apprentissage automatique – machine learning. Il y parlera plus spécifiquement de classification supervisée utilisant scikit-learn, et détaillera certains algorithmes comme NB  – Naïve Bayesian, classification naïve bayésienne – et SVM – Support Vector Machine, machine à vecteurs de support.

Résultats de différents classifieurs avec scikit-learn – cliquez sur l’image pour l’agrandir

Si vous ne pouvez pas y assister, vous en retrouverez ici le contenu qui sera publié le jour même.

Partenaires de cet événement :

Université Jean Monnet Laboratoire Hubert Curien École des Mines de Saint Étienne Telecom Saint Étienne CNRS Bonn Universität Fraunhofer Institut

Continuous integration, Continuous delivery, Continuous deployment : où en est-on chez Antidot ?

L’équipe Delivery a la responsabilité de la mise en place des outils et des process de l’équipe technique chez Antidot. Dans ce cadre, elle développe puis opère les chaînes d’intégration continues de nos produits logiciels.

Je me propose de vous faire un retour d’expérience basé sur notre pratique.

De quoi parle t-on ?

L’intégration continue (continuous integration dans la littérature anglo-saxonne) implique que les développements logiciels sont régulièrement intégrés sur une branche commune sur laquelle sont automatiquement déroulées toutes les étapes de compilation et de validation.

La livraison continue (continuous delivery) est la suite logique de l’intégration continue : elle implique qu’à chaque moment on est « prêt à livrer » une version. La sortie de l’intégration continue devient donc le livrable attendu.

Le déploiement continu (continuous deployment) représente le Graal des équipes DevOps : chaque commit, s’il n’introduit pas de régression, finit automagiquement en prod.

(source IamOnDemand)

Continuous Integration

Depuis 5 ans, nous avons mis en place des chaines d’intégration continues, de plus en plus complètes.

A ce jour, chaque commit dans git sur une des branches de référence déclenche séquentiellement :

  • La compilation et les tests smalls,
  • le packaging (.deb et .rpm) et la création de dépôts dédiés à la validation,
  • des tests dits « medium » puis des tests dits « larges ».

Les dénominations de tests « small », « mediums » et tests « larges » viennent de l’excellent livre « How Google tests software », dont vous trouverez ici un résumé en français et qui propose une classification des tests en small, medium et large.

  • Un test small valide une unique fonction, avec une granularité très fine
  • Un test medium implique un ensemble de « modules » qui collaborent pour réaliser une fonction
  • Un test large implique le système entier.

Les problèmes que nous avons rencontrés lors de la mise en place de ces chaines d’intégration continue tournent autour de deux thèmes :

  • L’instabilité chronique des chaines,
  • Le temps d’exécution de ces chaines.

La solution au premier point réside dans l’analyse systématique des erreurs pour essayer d’en éliminer les causes racines. Je pense qu’on pourrait faire un article entier (et d’ailleurs je le ferai peut être) sur toutes les raisons, bonnes ou mauvaises, qui font qu’une chaine d’intégration continue est instable.

Pour le second point, nous n’avons pas à ce jour de solution satisfaisante : après avoir facilité l’écriture de tests, mis en place des outils pour les jouer automatiquement, réussi à convaincre tout le monde de l’intérêt de produire un maximum de tests, nous sommes aujourd’hui confrontés au problème de l’adhésion de tous à ces principes, et donc nos suites de tests augmentent et leurs temps d’exécution s’allongent.

D’aucuns diront que c’est un problème de riche, mais il faudra assez rapidement que nous nous attaquions à ce problème.

Continuous Delivery && Continuous Deployment

Les chaines d’intégration continue installent toutes les nuits la meilleure version disponible (RC pour « Release Candidate ») dans un environnement simulant la production.

À tout instant, une version est donc prête à livrer, et en ce sens nous respectons le Continuous Delivery.

En pratique, nous livrons une version toute les semaines et chacune de ces versions est mise en production.

Qu’est ce que signifie livrer pour nous ?

  • positionner un numéro de version sur un SHA-1 git,
  • communiquer sur la disponibilité de cette version (mail, tweet),
  • communiquer (Release Notes) sur le contenu fonctionnel de la version : nouvelles fonctionnalités, corrections de bugs…
  • mettre à disposition des paquets dans un dépôt stable.

Pourquoi doit on livrer ?

La question peut surprendre, mais dans un monde où une part significative des développements est exploitée en mode Cloud, la notion de numéro de version peu avoir un coté archaïque. Si l’on applique à la lettre les principes du Continuous Deployment, la version en production est la dernière qui a passée toutes les validations, et la notion de livraison telle que décrite ci dessus s’estompe.

Pour autant, nous ne somme pas prêt à abandonner la notion de livraison car en plus d’opérer notre propre solution dans notre datacenter, nous livrons aussi  nos logiciels en licence et nous fournissons notre plateforme à des partenaires qui construisent des solutions par dessus.

Dans ces deux derniers cas, les clients peuvent attendre des fonctionnalités ou des corrections de défauts, qui doivent être corrélées à des versions.

Le Delivery Train

La pratique de livrer systématiquement toutes les semaines la meilleure version possible (la dernière ayant passée avec succès tous les tests disponibles) est inspirée du « Delivery train » prôné par Spotify. Par ailleurs, c’est un premier pas vers le « Continuous Deployment ».

Avant la mise en place du Delivery Train :

  • la livraison d’une version, son périmètre fonctionnel, sa date de sortie était le résultat d’âpres négociations entre développeurs et chefs de projet, arbitrées par l’équipe Delivery.

Depuis la mise en place du Delivery Train, la livraison est systématique le vendredi et cela a :

  • enlevé du travail inutile et chronophage de négociation de date et de contenu,
  • rassuré tout le monde : si on rate un créneau pour une correction, le suivant n’est jamais que dans une semaine dans le pire des cas,
  • fortement amélioré l’automatisation du mécanisme de livraison : ce sont les effets bénéfiques du classique : « if it hurts, do it more often » cher à toutes les pratiques d’automatisation
  • et donc bien évidemment, facilité le non respect de la règle : en cas d’urgence (bug critique…), nous relivrons immédiatement. Et les gains en automatisation du processus de livraison facilitent cette livraison supplémentaire.

Continuous Deployment

Antidot ne fait donc pas aujourd’hui de Continuous Deployment. Mais un des effets bénéfiques du Delivery Train est que l’on y va doucement mais sûrement, poussés par le train.

En effet, la mise à disposition toutes les semaines d’une nouvelle version, nous a poussé à essayer de la mettre en production dans la foulée.

Nous sommes à nouveau dans un mode « if it hurts do it more often » :

  • nous avons mis à plat les processus de mise en production,
  • nous avons systématisé un calendrier,
  • nous sommes actuellement en train de travailler à rendre ce process aussi automatique que possible.

À moyen terme notre objectif sera donc une livraison hebdomadaire de version et le déploiement automatique de cette version sur notre production.

Je ne sais pas dire aujourd’hui si nous irons vers le Continuous Deployment au sens strict de la définition. Je dirais que nous n’en n’avons jamais été aussi près, et je vous en reparlerai dans quelques mois, lorsque nos objectifs moyens termes seront atteints.

Références :

Ship It Day Antidot – première édition !

Les 19 et 20 mars derniers se tenait le premier « Ship It Day » dans les locaux de la R&D d’Antidot à Lambesc (13).

Le Ship … quoi ?

A l’origine initié par la société Atlassian, le Ship It Day est une opportunité donnée aux employés de travailler en 24 heures sur un projet de leur choix, en rapport avec le produit et l’activité de l’entreprise, en vue de le livrer à l’issue de la journée, avec une seule règle : « Pas de règles ! ».

Cette manifestation est une occasion pour l’entreprise de promouvoir l’innovation en mettant différentes équipes en concurrence. Oui, mais dans quel but ?

La raison est simple : qui n’a jamais entendu ce genre de remarques à la machine à café ?

« Ce serait vraiment pratique que cet outil permette de faire ça, ça et puis aussi ça »

« Je ne comprends pas, ce produit là ne se vend pas autant qu’on aimerait »

« Pfff, je ne me souviens jamais comment fonctionne cette appli… en même temps elle n’est pas vraiment intuitive ! »

En effet, pendant le Ship It Day, ces équipes vont enfin pouvoir développer ce plugin qui manque depuis si longtemps, repenser une fonctionnalité que personne n’utilise, redessiner une interface, etc.

Or le pilotage quotidien de ces équipes, la pression liée aux cycles de développements dans le respect scrupuleux de la roadmap ne permet guère de laisser parler la créativité des collaborateurs…

Pourquoi c’est cool ?

ShipItDayLe Ship It Day est avant tout une aventure humaine, ludique, faisant de l’évènement un vecteur d’émulation très fort. Cela permet de faire une pause dans le train-train quotidien, tout en avançant rapidement sur des projets, au final relativement aboutis.

C’est également l’occasion pour les collaborateurs, en sortant du cadre de travail habituel, de travailler et d’échanger avec des personnes qu’ils n’ont pas toujours l’habitude de côtoyer. Une réelle synergie inter-équipes se crée alors dans une ambiance très conviviale.

Enfin, certains prototypes réalisés au cours du Ship It Day pourront devenir des fonctionnalités du Produit, qui, une fois industrialisées, seront déployées en production.

Une première chez Antidot ?

Antidot est cependant coutumier du fait, puisqu’il s’agit en réalité du troisième évènement de ce type en trois ans, avec deux précédentes éditions sous la forme de “Hackathon”. À deux reprises déjà, il s’agissait de proposer un prototype destiné à faire avancer le Produit, réalisé à l’issue d’un marathon de développement d’une semaine,.

Néanmoins, bien que suscitant un réel intérêt au sein des équipes de développement, la durée pour ces hackathons s’est finalement avérée trop longue pour pouvoir les maintenir et les renouveler à un rythme régulier.

Cette année, la société a donc adopté le format Ship It, plus court, pouvant ainsi être reconduit régulièrement.

Comment ça marche ?

Le Ship it se déroule en plusieurs phases :

J – 2 mois : Lancement

La date à laquelle aura lieu le Ship It est annoncée aux collaborateurs.

J – 1 mois : Ship It order

Les collaborateurs peuvent proposer des projets. Il n’y a pas de contraintes sur le nombre de projets soumis par personne, ni sur le thème sur lequel ils vont participer.

Un projet peut même être proposé 5 min avant le début du Ship It Day, le jour J.

J – 1 semaine : Brown bag

Les personnes porteuses d’un ou plusieurs projets et ayant besoin d’autres collaborateurs peuvent, uniquement s’ils le souhaitent, présenter leur projet à l’ensemble de la société afin de recruter et constituer leur équipe.

Jour J :

Chaque équipe annonce le thème de son projet et la composition de l’équipe

Le concours débute un jeudi matin à 11 h pour se terminer le lendemain à la même heure.

Durant ces 24 h, ce sont les managers qui se chargent de l’intendance : pauses avec café / gâteaux / bonbons, pizza party le soir, petit déjeuner le matin, etc.

C’est une occasion unique de pouvoir se faire servir une bière par son manager !  😉

Les équipes constituées préparent ensuite des démonstrations de 5 min sur leurs prototypes, en vue de les présenter à l’ensemble de la société. Une fois les démonstrations terminées, l’ensemble des collaborateurs peut voter pour élire le projet vainqueur du Ship It Day. S’en suit alors une « party » digne de ce nom, afin de célébrer les vainqueurs et l’ensemble des participants à l’évènement.

A quand le prochain?

KeepCalmShipItAprès cette première édition fin mars, la prochaine est prévue les 18 et 19 juin prochains. Au total, ce seront donc quatre Ship It Day qui seront organisés par an, au rythme d’un par trimestre.

Lors du Ship It Day du mois de mars, entre les collaborateurs sur les pistes de ski, en déplacement professionnel ou tout simplement indisponibles, les projets ont principalement été réalisés par les équipes de la R&D.

Mais le Ship It Day a bien évidemment vocation à faire interagir le maximum de collaborateurs, quelles que soient leurs équipes de rattachement : chefs de projet, staff marketing, support client, etc. Nul doute que la prochaine édition verra encore plus de collaborateurs dans les équipes engagées.

Vivement la prochaine édition !

Et vous, dans votre entreprise, ça se passe comment le Ship It Day ? :-)

P.S. : si notre approche autour des Ship It Days ou des brown bags vous intéresse et si vous êtes tenté de nous rejoindre cela tombe bien, on recrute ! Et pour ne rien vous cacher, nous avons expliqué sur ce blog comment se déroule le processus de recrutement à la R&D d’Antidot.