Un coup d’œil sous le capot

« Tiens, Joachim, tu n’as pas encore grand chose à faire ? Bonne nouvelle, on a un projet pour toi. »

C’est comme ça qu’Olivier, mon nouveau boss manager chef d’équipe, m’a présenté l’idée quelques jours après mon arrivée chez Gandi. L’équipe tech a envie de parler tech sur le web, et donc il faut mettre en place un blog.

Comment est-ce qu’on fait un blog en 2022 ? J’admets que j’étais resté sur mon expérience de 2006 avec un hébergement Wordpress… mais le choix s’est fait autrement : pour limiter les besoins d’infrastructure et privilégier la performance, on voulait tester un générateur de site statique. Et comme peu de gens dans l’équipe font du Go, on en a choisi un en Go. Logique.

Hugo

Un générateur de site statique a une mission : à partir de contenus écrits dans des fichiers texte, il va générer des fichiers HTML qu’on pourra placer sur un serveur web. Un bon générateur va pouvoir permettre l’utilisation d’une taxonomie (les tags tout en bas 👇), la flexibilité des thèmes, et la rapidité de prise en main.

N’ayant jamais touché à Hugo, c’est cette dernière qualité qui m’a impressionné. En deux temps et trois lignes de commande, c’était prêt… enfin, je veux dire, j’avais mon site en local avec un thème par défaut et un premier post en faux-latin. On était loin d’un site complet.

Bon, et maintenant ?

La structure multi-langues

Un des éléments dans le brief, c’était de pouvoir poster des contenus en français et en anglais. Pour ça, il faut paramétrer un peu Hugo.

Tout d’abord, on a choisi une double arborescence, en utilisant /fr/ et /en/ pour différencier les langues. Les réglages sont explicites :

# config.toml

[languages]
  [languages.en]
    title = "Gandi Blog"
    languageName = "English"
    weight = 1
    contentDir = "content/en"

  [languages.fr]
    title = "Blog Gandi"
    languageName = "français"
    weight = 2
    contentDir = "content/fr"

La langue anglaise sera servie par défaut, mais il faudra préciser que même la langue par défaut devra être servie à partir de son répertoire, et non pas à partir de la racine. Pour ça :

# config.toml

defaultContentLanguageInSubdir = true

Ça y est pour l’architecture. Pour ce qui est de l’affichage, Hugo prend tout en charge automagiquement : il faut bien utiliser les balises i18n pour traduire les morceaux d’interface dans la langue voulue. Les fichiers de traduction utilisent le format .toml, qui a l’avantage d’être lisible. Une différence lorsqu’on a dû gérer des grosses applications multilingues, c’est qu’il y a peu d’intégrations avec les outils de gestion de traduction… mais le scope d’un blog est tel que je ne pense pas qu’on dépassera la cinquantaine de termes différents à traduire.

Quand deux posts de langue différente ont le même identifiant, ils sont considérés comme une traduction l’un de l’autre. J’ai voulu faire apparaître un lien au début du post pour indiquer où trouver la traduction :

<!-- layouts/partials/page-translated-list.html -->

{{ if .IsTranslated }}
<div>
  {{ range .Translations }}
  <span lang="{{ .Lang }}">
    {{ i18n "translations" .Language.LanguageName }}
    <a href="{{ .Permalink }}">{{ .Title }}</a>
  </span>
  {{ end }}
</div>
{{ end }}

La recherche

Le choix d’un site statique a provoqué une interrogation : comment est-ce qu’on va gérer la recherche interne ? Étant donné qu’il n’y a pas de back-end dynamique qui pourrait faire des requêtes en base de donnée (et surtout vu qu’on n’a pas de base de donnée), c’est une très bonne question.

La recherche doit donc se situer du côté du client. Pour se faire, on a intégré l’utilitaire Pagefind. Lorsque Hugo vient de compiler les contenus en pages HTML, on demande à Pagefind de faire un tour sur lesdites pages pour les indexer. Ensuite, l’utilitaire va générer un script JavaScript / WASM et des fichiers d’index, qui seront mis à disposition du visiteur comme le reste du site.

Lorsque le visiteur va activer la recherche, le script se déclenchera et téléchargera les index au fur et à mesure du besoin.

Les styles

Une autre nouveauté a été mise en place pour le développement de ce blog, elle est à découvrir du côté des styles.
Depuis peu, Pascal (le développeur responsable de l’intégration du Design System) travaille sur un système de design tokens pour faciliter les échanges et la passation du design, depuis les équipes de conception jusqu’aux équipes de développement.

Pour vous proposer ses produits et services, les développeurs de Gandi sont répartis en plusieurs équipes : application de gestion de domaine, application pour les offres d’hébergement, les sites web, etc. Ces équipes ont besoin d’utiliser les mêmes éléments de design, pour maintenir l’unité de l’apparence des applications et sites web. C’est là que les design tokens montrent leur utilité : il s’agit d’informations sous forme de valeurs partagées entre les équipes. Ces tokens sont dans nos logiciels de conception graphique : un designer ne peut pas se tromper dans le choix d’une couleur ou d’une police ; ils commencent aussi à être testés dans nos apps et nos sites : ça permet aux développeurs d’avoir une seule source de vérité. Une fois le système mis en place, si la couleur principale de la marque Gandi vient à changer, il ne faudra mettre à jour qu’un fichier qui répercutera ces informations aux applications et aux sites web : le risque d’erreurs sera réduit et l’application de changements dans la charte graphique sera accélérée.

Je disais plus haut que ça commence à être testé… en effet, le site que vous lisez utilise une version alpha de ces tokens. Ils couvrent les couleurs, les tailles de typos, les hauteurs de ligne, les dimensions, les espacements, les ombres… à l’heure où j’écris cet article, ce sont 200 valeurs qui sont définies.

Ces valeurs m’ont été fournies par l’autorité centrale (enfin, par Pascal), au format CSS Custom Property. Mais pour nos projets front-end React il les exporte en variables JavaScript ou SASS. C’est là la force du système : quelle que soit la conception et le framework qui sous-tendent le projet, on peut récupérer ces tokens et les utiliser nativement.

Contribution et déploiement

Toutes ces bases-là ne sont que des bases. L’important dans un blog, c’est d’avoir du contenu, et d’être visible en public.

Permettre à l’équipe de proposer des articles…

La gestion du contenu se fait de manière flat-file, c’est à dire que toutes les informations sont contenues dans des fichiers, contenus dans une arborescence de répertoires qui les structure. Pas de base de donnée, pas de complication.

J’écris actuellement dans un fichier Markdown. Je pourrais aussi écrire dans tout un tas d’alternatives—AsciiDoc, reStructuredText, Pandoc ou HTML—et je ne doute pas qu’une ou deux personnes dans l’équipe vont contribuer en Org Mode, un format utilisé avec Emacs. Hugo pourra ensuite convertir tous ces types de contenus en pages web, générer les index, les pages d’archives, etc.

Étant donné qu’on utilise des fichiers texte, le moyen le plus pratique pour ouvrir la contribution à toute l’équipe, c’est de mettre le site en commun dans un dépôt de code. Avec Gitlab, la forge logicielle qu’on utilise, on pourra contribuer directement depuis le web, grâce à l’interface de développement intégrée.

Ces aspects techniques peuvent être un frein à la contribution, donc j’ai documenté les diverses étapes pour proposer un article. Sans ça, l’opportunité de contribuer est freinée par la difficulté de le faire.

Une fois l’article sur le dépot Git, le reste de l’équipe va pouvoir le relire, proposer des modifications si c’est nécessaire, et le valider.

…et garder le processus de déploiement le plus simple possible

L’automatisation est une bien belle chose. Depuis quelques années, les forges logicielles permettent de déclencher des actions lorsque des changements sont faits à la base de code. Ces actions peuvent être très complexes, et ont le doux nom de CI/CD (Continuous Integration/Continuous Deployment). Elles nous donnent la possibilité de tester le code, la conformité de celui-ci par rapport aux règles de style de l’équipe, de tester les fonctionnalités une à une, les tester conjointement dans un environnement de production… puis si les tests sont valides, ces actions vont nous permettre de déployer le code sur les serveurs de production.

Une fois le nouvel article sur le dépôt de code, les actions de CI/CD vont :

1. créer une machine virtuelle et y installer Hugo et les autres outils nécessaires à…
2. …compiler les contenus pour en faire un site web, comme décrit dans la partie précédente,
3. pousser le site web vers le serveur.

Comme ça, une à deux minutes après la relecture et validation par l’équipe, le site est en ligne, et visible par le public, en HTML et en RSS.

Conclusion

En tant que premier projet public depuis mon arrivée chez Gandi, je suis content d’avoir pu tester tant de nouvelles chose—nouvelles pour moi, nouvelles pour l’équipe… la possibilité d’apprendre des nouveaux concepts et des nouvelles pratiques, c’est l’une des principales raisons pour laquelle je pratique ce métier. L’autre raison c’est que ça me permet de réaliser des choses pratiques et utiles dans le respect des personnes qui les utiliseront. J’espère avoir rempli ces missions, aussi bien pour mes nouveaux et nouvelles collègues que pour vous qui lisez cet article.