Comment SeLoger utilise Dareboost pour surveiller ses URL éphémères

Spread the love

Aujourd’hui, nous ouvrons les portes de notre blog à Antonio Gomes Rodrigues et Benjamin Tournache de SeLoger.com, un groupe français spécialisé dans la publication de sites Internet et de journaux pour les petites annonces immobilières. Antonio est en charge des initiatives liées à la performance web et, à ce titre, il répond à des exigences commerciales et techniques très spécifiques.

Chez Groupe SeLoger, nous utilisons Dareboost pour bien des raisons : comparer les URL, surveiller la performance de nos sites Web, trouver des optimisations et valider leur implémentation, etc.

Nous industrialisons de plus en plus l’utilisation de Dareboost. Par exemple actuellement, nous envoyons un événement à Dareboost à chaque déploiement en production, campagne de test AB ou crawl SEO, mettons à jour les URLs surveillées pour nos biens immobiliers, en utilisant CircleCI, AWS Lambda, AWS CloudWatch Events et GitHub.

Dans cet article de blog, nous allons nous plonger dans notre processus pour expliquer comment nous l’avons imaginé.

Les besoins du Groupe SeLoger

Le Groupe SeLoger fait face à de nombreux défis concernant l’utilisation des outils de surveillance synthétique :

  • Certaines de nos pages sont éphémères, nous devons donc être en mesure de déterminer en permanence les pages qui sont pertinentes à tester.
  • Toutes les équipes ont des plannings spécifiques, avec des livraisons de fonctionnalités à des fréquences différentes, selon la durée de leur sprint
  • Certaines équipes gèrent plusieurs sites web et de nombreuses fonctionnalités par site
  • L’équipe de performance est trop petite et ne peut pas surveiller toute cette activité seule.

Pour atteindre nos objectifs, nous avions besoin de mettre à jour facilement et automatiquement les URLs surveillées.

Comme nos pages sont éphémères, nous devons régulièrement nous assurer, par le biais de l’automatisation, que les pages testées correspondent à un bien immobilier disponible. Nous sommes en mesure de déterminer l’URL d’une telle page, mais nous devons également pouvoir mettre à jour notre moniteur.  

Sans automatisation, nous aurions des erreurs ou pire, de mauvaises statistiques, car nos mesures seraient calculées sur différents types de pages (biens immobiliers disponibles et biens immobiliers écoulés).

Nous devions également veiller à ce que les équipes soient autonomes en ce qui concerne le suivi de la performance Web de leurs pages éphémères.

Avec notre outil précédent, l’équipe de performance devait maintenir elle-même tous les moniteurs. Cela prenait beaucoup de temps et nous faisions des erreurs.

Les équipes ont une meilleure compréhension de leur processus de déploiement et de leur code, c’est pourquoi il est plus pertinent qu’elles maintiennent leurs propres moniteurs (seulement la partie spécifique).

Nous avions aussi besoin de mutualiser le code commun à l’ensemble des équipes, tout en conservant des paramétrages spécifiques.

Dans notre outil précédent, les mesures de performance étaient initiées par l’exécution, à intervalles réguliers, d’un fichier de code. Comme chaque équipe avait des besoins spécifiques, chaque fichier était composé d’une partie commune complétée par une partie spécifique à l’équipe.

Pour éviter de maintenir un code AWS dupliqué, nous avons dû combiner le code de base dans un seul fichier et ne conserver les fichiers individuels que pour les paramètres spécifiques de chaque Feature Team.

Enfin, comme la mise à jour des URL est un processus de Production, nous avons besoin de pouvoir le monitorer.

Comment nous nous sommes organisés pour le POC

Tout d’abord, nous nous sommes assurés que Dareboost disposait d’une API permettant de modifier les URL de nos moniteurs. Comme ce n’était pas le cas, nous les avons consultés, et avons expliqué nos besoins. Peu après, une nouvelle version de leur API, qui permettait de répondre à nos besoins, a été déployée.

Ensuite, nous avons constitué une équipe motivée et multidisciplinaire.

Nos outils

Maintenant que nous avions le endpoint API, l’équipe et que cela correspondait aux pré-requis, notre tâche suivante fût de décider quels outils nous utiliserions. Un de nos objectifs était de choisir des outils parmi ceux déjà utilisés chez Groupe SeLoger. Voici les outils/produits/services choisis :

  • Pour obtenir la nouvelle URL et utiliser l’API Dareboost pour mettre à jour le moniteur : AWS Lambda.
  • Pour héberger/partager/versionner le code et les paramètres spécifiques de la Lambda : GitHub.
  • Pour déployer la Lambda : CircleCI.

Pour programmer l’exécution de la Lambda : des événements CloudWatch.

Comment nous avons fait le POC

Voici ce que fait notre Lambda :

  1. La Lambda AWS effectue la recherche sur le site web surveillé.
  2. Des résultats sont renvoyés.
  3. La Lambda se concentre sur l’élément HTML intéressant du résultat, en utilisant document.querySelector, selon un sélecteur CSS.
  4. Une fois l’élément trouvé, la Lambda extrait l’URL à partir d’un attribut HTML.
  5. La Lambda met à jour la surveillance Dareboost correspondant.
  6. Les moniteurs Dareboost sont modifiés.

Nous avions besoin d’avoir une lambda générique et d’externaliser dans un fichier tous les paramètres.

Les paramètres sont :

  • URL de recherche du site web surveillé
  • Un sélecteur CSS (cssSelector) et un attribut HTML (htmlAttribrute) permettant de retrouver l’URL du bien immobilier dans la réponse HTML
  • L’id du moniteur Dareboost (monitoringId) pour mettre à jour la surveillance
  • La clé API Dareboost (token) pour communiquer avec Dareboost

Voici un extrait du code de la Lambda :

[…]
 
function getPageDetailUrl(source, cssSelector, htmlAttribute) {
  const { document } = new JSDOM(source).window;
 
  try {
    var url = document.querySelector(cssSelector).getAttribute(htmlAttribute);
  } catch (err) {
    throw "Cannot obtain an url with this selector and attribute";
  }
 
  if (!url.length) {
    throw "No url retrieved";
  }
 
  return url;
}
 
function sendToDareboost(pageDetailUrl, monitoringId) {
  const dareUrl = "https://www.dareboost.com/api/******************";
 
  const body = JSON.stringify({
    token: token,
    monitoringId: monitoringId,
    url: pageDetailUrl
  });
 
  return fetch(dareUrl, {
    headers: {
      "Content-Type": "application/json"
    },
    body: body,
    method: "POST"
  })
    .then(response => {
      if (response.ok) {
        console.log("Dareboost API responding");
        console.log("MonitoringId:" + monitoringId);
 
[…]

Une fois la lambda en place, nous pouvons la tester sur la console AWS pour certains sites web.

Voici les paramètres :

Pour surveiller l’exécution de la Lambda, nous avons décidé d’utiliser les métriques et les logs de CloudWatch.

Comment nous l’avons automatisé

Avant d’ajouter le code source de la Lambda dans GitHub, nous avons – bien sûr – retiré la clé API Dareboost et l’avons mise dans le coffre-fort de notre compte CircleCI.

Maintenant que tous les rouages sont en place, jetons un coup d’œil sur le processus complet.

Étape 1

Un développeur ou une développeuse de la Feature Team prépare le fichier de paramètres pour configurer l’événement CloudWatch (définissant fréquence de l’exécution de la Lambda) et les paramètres d’entrée pour la Lambda.

Nous avons un fichier par surveillance Dareboost.
Voici un exemple de fichier de paramètres pour le site de Belles Demeures.

Étape 2

Le fichier est poussé sur un dépôt Github commun à toutes les Features Team, ce qui génère automatiquement une Pull Request (PR) entre la branche principale et une branche temporaire créée automatiquement par la plate-forme pour héberger cette contribution.

Voici l’organisation de notre dépôt.

Étape 3

La PR est validée, provoquant un appel à CircleCI.

Étape 4

S’il s’agit d’un nouveau fichier, un événement CloudWatch est créé par CircleCI.
Sinon, CircleCI met à jour l’événement existant (par exemple : une modification du sélecteur CSS permettant le scraping du site web).

Voici trois événements CloudWatch correspondant à trois surveillances de pages Dareboost.

Ici nous pouvons voir les 3 événements CloudWatch attachés à notre Lambda.

Étape 5

À cette étape, le déploiement de CloudWatch est terminé.
L’événement CloudWatch déclenche la Lambda avec les paramètres mis à jour.

Étape 6

L’exécution de la Lambda met à jour la surveillance de pages dans Dareboost.

Et pour la suite ?

La migration d’un outil interne vers Dareboost (passant d’un modèle « maison » à un service loué) nous a permis de :

  • libérer du temps (sauf pour la mise en place de ce processus) ;
  • gagnez en réactivité et donner plus de responsabilités aux Feature Teams
  • Corriger les erreurs du passé

L’amélioration continue est importante pour nous et nous continuerons dans cette direction en :

  • travaillant à l’automatisation de la gestion de PR spécifiques à des moniteurs
  • améliorant notre Lambda pour réduire le caractère aléatoire du choix du bien immobilier.

Antonio Gomes Rodrigues est responsable des performances applicatives des sites du Groupe SeLoger. Il accompagne les développeurs sur la mise en place des outils de supervision, test de charge, méthodologie et l’amélioration des performances. 

Benjamin Tournache est membre de l’équipe DevOps, en charge des sites filiales du Groupe SeLoger (BellesDemeures, SeLoger Neuf…) et du BtoB. Son rôle est d’accompagner les Feature Teams dans leur utilisation du cloud AWS, et de garantir l’application des “best practices” DevOps au sein de ces dernières.



Spread the love

A propos Boris Schapira

Customer Success Manager chez Dareboost, je suis aussi un développeur web, un consultant en stratégie digitale, un formateur… expliquez-moi vos problèmes de performance web ou de gouvernance et je vous aiderai à les régler. Twitter: @boostmarks |

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.