Archives de l’auteur : Stéphanie CHARRIÈRE

devops chez Antidot

DevOps, kesako ?

Le terme DevOps est apparu il y’a environ une dizaine d’années et est largement utilisé dans de nombreuses fiches de poste (dont la mienne) mais il reste encore flou aujourd’hui. Je vais donc essayer de me lancer dans une définition ; ou du moins dans la définition que nous en faisons chez Antidot.

Origine du mot DevOps

nuage de mot devopsDevOps vient de la contraction de 2 termes anglais « development » « operation* ( *exploitation en français) ». Cela part du postulat qu’il y’a donc deux mondes, celui des développeurs donnant vie à un produit, et celui des administrateurs système qui l’opère dans le Datacenter.

Avec l’apparition des méthodes agiles, ce postulat est mis à mal, et le terme DevOps fait son apparition en proposant le trait d’union entre ces deux mondes. Le « DevOps engineer » n’est plus un simple admin, mais s’oriente plus vers un développeur qui aurait pleinement conscience des ressources requises par son produit, et saurait comment l’opérer efficacement dans un espace de production car il en connaît toutes les ficelles. Cette double compétence permet une grande réactivité, et est un atout non négligeable dans un procès de déploiement continu ou d’intégration continue.

Et Antidot alors ?

Antidot est un éditeur logiciel spécialisé dans la transformation et l’enrichissement de données, aussi, la société propose plusieurs produits qui utilisent une architecture assez complexe. C’est là qu’une approche DevOps est intéressante, voir indispensable pour opérer un Datacenter en perpétuelle évolution.

En effet, le marché fait que nous avons régulièrement besoin d’ajouter/réinstaller de nombreuses machines. Amazon avec AWS fait ça très bien, mais nous préférons opérer nous-même 95% de notre Datacenter (5% étant quand même chez AWS). Nous voulons avoir la même souplesse qu’AWS en termes de mise à disposition de machines, pour cela nous utilisons divers outils qui nécessitent des compétences en développement comme Puppet (ruby)/Ansible (python)/FAI (bash) ou encore Docker et LXC pour la virtualisation. Aujourd’hui une installation complète d’une machine pour notre DC (comprendre avec compte UNIX, produit installé « Up & Running ») prend moins de 10 mins pour une machine bare-métal, moins de 5 minutes pour un container LXC et quelques secondes pour un container sous docker.

Même si cette partie utilise des compétences de DEV, elle reste très orientée, OPS. Ce n’est pas le seul besoin que nous avons chez Antidot, comme je l’évoquais un peu plus haut, nous avons besoin de réduire et d’automatiser au maximum le passage en production de chaque ligne de code* (*de chaque commit)  produite par nos développeurs « de souche ». Il a fallu repenser toute la chaine de livraison/test de notre solution.

devops chez Antidot

Ce besoin est résolu avec la mise en place d’une architecture basée sur les fonctionnalités offertes par docker et gitlabCI. Ainsi, un développeur peut à loisir développer dans une branche git sur son propre poste, chaque commit déclenche l’instanciation d’un environnement virtualisé complet à l’image de notre production, afin d’y effectuer une série de tests. Une fois tous les tests passés, le commit est automatiquement mergé/fusionné dans la branche principale de notre produit, et une nouvelle version est livrée, prête à être installé en production. A chaque étape, une notification est envoyée au développeur (dans une room Hipchat) lui permettant un retour « temps réel ». Il va de soi que le déploiement vers l’environnement de production est également automatisé, ce qui ne veut pas dire automatique. Nous préférons garder le contrôle sur le moment où nous déployons en un clic vers tout notre parc de production. A titre d’exemple, avant cette automatisation, une mise à jour de production pouvait prendre plus d’une journée à un de nos administrateur système pour tout le parc, elle a été réduite à 20 secondes pour appeler la commande et à 20/30 minutes pour son exécution (temps incompressible d’arrêt et de redémarrage des services sur tout notre parc de production).

Le monitoring en Devops

Le monitoring est egalement opéré en mode DevOps. Chez Antidot, nous utilisons principalement Shinken. Shinken utlise une liste de « hosts » et de « probes » statique. Avec notre Datacenter devenu dynamique, il a fallut ecrire une bibliotheque capable de découvrir tous les hosts provenant de notre inventaire (GLPI) et de leur appliquer les bonnes sondes metier en fonction de certain critères/tags. Grace a cette bibliotheque écrite en Python, nous pouvons par exemple ajouter une machine dans un cluster Mongo (Kickstart + playbook Ansible), le monitoring arrive automatiquement avec uniquement les  psondes necessaire.

schema devops

Le « devops » chez Antidot ne consiste pas à réinventer la roue, mais à utiliser une multitude d’outils/de standard open source (ou non), et de créer le « liant » entre tous ces outils afin de ne pas avoir à répéter deux fois une même action (là ce sont mes origines Corses qui parlent). D’aucun diront* (* les mauvaises langues) que c’est une sorte de fainéantise poussé à l’extrême, afin de simplifier ses tâches. Je préfère dire que c’est plus une façon de se débarrasser des tâches ingrates/répétitives en créant une architecture « vivante » et « dynamique », et surtout plus intéressante, piloté d’une main de maitre 🙂

C’est un défi que nous aimons relever et qui nous permet de nous tenir au fait des nouvelles technologies. A ce titre, si tu es comme nous et que tu souhaites faire de cette philosophie devops ton quotidien, je rappelle qu’Antidot recrute un Administrateur DevOps, n’hésite pas à nous contacter, toute proposition sera étudiée.

Article rédigé par Yann Finidori

matinee hub retail

Matinée au Hub Retail à Lyon le 25/01

Le Hub Retail est une association professionnelle rhône-alpine qui fédère des commerçants et acteurs du secteur concernés par le cross canal et les questions connexes. De même qu’en septembre dernier Equip Mag (salon spécialisé pour le retail physique, point de vente) et eCommerce Paris étaient regroupés, pour hub retail, il n’y a plus de ecommerce, uniquement du commerce.

Notre client King Jouet en est membre fondateur d’Hub Retail et m’a proposé d’y assister.

Hub Retail organise tous les mois des matinées d’échange. Ce 25 janvier la rencontre a eu lieu à Lyon.

Le coeur de la matinée était un retour de visite au NRF à New-York d’Olivier Dauvers, journaliste spécialisé brillant qui n’a pas sa langue dans sa poche.

Il a parlé de 4 innovations qui l’ont marqué par leur intelligence, non pas technique mais « marketing » de solution à une problématique de la relation client.

– utilisation de capteurs (type accéléromètres / volume du pied) pour caractériser finement l’adéquation d’une chaussure de running avec la morphologie/foulée du client. Le commerçant en tire une information d’une grande valeur qui pousse le client à s’approprier le produit plus facilement.

– application de yield management à des denrées périssables. L’exemple montré était basé sur un rayon boulangerie équipé d’étiquettes pilotables à distance. L’historique de vente analysé permet de prévoir finement l’impact du prix sur les ventes, et donc de réduire la perte pour des produits à durée de vie courte.

– utilisation de reconnaissance d’image pour détecter les rayon vides à partir de caméras montées sur l’ensemble des caddies du magasin : ces caméras grand angle parcourent sans cesse les rayons, transmettent en temps réel les images captées et permettent de voir dans quel linéaire on a des manques. La détection se fait en quelques secondes, sans besoin de parcourir physiquement le magasin. Le réassort peut ainsi se faire très rapidement.

– Utilisation de reconnaissance d’image pour compter le contenu du caddie sans besoin de RFID sur chaque produit. Une caméra est placée sur la poignée du chariot. Elle filme en continu le caddie et détecte les produits qui y sont posés (ou enlevés) afin de permettre un paiement sans caisse et sans attente. L’intérêt de ce système réside dans l’absence de puce RFID sur chaque produit.

L’intervention se termine sur la présentation de la librairie physique Amazon ouverte à Seatlle. C’est un très bon exemple d’application du meilleur du online sur un produit off line. On trouve dans cette librairie :

– quelques milliers de titres mais uniquement les meilleures ventes (les autres sont dispos en ligne)

– tous les livres sont montrés de face vs sur la tranche dans une librairie traditionnelle (torticoli garanti)

– les livres sont classés par thématique et ont tous un extrait des avis clients et les étoiles des internautes. Chaque livre est ainsi bien mis en valeur.

– au delà des thématiques, de nombreuses « aspérités » dans la présentation de l’offre sont présentes : les 100 livres qu’il faut avoir lu dans sa vie, si vous avez aimé tel livre, vous aimerez  celui là ou celui là, parmi les policiers, une sélection d’histoires vraies, … 

– et bien sûr captation de toute information via un compte client unique partagé Amazon bookshop et Amazon online.

La matinée se poursuit par une table ronde retour d’expérience sur la politique omni canal basée sur l’expérience de King Jouet d’un côté, et de la Boite à Outil de l’autre. 

Cette table ronde est également animée par Olivier Dauvers qui n’hésite jamais à challenger les visions des différents intervenants, quitte à pointer des contradictions ou des situations difficiles. 

Dans les deux cas des histoires différentes, des contextes concurrentiels différents, et des approches disctinctes sur l’apport du cross canal.

La politique de prix et d’offre entre site internet et magasin physique par exemple est traitée différemment par les deux marchands.

Enfin, la matinée se termine par un cocktail networking qui est l’occasion de rencontrer les fondateurs d’Improveeze, l’inventeur français du concept de « phygital » dans le retail, alliance du monde physique et du monde digital en magasin.

Une excellente matinée donc, tous le remerciements à Olivier Bourgeois, fondateur et délégué général du Hub Retail

Antidot Engineering practices

Software quality and robustness largely depend on the development methods in place. We can proudly say that Antidot applies state-of-the-art practices, with a constant effort to sharpen our methodology.

Software engineering

We apply state of the art techniques and good practices when coding. Our software is built using the continuous delivery paradigm.

  • Code is versioned in an internal Git source control system: all changes are logged and monitored
  • Our products are built using the latest versions of C++ , Java and Python (currently C++14, Java 8 and Python 3.5). We apply security patches and bug fixes to the third libraries that we use. Software is built using the continuous delivery paradigm
  • For every feature or bug fix, a topic branch is created. Jira epic/stories/tasks are created to track the development and our SCM tools (Gitlab CI and Jenkins) are linked to Jira.
  • A bug fix commit is not accepted without a test proving the issue is really fixed.
  • Code is written in pair mode and/or a merge request is created for review.
  • Code includes unit tests, functional tests and large tests involving all components.
  • These tests are run for every commit (several thousand tests).
  • Branches can be merged into a release branch only after review and if CI status is still ok.
  • Every commit on a release branch that leaves CI green (including large tests) creates an installation candidate. It usually takes about an hour for a valid commit to produce an installation candidate.
  • Each night additional tests that recreate a full day of production are run on the latest installation candidate, including stress and recovery tests.
  • Every week (or more often if required) we cherry pick the « best » candidate of the week (usually the latest) and deliver it to our customers (release note + updated package repository).

Code analysis

  • Code coverage and static analysis tools are frequently run (Sonar,CppCheck, SafeHTML …).
  • Penetration tools are frequently run.

DevOps

  • DevOps feedback loop provides quick feedback to developers about installation, upgrade or production issues.
  • Our Ops team can (and will) refuse to install a version if they are not confident with its quality.
  • Our Ops team uses state of the art monitoring and automated deployment tools (Puppet, Ansible, FAI …).  Our servers are regularly cleaned and reinstalled automatically.
  • Container technologies (LXD, Docker) are heavily used to isolate environments and to ensure that our software can be built, installed and run from a bare OS installation.
  • When preparing rollout of major update, DevOps transversal teams perform non-regression, performance and stress tests of the new binaries (“you build it, you run it”).
  • A/B techniques are used to progressively roll out new versions in our Cloud. Changes and user behavior are monitored in real time and can remove a new version from production if required without having the need to rollback software or databases.
  • Feature toggles enable progressive rollout of new features to selected customers.
  • HipChat rooms are used internally for efficient communication between Dev, Ops, internal Professional Services users, …

Agility

  • Teams work in Agile mode, using Scrum, Kanban or in-house mix of various Agile methods.
  • All teams use the same rhythm: iterations of 3 weeks, at the end of which retrospectives and review ceremonies are held.
  • Our managers and developers frequently attend Agile Tour meetings to challenge and update their skills.

Culture

  • Our developers are passionate, they attend several conferences per year (DockerCon, Fosdem, Devoxx …) and go to local meetups and JUGs.
  • Every week a developer talks in front of his peers of a specific technological topic (30 minutes).
  • Hackathons are held to foster innovation.
  • Frequent meetings are held between stakeholders (Product owner, Support and Professional Services managers, Pre-sales staff, Top management ….) to ensure that everybody is focused on providing value to our Customers.
  • Professional Services teams lead a review meeting after completion of customer’s projects. This review provides feedback to developers and ops, allow fine tuning of the backlogs. This also allow Support staff members to gain project knowledge.